Subject: Re: [rbridge] MUST not send spanning tree BPDUs?

From: "Silvano Gai" <[email-masked]>
Date: Mon, 1 Dec 2008 07:59:57 -0800

Agreed

-- Silvano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Friday, November 28, 2008 9:37 PM
To: Donald Eastlake
Cc: [email-masked]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?

Yeah. I think we should either drop the sentence, or say "MAY generate 
BPDUs,
but MUST NOT forward BPDUs from
one link to another".

Radia

Donald Eastlake wrote:
> Hi Radia,
>
> See below...
>
> On Fri, Nov 28, 2008 at 6:31 PM, Radia Perlman <[email-masked]>
wrote:
>   
>> The spec currently says (in section 4.7.3.3 Transmission of BPDUs)
>>
>>  RBridges MAY support a capability for sending spanning tree BPDUs
for
>>   the purpose of attempting to force a bridged LAN to partition as
>>   discussed in Section A.3.3.  Except for this optional capability,
>>   RBridges MUST NOT send spanning tree BPDUs.
>>
>>
>> I don't remember any discussion on saying that RBridges MUST NOT send
>> BPDUs. I remember
>> at one point requiring it, and saying that an RBridge is DRB if and
only
>> if it is the Spanning tree Root.
>> (I still would prefer that, by the way -- makes all the controversial
>> per VLAN Hellos
>> unnecessary).
>>
>> I remember it being removed from the spec (because of complexity with
n
>> versions of
>> spanning tree, and links with no bridges, perhaps, where the spanning
>> tree messages would
>> be unnecessary overhead), but I don't remember any reason to say
>> RBridges MUST NOT sent
>> BPDUs.
>>     
>
> I suspect it used to say "do not" in the sense that there is no
> RBridge reason for an RBridge port to send spanning tree BPDUs except
> for the optional bridge LAN partitioning feature described in Section
> A.3.3. In some pass to upgrade to IETF implementation key words, it
> probably got changed when it didn't necessarily need to be. The only
> problem I can see with dropping this is that it might marginally
> increase the chance someone would erroneously try to build spanning
> trees through an RBridge.
>
> Donald
>
>   
>> Anyone else remember?
>>
>> Thanks,
>>
>> Radia
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [email-masked]
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Mon, 1 Dec 2008 17:58:14 -0800

I agree about the "MUST NOT forward BPDUs" part.

