[rbridge] Consensus Check: Egress processing of unicast not locally known
Eastlake III Donald-LDE008
Donald.Eastlake at motorola.com
Mon Oct 22 11:22:23 PDT 2007
Could you be more specific about your worries? I don't see that this
normally has much to do with "configuration".
This is only about the case where an ingress Rbridge receives a unicast
frame where it has learned the egress Rbridge. So it is a known unicast
which it encapsulates and sends off to the egress. The Egress Rbridge
receives this TRILL data frame, can see that it is supposed to be a
known unicast but, for whatever reason, it does not find the original
destination MAC address in its cache of learned addresses. Generally
speaking, this should be a rare occurrence. But you can imagine cases
where you could get a burst of these or cases where you have a chronic
trickle (something sending frames at an interval just slightly longer
than the address cache time out for example).
The alternatives discussed at the Chicago meeting included (1)
broadcasting the frame as an unknown unicast (presumably what 802.1D
bridges do), (2) just dropping the frame, or (3) decapsulating the frame
and sending it out on local links for which this egress Rbridge is the
DRB for the VLAN of the frame. Choice (3) was the consensus in Chicago.
Is that what you are disagreeing with?
There was also consensus in Chicago that the SHOULD do choice (3) did
not apply to a local link where the egress Rbridge knows that a station
with the destination MAC address could not be on that link. SHOULD means
you must do it unless you have a good reason not to. The release of the
"SHOULD" requirement if you know that the MAC address can't be on that
link merely gives the egress Rbridge complete freedom to act. The
consensus does NOT say that the egress Rbridge "SHOULD NOT" send the
frame on such a link. It is free to send it or not on whatever basis it
feels like and would still be in compliance with the standard. To
emphasize this, it says "This is a local decision."
Do you disagree with the consensus as explained in more detail above?
From: Dinesh G Dutt [mailto:ddutt at cisco.com]
Sent: Thursday, October 04, 2007 2:29 AM
To: Eastlake III Donald-LDE008
Cc: Rbridge at postel.org
Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not
This is different from existing IEEE 802.1D bridges. I'm OK with it, as
long as it is a MAY and not a MUST or a SHOULD. I'm worried that
misconfigurations and such can cause silent packet drops which can be
hard to debug.
Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus from the minutes of the Chicago meeting for a change from
> protocol draft -05:
> Egress RBridges that receive a known unicast TRILL data frame whose
> inner destination address is not known locally should send the
> native form of the frame out on every link for which the RBridge
> is DRB for the frame's VLAN unless it knows that an end station
> with that MAC address could not be on that link. (For example,
> there is a layer-2 registration procedure for end stations on that
> link and the destination MAC address in question is not
> registered.) This is a local decision. No "error" message will be
> defined for this condition at this time.
> If no particular controversy arises over this in the next two weeks,
> will declare it to be the working group consensus.
> Donald & Erik
> rbridge mailing list
> rbridge at postel.org
We make our world significant by the courage of our questions and by
the depth of our answers. - Carl Sagan
More information about the rbridge