<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3314" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=437375903-13052008>Hi,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=437375903-13052008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=437375903-13052008>See below at @@@</SPAN></FONT></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> rbridge-bounces@postel.org
[mailto:rbridge-bounces@postel.org] <B>On Behalf Of </B>David
Melman<BR><B>Sent:</B> Monday, May 12, 2008 5:54 AM<BR><B>To:</B>
rbridge@postel.org<BR><B>Subject:</B> [rbridge] Rbridge Protocol draft
questions<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=Arial><FONT size=2><SPAN
class=074422607-12052008></SPAN></FONT></FONT><FONT face=Arial><FONT
size=2><SPAN class=074422607-12052008>In reading <FONT
face="Times New Roman"><FONT size=3>d<SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: HE">raft-ietf-trill-rbridge-protocol-07.txt,
I have some questions:</SPAN></FONT></FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><SPAN
class=074422607-12052008></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT size=+0><FONT size=2><SPAN
class=074422607-12052008>In the Forwarding Behavior of native unknown DA,
Multicast, and Broadcast frames (described in sec
4.4.1):</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=+0><FONT size=2><SPAN
class=074422607-12052008></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT size=+0><FONT size=+0><FONT face=Arial><FONT size=2><SPAN
class=074422607-12052008>1) </SPAN>If there are links for which the Rbridge is
the appointed forwarder for the VLAN, should the packet be forwarded in native
format out <SPAN class=074422607-12052008>each of those </SPAN>link<SPAN
class=074422607-12052008>s, </SPAN></FONT></FONT></FONT></FONT><FONT
size=+0><FONT size=+0><FONT face=Arial size=2>in addition to being <SPAN
class=074422607-12052008>TRILL </SPAN>encapsulated and <SPAN
class=074422607-12052008>sent on the</SPAN> multi-destination
tree? <SPAN class=074422607-12052008> 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.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=+0><FONT size=+0><FONT face=Arial><FONT
size=2></FONT></FONT></FONT></FONT> </DIV>
<DIV><SPAN class=437375903-13052008><FONT face=Arial size=2>@@@ 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.</FONT></SPAN></DIV>
<DIV><SPAN class=437375903-13052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><FONT face=Arial><FONT size=2>2<SPAN class=074422607-12052008>)
</SPAN><SPAN class=074422607-12052008>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?<SPAN
class=437375903-13052008> </SPAN></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><SPAN class=074422607-12052008><SPAN
class=437375903-13052008></SPAN></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT size=2><SPAN class=074422607-12052008><SPAN
class=437375903-13052008>@@@ Sure. </SPAN></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial size=2><SPAN
class=074422607-12052008>In the Forwarding Behavior of </SPAN> Unicast
TRILL data frames (described in sec 4.4.2.2.1):</FONT></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial><FONT size=2>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.<SPAN class=437375903-13052008><FONT
color=#0000ff> </FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial><FONT size=2><SPAN
class=437375903-13052008></SPAN></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial><FONT size=2><SPAN
class=437375903-13052008>@@@ 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.
</SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial size=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? </FONT></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=074422607-12052008><SPAN class=437375903-13052008><FONT
face=Arial size=2>@@@ 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).</FONT></SPAN></SPAN></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial size=2>David
</FONT></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><FONT face=Arial size=2></FONT></SPAN><SPAN
class=074422607-12052008><FONT face=Arial size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=074422607-12052008><SPAN class=437375903-13052008><FONT
face=Arial size=2>@@@ Thanks,</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><SPAN class=437375903-13052008><FONT
face=Arial size=2>@@@ Donald</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=074422607-12052008><SPAN class=437375903-13052008><FONT
face=Arial size=2></FONT></SPAN> </DIV></SPAN></BODY></HTML>