However, I think it should always be legal for an
RBridge to generate BDPUs (although not a requirement).
In many cases, this can help with loop detection
on access ports.

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> > On Fri, Nov 28, 2008 at 6:31 PM, Radia Perlman 
> <[email-masked]> wrote:
> >   
> >>  RBridges MAY support a capability for sending spanning 
> tree BPDUs for
> >> at one point requiring it, and saying that an RBridge is 
> DRB if and only
> >> I remember it being removed from the spec (because of 
> complexity with n
> >> versions of

---

From: "Donald Eastlake" <[email-masked]>
Date: Sun, 14 Dec 2008 23:07:23 -0500

Hi,

I'll go ahead and change the draft, since that seems to be what most
people want. But I don't consider it that big a deal for the following
reason:
       If you wanted to send BPDUs despite the current prohibition,
you would just say that you are implementing a virtual bridge
connected between the RBridge port and the link. That way of thinking
about it makes it crystal clear that RBridges don't participate as a
single node in spanning tree.

Saying that RBridges never forward BPDUs is good but a greater risk
would be that once someone has their RBridge ports participating in
spanning tree they might be tempted to connect the ports together so
that the RBridge as a whole participated in spanning tree. This would
result in a bigger spanning tree causing an increase in blocked ports,
which would thereby become unavailable for use by TRILL, as well as
longer spanning tree settling times, etc.

Donald

On Sun, Nov 30, 2008 at 12:00 AM, Dinesh G Dutt <[email-masked]> wrote:
> I strongly agree with dropping the sentence and adding the "MUST NOT
> forward" piece,
>
> Dinesh
> Radia Perlman wrote:
>>
>>>>  RBridges MAY support a capability for sending spanning tree BPDUs for
>>>> at one point requiring it, and saying that an RBridge is DRB if and only
>>>> I remember it being removed from the spec (because of complexity with n
>>>> versions of
> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Dec 2008 20:10:34 -0800

> single node in spanning tree.

FWIW, this is the reason for the MUST NOT. I was a proponent of
basically the perspective above; that an rbridge was a device distinct
from a bridge that was compatible with bridges, not a superset of their
functionality per se.

Joe

Date: Mon, 15 Dec 2008 20:10:34 -0800
From: Joe Touch <[email-masked]>
To: Donald Eastlake <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 4312

> single node in spanning tree.

FWIW, this is the reason for the MUST NOT. I was a proponent of
basically the perspective above; that an rbridge was a device distinct
from a bridge that was compatible with bridges, not a superset of their
functionality per se.

Joe

>> depth of our answers.                               - Carl Sagan

Date: Sun, 14 Dec 2008 23:07:23 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 3972

Hi,

Donald

Date: Sun, 14 Dec 2008 17:12:39 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 8298

Hi,

I plan to resolve this by adding a Maximum Transit Delay per RBridge
configuration parameter and state that frames which have exceeded that
time MAY be discarded.

Donald

On Mon, Dec 1, 2008 at 9:20 PM, Anoop Ghanwani <[email-masked]> wrote:
>
> I think it may be worth adding it as a MAY (or even a SHOULD).
> Bridges do actually implement this and it can happen due to
> starvation of service, either because of strict priority
> queueing (as pointed out by Donald) or because link-level
> flow control such as 802.3x is in use.
>
> For routers, according to RFC 1812
>
>  When a router forwards a packet, it MUST reduce the TTL by at least
>  one.  If it holds a packet for more than one second, it MAY decrement
>  the TTL by one for each second.
>
> We know how many people implement the optional part :-),
> but at least the issue is discussed.
>
> Anoop
>
>> [mailto:[email-masked]] On Behalf Of Donald Eastlake
>> Sent: Monday, December 01, 2008 9:55 AM
>> To: James Carlson
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge
>> Transit Delay
>>
>> Hi Jim,
>>
>> On Mon, Dec 1, 2008 at 9:15 AM, James Carlson
>> <[email-masked]> wrote:
>> > Donald Eastlake writes:
>> >> > Do modern bridges actually _implement_ such a feature,
>> or do they just
>> >> > have a knob labeled "Maximum Bridge Transit Delay"
>> that's connected to
>> >> > nothing underneath?
>> >>
>> >> It is my impression that low end 802.1D bridges don't
>> implement this
>> >> but mid and high end 802.1Q bridges do. Typically, when a frame is
>> >> received, a control block is created with the VLAN,
>> priority, time of
>> >> receipt, and other control information. When a frame is
>> de-queued for
>> >> transmission, the time is checked and frame discarded if it is too
>> >> old. This time check doesn't need to be, and probably
>> isn't, extremely
>> >> accurate.
>> >
>> > Under what conditions would that be expected to happen?
>>
>> Actually, I think I may have misstated what happens as you would want
>> old frames discarded that were just sitting around in a queue, not
>> just when they were de-queued.
>>
>> All you need is enough higher priority frames and low priority ones
>> could be queued forever even with no link ever going down and no flow
>> control impediments.
>>
>> > I suspect that one good reason to avoid bothering with such
>> a feature
>> > on high-end switches is that the amount of buffering
>> required to reach
>> > a 1 second delay at high line rates becomes prohibitive -- in other
>> > words, you'll ordinarily drop on queue entry well before
>> that happens
>> > in all but pathological cases, so why bother caring?
>>
>> Hummm, it's not clear to me what the resolution of the maximum transit
>> delay is... although 1 second is the default, the resolution could be
>> small allowing it to be set to some number of milliseconds or
>> something...
>>
>> As above, you could have a stream of, say, 1 Gbps higher priority
>> frames going from port 1 to port 3 and one lower priority frame for
>> port 3 that drifts in port 2 and this poor low priority frame could
>> just sit in a queue for days and then pop out due to a hiccup in the
>> high priority stream. I won't argue if you want to call that
>> pathological but it doesn't seem good that it could happen.
>>
>> >> > I'm inclined to say "no" to this, just on the basis that
>> I cannot see
>> >> > how it would serve any real purpose.  It looks like a
>> spec for the
>> >> > sake of a spec.
>> >>
>> >> In bridges, I think it is required to back up the assurances of
>> >> Spanning Tree Protocol. I think bridges also flush the output queue
>> >> and any input queue associated with a port when the port goes down.
>> >> Generally, it seems like good hygiene not to keep a frame
>> for a long
>> >> time and then release it...
>>
>> (As I recall, the 802.1 bridging model does not really admit that
>> input queues can exist so any frame in an input queue is logically
>> considered not to have been received yet by the bridge...)
>>
>> > We're not using STP here, though, so we don't need to back up its
>> > assurances.
>>
>> The specific provisions in 802.1D-2004 include :
>> "6.3.6 Frame lifetime
>> The MAC Service mandates an upper bound to the transit delay
>> experienced for a particular instance of
>> communication. This maximum frame lifetime is necessary to ensure the
>> correct operation of higher layer
>> protocols. ..."
>>
>> "7.1.1 Relay
>> A MAC Bridge relays individual MAC user data frames between the
>> separate MACs of the bridged LANs
>> connected to its Ports. The functions that support relaying frames and
>> maintain QoS are as follows:
>> ...
>> l) Frame discard to ensure that a maximum bridge transit delay is not
>> exceeded (6.3.6).
>> ..."
>>
>> "7.7.3 Queuing frames
>> ...
>> A frame queued for transmission on a Port shall be removed from that
>> queue if that is necessary to ensure
>> that the maximum bridge transit delay (6.3.6, Table 7-3) will not be
>> exceeded at the time at which the frame
>> would subsequently be transmitted.
>> ..."
>>
>> Similar provisions appear in 802.1Q-2005.
>>
>> > As for avoiding a too-old release, I don't think that's
>> easy to avoid
>> > with modern hardware due to the funky 802 flow control
>> mechanism.  If
>> > the other end is having trouble, you can end up with a really old
>> > frame caught in your transmission craw.  It'd require some fancy
>> > footwork in most implementations I've seen to detect that
>> sort of edge
>> > case, reset, and restart.
>> >
>> >> It would certainly be easy enough to make this a SHOULD rather than
>> >> being mandatory the way it is in 802.1, not that people seem to pay
>> >> that much attention to what is mandatory in 802.1. But perhaps it
>> >> really isn't necessary for RBridges... Anyone else have an
>> opinion on
>> >> this.
>> >
>> > That 'one second delay' smells to me too much like the old IP TTL
>> > specification, and likely dates back to the same rules of thumb.
>> >
>> > I think that SHOULD is a fairly strong statement; it means that
>> > implementors who choose not to implement that feature need to have a
>> > clear explanation of why they don't, if they're going to
>> try to follow
>> > the spirit of the RFC.  I don't think it ought to be a SHOULD unless
>> > it's something that's required for interoperability in most
>> cases, but
>> > can be avoided in a few.  As 2119 says:
>> >
>> > 3. SHOULD   This word, or the adjective "RECOMMENDED", mean
>> that there
>> >   may exist valid reasons in particular circumstances to ignore a
>> >   particular item, but the full implications must be understood and
>> >   carefully weighed before choosing a different course.
>> >
>> > Do RBridge implementors really need to weigh the pros and cons of
>> > implementing the delay time check in order to achieve
>> > interoperability?
>> >
>> > MAY is closer to the intent of saying, "here's something
>> that's common
>> > in this field and that may be helpful in an implementation, but that
>> > is not known to be required for the sake of interoperability of
>> > RBridges."
>>
>> Well, I'm OK with saying MAY. Since this is described in the 802.1
>> standards as being in the port output queue behavior, and since we now
>> incorporate that by reference unless we say otherwise, one could argue
>> that it is mandatory under the current draft. Unless people weigh in
>> with other opinions, I'll change it to MAY.
>>
>> > James Carlson, Solaris Networking
>> <[email-masked]>
>> > Sun Microsystems / 35 Network Drive        71.232W   Vox +1
>> 781 442 2084
>> > MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1
>> 781 442 1677
>>
>> Thanks,
>> Donald

-- 

Date: Thu, 11 Dec 2008 00:02:34 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] draft-eastlake-trill-rbridge-notes-01.txt
Status: RO
Content-Length: 2806

------=_Part_97282_12583811.1228971754129
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

An updated version of RBridge notes draft has been posted.

Donald

------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Rbridge Notes
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-rbridge-notes-01.txt
	Pages		: 20
	Date		: 2008-12-10
	
This document provides additional informational material related to
   RBridges, which are devices that implement the TRILL protocol. It is
   a supplement to the RBridges base protocol specification and includes
   discussion of tradeoffs in some features and configurations of
   RBridges. In addition, it provides a sketch of a proof that, with
   reasonable assumptions, persistent loops do not occur in a TRILL
   campus.

A URL for this Internet-Draft
is:http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-notes-01.txt

Internet-Drafts are also available by anonymous FTP
at:ftp://ftp.ietf.org/internet-drafts/

------=_Part_97282_12583811.1228971754129
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><h1></h1><div>An updated version of RBridge notes draft has been posted.</div><div><br></div><div>Donald</div><div><br></div><hr><pre><span class="Apple-style-span" style="font-size: small;">A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Rbridge Notes
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-rbridge-notes-01.txt
	Pages		: 20
	Date		: 2008-12-10
	
This document provides additional informational material related to
   RBridges, which are devices that implement the TRILL protocol. It is
   a supplement to the RBridges base protocol specification and includes
   discussion of tradeoffs in some features and configurations of
   RBridges. In addition, it provides a sketch of a proof that, with
   reasonable assumptions, persistent loops do not occur in a TRILL
   campus.

