[rbridge] Rbridge Protocol draft questions

[Eastlake III Donald-LDE008]

Hi,
 
See below at @@@

________________________________

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of David Melman
Sent: Monday, May 12, 2008 5:54 AM
To: rbridge at postel.org
Subject: [rbridge] Rbridge Protocol draft questions


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.
 
@@@ Yes, unknown DA, multicast, and broadcast native frames need to be
forwarded in native form out all RBridge ports where the RBridge is an
appointed forwarder for their VLAN, end station service has not been
disabled, and multicast pruning does not prune such transmission. Note
that in -07, the pseudo code dominates that text and there is a more
complete description covering more of these corner cases in Section 5.
The working group has decided that the text should dominate the pseudo
code so the text will have to be made complete.
 
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? 
 
@@@ Sure. 
 
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. 
 
@@@ I think you're right. Thanks for spotting this. At 4.4.2.2.1, if
M==1, it should just handle the frame as in 4.4.2.2.2. 
 
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? 
 
@@@ For known unicast, forwarding is based on the Egress RBridge
nickname. Transit RBridges don't learn the MAC addresses of end stations
attached to ingress and egress RBridges and have no need to do so. This
might, of course, lead you to question what a transit RBridge does with
a known unicast TRILL data frame if the egress RBridge nickname is
unknown. The answer is that there is, as yet, no provision for that
contingency in the protocol document. But presumably it silently drops
the frame (and increments some MIB variable but we haven't specified the
RBridge MIB yet).
 
Thanks
David 
 
@@@ Thanks,
@@@ Donald
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080513/716ead15/attachment.html