Subject: [rbridge] Consensus Check: Egress processing of unicast not locally known

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 2 Oct 2007 23:25:16 -0400

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, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 3 Oct 2007 10:03:43 -0700

I'm not sure why the case of "MAC address could
not be on that link" needs to be called out at all.
That is an access control issue.  But I am OK
with having it if someone really feels strongly
about it.

Anoop 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, October 02, 2007 8:25 PM
> To: Rbridge at postel.org
> Subject: [rbridge] Consensus Check: Egress processing of 
> unicast not locallyknown
> 
> 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:
> 
> If no particular controversy arises over this in the next two 
> weeks, we will declare it to be the working group consensus.
> 
> Thanks,
> Donald & Erik
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 03 Oct 2007 23:29:26 -0700

Donald,

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.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 03 Oct 2007 23:33:08 -0700

Anoop,

Did you mean that in the example that he quoted the reason for dropping 
the frame was access control (such as 802.1x authenticated) ? To me 
access control is a very generic term that can also include things such 
as security ACLs.

"Access Control" is orthogonal to forwarding. For example, I can have IP 
FIB entries or MAC table entries associated with a frame, but can drop a 
specific frame such as those going to "port 80" as part of access 
control. What Donald is specifying *seems* to be in addition to access 
control.

Dinesh

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 6 Oct 2007 15:46:16 -0400

This is a check via the mailing list on a slight modification of an
apparent consensus from the minutes of the Chicago meeting for a change
from protocol draft -05. The tentative consensus at the Chicago meeting
was:

   It is mandatory for an RBridge to announce the bridge root that
   it sees out each physical port.

Based on mailing list discussion, I would like to tweak this as follows:

   An Rbridge MUST parse BPDUs it receives on a port and announce
   in the core IS-IS instance the bridge root that it sees out
   each port. For MSTP (Multiple Spanning Tree Protocol), this is
   the CIST (Common and Internal Spanning Tree) root.

I have a question in connection with this. What is announced for the
port if no BPDU has been received recently or ever? Should there be a
"root MAC address valid" flag per port or should there some conventional
value, like zero, which is announced?

Thanks,
Donald

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 12 Oct 2007 14:46:16 -0400

This is the last of the consensus checks 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:

   Each RBridge which is DRB for one or more VLANs out one physical
   port should announce only one pseudo-node for the port.

Please also post any other comments you have on the current -05 protocol
draft. If a revision can be posted in 3 or 4 weeks, we may be able to do
a working group last call before the December IETF TRILL meeting.

Thanks,
Donald & Erik

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 22 Oct 2007 14:22:23 -0400

Dinesh,

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?

Thanks,
Donald

-----Original Message-----
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
locally known

Donald,

Dinesh

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 26 Oct 2007 14:00:04 -0400

This consensus from the Chicago meeting has been confirmed.

Donald & Erik

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Eastlake III Donald-LDE008
Sent: Friday, October 12, 2007 2:46 PM
To: Rbridge at postel.org
Subject: [rbridge] Consensus Check: Single Pseudo-node Announcment

Thanks,
Donald & Erik