A URL for this Internet-Draft is:
</span><a rel="nofollow" href="http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-notes-01.txt"><span class="Apple-style-span" style="font-size: small;">http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-notes-01.txt</span></a><span class="Apple-style-span" style="font-size: small;">

Internet-Drafts are also available by anonymous FTP at:
</span><a rel="nofollow" href="ftp://ftp.ietf.org/internet-drafts/"><span class="Apple-style-span" style="font-size: small;">ftp://ftp.ietf.org/internet-drafts/</span></a></pre></span>

------=_Part_97282_12583811.1228971754129--

Date: Wed, 10 Dec 2008 22:54:14 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft Minneapolis minutes uploaded
Status: RO
Content-Length: 1908

------=_Part_96850_7817761.1228967655029
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Slightly expanded minutes have been uploaded. As before,
corrections/comments welcome,Donald

On Mon, Dec 1, 2008 at 11:10 PM, Donald Eastlake <[email-masked]> wrote:

> Hi,
>
> Draft minutes of the TRILL WG meeting in Minneapolis last month have
> been uploaded and are available on the Meeting Materials page:
>
>     https://datatracker.ietf.org/meeting/73/materials.html
>
> Corrections/comments welcome,
> Donald

------=_Part_96850_7817761.1228967655029
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Slightly expanded minutes have been uploaded. As before, corrections/comments welcome,<div>Donald<br><br><div class="gmail_quote">On Mon, Dec 1, 2008 at 11:10 PM, Donald Eastlake <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Draft minutes of the TRILL WG meeting in Minneapolis last month have<br>
been uploaded and are available on the Meeting Materials page:<br>
<br>
 &nbsp; &nbsp; <a href="https://datatracker.ietf.org/meeting/73/materials.html" target="_blank">https://datatracker.ietf.org/meeting/73/materials.html</a><br>
<br>
Corrections/comments welcome,<br>
Donald<br>
=============================<br>
&nbsp;Donald E. Eastlake 3rd &nbsp; +1-508-634-2066 (home)<br>
&nbsp;155 Beaver Street<br>
&nbsp;Milford, MA 01757 USA<br>
&nbsp;<a href="mailto:[email-masked]">[email-masked]</a><br>
</blockquote></div><br>
</div>

------=_Part_96850_7817761.1228967655029--

Date: Tue, 02 Dec 2008 09:23:03 -0800
From: Dinesh G Dutt <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: Donald Eastlake <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
Status: RO
Content-Length: 6101

To follow the analogy of SVLAN BPDUs and the behavior of CVLAN BPDUs in 
an SVLAN cloud, since the CVLAN BPDUs are treated as data by the SVLAN 
bridges, the SVLAN Rbridge would encapsulate the CVLAN IS-IS (which has 
a different MAC address than SVLAN IS-IS) in a TRILL header while 
transporting it through the provider RBridge cloud. This will work fine 
without having to reserve a bunch of MAC addresses.

Dinesh
Anoop Ghanwani wrote:
> Donald, 
>
> With respect to the example you mention below...
>
> It is true that the BPDUs from C-VLAN Bridges are
> treated as data by S-VLAN Bridges, but they have 
> an S-tag in them when transported over provider
> bridges.  In our case, if we wanted to
> design such a hierarchy, we would have to depend
> on the TRILL header to separate traffic from
> different belonging to different "customers"
> including the control traffic.  In other words,
> we would have no choice but to encapsulate the
> customer IS-IS frames with a TRILL header.
>
> In any case, as I stated earlier, I don't see
> it hurting anything to reserve the block of MAC
> addresses.
>
> Anoop
>
>   
>> From: Donald Eastlake [mailto:[email-masked]] 
>> Sent: Monday, December 01, 2008 7:58 PM
>> To: Anoop Ghanwani
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
>>
>> Hi Anoop,
>>
>> On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani 
>> <[email-masked]> wrote:
>>     
>>> It probably wouldn't hurt, but I'm not sure that this is at 
>>>       
>> all necessary.
>>     
>>> Other than the core IS-IS instance, all other frames have a TRILL
>>> header and we can control forwarding behavior using those contents
>>> (and we have already reserved NickName values for that purpose).
>>> In future, if we define anything that we don't want to be forwarded
>>> by RBridges, we can always force it to have the TRILL header.
>>> So we are not dependent on MAC addresses...
>>>       
>> You are probably right that you could figure out some way to do
>> whatever you wanted with reserved nick names or other tweaking of the
>> TRILL header but it might not be very simple or efficient.
>>
>> Just as an example, if you wanted to specify Provider RBridges that
>> related to the current RBridge specification the same way Provider
>> Bridges relate to customer Bridges, one obvious way to do this would
>> include a new multicast address (All-Provider-IS-IS-RBridges?) for
>> provider core IS-IS messages, they same way Provider Bridges use a
>> different multicast address for their BPDUs and, as I understand it,
>> simply forward customer Bridge BPDUs...
>>
>> This could alternatively be done as you suggest, but that would
>> require encapsulating the Provider RBridge IS-IS messages with a funny
>> TRILL Header and, I think, some people on this list really like
>> dispatching on the multicast address and don't like encapsulating
>> IS-IS...
>>
>> Donald
>>
>>     
>>> Anoop
>>>
>>> ________________________________
>> [mailto:[email-masked]] On
>>     
>>> Behalf Of Donald Eastlake
>>> Sent: Wednesday, November 26, 2008 2:09 PM
>>> To: Developing a hybrid router/bridge.
>>> Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses
>>>
>>> Hi,
>>> When TRILL started, it had only one multicast address: 
>>>       
>> All-RBridges. Then it
>>     
>>> was decided that encapsulated IS-IS frames would have an 
>>>       
>> Inner.MacDA of
>>     
>>> All-IS-IS-RBridges and there were two. Now there are three multicast
>>> address: (1) IS-IS frames are not longer encapsulated
>>> and  All-IS-IS-RBridges is their Outer.MacDA, (2) 
>>>       
>> All-RBridges is the
>>     
>>> Outer.MacDA for ESADI and multi-destination data frames, and (3)
>>> All-ESADI-RBridges is the Inner.MacDA for ESADI frames.
>>> I don't think we are going to need any more than these 
>>>       
>> three multicast
>>     
>>> addresses for the Base Protocol Specification but multicast 
>>>       
>> addresses are
>>     
>>> cheap. 802.1 initially allocated itself a block of 16 
>>>       
>> addresses for bridging
>>     
>>> and link protocols (see, for example, 802.1D-2004 Figure 
>>>       
>> 7-10 or the more
>>     
>>> recent 802.1Q-2005 Table 8-1) with the defined behavior 
>>>       
>> being that a bridge
>>     
>>> was required to drop any frame sent to one of these 
>>>       
>> addresses if the bridge
>>     
>>> did not understand the protocol(s) indicated by that 
>>>       
>> address. This sort of
>>     
>>> behavior has to be specified at the beginning. Once you 
>>>       
>> start shipping
>>     
>>> devices that are transparent to some addresses, you can't 
>>>       
>> practically later
>>     
>>> say they have to drop them if they don't know the 
>>>       
>> protocol(s) associated
>>     
>>> with those addresses. (This behavior for bridges has been 
>>>       
>> somewhat modified
>>     
>>> for more recent complicated cases like provider bridging.)
>>> So, I propose that, when we apply, we get a block of 16 
>>>       
>> addresses with the
>>     
>>> ones listed in the first paragraph above being the first 
>>>       
>> three addresses in
>>     
>>> this block and the remaining 13 being reserved for future 
>>>       
>> use. And that the
>>     
>>> protocol specification require RBridges to drop frames with 
>>>       
>> Outer.MacDA
>>     
>>> being any of these 13 addresses (unless the RBridge 
>>>       
>> understands some future
>>     
>>> use of that address).
>>>
>>> Thanks,
>>> Donald

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

