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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Donald Eastlake wrote:
> 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.

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

> On Sun, Nov 30, 2008 at 12:00 AM, Dinesh G Dutt <[e-mail]> wrote:
>> I strongly agree with dropping the sentence and adding the "MUST NOT
>> forward" piece,
>>
>> Dinesh
>> Radia Perlman wrote:
>>> 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 <[e-mail]>
>>>> 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
>>>>> [e-mail]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>> =============================
>>>>  Donald E. Eastlake 3rd   [phone] (home)
>>>>  155 Beaver Street
>>>>  Milford, MA 01757 USA
>>>>  [e-mail]
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>> We make our world significant by the courage of our questions and by the
>> depth of our answers.                               - Carl Sagan
> =============================
>  Donald E. Eastlake 3rd   [phone] (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [e-mail]
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklHKjoACgkQE5f5cImnZruEGQCeINqIN8WM14tr8j8/dLucVjUN
8RMAoJm6BT+qbbqLhkE1D5wK8BW6ocqG
=JGYA
-----END PGP SIGNATURE-----

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mBGH8iHU027529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 16 Dec 2008 09:08:44 -0800 (PST)
Received: from [75.215.212.246] (246.sub-75-215-212.myvzw.com [75.215.212.246]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mBGH8LeL008235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Dec 2008 09:08:24 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 20:10:34 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 16 Dec 2008 17:09:22 -0000
Status: RO
Content-Length: 4312

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Donald Eastlake wrote:
> 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.

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

> On Sun, Nov 30, 2008 at 12:00 AM, Dinesh G Dutt <[e-mail]> wrote:
>> I strongly agree with dropping the sentence and adding the "MUST NOT
>> forward" piece,
>>
>> Dinesh
>> Radia Perlman wrote:
>>> 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 <[e-mail]>
>>>> 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
>>>>> [e-mail]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>> =============================
>>>>  Donald E. Eastlake 3rd   [phone] (home)
>>>>  155 Beaver Street
>>>>  Milford, MA 01757 USA
>>>>  [e-mail]
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>> We make our world significant by the courage of our questions and by the
>> depth of our answers.                               - Carl Sagan
> =============================
>  Donald E. Eastlake 3rd   [phone] (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [e-mail]
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklHKjoACgkQE5f5cImnZruEGQCeINqIN8WM14tr8j8/dLucVjUN
8RMAoJm6BT+qbbqLhkE1D5wK8BW6ocqG
=JGYA
-----END PGP SIGNATURE-----



Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mBF47Na0000620 for <[e-mail]>; Sun, 14 Dec 2008 20:07:24 -0800 (PST)
Received: by yw-out-2324.google.com with SMTP id 5so996563ywh.75 for <[e-mail]>; Sun, 14 Dec 2008 20:07:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=aRooWO0Ad590ccMQojPVhmh+6UMJArurIIvTXBop7HI=; b=oBVw+G8Ph+wl90xl5bJJSTyaYLH+GEBFfeRJVSCtZrg60GyASdM7I9nN+gtVxH9H6y HkkPEZZW3tyfqPWbtAQ4TXlAgfXNdcIIguhTkhorY2gcQCxDW1l4+g2l2mCsW1OI7rEo TtGxVVIXkrDQ8O180QFYwuYnRJ3AeVs+2XOAs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=RHo3/ZjXihAw00Pt7gWrOfiVbxE/FMPNZGlZZYbZD4Gr87ejdRP2+lxNdOmv7jdVdv R9HZveFM/+Lw20DJ2pLe8dcvmMAksOL8SYQEJTykVO+clZuoa50MEjabyH6ggUal91OW G+JbBvMF/hyHrWcbN3ZXmLBxfdX/tiuBHyWV8=
Received: by 10.100.105.15 with SMTP id d15mr4269299anc.69.1229314043199; Sun, 14 Dec 2008 20:07:23 -0800 (PST)
Received: by 10.100.41.1 with HTTP; Sun, 14 Dec 2008 20:07:23 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 23:07:23 -0500
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2008 04:07:56 -0000
Status: RO
Content-Length: 3972

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 <[e-mail]> wrote:
> I strongly agree with dropping the sentence and adding the "MUST NOT
> forward" piece,
>
> Dinesh
> Radia Perlman wrote:
>>
>> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>> =============================
>>>  Donald E. Eastlake 3rd   [phone] (home)
>>>  155 Beaver Street
>>>  Milford, MA 01757 USA
>>>  [e-mail]
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mBEMCewS003166 for <[e-mail]>; Sun, 14 Dec 2008 14:12:41 -0800 (PST)
Received: by yx-out-2324.google.com with SMTP id 8so966311yxg.75 for <[e-mail]>; Sun, 14 Dec 2008 14:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FXB+RRWQFjCuvOm/9cnnPinu3ohGMjMDB6XtOl6oquA=; b=hTJNdXQdp+vYKVrxsjd5SMTntD+BE7lII5Nc7wpDdAudlwJS2FiMDtpFEKdlQNX1L/ xz2LDlDs5af1tUpBHfaoMOE270/IhEbPX4rLYZBDl7m1N1hENtYq3RD+pUQ52zOhsXEl r39FEqE+WZXLmgt7FZZRYGkH+BdIctQ6rX5oY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jEF0WvS5Li7RMRIb+DyybhHBEJTW9j1TlW9zLcIC7l1btU5PcfV3/yPhneJ9I2L42t E9xdlvl+rziqw/nUC9b1PiY4kYbozmVrZp62+OhIk6YXSQ/xrq+oHUyjtshI+FU7zrKl n8khYydl8Z7zjDAzKOdP3x7Tp4zVH/nCJLrRM=
Received: by 10.100.151.14 with SMTP id y14mr4144701and.117.1229292760001; Sun, 14 Dec 2008 14:12:40 -0800 (PST)
Received: by 10.100.41.1 with HTTP; Sun, 14 Dec 2008 14:12:39 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 17:12:39 -0500
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 14 Dec 2008 22:12:50 -0000
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 <[e-mail]> 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
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] 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
>> <[e-mail]> 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
>> <[e-mail]>
>> > 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
>> =============================
>>  Donald E. Eastlake 3rd   [phone] (home)
>>  155 Beaver Street
>>  Milford, MA 01757 USA
>>  [e-mail]
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>



-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mBB52Yek020868 for <[e-mail]>; Wed, 10 Dec 2008 21:02:35 -0800 (PST)
Received: by an-out-0708.google.com with SMTP id d11so375336and.30 for <[e-mail]>; Wed, 10 Dec 2008 21:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=HlfplsbfjZ6XXiMobSKIKqrbGXh1hN7kCcMv6lUUpt4=; b=hXwklR5xPB42RaPvNTHup18jEbXziirxFJJcBw3QQ5cxklCGzqTn6CxqD6KSMNKsA9 2cHsZ+2v8fn4dla26ENkh0aLauGwVYh99L8Wm0IcIjuH4F+vh1M3EvAtyY3k+p5kFQIS f7zcUfJ08ZUxcBd+C+g1GzdrNLcuW7fJBW0u4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=l87yl9ZNddByf3OiEYMrRUk2CBlqE2xCPEn8pf2UTdo1FlFqKhNhDXpO07As2HS1Uy GOCeUMJ/OPcFY/19nrZ5o8zx1ap8t41iRxxOBpHhie/mLgBpJ14tRCSawVi9yDwdwz88 tdTRuzh6AnF7jV/G3VavJvtX43Sj8aaKjeHEc=
Received: by 10.100.124.6 with SMTP id w6mr1753342anc.80.1228971754153; Wed, 10 Dec 2008 21:02:34 -0800 (PST)
Received: by 10.100.37.14 with HTTP; Wed, 10 Dec 2008 21:02:34 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 11 Dec 2008 00:02:34 -0500
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_97282_12583811.1228971754129"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] draft-eastlake-trill-rbridge-notes-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 11 Dec 2008 05:03:05 -0000
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--


Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mBB3sFlo004363 for <[e-mail]>; Wed, 10 Dec 2008 19:54:16 -0800 (PST)
Received: by yw-out-2324.google.com with SMTP id 5so368915ywh.75 for <[e-mail]>; Wed, 10 Dec 2008 19:54:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=/EcZKLzg5kp7jpSxmkPsn5Hz2fF2Jq947ijyfBf/NDI=; b=oLdVY7GkKmTv7MV9TIB7jz+QgVyajvdZ2fgkkDcKWK2NI+pgY3SR+4IiuRFtL/h0Xb RN4rV69fJZmB1JAHkx4PNqhGhA1/B0XrR3c8euhgRnZxHhQaAiNISP1aJUWO4E3xldsZ WXi37ceJIcXLfaQRlY9EMXrHlQhpfEiIdjMrI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=ZWchQE+tXsI8I31UF3eD6i2nnYwPzmA1Gj8Ep0KCqf66CV69H6ieMsWI8++DsSdhfi wfmZuvAOFeyrO7AH76bYneMRtfPk8dQsE0xhECN/51DaSclOtcUo+ng/dcrXP/o+VoRQ QkaYhubFgFmaqXqWj/mhQieNTP2DEis3V+Uww=
Received: by 10.100.178.2 with SMTP id a2mr1715696anf.114.1228967655045; Wed, 10 Dec 2008 19:54:15 -0800 (PST)
Received: by 10.100.37.14 with HTTP; Wed, 10 Dec 2008 19:54:14 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 10 Dec 2008 22:54:14 -0500
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_96850_7817761.1228967655029"
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Draft Minneapolis minutes uploaded
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 11 Dec 2008 03:54:34 -0000
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 <[e-mail]> 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
> =============================
>  Donald E. Eastlake 3rd   [phone] (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [e-mail]
>

------=_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:[e-mail]">[e-mail]</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; [phone] (home)<br>
&nbsp;155 Beaver Street<br>
&nbsp;Milford, MA 01757 USA<br>
&nbsp;<a href="mailto:[e-mail]">[e-mail]</a><br>
</blockquote></div><br>
</div>

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


Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB2HNFPu014258 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Tue, 2 Dec 2008 09:23:16 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,702,1220227200"; d="scan'208";a="112478362"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Dec 2008 17:23:07 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB2HN4PY026989;  Tue, 2 Dec 2008 09:23:04 -0800
Received: from [10.21.93.110] (sjc-vpn5-1390.cisco.com [10.21.93.110]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB2HN44d010998; Tue, 2 Dec 2008 17:23:04 GMT
Message-ID: <[e-mail]>
Date: Tue, 02 Dec 2008 09:23:03 -0800
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (X11/20081105)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6290; t=1228238585; x=1229102585; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20draft=20protocol-10=20WGLC= 20Multicast=20Addresses |Sender:=20; bh=4RojyXj47RYG25WPpSg5u9iO6DibNfp3IyGlTE5dhPM=; b=IoKkImEczv22C9ZAEkOztnrGE2HmCf8IlcTmZC/YFauqWwPd6gqATXIfQQ g6gY+XfYNH8QsfjLEP8hbiQAb9oODvO9/chbb5xx3unfRMKJx6p5EeFVkp3A zdcVkYejF7vZBfwuhVvFoZIhyjSAshB0S22bQvzLTIbTtjd7cyF34=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Donald Eastlake <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2008 17:23:51 -0000
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
>
>   
>> -----Original Message-----
>> From: Donald Eastlake [mailto:[e-mail]] 
>> 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 
>> <[e-mail]> 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
>>>
>>> ________________________________
>>> From: [e-mail] 
>>>       
>> [mailto:[e-mail]] 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
>>> =============================
>>> Donald E. Eastlake 3rd   [phone] (home)
>>> 155 Beaver Street
>>> Milford, MA 01757 USA
>>> [e-mail]
>>>       
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

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



Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB27Vskk019322 for <[e-mail]>; Mon, 1 Dec 2008 23:31:55 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,701,1220252400"; d="scan'208";a="78555466"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 01 Dec 2008 23:31:54 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-exchfe-2-smtp.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 36A6C2383F2; Mon,  1 Dec 2008 23:31:54 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 1 Dec 2008 23:31:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 1 Dec 2008 23:31:39 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] draft protocol-10 WGLC Multicast Addresses
Thread-Index: AclUMh7PfGLQgJpsQQmt53knpVpZCgAHRcEg
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Donald Eastlake" <[e-mail]>
X-OriginalArrivalTime: 02 Dec 2008 07:31:53.0892 (UTC) FILETIME=[0C665640:01C95450]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id mB27Vskk019322
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2008 07:32:34 -0000
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

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]] 
> 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 
> <[e-mail]> 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
> >
> > ________________________________
> > From: [e-mail] 
> [mailto:[e-mail]] 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
> > =============================
> > Donald E. Eastlake 3rd   [phone] (home)
> > 155 Beaver Street
> > Milford, MA 01757 USA
> > [e-mail]
> 



Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB24Ai93022704 for <[e-mail]>; Mon, 1 Dec 2008 20:10:45 -0800 (PST)
Received: by rn-out-0910.google.com with SMTP id k57so2153649rnd.13 for <[e-mail]>; Mon, 01 Dec 2008 20:10:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=0flgLP8knW/Vjhyj+YI2a+Ngw6U/AUZUb4RVrATD48U=; b=WO7qjPQJvPrwAYntnQZz3m7gfV2Jn2aqDTpvtQeCgc5gcW/qHRp1MY5fsqVMaMRy6Z NIxNGnyBLjmXpoxcgjHoYKDL5wtTl+dK16JpjaY8uQ6DIfA7K/wr7p5Uj4orX6KvHqUN yi/AYHX6Ep6Z/YMaFQbyIc4ZaptdyFFrcKh/E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=kZ84A+dudnWIKWREm/XWwnNCxfD4O2M9us6uX6IaoFXARYYMN23Uu7THafNlDrnJAr 75L7fx7hunT79ZFl6rgWC9LAc3t33jwNnzBzvhZEs3S+JUCid48IlkrIe3OVntCDmD10 Z4fN+effABjMkt3i+SDoSu57N3pavG6lTBLiI=
Received: by 10.100.93.19 with SMTP id q19mr6372812anb.156.1228191044177; Mon, 01 Dec 2008 20:10:44 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Mon, 1 Dec 2008 20:10:44 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 1 Dec 2008 23:10:44 -0500
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Draft Minneapolis minutes uploaded
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2008 04:11:21 -0000
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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB23vZhZ019121 for <[e-mail]>; Mon, 1 Dec 2008 19:57:36 -0800 (PST)
Received: by rn-out-0910.google.com with SMTP id k57so2150749rnd.13 for <[e-mail]>; Mon, 01 Dec 2008 19:57:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qUpBd3ckjjUtLx68uXXkEfaeTJkyU8s4YGpabZU+9YU=; b=ktndHAscpQp7MpTw0qIUZeTQY4/hlcecpt0niDOdOpQdmIaFCkQcTz8KqKHTlXAESQ D3AVFpQf9asQ/xWvyy74JNdzA6gWIupRe069H44i2pTlW/ODcgKLNsVlAeU1IfGhYJw/ +gPdorL52QImHp0EtI1pGX2IHPwj6FSdyfMoc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LAfPO7BXQvNr1sTdjsm3vNALxnf38a1h8cOHbof8SosSWEzxaWmkyd7sE4N94wkFfy TaPUYmGZyS1pdInqz+/TBTk64W/fY0eEzKlzffbvas1nNGrLPIV+GpVmSixANUEIHelw vHr4YU92zVqlvEN+Ruvi7M9BKvccYFVgyxmwo=
Received: by 10.100.94.14 with SMTP id r14mr6385277anb.68.1228190255120; Mon, 01 Dec 2008 19:57:35 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Mon, 1 Dec 2008 19:57:35 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 1 Dec 2008 22:57:35 -0500
From: "Donald Eastlake" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2008 03:57:52 -0000
Status: RO
Content-Length: 3733

Hi Anoop,

On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani <[e-mail]> 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
>
> ________________________________
> From: [e-mail] [mailto:[e-mail]] 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
> =============================
> Donald E. Eastlake 3rd   [phone] (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> [e-mail]


Received: from mx30.brocade.com (mx30.brocade.com [144.49.194.4]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB22Rqii025810 for <[e-mail]>; Mon, 1 Dec 2008 18:27:53 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,700,1220252400"; d="scan'208,217";a="58076613"
Received: from discus.brocade.com ([192.168.126.240]) by mx30.brocade.com with ESMTP; 01 Dec 2008 18:27:52 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-exchfe-2-smtp.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 11CE62383F2; Mon,  1 Dec 2008 18:27:46 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 1 Dec 2008 18:27:45 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95425.8FAA87C9"
Date: Mon, 1 Dec 2008 18:27:32 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] draft protocol-10 WGLC Multicast Addresses
Thread-Index: AclQFJfN7X4NIrlzRuCqrdI3cjfPPQEEAfCg
References: <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Donald Eastlake" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
X-OriginalArrivalTime: 02 Dec 2008 02:27:45.0869 (UTC) FILETIME=[8FBAFFD0:01C95425]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2008 02:28:22 -0000
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: [e-mail]
[mailto:[e-mail]] 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   [phone] (home)
	155 Beaver Street
	Milford, MA 01757 USA
	[e-mail]
=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> [e-mail]=20
  [mailto:[e-mail]] <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
  [phone] (home)<BR>155 Beaver Street<BR>Milford, MA 01757 =
USA<BR><A=20
  href=3D"mailto:[e-mail]"=20
  =
target=3D_blank>[e-mail]</A><BR></DIV></DIV></DIV></BLOCKQUOTE></=
BODY></HTML>

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


Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB22KI2Y023648 for <[e-mail]>; Mon, 1 Dec 2008 18:20:19 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,699,1220252400"; d="scan'208";a="78532735"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 01 Dec 2008 18:20:18 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-exchfe-2-smtp.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 93DE32383F2; Mon,  1 Dec 2008 18:20:18 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 1 Dec 2008 18:20:18 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 1 Dec 2008 18:20:04 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Thread-Index: AclT9E+mV3k5QamkT8SDxbvYRPj5wQALkCiw
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Donald Eastlake" <[e-mail]>, "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 02 Dec 2008 02:20:18.0408 (UTC) FILETIME=[8505DE80:01C95424]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id mB22KI2Y023648
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2008 02:20:58 -0000
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

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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 
> <[e-mail]> 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              
> <[e-mail]>
> > 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
> =============================
>  Donald E. Eastlake 3rd   [phone] (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [e-mail]
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB21wT2u016516 for <[e-mail]>; Mon, 1 Dec 2008 17:58:30 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,699,1220252400"; d="scan'208";a="78531122"
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 01 Dec 2008 17:58:29 -0800
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-exchfe-2-smtp.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 34B442383F2; Mon,  1 Dec 2008 17:58:29 -0800 (PST)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 1 Dec 2008 17:58:28 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 1 Dec 2008 17:58:14 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] MUST not send spanning tree BPDUs?
Thread-Index: AclR5ghmEEViZaauQU6M3B04wJuYGACOvRlg
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Donald Eastlake" <[e-mail]>
X-OriginalArrivalTime: 02 Dec 2008 01:58:28.0648 (UTC) FILETIME=[78585A80:01C95421]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id mB21wT2u016516
Cc: [e-mail]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2008 01:58:59 -0000
Status: RO
Content-Length: 3125

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

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Friday, November 28, 2008 9:37 PM
> To: Donald Eastlake
> Cc: [e-mail]
> 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 
> <[e-mail]> 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
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>     
> > =============================
> >  Donald E. Eastlake 3rd   [phone] (home)
> >  155 Beaver Street
> >  Milford, MA 01757 USA
> >  [e-mail]
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB1JWkb3011553 for <[e-mail]>; Mon, 1 Dec 2008 11:32:47 -0800 (PST)
Received: by an-out-0708.google.com with SMTP id d11so1041364and.30 for <[e-mail]>; Mon, 01 Dec 2008 11:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=DpOM4vb0yblwU19KFZbe0S5q0THjM8fHnWJl6SSa48Y=; b=w5VFHhC5bGwaXY+79Xdzv50077O+p4Zuas4pHIa5m2y7zlghzcmrmCvf73zbGWcjW1 iqJgOY4qd0dJZHAXcYxkEV0muSuYLiUTQpkGITaD5p8gdwIK46O6plT5R1MXL7UklMrX iJeAx0GHZrLRnyqSiKR6AWN1V0Rco/kGGA4K8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=N8WLuLLir91Dw8h+oZVqmfe6F08VP6m1OrnLl2RXs3U/wu+P3fiRZ8KVs21kagNwWa jRz7TGI7WbMuLlYDBsrxW1KxChCrXKmBKvzbvesaKdokiwlAUxMX7EpivHlGCjF6HjM+ 4eB/D8Acu8Za5WtVk8CF3i9R6u8gmZqxAGrGs=
Received: by 10.100.144.11 with SMTP id r11mr6084757and.24.1228159966162; Mon, 01 Dec 2008 11:32:46 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Mon, 1 Dec 2008 11:32:46 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 1 Dec 2008 14:32:46 -0500
From: "Donald Eastlake" <[e-mail]>
To: "James Carlson" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2008 19:33:27 -0000
Status: RO
Content-Length: 2594

Hi Jim,

On Mon, Dec 1, 2008 at 1:27 PM, James Carlson <[e-mail]> 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              <[e-mail]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB1Ijtls024280 for <[e-mail]>; Mon, 1 Dec 2008 10:45:56 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB1Ijs0J003390 for <[e-mail]>; Mon, 1 Dec 2008 18:45:55 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB1Ijs72002865 for <[e-mail]>; Mon, 1 Dec 2008 13:45:54 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1IR7UA003610; Mon, 1 Dec 2008 13:27:07 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1IR7QR003607; Mon, 1 Dec 2008 13:27:07 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 1 Dec 2008 13:27:07 -0500
From: James Carlson <[e-mail]>
To: Donald Eastlake <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2008 18:46:04 -0000
Status: RO
Content-Length: 3187

Donald Eastlake writes:
> On Mon, Dec 1, 2008 at 9:15 AM, James Carlson <[e-mail]> 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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB1HtOTZ006045 for <[e-mail]>; Mon, 1 Dec 2008 09:55:25 -0800 (PST)
Received: by an-out-0708.google.com with SMTP id d11so1013179and.30 for <[e-mail]>; Mon, 01 Dec 2008 09:55:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=3QBTi2QRa/Z4uGHcSFOGvSOyYSzsfnK/KnQJvQMuUg0=; b=iZSg6HXN38o37dzNYATvjGtciZs3RWIsK4TIniki5Y8cRPuRx2mwzid0kXjb8HQ5Ef qoHDXsbCgIMLqAy5v2yVb3wILNGKQEGGuAvU5CAqBA2cc5yT1w5AruXcEW1X0/Yr3PZz McgA81raN7qOow6STHPx9QExSz4GwWxwparXs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KS0b/PQXJs+rBInpfUVLgOxl8gnKyt7Cs2fDyNzL4dQ4QITFPOqrn/PqNWvPjZj3S0 qcNgpsW6roS9dXpyiilgWuF2ooQSZHI2MQG8b3nweIf9S+U2rnWX6Ck0tu2hXdW2p727 zwiR7fMS4b79w0kxTmvPVQl0ZRevXzy3tcWPM=
Received: by 10.100.43.10 with SMTP id q10mr6016922anq.1.1228154123491; Mon, 01 Dec 2008 09:55:23 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Mon, 1 Dec 2008 09:55:23 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 1 Dec 2008 12:55:23 -0500
From: "Donald Eastlake" <[e-mail]>
To: "James Carlson" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2008 17:56:16 -0000
Status: RO
Content-Length: 6326

Hi Jim,

On Mon, Dec 1, 2008 at 9:15 AM, James Carlson <[e-mail]> 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              <[e-mail]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB1G06ID026101 for <[e-mail]>; Mon, 1 Dec 2008 08:00:07 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 1 Dec 2008 07:59:57 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] MUST not send spanning tree BPDUs?
Thread-Index: AclR5O7x/2keJB8YSV2bXMuqAfS1eQB6OLuw
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Donald Eastlake" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id mB1G06ID026101
Cc: [e-mail]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2008 16:00:40 -0000
Status: RO
Content-Length: 2712

Agreed

-- Silvano

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Friday, November 28, 2008 9:37 PM
To: Donald Eastlake
Cc: [e-mail]
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 <[e-mail]>
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
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     
> =============================
>  Donald E. Eastlake 3rd   [phone] (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [e-mail]
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB1EYUPC026880 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Mon, 1 Dec 2008 06:34:31 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB1EYSV4028759 for <[e-mail]>; Mon, 1 Dec 2008 14:34:30 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB1EYRvp039026 for <[e-mail]>; Mon, 1 Dec 2008 09:34:27 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1EFXnD002135; Mon, 1 Dec 2008 09:15:36 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1EFT84002132; Mon, 1 Dec 2008 09:15:29 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 1 Dec 2008 09:15:29 -0500
From: James Carlson <[e-mail]>
To: Donald Eastlake <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2008 14:35:22 -0000
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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]