[rbridge] Rbridge Protocol draft questions
David Melman
davidme at marvell.com
Mon May 12 02:53:48 PDT 2008
In reading draft-ietf-trill-rbridge-protocol-07.txt, I have some
questions:
In the Forwarding Behavior of native unknown DA, Multicast, and
Broadcast frames (described in sec 4.4.1):
1) If there are links for which the Rbridge is the appointed forwarder
for the VLAN, should the packet be forwarded in native format out each
of those links, in addition to being TRILL encapsulated and sent on the
multi-destination tree? The text does not describe forwarding in
native format on the links in which the Rbridge is the appointed
forwarder for the VLAN; however the behavior is described in regards to
forwarding of TRILL multi-destination packets.
2) Might the TRILL encapsulated packet need to forwarded on more than
one link, e.g. if there are 2 or more downstream branches in the
multi-destination tree?
In the Forwarding Behavior of Unicast TRILL data frames (described in
sec 4.4.2.2.1):
1) Text says "If M==1 the frame is discarded". But in the case the
inner MAC DA is unknown in ingress Rbridge FDB, the M bit is set to 1.
So this check to verify M==1 seems to be a bug.
2) For the Transit Rbridge case (i.e. egress Rbridge nickname != local
Rbridge nickname), the text states: "the frame forwarded to the next hop
Rbridge towards the egress Rbridge using the Forwarding Database". Is
this lookup in the "Forwarding Database" based on the inner MAC DA and
inner VLAN-ID, or is it intended that the Forwarding Database lookup be
based on the Trill header Egress RBridge nickname only? If the prior,
what is the forwarding behavior in case the inner MAC DA is unknown on
the transit Rbridge - would it be similar to the native case?
Thanks
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080512/82f40ca2/attachment.html
More information about the rbridge
mailing list