Content-class: urn:content-classes:message
Date: Mon, 1 Dec 2008 23:31:39 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Donald Eastlake" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
Status: RO
Content-Length: 4847

Donald, 

With respect to the example you mention below...

It is true that the BPDUs from C-VLAN Bridges are
treated as data by S-VLAN Bridges, but they have 
an S-tag in them when transported over provider
bridges.  In our case, if we wanted to
design such a hierarchy, we would have to depend
on the TRILL header to separate traffic from
different belonging to different "customers"
including the control traffic.  In other words,
we would have no choice but to encapsulate the
customer IS-IS frames with a TRILL header.

In any case, as I stated earlier, I don't see
it hurting anything to reserve the block of MAC
addresses.

Anoop

> From: Donald Eastlake [mailto:[email-masked]] 
> Sent: Monday, December 01, 2008 7:58 PM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
> 
> Hi Anoop,
> 
> On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani 
> <[email-masked]> wrote:
> > It probably wouldn't hurt, but I'm not sure that this is at 
> all necessary.
> >
> > Other than the core IS-IS instance, all other frames have a TRILL
> > header and we can control forwarding behavior using those contents
> > (and we have already reserved NickName values for that purpose).
> > In future, if we define anything that we don't want to be forwarded
> > by RBridges, we can always force it to have the TRILL header.
> > So we are not dependent on MAC addresses...
> 
> You are probably right that you could figure out some way to do
> whatever you wanted with reserved nick names or other tweaking of the
> TRILL header but it might not be very simple or efficient.
> 
> Just as an example, if you wanted to specify Provider RBridges that
> related to the current RBridge specification the same way Provider
> Bridges relate to customer Bridges, one obvious way to do this would
> include a new multicast address (All-Provider-IS-IS-RBridges?) for
> provider core IS-IS messages, they same way Provider Bridges use a
> different multicast address for their BPDUs and, as I understand it,
> simply forward customer Bridge BPDUs...
> 
> This could alternatively be done as you suggest, but that would
> require encapsulating the Provider RBridge IS-IS messages with a funny
> TRILL Header and, I think, some people on this list really like
> dispatching on the multicast address and don't like encapsulating
> IS-IS...
> 
> Donald
> 
> > Anoop
> >
> > ________________________________
> [mailto:[email-masked]] On
> > Behalf Of Donald Eastlake
> > Sent: Wednesday, November 26, 2008 2:09 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses
> >
> > Hi,
> > When TRILL started, it had only one multicast address: 
> All-RBridges. Then it
> > was decided that encapsulated IS-IS frames would have an 
> Inner.MacDA of
> > All-IS-IS-RBridges and there were two. Now there are three multicast
> > address: (1) IS-IS frames are not longer encapsulated
> > and  All-IS-IS-RBridges is their Outer.MacDA, (2) 
> All-RBridges is the
> > Outer.MacDA for ESADI and multi-destination data frames, and (3)
> > All-ESADI-RBridges is the Inner.MacDA for ESADI frames.
> > I don't think we are going to need any more than these 
> three multicast
> > addresses for the Base Protocol Specification but multicast 
> addresses are
> > cheap. 802.1 initially allocated itself a block of 16 
> addresses for bridging
> > and link protocols (see, for example, 802.1D-2004 Figure 
> 7-10 or the more
> > recent 802.1Q-2005 Table 8-1) with the defined behavior 
> being that a bridge
> > was required to drop any frame sent to one of these 
> addresses if the bridge
> > did not understand the protocol(s) indicated by that 
> address. This sort of
> > behavior has to be specified at the beginning. Once you 
> start shipping
> > devices that are transparent to some addresses, you can't 
> practically later
> > say they have to drop them if they don't know the 
> protocol(s) associated
> > with those addresses. (This behavior for bridges has been 
> somewhat modified
> > for more recent complicated cases like provider bridging.)
> > So, I propose that, when we apply, we get a block of 16 
> addresses with the
> > ones listed in the first paragraph above being the first 
> three addresses in
> > this block and the remaining 13 being reserved for future 
> use. And that the
> > protocol specification require RBridges to drop frames with 
> Outer.MacDA
> > being any of these 13 addresses (unless the RBridge 
> understands some future
> > use of that address).
> >
> > Thanks,
> > Donald

Date: Mon, 1 Dec 2008 23:10:44 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Draft Minneapolis minutes uploaded
Status: RO
Content-Length: 375

Hi,

Draft minutes of the TRILL WG meeting in Minneapolis last month have
been uploaded and are available on the Meeting Materials page:

     https://datatracker.ietf.org/meeting/73/materials.html

Corrections/comments welcome,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

Date: Mon, 1 Dec 2008 22:57:35 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
Status: RO
Content-Length: 3733

Hi Anoop,

On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani <[email-masked]> wrote:
> It probably wouldn't hurt, but I'm not sure that this is at all necessary.
>
> Other than the core IS-IS instance, all other frames have a TRILL
> header and we can control forwarding behavior using those contents
> (and we have already reserved NickName values for that purpose).
> In future, if we define anything that we don't want to be forwarded
> by RBridges, we can always force it to have the TRILL header.
> So we are not dependent on MAC addresses...

You are probably right that you could figure out some way to do
whatever you wanted with reserved nick names or other tweaking of the
TRILL header but it might not be very simple or efficient.

Just as an example, if you wanted to specify Provider RBridges that
related to the current RBridge specification the same way Provider
Bridges relate to customer Bridges, one obvious way to do this would
include a new multicast address (All-Provider-IS-IS-RBridges?) for
provider core IS-IS messages, they same way Provider Bridges use a
different multicast address for their BPDUs and, as I understand it,
simply forward customer Bridge BPDUs...

This could alternatively be done as you suggest, but that would
require encapsulating the Provider RBridge IS-IS messages with a funny
TRILL Header and, I think, some people on this list really like
dispatching on the multicast address and don't like encapsulating
IS-IS...

Donald

> Anoop
>
> ________________________________
> Behalf Of Donald Eastlake
> Sent: Wednesday, November 26, 2008 2:09 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses
>
> Hi,
> When TRILL started, it had only one multicast address: All-RBridges. Then it
> was decided that encapsulated IS-IS frames would have an Inner.MacDA of
> All-IS-IS-RBridges and there were two. Now there are three multicast
> address: (1) IS-IS frames are not longer encapsulated
> and  All-IS-IS-RBridges is their Outer.MacDA, (2) All-RBridges is the
> Outer.MacDA for ESADI and multi-destination data frames, and (3)
> All-ESADI-RBridges is the Inner.MacDA for ESADI frames.
> I don't think we are going to need any more than these three multicast
> addresses for the Base Protocol Specification but multicast addresses are
> cheap. 802.1 initially allocated itself a block of 16 addresses for bridging
> and link protocols (see, for example, 802.1D-2004 Figure 7-10 or the more
> recent 802.1Q-2005 Table 8-1) with the defined behavior being that a bridge
> was required to drop any frame sent to one of these addresses if the bridge
> did not understand the protocol(s) indicated by that address. This sort of
> behavior has to be specified at the beginning. Once you start shipping
> devices that are transparent to some addresses, you can't practically later
> say they have to drop them if they don't know the protocol(s) associated
> with those addresses. (This behavior for bridges has been somewhat modified
> for more recent complicated cases like provider bridging.)
> So, I propose that, when we apply, we get a block of 16 addresses with the
> ones listed in the first paragraph above being the first three addresses in
> this block and the remaining 13 being reserved for future use. And that the
> protocol specification require RBridges to drop frames with Outer.MacDA
> being any of these 13 addresses (unless the RBridge understands some future
> use of that address).
>
> Thanks,
> Donald

Content-class: urn:content-classes:message
Date: Mon, 1 Dec 2008 18:27:32 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Donald Eastlake" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
Status: RO
Content-Length: 8327

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95425.8FAA87C9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It probably wouldn't hurt, but I'm not sure that this is at all
necessary.
=20
Other than the core IS-IS instance, all other frames have a TRILL
header and we can control forwarding behavior using those contents
(and we have already reserved NickName values for that purpose). =20
In future, if we define anything that we don't want to be forwarded=20
by RBridges, we can always force it to have the TRILL header.
So we are not dependent on MAC addresses...
=20
Anoop

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Donald Eastlake
	Sent: Wednesday, November 26, 2008 2:09 PM
	To: Developing a hybrid router/bridge.
	Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses
=09
=09
	Hi,=20

	When TRILL started, it had only one multicast address:
All-RBridges. Then it was decided that encapsulated IS-IS frames would
have an Inner.MacDA of All-IS-IS-RBridges and there were two. Now there
are three multicast address: (1) IS-IS frames are not longer
encapsulated and  All-IS-IS-RBridges is their Outer.MacDA, (2)
All-RBridges is the Outer.MacDA for ESADI and multi-destination data
frames, and (3) All-ESADI-RBridges is the Inner.MacDA for ESADI frames.

	I don't think we are going to need any more than these three
multicast addresses for the Base Protocol Specification but multicast
addresses are cheap. 802.1 initially allocated itself a block of 16
addresses for bridging and link protocols (see, for example, 802.1D-2004
Figure 7-10 or the more recent 802.1Q-2005 Table 8-1) with the defined
behavior being that a bridge was required to drop any frame sent to one
of these addresses if the bridge did not understand the protocol(s)
indicated by that address. This sort of behavior has to be specified at
the beginning. Once you start shipping devices that are transparent to
some addresses, you can't practically later say they have to drop them
if they don't know the protocol(s) associated with those addresses.
(This behavior for bridges has been somewhat modified for more recent
complicated cases like provider bridging.)=20

	So, I propose that, when we apply, we get a block of 16
addresses with the ones listed in the first paragraph above being the
first three addresses in this block and the remaining 13 being reserved
for future use. And that the protocol specification require RBridges to
drop frames with Outer.MacDA being any of these 13 addresses (unless the
RBridge understands some future use of that address).
=09
=09
	Thanks,
	Donald
	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
	Donald E. Eastlake 3rd   +1-508-634-2066 (home)
	155 Beaver Street
	Milford, MA 01757 USA
	[email-masked]
=09

------_=_NextPart_001_01C95425.8FAA87C9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>It probably wouldn't hurt, but I'm not sure =
that this is at=20
all necessary.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Other than the core IS-IS instance, all other =
frames have a=20
TRILL</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>header and we can control forwarding behavior =
using those=20
contents</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>(and we have already reserved NickName values =
for that=20
purpose).&nbsp; </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>In future, if we define </FONT></SPAN><SPAN=20
class=3D937022102-02122008><FONT face=3DArial color=3D#0000ff =
size=3D2>anything that we=20
don't want to be forwarded </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>by RBridges, we can </FONT></SPAN><SPAN=20
class=3D937022102-02122008><FONT face=3DArial color=3D#0000ff =
size=3D2>always force it=20
to have the TRILL header.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>So we are not dependent on MAC=20
addresses...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D937022102-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Anoop</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Donald=20
  Eastlake<BR><B>Sent:</B> Wednesday, November 26, 2008 2:09 =
PM<BR><B>To:</B>=20
  Developing a hybrid router/bridge.<BR><B>Subject:</B> [rbridge] draft=20
  protocol-10 WGLC Multicast Addresses<BR></FONT><BR></DIV>
  <DIV></DIV>Hi,
  <DIV><BR></DIV>
  <DIV>When TRILL started, it had only one multicast address: =
All-RBridges. Then=20
  it was decided that encapsulated IS-IS frames would have an =
Inner.MacDA of=20
  All-IS-IS-RBridges and there were two. Now there are three multicast =
address:=20
  (1) IS-IS frames are not longer encapsulated =
and&nbsp;&nbsp;All-IS-IS-RBridges=20
  is their Outer.MacDA, (2) All-RBridges is the Outer.MacDA =
for&nbsp;ESADI=20
  and&nbsp;multi-destination data frames, and (3) All-ESADI-RBridges is =
the=20
  Inner.MacDA for ESADI frames.</DIV>
  <DIV><BR>
  <DIV>I don't think we are going to need any more than these three =
multicast=20
  addresses for the Base Protocol Specification but multicast addresses =
are=20
  cheap. 802.1 initially allocated itself a block of 16 addresses for =
bridging=20
  and link protocols (see, for example, 802.1D-2004 Figure 7-10 or the =
more=20
  recent 802.1Q-2005 Table 8-1) with the defined behavior being that a =
bridge=20
  was required to drop any frame sent to one of these addresses if the =
bridge=20
  did not understand the protocol(s) indicated by that =
address.&nbsp;This sort=20
  of behavior has to be specified at the beginning. Once you start =
shipping=20
  devices that are transparent to some addresses, you can't practically =
later=20
  say they have to drop them if they don't know the protocol(s) =
associated with=20
  those addresses.&nbsp;(This behavior for bridges has been somewhat =
modified=20
  for more recent complicated cases like provider bridging.)&nbsp;</DIV>
  <DIV>
  <DIV><BR></DIV>
  <DIV>So, I propose that, when we apply, we get a block of 16 addresses =
with=20
  the ones listed in the first paragraph above being the first three =
addresses=20
  in this block and the remaining 13 being reserved for future use. And =
that the=20
  protocol specification require RBridges to drop frames with =
Outer.MacDA being=20
  any of these 13 addresses (unless the RBridge understands some future =
use of=20
  that address).<BR><BR></DIV>
  <DIV>Thanks,</DIV>
  =
<DIV>Donald<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Donald E. Eastlake 3rd &nbsp;=20
  +1-508-634-2066 (home)<BR>155 Beaver Street<BR>Milford, MA 01757 =
USA<BR><A=20
  href=3D"mailto:[email-masked]"=20
  =
target=3D_blank>[email-masked]</A><BR></DIV></DIV></DIV></BLOCKQUOTE></=
BODY></HTML>

------_=_NextPart_001_01C95425.8FAA87C9--

Content-class: urn:content-classes:message
Date: Mon, 1 Dec 2008 18:20:04 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Donald Eastlake" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 7752

I think it may be worth adding it as a MAY (or even a SHOULD).
Bridges do actually implement this and it can happen due to 
starvation of service, either because of strict priority 
queueing (as pointed out by Donald) or because link-level 
flow control such as 802.3x is in use.

For routers, according to RFC 1812

  When a router forwards a packet, it MUST reduce the TTL by at least
  one.  If it holds a packet for more than one second, it MAY decrement
  the TTL by one for each second.

We know how many people implement the optional part :-),
but at least the issue is discussed.

Anoop

> [mailto:[email-masked]] On Behalf Of Donald Eastlake
> Sent: Monday, December 01, 2008 9:55 AM
> To: James Carlson
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge 
> Transit Delay
> 
> Hi Jim,
> 
> On Mon, Dec 1, 2008 at 9:15 AM, James Carlson 
> <[email-masked]> wrote:
> > Donald Eastlake writes:
> >> > Do modern bridges actually _implement_ such a feature, 
> or do they just
> >> > have a knob labeled "Maximum Bridge Transit Delay" 
> that's connected to
> >> > nothing underneath?
> >>
> >> It is my impression that low end 802.1D bridges don't 
> implement this
> >> but mid and high end 802.1Q bridges do. Typically, when a frame is
> >> received, a control block is created with the VLAN, 
> priority, time of
> >> receipt, and other control information. When a frame is 
> de-queued for
> >> transmission, the time is checked and frame discarded if it is too
> >> old. This time check doesn't need to be, and probably 
> isn't, extremely
> >> accurate.
> >
> > Under what conditions would that be expected to happen?
> 
> Actually, I think I may have misstated what happens as you would want
> old frames discarded that were just sitting around in a queue, not
> just when they were de-queued.
> 
> All you need is enough higher priority frames and low priority ones
> could be queued forever even with no link ever going down and no flow
> control impediments.
> 
> > I suspect that one good reason to avoid bothering with such 
> a feature
> > on high-end switches is that the amount of buffering 
> required to reach
> > a 1 second delay at high line rates becomes prohibitive -- in other
> > words, you'll ordinarily drop on queue entry well before 
> that happens
> > in all but pathological cases, so why bother caring?
> 
> Hummm, it's not clear to me what the resolution of the maximum transit
> delay is... although 1 second is the default, the resolution could be
> small allowing it to be set to some number of milliseconds or
> something...
> 
> As above, you could have a stream of, say, 1 Gbps higher priority
> frames going from port 1 to port 3 and one lower priority frame for
> port 3 that drifts in port 2 and this poor low priority frame could
> just sit in a queue for days and then pop out due to a hiccup in the
> high priority stream. I won't argue if you want to call that
> pathological but it doesn't seem good that it could happen.
> 
> >> > I'm inclined to say "no" to this, just on the basis that 
> I cannot see
> >> > how it would serve any real purpose.  It looks like a 
> spec for the
> >> > sake of a spec.
> >>
> >> In bridges, I think it is required to back up the assurances of
> >> Spanning Tree Protocol. I think bridges also flush the output queue
> >> and any input queue associated with a port when the port goes down.
> >> Generally, it seems like good hygiene not to keep a frame 
> for a long
> >> time and then release it...
> 
> (As I recall, the 802.1 bridging model does not really admit that
> input queues can exist so any frame in an input queue is logically
> considered not to have been received yet by the bridge...)
> 
> > We're not using STP here, though, so we don't need to back up its
> > assurances.
> 
> The specific provisions in 802.1D-2004 include :
> "6.3.6 Frame lifetime
> The MAC Service mandates an upper bound to the transit delay
> experienced for a particular instance of
> communication. This maximum frame lifetime is necessary to ensure the
> correct operation of higher layer
> protocols. ..."
> 
> "7.1.1 Relay
> A MAC Bridge relays individual MAC user data frames between the
> separate MACs of the bridged LANs
> connected to its Ports. The functions that support relaying frames and
> maintain QoS are as follows:
> ...
> l) Frame discard to ensure that a maximum bridge transit delay is not
> exceeded (6.3.6).
> ..."
> 
> "7.7.3 Queuing frames
> ...
> A frame queued for transmission on a Port shall be removed from that
> queue if that is necessary to ensure
> that the maximum bridge transit delay (6.3.6, Table 7-3) will not be
> exceeded at the time at which the frame
> would subsequently be transmitted.
> ..."
> 
> Similar provisions appear in 802.1Q-2005.
> 
> > As for avoiding a too-old release, I don't think that's 
> easy to avoid
> > with modern hardware due to the funky 802 flow control 
> mechanism.  If
> > the other end is having trouble, you can end up with a really old
> > frame caught in your transmission craw.  It'd require some fancy
> > footwork in most implementations I've seen to detect that 
> sort of edge
> > case, reset, and restart.
> >
> >> It would certainly be easy enough to make this a SHOULD rather than
> >> being mandatory the way it is in 802.1, not that people seem to pay
> >> that much attention to what is mandatory in 802.1. But perhaps it
> >> really isn't necessary for RBridges... Anyone else have an 
> opinion on
> >> this.
> >
> > That 'one second delay' smells to me too much like the old IP TTL
> > specification, and likely dates back to the same rules of thumb.
> >
> > I think that SHOULD is a fairly strong statement; it means that
> > implementors who choose not to implement that feature need to have a
> > clear explanation of why they don't, if they're going to 
> try to follow
> > the spirit of the RFC.  I don't think it ought to be a SHOULD unless
> > it's something that's required for interoperability in most 
> cases, but
> > can be avoided in a few.  As 2119 says:
> >
> > 3. SHOULD   This word, or the adjective "RECOMMENDED", mean 
> that there
> >   may exist valid reasons in particular circumstances to ignore a
> >   particular item, but the full implications must be understood and
> >   carefully weighed before choosing a different course.
> >
> > Do RBridge implementors really need to weigh the pros and cons of
> > implementing the delay time check in order to achieve
> > interoperability?
> >
> > MAY is closer to the intent of saying, "here's something 
> that's common
> > in this field and that may be helpful in an implementation, but that
> > is not known to be required for the sake of interoperability of
> > RBridges."
> 
> Well, I'm OK with saying MAY. Since this is described in the 802.1
> standards as being in the port output queue behavior, and since we now
> incorporate that by reference unless we say otherwise, one could argue
> that it is mandatory under the current draft. Unless people weigh in
> with other opinions, I'll change it to MAY.
> 
> > James Carlson, Solaris Networking              
> <[email-masked]>
> > Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> > MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 
> Thanks,
> Donald

Content-class: urn:content-classes:message
Date: Mon, 1 Dec 2008 17:58:14 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Donald Eastlake" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 3125

Anoop

> > trees through an RBridge.

Date: Mon, 1 Dec 2008 14:32:46 -0500
From: "Donald Eastlake" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 2594

Hi Jim,

On Mon, Dec 1, 2008 at 1:27 PM, James Carlson <[email-masked]> wrote:
> Donald Eastlake writes:
...
>> The specific provisions in 802.1D-2004 include :
>> "6.3.6 Frame lifetime
>> The MAC Service mandates an upper bound to the transit delay
>> experienced for a particular instance of
>> communication. This maximum frame lifetime is necessary to ensure the
>> correct operation of higher layer
>> protocols. ..."
>
> If there's no limit on the number of bridges that may be encountered
> in transit, and no limit on the speed-of-light delays between nodes,
> then I think there's little that this transit delay limit does to
> protect those upper layer protocols.

Seems like good points. I'm not aware of any hops limit for bridges
like the 7 level limit for hubs.

> It limits variance in some cases, at the cost of higher loss, but
> that's about it; it can't practically set any upper limit.  (For a
> worst-case scenario, consider two adjacent nodes that are unable to
> use a shared link due to redundancy elsewhere in the network.  Failure
> of that redundancy can bring up that low-latency link, and restoring
> the far-away link tears it down again.  The variance in that case may
> be predictable if you know the entire topology, but it's arbitrarily
> large.)
>
...
>> Well, I'm OK with saying MAY. Since this is described in the 802.1
>> standards as being in the port output queue behavior, and since we now
>> incorporate that by reference unless we say otherwise, one could argue
>> that it is mandatory under the current draft. Unless people weigh in
>> with other opinions, I'll change it to MAY.
>
> That seems fine.  (If we're incorporating all of 802.1 by reference,
> do we need to restate much of it ... ?)

Not much of it. But, since we are essentially incorporating a snapshot
of the 802.1Q port processing below the EISS layer, I think we need to
say how we differ from 802.1Q in that area. Currently, the protocol
spec just says we differ for BPDUs and VLAN registration protocols.
Although it seems like a minor difference in practice, if enforcement
of a maximum bridge transit delay is a MAY rather than being mandatory
as it is in 802.1, I think we should say so.

Thanks,
Donald

> James Carlson, Solaris Networking              <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Date: Mon, 1 Dec 2008 13:27:07 -0500
From: James Carlson <[email-masked]>
To: Donald Eastlake <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 3187

Donald Eastlake writes:
> On Mon, Dec 1, 2008 at 9:15 AM, James Carlson <[email-masked]> wrote:
> > I suspect that one good reason to avoid bothering with such a feature
> > on high-end switches is that the amount of buffering required to reach
> > a 1 second delay at high line rates becomes prohibitive -- in other
> > words, you'll ordinarily drop on queue entry well before that happens
> > in all but pathological cases, so why bother caring?
> 
> Hummm, it's not clear to me what the resolution of the maximum transit
> delay is... although 1 second is the default, the resolution could be
> small allowing it to be set to some number of milliseconds or
> something...

Actually, I wasn't talking about the resolution, but rather just the
amount of buffering you'd need at a single priority level to queue
across that much delay anywhere and not begin dropping.

> As above, you could have a stream of, say, 1 Gbps higher priority
> frames going from port 1 to port 3 and one lower priority frame for
> port 3 that drifts in port 2 and this poor low priority frame could
> just sit in a queue for days and then pop out due to a hiccup in the
> high priority stream. I won't argue if you want to call that
> pathological but it doesn't seem good that it could happen.

Yes, I'd call that pathological, but, ok, point taken.

> The specific provisions in 802.1D-2004 include :
> "6.3.6 Frame lifetime
> The MAC Service mandates an upper bound to the transit delay
> experienced for a particular instance of
> communication. This maximum frame lifetime is necessary to ensure the
> correct operation of higher layer
> protocols. ..."

If there's no limit on the number of bridges that may be encountered
in transit, and no limit on the speed-of-light delays between nodes,
then I think there's little that this transit delay limit does to
protect those upper layer protocols.

It limits variance in some cases, at the cost of higher loss, but
that's about it; it can't practically set any upper limit.  (For a
worst-case scenario, consider two adjacent nodes that are unable to
use a shared link due to redundancy elsewhere in the network.  Failure
of that redundancy can bring up that low-latency link, and restoring
the far-away link tears it down again.  The variance in that case may
be predictable if you know the entire topology, but it's arbitrarily
large.)

> Similar provisions appear in 802.1Q-2005.

Yep; I saw them.  I wasn't questioning whether they're there, but
whether they do any real good.

> Well, I'm OK with saying MAY. Since this is described in the 802.1
> standards as being in the port output queue behavior, and since we now
> incorporate that by reference unless we say otherwise, one could argue
> that it is mandatory under the current draft. Unless people weigh in
> with other opinions, I'll change it to MAY.

That seems fine.  (If we're incorporating all of 802.1 by reference,
do we need to restate much of it ... ?)

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Date: Mon, 1 Dec 2008 12:55:23 -0500
From: "Donald Eastlake" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 6326

Hi Jim,

On Mon, Dec 1, 2008 at 9:15 AM, James Carlson <[email-masked]> wrote:
> Donald Eastlake writes:
>> > Do modern bridges actually _implement_ such a feature, or do they just
>> > have a knob labeled "Maximum Bridge Transit Delay" that's connected to
>> > nothing underneath?
>>
>> It is my impression that low end 802.1D bridges don't implement this
>> but mid and high end 802.1Q bridges do. Typically, when a frame is
>> received, a control block is created with the VLAN, priority, time of
>> receipt, and other control information. When a frame is de-queued for
>> transmission, the time is checked and frame discarded if it is too
>> old. This time check doesn't need to be, and probably isn't, extremely
>> accurate.
>
> Under what conditions would that be expected to happen?

Actually, I think I may have misstated what happens as you would want
old frames discarded that were just sitting around in a queue, not
just when they were de-queued.

All you need is enough higher priority frames and low priority ones
could be queued forever even with no link ever going down and no flow
control impediments.

> I suspect that one good reason to avoid bothering with such a feature
> on high-end switches is that the amount of buffering required to reach
> a 1 second delay at high line rates becomes prohibitive -- in other
> words, you'll ordinarily drop on queue entry well before that happens
> in all but pathological cases, so why bother caring?

Hummm, it's not clear to me what the resolution of the maximum transit
delay is... although 1 second is the default, the resolution could be
small allowing it to be set to some number of milliseconds or
something...

As above, you could have a stream of, say, 1 Gbps higher priority
frames going from port 1 to port 3 and one lower priority frame for
port 3 that drifts in port 2 and this poor low priority frame could
just sit in a queue for days and then pop out due to a hiccup in the
high priority stream. I won't argue if you want to call that
pathological but it doesn't seem good that it could happen.

>> > I'm inclined to say "no" to this, just on the basis that I cannot see
>> > how it would serve any real purpose.  It looks like a spec for the
>> > sake of a spec.
>>
>> In bridges, I think it is required to back up the assurances of
>> Spanning Tree Protocol. I think bridges also flush the output queue
>> and any input queue associated with a port when the port goes down.
>> Generally, it seems like good hygiene not to keep a frame for a long
>> time and then release it...

(As I recall, the 802.1 bridging model does not really admit that
input queues can exist so any frame in an input queue is logically
considered not to have been received yet by the bridge...)

> We're not using STP here, though, so we don't need to back up its
> assurances.

The specific provisions in 802.1D-2004 include :
"6.3.6 Frame lifetime
The MAC Service mandates an upper bound to the transit delay
experienced for a particular instance of
communication. This maximum frame lifetime is necessary to ensure the
correct operation of higher layer
protocols. ..."

"7.1.1 Relay
A MAC Bridge relays individual MAC user data frames between the
separate MACs of the bridged LANs
connected to its Ports. The functions that support relaying frames and
maintain QoS are as follows:
...
l) Frame discard to ensure that a maximum bridge transit delay is not
exceeded (6.3.6).
..."

"7.7.3 Queuing frames
...
A frame queued for transmission on a Port shall be removed from that
queue if that is necessary to ensure
that the maximum bridge transit delay (6.3.6, Table 7-3) will not be
exceeded at the time at which the frame
would subsequently be transmitted.
..."

Similar provisions appear in 802.1Q-2005.

> As for avoiding a too-old release, I don't think that's easy to avoid
> with modern hardware due to the funky 802 flow control mechanism.  If
> the other end is having trouble, you can end up with a really old
> frame caught in your transmission craw.  It'd require some fancy
> footwork in most implementations I've seen to detect that sort of edge
> case, reset, and restart.
>
>> It would certainly be easy enough to make this a SHOULD rather than
>> being mandatory the way it is in 802.1, not that people seem to pay
>> that much attention to what is mandatory in 802.1. But perhaps it
>> really isn't necessary for RBridges... Anyone else have an opinion on
>> this.
>
> That 'one second delay' smells to me too much like the old IP TTL
> specification, and likely dates back to the same rules of thumb.
>
> I think that SHOULD is a fairly strong statement; it means that
> implementors who choose not to implement that feature need to have a
> clear explanation of why they don't, if they're going to try to follow
> the spirit of the RFC.  I don't think it ought to be a SHOULD unless
> it's something that's required for interoperability in most cases, but
> can be avoided in a few.  As 2119 says:
>
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
>
> Do RBridge implementors really need to weigh the pros and cons of
> implementing the delay time check in order to achieve
> interoperability?
>
> MAY is closer to the intent of saying, "here's something that's common
> in this field and that may be helpful in an implementation, but that
> is not known to be required for the sake of interoperability of
> RBridges."

Well, I'm OK with saying MAY. Since this is described in the 802.1
standards as being in the port output queue behavior, and since we now
incorporate that by reference unless we say otherwise, one could argue
that it is mandatory under the current draft. Unless people weigh in
with other opinions, I'll change it to MAY.

> James Carlson, Solaris Networking              <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Mon, 1 Dec 2008 07:59:57 -0800
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Donald Eastlake" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 2712

Agreed

-- Silvano

-----Original Message-----

Radia

for
only
n

Date: Mon, 1 Dec 2008 09:15:29 -0500
From: James Carlson <[email-masked]>
To: Donald Eastlake <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 3603

Donald Eastlake writes:
> > Do modern bridges actually _implement_ such a feature, or do they just
> > have a knob labeled "Maximum Bridge Transit Delay" that's connected to
> > nothing underneath?
> 
> It is my impression that low end 802.1D bridges don't implement this
> but mid and high end 802.1Q bridges do. Typically, when a frame is
> received, a control block is created with the VLAN, priority, time of
> receipt, and other control information. When a frame is de-queued for
> transmission, the time is checked and frame discarded if it is too
> old. This time check doesn't need to be, and probably isn't, extremely
> accurate.

Under what conditions would that be expected to happen?

I suspect that one good reason to avoid bothering with such a feature
on high-end switches is that the amount of buffering required to reach
a 1 second delay at high line rates becomes prohibitive -- in other
words, you'll ordinarily drop on queue entry well before that happens
in all but pathological cases, so why bother caring?

> > I'm inclined to say "no" to this, just on the basis that I cannot see
> > how it would serve any real purpose.  It looks like a spec for the
> > sake of a spec.
> 
> In bridges, I think it is required to back up the assurances of
> Spanning Tree Protocol. I think bridges also flush the output queue
> and any input queue associated with a port when the port goes down.
> Generally, it seems like good hygiene not to keep a frame for a long
> time and then release it...

We're not using STP here, though, so we don't need to back up its
assurances.

As for avoiding a too-old release, I don't think that's easy to avoid
with modern hardware due to the funky 802 flow control mechanism.  If
the other end is having trouble, you can end up with a really old
frame caught in your transmission craw.  It'd require some fancy
footwork in most implementations I've seen to detect that sort of edge
case, reset, and restart.

> It would certainly be easy enough to make this a SHOULD rather than
> being mandatory the way it is in 802.1, not that people seem to pay
> that much attention to what is mandatory in 802.1. But perhaps it
> really isn't necessary for RBridges... Anyone else have an opinion on
> this.

That 'one second delay' smells to me too much like the old IP TTL
specification, and likely dates back to the same rules of thumb.

I think that SHOULD is a fairly strong statement; it means that
implementors who choose not to implement that feature need to have a
clear explanation of why they don't, if they're going to try to follow
the spirit of the RFC.  I don't think it ought to be a SHOULD unless
it's something that's required for interoperability in most cases, but
can be avoided in a few.  As 2119 says:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Do RBridge implementors really need to weigh the pros and cons of
implementing the delay time check in order to achieve
interoperability?

MAY is closer to the intent of saying, "here's something that's common
in this field and that may be helpful in an implementation, but that
is not known to be required for the sake of interoperability of
RBridges."

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677