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

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 <Radia.Perlman@sun.com> 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
>>> rbridge@postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>     
>>>       
>> =============================
>>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>>  155 Beaver Street
>>  Milford, MA 01757 USA
>>  d3e3e3@gmail.com
>> _______________________________________________
>> rbridge mailing list
>> rbridge@postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>   
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> 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

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

Message-ID: <49321DDF.2080608@cisco.com>
Date: Sat, 29 Nov 2008 21:00:15 -0800
From: Dinesh G Dutt <ddutt@cisco.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081105)
MIME-Version: 1.0
To: Radia Perlman <Radia.Perlman@sun.com>
References: <49147147.50605@sun.com>	<4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>	<49307F47.3050405@sun.com>	<1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com> <4930D4EA.7020005@sun.com>
In-Reply-To: <4930D4EA.7020005@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Donald Eastlake <d3e3e3@gmail.com>, rbridge@postel.org
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Precedence: list
Status: RO
Content-Length: 2827

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 <Radia.Perlman@sun.com> 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
>>> rbridge@postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>     
>>>       
>> =============================
>>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>>  155 Beaver Street
>>  Milford, MA 01757 USA
>>  d3e3e3@gmail.com
>> _______________________________________________
>> rbridge mailing list
>> rbridge@postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>   
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> 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

Date: Fri, 28 Nov 2008 21:36:42 -0800
From: Radia Perlman <Radia.Perlman@sun.com>
In-reply-to: <1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Message-id: <4930D4EA.7020005@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> <49307F47.3050405@sun.com> <1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com>
User-Agent: Thunderbird 2.0.0.19pre (Windows/20081127)
Cc: rbridge@postel.org
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Precedence: list
Status: RO
Content-Length: 2287

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 <Radia.Perlman@sun.com> 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
>> rbridge@postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3@gmail.com
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

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=xD0KV/pF2SVayrxxSkg8t8hQnztNmwHzCmXjiCqq5G1mu/dDXHPt36XuzalavQidTu j8+WuG9hw5ctvmKC+TY7Rkkd3EaoAVxrnOnxGbbZl3bmAUw6iG4fJ9mQ+z98TjFIhkyx kgRTGWiObiTLfKFkciLwo66jv7td00dQJ9qqs=
Message-ID: <1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com>
Date: Fri, 28 Nov 2008 21:01:29 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "Radia Perlman" <Radia.Perlman@sun.com>
In-Reply-To: <49307F47.3050405@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> <49307F47.3050405@sun.com>
Cc: rbridge@postel.org
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Precedence: list
Status: RO
Content-Length: 1873

Hi Radia,

See below...

On Fri, Nov 28, 2008 at 6:31 PM, Radia Perlman <Radia.Perlman@sun.com> 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
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3@gmail.com

Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAT1Lu0t009894 for <rbridge@postel.org>; Fri, 28 Nov 2008 17:21:57 -0800 (PST)
Received: by yx-out-2324.google.com with SMTP id 8so614081yxg.75 for <rbridge@postel.org>; Fri, 28 Nov 2008 17:21:56 -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=Z9fnimxSxGy8Q0BoKxHIWQC2x9Q+nuivdswxKZtiVs8=; b=jaXJWABIf+LbdxRV1bCPb8HDkjCJ+y3WkaWWXTSupgeapAj2AOAVg73fgICkhKDiHS JhAR+xeIgMR52L40CDC7E7itvyIwHwYDyz1anLnUnGRjL69rSv9oXuUY5DKB7E5dGNk1 lC72Gz4MPqOrnyEBAO3/NCwBMF40Fz+n9Y7g4=
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=wmgQVwA6GxVkA+xxP0/a6IoKa/S6YlpeKy3z7W45f2r4KV6z9NAZb6fx7vx8+jyZ0d i4c9x/mK0jnlq4gZrlKRn98dyOMh9wQLyk05taTzfWoVmxgMnO69h0tbGA/mYlVJKFK3 +HH8kt/xbex4d3+ofD+ZlNWQ3zRY56MIutV7Y=
Received: by 10.100.163.15 with SMTP id l15mr4475482ane.128.1227921716432; Fri, 28 Nov 2008 17:21:56 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Fri, 28 Nov 2008 17:21:56 -0800 (PST)
Message-ID: <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com>
Date: Fri, 28 Nov 2008 20:21:56 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "James Carlson" <james.d.carlson@sun.com>
In-Reply-To: <18733.52215.806793.660780@gargle.gargle.HOWL>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> <18733.52215.806793.660780@gargle.gargle.HOWL>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Nov 2008 01:22:20 -0000
Status: RO
Content-Length: 2678

Hi Jim,

See below...

On Wed, Nov 26, 2008 at 5:21 PM, James Carlson <james.d.carlson@sun.com> wrote:
> Donald Eastlake writes:
>> I've reviewed the draft and will be posting a few suggested changes. This is
>> the first.
>> 802.1 bridges have a Maximum Bridge Transit Delay. They are required to
>> discard frames that have been inside the bridge for longer than this time.
>> It is configurable with a recommended value of 1 second and maximum value of
>> 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a
>> sentence or two to indicate that RBridges have this parameter configurable
>> per RBridge and enforce a maximum RBridge transit delay.
>
> 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.

> I can imagine flushing Ethernet output queues if link status goes down
> and stays down for more than a second, thus blocking timely output,
> but tracking internal timestamps on individual packets seems like a
> wasted effort to me, and may not even be feasible with modern
> hardware.
>
> 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...

> James Carlson, Solaris Networking              <james.d.carlson@sun.com>
> 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

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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3@gmail.com

Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mASNUpLv013777 for <rbridge@postel.org>; Fri, 28 Nov 2008 15:30:51 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KB200M2VHBFYY00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 28 Nov 2008 15:30:51 -0800 (PST)
Received: from [172.16.4.9] ([217.172.65.124]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KB200F8LHBDJNN0@mail.sunlabs.com> for rbridge@postel.org; Fri, 28 Nov 2008 15:30:51 -0800 (PST)
Date: Fri, 28 Nov 2008 15:31:19 -0800
From: Radia Perlman <Radia.Perlman@sun.com>
In-reply-to: <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>
To: rbridge@postel.org
Message-id: <49307F47.3050405@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>
User-Agent: Thunderbird 2.0.0.19pre (Windows/20081127)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: radia.perlman@sun.com
Subject: [rbridge] MUST not send spanning tree BPDUs?
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2008 23:31:13 -0000
Status: RO
Content-Length: 935

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.

Anyone else remember?

Thanks,

Radia

Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mASNQWoS012615 for <rbridge@postel.org>; Fri, 28 Nov 2008 15:26:32 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KB200M2QH44YY00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 28 Nov 2008 15:26:29 -0800 (PST)
Received: from [172.16.4.9] ([217.172.65.124]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KB200F8JH40JNN0@mail.sunlabs.com> for rbridge@postel.org; Fri, 28 Nov 2008 15:26:26 -0800 (PST)
Date: Fri, 28 Nov 2008 15:26:53 -0800
From: Radia Perlman <Radia.Perlman@sun.com>
In-reply-to: <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>
To: "Ayan Banerjee (ayabaner)" <ayabaner@cisco.com>
Message-id: <49307E3D.6070400@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>
User-Agent: Thunderbird 2.0.0.19pre (Windows/20081127)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: radia.perlman@sun.com
Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM>
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2008 23:26:44 -0000
Status: RO
Content-Length: 5095

More re: Ayan Banerjee's comments on protocol-10:

>
>
> Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear.
>   

How about adding a comma after "controls"
> Item 14: Section 4.2.3.1.2 - Based on feedback from the IS-IS WG should
> we remove this optimization (delete last 3 paras) 
>   
I think that the optimization is particularly valuable when IS-IS is 
operating in layer 2. And it
doesn't add complexity, so I see no downside to this.
> Item 15: section 4.2.3.2 - (note 1) - designated vlan to be used for
> trill data frames, does this imply that 
>                             vlans are getting tunneled with a different
> outer vlan-id. Just want to make this 
>                             explicit.
>   
Yes. The inner and outer VLAN tags are unrelated on encapsualted frames. 
I thought the
spec was clear about this.
> Item 16: Section 4.2.3.3 - (last note - should this must be the
> ext-ckt-id for P2P, and in a lan. This implies
>                            that we should mandate 3-way handshake for
> P2P links
>   
> Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose
> all (see note 3 in the last call) 
>
> Item 18: Section 4.3 - Distribution tree (see note 3 in last call and
> please see draft-ward) 
>   

Hmm. I don't understand the above comments, probably because I don't 
know what "note 5"
and "note 3" are referring to.
> Item 19: Section 4.3.1 - Talk about parallel links and what needs to
> break them 
>
> Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address
> and go everywhere) 
>
>   
Can you be more specific about your concern? I can't tell, based on 
reading the section, what you're
asking about.
> Item 21: Section 4.4.1.2 - Second last paragraph - please change the
> last sentence.
>   

I think the last sentence you are referring to is:

>>(Using a unicast
>>   Outer.MacDA is of no benefit on a point-to-point link but may result
>>   in substantial savings if the link is actually a bridged LAN with
>>   many bridged branches and end stations, to all of which the frame may>>
>>   get flooded if a multicast destination is used.)

Not sure what's wrong with it...

> Item 22: Section 4.4.2.2 - the forwarding rbridge need not be a AF on
> the link (paragraph 2, consider a P2P case).
>                            Or make a statement, that on a P2P, rbridges
> are automatically AFs.
>   
I think this is just a simple clarification. That if it's a P2P case 
RBridge-endnode, that the
RBridge is automatically an AF...
> Item 23: Section 4.5 needs more text on forwarding of various classes of
> multicast control plane packets
>                      some are forwarded using a special address while
> other are flooded.
>   

Hope Donald understands this one...
> Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. 
>   
It might be nice to quote the offending text, but I think you are 
referring to:

>>   When the appointed forwarder lost counter for RBridge RBn for VLAN-x
>>   is observed to increase via the core TRILL IS-IS link state database
>>   but RBn continues to be an appointed forwarder for VLAN-x on at least
>>   one of its ports, every other RBridge that is an appointed forwarder
>>   for VLAN-x modifies the aging of all the addresses it has learned by
>>   decapsulating native frames in VLAN-x from ingress RBridge RBn as
>>   follows: The time remaining for each entry is adjusted to be no
>>   larger than a per RBridge configuration parameter called (to
>>   correspond to [802.1Q]) "Forward Delay".

Hmm. I don't remember that section, and don't remember the purpose of
counting the number of times appointed forwarder status is lost. Wouldn't
the sequence number on the ESADI (together with the CSNP to assure delivery
of the latest ESADI from each RBridge) make is unnecessary to have a
"appointed forwarder lost counter"?

> Item 25: Section 4.6.3 - Not sure if mis-configuration detection being
> carried in the LSP is a good idea. 
>                          Assuming that it stays there, I do not see any
> text on what to do when things are 
>                          mis-configured. If this is just a log, I would
> suggest that we take this out-of-band
>                          and configuration mismatch issues be handled
> separately. 
>   
Adding optional information into LSPs to detect misconfiguration, and 
not saying what to do as a result
of this information, was a compromise. One could have RBridges act on 
the information, or
have some sort of management tool that looks through things for 
misconfigurations. Seems like a good
idea and mostly harmless.
>
> Item 27: Section 4.7.3.3 - Last sentence, do rbridges with access ports,
> run STP ? If not, why not? I am 
>                            guessing that statement is talking about
> trunk ports; if so can we make that 
>                            explicit.
>   

The sentence is
 >>"Except for this optional capability,

 >>  RBridges MUST NOT send spanning tree BPDUs."

I don't remember that. Why did we put that in? I might make an independent note about
this...

Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mASMvp6D004956 for <rbridge@postel.org>; Fri, 28 Nov 2008 14:57:52 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KB200M2DFSBYY00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 28 Nov 2008 14:57:47 -0800 (PST)
Received: from [172.16.4.9] ([217.172.65.124]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KB200F8EFS6JNN0@mail.sunlabs.com> for rbridge@postel.org; Fri, 28 Nov 2008 14:57:45 -0800 (PST)
Date: Fri, 28 Nov 2008 14:58:11 -0800
From: Radia Perlman <Radia.Perlman@sun.com>
In-reply-to: <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>
To: "Ayan Banerjee (ayabaner)" <ayabaner@cisco.com>
Message-id: <49307783.9010504@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>
User-Agent: Thunderbird 2.0.0.19pre (Windows/20081127)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: radia.perlman@sun.com
Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM>
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2008 22:58:16 -0000
Status: RO
Content-Length: 13902

Re Ayan Banerjee's comments on protocol-10:

a) your concern about spraying of hellos. Indeed there was much 
discussion, with viewpoints ranging
from "send Hellos on every VLAN by all RBridges" (which minimizes the 
possibility of two RBridges
not noticing each other because of weird bridge configurations) to "only 
send Hellos on VLAN 1" (simplicity,
least bandwidth). What is in the spec is a compromise which people 
seemed willing to live with. Only
the DRB (once established) sends Hellos on more than one VLAN, and it 
can be configured to
send on a smaller set of VLANs than the set it supports.

Another option which I kind of liked was to have the RBridge attempt to 
become bridge Root. And
become DRB if and only if it succeeds in being tree Root. We might want 
to revisit that. I happened to
be talking to someone (who hasn't been participating in the WG, but 
might be building this) who brought up
that solution as a suggestion instead of spraying with hellos.

b) differently-configured access and trunk ports: I think all the 
scenarios work. It is the DRB that decides
if it is an access port (and therefore prevents any through-traffic by 
either setting the overload bit or not
creating a pseudonode). So it doesn't matter what the other RBs think 
the port is. And if the DRB
thinks it is a trunk port, it will not assign any designated forwarders.
If the DRB thinks it's a "universal port" (both access and transit), and 
some other RBridge believes
it is a trunk port, that other RBridge will not volunteer to be 
designated forwarder. No problem.
If the other RBridge thinks it's an access port, then given that the DRB 
doesn't claim it's an access port,
its decision is overridden, and it does have to forward.

c) no nickname necessary if not ingress, egress, or tree root

We decided this was a good thing in case nicknames became scarce. It 
seems totally harmless. Just RB
doesn't include a TLV for nickname if it doesn't want a nickname.

d) ESADI instances: I couldn't find the place in the spec you point to 
(you said 4.1.2). I don't see a scalability
problem if endnodes for each VLAN are announced in separate 
announcements. I think the notion of
calling it an "IS-IS instance" (my bad terminology) led to lots of 
confusion, ranging from people thinking
that it meant totally separate per-VLAN topologies of the core, to ... 
not sure what else. I think we've
decided not to call it an "instance" anymore, but just to redefine the 
acronym "ESADI" to be "End System
Advertisement Information". One of the reasons to keep the announcements 
in separate packets for
different VLANs is because of VLAN mapping.

The scalability concerns people have raised for this involve sending 
Hellos per VLAN for these ESADI "instances".
But there are no Hellos. There is, however, a CSNP for each VLAN-ESADI.

e) you said:

>>Item 10: Section 4.2.3.5 - New section -- I think that we are better
>>served with a P2P IIH

Just to confirm on the mailing list what I asked at the meeting (since sometimes
"off the top of people's head at a meeting" might be incorrect):

I was worried about sending a P2P IIH and having it misinterpreted. Someone
said that P2P IIHs and multi-access IIHs are different PDU types. Is this correct?
If so, (or if there is some other way of not getting confused by getting one when
you are expecting the other), it seems OK, but we'd have to look through the
P2P IIH and make sure that all the TRILL information we need is there. I suppose
there is no VLAN information needed, pseudonodes, or information about whether it's
a trunk or access port. maybe there really is no TRILL information needed in
a P2P IIH...

f) You said you were confused by this sentence:
>>Note that an RBridge RBn does not defer to the
>>   DRB listed in a Hello, even if that claimed DRB is higher priority,
>>   if the Hello was sent by an RBridge with lower priority than RBn.

I think that's saying that RB1 might hear a Hello from RB2, wherein RB2 announces
that RB2 thinks RB3 is DRB, and that RB1 should not defer to RB2 unless RB3
actually hears Hellos from RB3.
That's kind of interesting -- maybe it should...

I'm sending this in case my email fails, and will try to respond to the rest
of Ayan's comments later.

Radia

> Item 3: Section 2.3.1 - Spraying of hellos, scalability concerns, text
> is unclear Consider the following topology and the following scenarios.
>       
>       |            |              |
>      RB1--------- RB2 ---------- RB3
>       |            |              |
>       |p1          |p2            |p3
>
> The Rbi's are connected on the top to a TRILL cloud consisting of only
> Rbridges (for ease of discussion). They are connected on the bottom to
> CE switches/network via ports p1, p2, and p3. 
>
> Scenario 1: All ports (p1, p2, and p3) are configured to be access ports
> (as defined in Appendix A of the draft). 
> In this case, Rbi's will spray with hellos on all VLANs configured on
> their respective ports. The intent is if a hello is received by other
> Rbi's and an "adjacency" can be formed, then we want to block ports to
> prevent loops. The intent is such a link should not get in the LSP-DB;
> this is inverse of the operation desired with a traditional-isis-hello.
> Only one port remains forwarding and the others are blocked; if so I
> could not figure out from the draft which one is forwarding (is
> system-id etc used as a tie?). Once this is blocked, it remains blocked
> till we "loose" the adjacency again. It is possible that the requirement
> will be to send in the order of 10,000s hellos/per sec per node. This
> solution of spraying poses scalability concerns for the protocol. Also,
> the announcement of the vlan list (however compressed) may not fit
> within the isis-hello-pdu. 
>
> Scenario 2: All ports (p1, p2, and p3) are configured to be trunk ports
> (as defined in Appendix A of the draft). 
> Once again, Rbi's spray hello on all VLANs. In this case, forming of
> adjacencies is desired, in the sense this links gets in the LSP-DB. Once
> a DRB is elected, only the DRB continues spraying with hellos such that
> future nodes can discover and join the designated vlan to send hellos.
> Nodes other than the DIS after the initial spraying will move to sending
> hellos on the designated vlan only. Question: What happens if the DRB
> does not capture all the vlans, for example RB1 became DRB, but has
> vlans 2,3 on p1 and the others p2 and p3, have vlan 2,3,4. Can a new
> RB4, with vlan 4 configured on it enter this Rbridge LAN and create
> issues? Can we have some text to clearly show the desired operation. 
>
> Scenario 3: Some ports are configured to be trunk and some others access
> (could be due to mis-configuration or error in cabling) Not sure what is
> the desired behavior? Are we saying that "adjacency" must not be formed
> with hellos that have the access "AC" bit set, however, must be formed
> with others. If p1 is the only with AC set, then does it "block" or
> "forward" traffic? I believe that the above scenarios needs to be
> addressed in the TRILL base spec. 
>
>
> Item 4: Section 3.7.3 - An RBridge that will not act as an ingress,
> egress, or tree root need not have a nickname.
>         Do we really want this statement in the base spec ? What if it
> does vlan-mapping, etc. Can we just delete
>         this statement from the dradt. 
>
> Item 5: Section 4.1 - please replace on Ethernet links with (on
> multi-access links). I am hoping that we can be 
>         sensitive to running a P2P mode (configured albeit) on Ethernet
> links. 
>
> Item 6: Section 4.1.2 - ESADI is a single instance or multiple instances
> per vlan as currently defined. I 
>         believe that I had raised scalability concerns with ESADI being
> multiple instances.  
>
> Item 7: Section 4.1.3 - There is talk about TRILL-IS-IS Hellos and outer
> encapsulation. [This is to be 
>         removed as per the last call note 2]. 
>
> Item 8: Section 4.2.2 - TRILL-IS-IS frames must be ALL-Rbridges
> multicast address (unicast address how?)
>         Updates to this section are not in sync with 4.1.3 
>
> Item 9: Section 4.2.3.1 - one rbridge is elected DRB for LAN case, but
> in P2P case there should be no 
>         such thing. I believe that the confusion could be due to the
> fact 
>         the base spec talks about TRILL-IS-IS in terms of LAN IIHs,
> however, P2P IIHs (with a config option) 
>         need to be accounted.  We want text in the base protocol spec
> that says that in the event a link 
>         is configured to be P2P, such DRB election is not needed (as per
> base IS-IS protocol). Also, 
>         with P2P mode configuration, there need not be any spraying of
> hellos. 
>
> Item 10: Section 4.2.3.5 - New section -- I think that we are better
> served with a P2P IIH section in the draft. 
>
> Item 11: Section 4.2.3.1.1 - Are Core IS-IS hellos tagged ? Maybe okay
> for LAN, but is this true for P2P 
>
> Item 12: Section 4.2.3.1.1 - Last sentence ?? Not sure I follow this,
> can this be re-written please.
>
> Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear. 
>
> Item 14: Section 4.2.3.1.2 - Based on feedback from the IS-IS WG should
> we remove this optimization (delete last 3 paras) 
>
> Item 15: section 4.2.3.2 - (note 1) - designated vlan to be used for
> trill data frames, does this imply that 
>                             vlans are getting tunneled with a different
> outer vlan-id. Just want to make this 
>                             explicit.
>
> Item 16: Section 4.2.3.3 - (last note - should this must be the
> ext-ckt-id for P2P, and in a lan. This implies
>                            that we should mandate 3-way handshake for
> P2P links.
>
> Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose
> all (see note 3 in the last call) 
>
> Item 18: Section 4.3 - Distribution tree (see note 3 in last call and
> please see draft-ward) 
>
> Item 19: Section 4.3.1 - Talk about parallel links and what needs to
> break them 
>
> Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address
> and go everywhere) 
>
> Item 21: Section 4.4.1.2 - Second last paragraph - please change the
> last sentence. 
>
> Item 22: Section 4.4.2.2 - the forwarding rbridge need not be a AF on
> the link (paragraph 2, consider a P2P case).
>                            Or make a statement, that on a P2P, rbridges
> are automatically AFs.
>
> Item 23: Section 4.5 needs more text on forwarding of various classes of
> multicast control plane packets
>                      some are forwarded using a special address while
> other are flooded.
>
> Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. 
>
> Item 25: Section 4.6.3 - Not sure if mis-configuration detection being
> carried in the LSP is a good idea. 
>                          Assuming that it stays there, I do not see any
> text on what to do when things are 
>                          mis-configured. If this is just a log, I would
> suggest that we take this out-of-band
>                          and configuration mismatch issues be handled
> separately. 
>
> Item 26: Section 4.7.1 - Text is confusing since we are talking about
> creating adjacencies, pseudo-node
>                          LSPs etc. Please see item 3 above and text
> needs to make the scenarios outlined
>                          there clearer.
>
> Item 27: Section 4.7.3.3 - Last sentence, do rbridges with access ports,
> run STP ? If not, why not? I am 
>                            guessing that statement is talking about
> trunk ports; if so can we make that 
>                            explicit.
>
> Item 28: Section A.2 - Solution 4 to problem 1- what optional feature?
>
> -----Original Message-----
> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On
> Behalf Of Erik Nordmark
> Sent: Friday, November 07, 2008 8:48 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
>
> This message begins a working group last call on
> draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
> document, it will run for three weeks until Wednesday, November 26th.
>
> There are three issues in connection with this draft that you may wish
> to note:
>    1. A method of doing VLAN mapping was discussed on the working group
> mailing list. This protocol draft is compatible with that method which
> has been written up in draft-perlman-trill-rbridge-vlan-mapping-00. This
> separate draft could be considered for adoption as a working group draft
> and be progressed separately or it could be considered as material to
> add to the protocol draft, perhaps as an appendix.
>    2. The protocol draft does incorporate a change in the encapsulation
> of TRILL IS-IS frames (they are no longer encapsulated but are always
> sent to a different multicast address) and a minor change in the
> encapsulation of TRILL ESADI frames (they have a different new inner
> multicast address). There was discussion of this on the mailing list but
> sufficiently little that it was hard to gauge working group opinion.
>    3. There was discussion on the mailing list of alternatives for
> distribution tree root selection and announcement but no changes along
> these lines were made in the draft.
>
> At least items 1 and 3 above are expected to be discussed at the working
> group meeting in Minneapolis. Should those discussions result in any
> changes to the base draft then we will separately last call those
> changes.
>
> Erik and Donald
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mASFSEiA007362 for <rbridge@postel.org>; Fri, 28 Nov 2008 07:28:15 -0800 (PST)
Received: by an-out-0708.google.com with SMTP id d11so561542and.30 for <rbridge@postel.org>; Fri, 28 Nov 2008 07:28:14 -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=zm/CuqxzO/3sCngEuakTa3pbUps6CTVbbeX1y0ZSwvk=; b=caKfc8l2O2L883Ycz1wWYFhABS1AqEGmlxrhOEMw3ZoveNjuWhxKyeNjv+EhyGgLok V6bcCPEJ/rttCPCq7dwmsSc67IcnUABfxOmH4+LBin4x4guxO2SwCK1YhRCymDzHMWYz fZOk25nRkrJ0ekL9g0/uuh7olGKQj8b9WebNA=
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=Nsvuar7nJbpOeEN5hRaU1K+Jwf4DqBE83224RqLmec3wO7k8TyrEj9icuM4xVfY0os eVWc1oVTWtYtVA6dH2+4KSSQtO3ojhaZUfQILynrfe09X0zQq7LP+kxmrk3rj3AYskIW Qbm/8Qv3hCKRvpyCkajb6+/ipJ4Dau/OTVxL4=
Received: by 10.100.255.10 with SMTP id c10mr4184403ani.86.1227886094182; Fri, 28 Nov 2008 07:28:14 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Fri, 28 Nov 2008 07:28:14 -0800 (PST)
Message-ID: <1028365c0811280728k544d61a2s4c6c5ab2d83e91a8@mail.gmail.com>
Date: Fri, 28 Nov 2008 10:28:14 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "mike shand" <mshand@cisco.com>
In-Reply-To: <492D92F5.4000902@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <49147147.50605@sun.com> <492D92F5.4000902@cisco.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
Cc: rbridge@postel.org
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2008 15:28:33 -0000
Status: RO
Content-Length: 8387

Hi Mike,

Thanks for your comments, responses below...

On Wed, Nov 26, 2008 at 1:18 PM, mike shand <mshand@cisco.com> wrote:
>
>...
>
> 1. The problem of IIH space limitations (typically a maximum of < 1500
> octets) and potential number of VLAN tags (4.2.3.1.1) is not discussed.
> Even if some range based compression is used there is the possibility of
> pathological distributions of VLAN ids (e.g. just the odd ones) causing
> problems. There needs to be some guidance on what limitations this may
> impose etc.

That's a reasonable point. The Hello contents are in 4.2.3.1.2. The
only bulky items are 3 (enabled VLANs) and 6 (appointed forwarders).

Item 3 is usually present and relates, so to speak, to the
configuration of the 802.1Q part of the RBridge port and so could be
pretty arbitrary. For that reason, draft-eastlake-trill-isis proposes
that it be bit encoded so it can't take too much more than 512 bytes
(in the worst case it takes three TLVs/sub-TLVs to fit the data).

Item 6 is only in the DRB's Hello but you may want to specify VLANs
for each of several other RBridges if you are load sharing the
forwarding function. This obviously won't fit in the general case and
there should be a comment to that effect. On the other hand, I don't
see this as a big problem.  The DRB appointing some other RBridge as
forwarder for one or more VLANs or blocks of VLANs is just an
optimization. Its probably OK, in my opinion, if the DRB can't do such
appointments with complete generality due to the Hello frame size
limit.

I think some discussion of this should be added as you suggest.

> 2. The number of IIHs required to be sent when large numbers of VLANs
> are in use (4.2.3.1.1) is of some concern. Again there needs to be some
> discussion of what impact this may have in terms of limiting the
> scaleability of the protocol, and whether such limitations are acceptable.

There was considerable discussion in the TRILL WG on the number of
Hellos to be sent. Some wanted Hellos to always be sent on all VLANs,
considerably more than the default specified in this protocol
specification draft. Some wanted fewer Hellos, possibly just Hellos on
the Designated VLAN. However, fewer Hellos are not safe in general
unless you also use the optional decapsulation check. See Sections 3.2
of
http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt
(However, note that that draft has not been updated for the latest
changes in the protocol draft; I'm working on a -01).

> 3. The loop avoidance mechanisms described in 4.2.3.3 needs to be
> verified by the IS-IS WG. In addition the last bullet needs some further
> explanation as to what aspect "already provided in IS-IS" is being
> referenced.  IS-IS will normally only elect a single DIS in such
> circumstances, but there is no provision for disabling forwarding as is
> implied here.

TRILL loop avoidance is unrelated to IS-IS routing loop avoidance.
TRILL loop avoidance is just about minimizing the probability that a
frame which is decapsulated by one RBridge port onto a link will be
picked up and re-encapsulated by another RBridge port connected to
that link (where a link may be a bridged LAN). In fact, the sketch of
a proof that persistent loops do not occur in RBridge campuses, which
appears in Section 4 of
http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt
(which, as I mention above, is out of date and needs to be updated),
simply assumes that there are no persistent IS-IS routing loops (and
no persistent loops within any bridged LANs). So, while I welcome any
review and intelligent comment, given that TRILL loop avoidance is
unrelated to IS-IS routing loop avoidance, it is not clear to me why
the TRILL loop avoidance mechanisms need to be blessed by the IS-IS
WG.

On your second point concerning the last bullet point in Section
4.2.3.3, I think you are correct to question it. It seems superfluous
and a little confused.
       As I understand it, TRILL IS-IS Hellos injected by the same
RBridge into a link through different ports are distinguished by their
source MAC addresses. In any case, it would be plausible that, under
some circumstances, the DRB would want to appoint as a forwarder some
other of its own port's that are attached to the same link. This might
seem like an odd and useless thing to do if you imagine the link as a
hunk of classic Ethernet cable but, in fact, the ports may be
connected to different areas of an arbitrarily complex bridged LAN.
       In any case, I think this last bullet point item should simply
be deleted.

> 4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by IS-IS
> WG. In particular the mechanism of setting the  mapping detected bit in
> the next 5 hellos seems dangerous, since such messages could be lost in
> the looping which would ensue when mapping was configured. This should
> either be latched until reset, or at the very least latched until it is
> detected that it has been actioned by the DRB.

The TRILL VLAN mapping detection is only there for TRILL loop
avoidance. A mapping of VLAN X to Y inside a link is only a problem if
different RBridge ports are appointed forwarder for X and Y on that
link. That's why, by default, RBridges send Hellos on a port in all
VLANs for which they are appointed forwarder for that port. If a
VLAN-X frame is decapsulated onto a link and picked up and
re-encapsulated as a VLAN-Y frame, while you're not there yet, you
have taken a big step towards having a loop. (A second link doing VLAN
Y to X mapping and one broadcast frame and you're sunk...)
       But having it latch until the DRB acknowledges it seems like a
reasonable idea.

> 5. It is not clear how the existing VLAN mapping detection will
> interoperate with the proposed VLAN mapping extensions discussed in
> Minneapolis.

TRILL VLAN mapping detection concerns mapping that is occurring
between RBridges on a path that includes an initial RBridge port below
the EISS interface, a link which may be a bridged LAN, and a final
RBridge port below the EISS interface. On the other hand, the VLAN
mapping extension in
http://tools.ietf.org/id/draft-perlman-trill-rbridge-vlan-mapping-00.txt
that was discussed in Minneapolis provides for VLAN mapping in the
core of the cut-set RBridges between two regions. As far as I can see,
these two kinds of VLAN mapping are orthogonal.

> 6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID
> USUALLY by appending another octet to the 6 octet system ID owned by the
> DRB. This suggests that the possibility of some other way is intended.
> If so this needs to be described.

Probably Radia should answer this one. However, if the assertion in
that section that "The only constraint is that the 7-octet ID be
unique within the campus, and that the 7th octet be nonzero." is not
correct, then the section needs to be re-written. However, if that
assertion is correct, I see no reason why the method used by any
particular DRB to determine the campus-unique 7-octet ID needs to be
discussed or described. There are a number of obvious ways to do this
which generally leverage off the global uniqueness of MAC addresses.

> 7. The second para of 4.2.4.1 (ESADI participation) needs some rational
> for the sending of CSNPs by the non-DRB.

Another item probably for Radia...but as I recall the idea is that
participants, other than the DRB, know they should be getting a CSNP
occasionally. If they don't get one in a long enough time, they send
one on the theory it might help and can't hurt.

> 8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is
> not IS-IS NSAP..." What does this mean?

The wording is poor... You get to 4.4.2.1 on receipt of a frame
addressed to All-IS-IS-RBridges. You want to discard the frame if it
isn't an IS-IS frame. The "frame protocol" is the Ethertype or SNAP
SAP 5-octet protocol or the LSAPs... anyway, I think this is just
trying to say that it must be an IS-IS frame encoded in the usual LLC
way even if there is currently or in the future an IS-IS Ethertype or
the like... i.e., if there is now, or in the future, some other way of
encoding the IS-IS protocol in a frame, RBridges need not support it.

> Mike

Thanks again for the comments,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com

Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQMef1x017718 for <rbridge@postel.org>; Wed, 26 Nov 2008 14:40:42 -0800 (PST)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAQMefm0020612 for <rbridge@postel.org>; Wed, 26 Nov 2008 22:40:41 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mAQMee23046081 for <rbridge@postel.org>; Wed, 26 Nov 2008 17:40:40 -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 mAQMLoMi026838; Wed, 26 Nov 2008 17:21:56 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mAQMLhwZ026831; Wed, 26 Nov 2008 17:21:43 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18733.52215.806793.660780@gargle.gargle.HOWL>
Date: Wed, 26 Nov 2008 17:21:43 -0500
From: James Carlson <james.d.carlson@sun.com>
To: Donald Eastlake <d3e3e3@gmail.com>
In-Reply-To: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com>
References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: carlsonj@phorcys.east.sun.com
Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 22:40:50 -0000
Status: RO
Content-Length: 1382

Donald Eastlake writes:
> I've reviewed the draft and will be posting a few suggested changes. This is
> the first.
> 802.1 bridges have a Maximum Bridge Transit Delay. They are required to
> discard frames that have been inside the bridge for longer than this time.
> It is configurable with a recommended value of 1 second and maximum value of
> 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a
> sentence or two to indicate that RBridges have this parameter configurable
> per RBridge and enforce a maximum RBridge transit delay.

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?

I can imagine flushing Ethernet output queues if link status goes down
and stays down for more than a second, thus blocking timely output,
but tracking internal timestamps on individual packets seems like a
wasted effort to me, and may not even be feasible with modern
hardware.

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.

-- 
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
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

Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQMQX8N013440 for <rbridge@postel.org>; Wed, 26 Nov 2008 14:26:34 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so632672rvf.45 for <rbridge@postel.org>; Wed, 26 Nov 2008 14:26:33 -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=PviFe8Q/lhlGOf0lxZa3xPx4Tl5vSDeSjmsZOdzJykw=; b=RN6/WULp41VGI5s9vb0Xe3ncGx01Qiz2qItSzKBKKwl1sAxUI786ty0hbklB+N21/0 jjTWdF9b4Zqk77CTQiP/XMgD9Wb5cFuq/VY2bH0sb/YHgw6mfHKA4fZ3NxinYV+cnIfm T1H5JgrYPThwl4WxAkvXXaE9JTpPam7GVg9Ug=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=BC7Zpw2Yy7Rt3/7EPmF6c6Es9y/Ruaq9wRklz8MQUoxxmSCMPW0b+xNp32lIek9RdP Lbsluvz9yjF5prLWwLe43icOHtEgfALtbyK+PAXNqHaJW0CjoI1BJ1TA+9Z5nqN+UrVi KFklXbpDDni/Zdx14fmDZO3K48243Roy84+EU=
Received: by 10.141.162.9 with SMTP id p9mr3104854rvo.202.1227738393715; Wed, 26 Nov 2008 14:26:33 -0800 (PST)
Received: by 10.140.208.6 with HTTP; Wed, 26 Nov 2008 14:26:33 -0800 (PST)
Message-ID: <1028365c0811261426m12b34f4bx8cf08cf6c6c0b2b5@mail.gmail.com>
Date: Wed, 26 Nov 2008 17:26:33 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_21997_30575635.1227738393709"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
Subject: [rbridge] draft protocol-10 WGLC Security Considerations BPDU/Hello DoS addition
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 22:26:57 -0000
Status: RO
Content-Length: 5649

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

This is the last of my three comments on the draft.
I propose to add a section to the Security Considerations of the protocol-10
draft as pasted at the end of this message. Comments welcome.

Thanks,Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com

The TRILL protocol requires that an appointed forwarder on an RBridge port
be temporarily inhibited if it sees a Hello from another RBridge claiming to
be the appointed forwarder or sees a root bridge change out that port. Thus
it would seem that forged BPDUs showing repeated root bridge changes and
forged Hellos with the Appointed Forwarder flag set could represent a
significant denial of service attack. However, the situation is not as bad
as it seems.

The best defense against forged Hellos or other IS-IS messages is the use of
IS-IS security [RFC5304]. Rogue end-stations would not normally have access
to the required IS-IS keying material needed to forge authenticatible
messages.

Authentication similar to IS-IS security is usually unavailable for BPDUs.
However, it is also the case that in typical modern wired LANs, all the
links are point-to-point. If you have an all RBridged campus, then the worst
that an end-station can do by forging BPDUs is to deny itself service. This
could be either through falsely inhibiting the forwarding of native frames
by the RBridge to which it is connected or by falsely activating the
optional decapsulation check (see Section 4.2.3.3).

However, when an RBridge campus contains bridged LANs, those bridged LANs
appear to any connected RBridges to be multi-access links. The forging of
BPDUs by an end-station attached to such a bridged LAN could affect service
to other end-stations attached to the bridged LAN. Note that bridges do not
forward BPDUs but process them, although this processing may result in the
issuance of further BPDUs. Thus, for an end-station to forge BPDUs to cause
continuing changes in the root bridge as seen by an RBridge through
intervening bridges would typically require it to cause root bridge
thrashing throughout the bridged LAN which would be disruptive even in the
absence of RBridges.

Some bridges can be configured to ignore BPDUs on particular ports and
RBridges can be configured not to inhibit appointed forwarding on a port;
however, such configuration should be used with caution as it can be unsafe.

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

This is the last of my three comments on the draft.<div><br></div><div>I propose to add a section to the Security Considerations of the protocol-10 draft as pasted at the end of this message. Comments welcome.<br clear="all">
<br>Thanks,<div>Donald<br>=============================<br> Donald E. Eastlake 3rd &nbsp; +1-508-634-2066 (home)<br>

 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:d3e3e3@gmail.com" target="_blank">d3e3e3@gmail.com</a><br>
</div><div><br></div><div><br></div><div><br></div><div>The TRILL protocol requires that an appointed forwarder on an RBridge port be temporarily inhibited if it sees a Hello from another RBridge claiming to be the appointed forwarder or sees a root bridge change out that port. Thus it would seem that forged BPDUs showing repeated root bridge changes and forged Hellos with the Appointed Forwarder flag set could represent a significant denial of service attack. However, the situation is not as bad as it seems.</div>

<div><br></div><div>The best defense against forged Hellos or other IS-IS messages is the use of IS-IS security [RFC5304]. Rogue end-stations would not normally have access to the required IS-IS keying material needed to forge authenticatible messages.</div>

<div><br></div><div>Authentication similar to IS-IS security is usually unavailable for BPDUs. However, it is also the case that in typical modern wired LANs, all the links are point-to-point. If you have an all RBridged campus, then the worst that an end-station can do by forging BPDUs is to deny itself service. This could be either through falsely inhibiting the forwarding of native frames by the RBridge to which it is connected or by falsely activating the optional decapsulation check (see Section <a href="http://4.2.3.3"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 4.2.3.3</a>).</div>

<div><br></div><div>However, when an RBridge campus contains bridged LANs, those bridged LANs appear to any connected RBridges to be multi-access links. The forging of BPDUs by an end-station attached to such a bridged LAN could affect service to other end-stations attached to the bridged LAN. Note that bridges do not forward BPDUs but process them, although this processing may result in the issuance of further&nbsp;BPDUs. Thus, for an end-station to forge BPDUs to cause continuing changes in the root bridge as seen by an RBridge through intervening bridges would typically require it to cause root bridge thrashing throughout the bridged LAN which would be disruptive even in the absence of RBridges.</div>

<div><br></div><div>Some bridges can be configured to ignore BPDUs on particular ports and RBridges can be configured not to inhibit appointed forwarding on a port; however, such configuration should be used with caution as it can be unsafe.</div>

</div>

------=_Part_21997_30575635.1227738393709--

Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQM8b00007486 for <rbridge@postel.org>; Wed, 26 Nov 2008 14:08:38 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so626898rvf.45 for <rbridge@postel.org>; Wed, 26 Nov 2008 14:08:37 -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=yslpN2DLnOlC2/UULdq1X0FOe/xJthgEeFbqPYSSkGo=; b=es4nMZ38+lMIuy3bsCysWnJGVdmkx6UsObKkpFO0baCX5USX2O63GF0kBf1XPOJ6k7 G+W6mvQogc6vGnOpoygY6vj73b2gF3d+tZqvjIHolH+IwSHUaG/0uoJ3t5SCdrvLPo+K 9xfM4TqreFEQfD9OAxI0j+dMH27qoAq/A+mWM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=clEsn9GaSiEEGSkrhyQksep3yXCir7w6qLEtLYWND+l2LO70JQ1T+aWB+vR8lMW7sP 9M7LsebrGojj3ojvarwdxeHmA+vlhFaRdONlRzAi/a8ETfDa2eFbnwSIwwUIeFbBNCkJ DERxowmjFbEpMRli/vKaGTWk6E1AXYWz1vbMk=
Received: by 10.141.34.12 with SMTP id m12mr3106592rvj.118.1227737317613; Wed, 26 Nov 2008 14:08:37 -0800 (PST)
Received: by 10.140.208.6 with HTTP; Wed, 26 Nov 2008 14:08:37 -0800 (PST)
Message-ID: <1028365c0811261408o459c3d19jc23b3235bf2f9ef4@mail.gmail.com>
Date: Wed, 26 Nov 2008 17:08:37 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_21853_18661479.1227737317617"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 22:08:48 -0000
Status: RO
Content-Length: 4390

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

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   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com

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

Hi,<div><br></div><div>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&nbsp;&nbsp;All-IS-IS-RBridges is their Outer.MacDA, (2) All-RBridges is the Outer.MacDA for&nbsp;ESADI and&nbsp;multi-destination data frames, and (3) All-ESADI-RBridges is the Inner.MacDA for ESADI frames.</div>

<div>

<br><div>I don&#39;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.&nbsp;This sort of behavior has to be specified at the beginning. Once you start shipping devices that are transparent to some addresses, you can&#39;t practically later say they have to drop them if they don&#39;t know the protocol(s) associated with those addresses.&nbsp;(This behavior for bridges has been somewhat modified 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 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).<br>

<br></div><div>Thanks,</div><div>Donald<br>=============================<br> Donald E. Eastlake 3rd &nbsp; +1-508-634-2066 (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:d3e3e3@gmail.com" target="_blank">d3e3e3@gmail.com</a><br>

</div></div>
</div>

------=_Part_21853_18661479.1227737317617--

Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQLUxn9025195 for <rbridge@postel.org>; Wed, 26 Nov 2008 13:30:59 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id g9so1454773rvb.0 for <rbridge@postel.org>; Wed, 26 Nov 2008 13:30:58 -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=vkAzi4q19kO7d2tkakJPG7le1sgld+eD4XesbBKv9JQ=; b=m7MjG7rd6OnNaqDnANd6lSSccHFMLp6uTRubeod1B9l/3WFwWFVtZHCWftYc+STFEf gNTzHCYs6xawDJs1deMiXK6b/vAr8msVd6ClrJ7kXtxLeaRd/eTiUkyf4r6lk0cTh+LJ A+AaXYUTYpF2Gcgx4nNXOI712qUfuJGLbeHhw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Faw29qxUIp4nI9RuA1PDaEh9J1iM8Q8JaW2Fy2D/bJHTAaKERnJfCAjyCEJ3+WtLgS cgba92rf6AqBw8b/KCayhnMCVGr/TLy9r1K3pX+wGR0Fb2xsIYI+i/uaiOv8sfqaYyjP 0f0P9d0Y/pTN76NxZJS7omIXhwkNbONIiOe1k=
Received: by 10.140.127.13 with SMTP id z13mr3091065rvc.145.1227735058911; Wed, 26 Nov 2008 13:30:58 -0800 (PST)
Received: by 10.140.208.6 with HTTP; Wed, 26 Nov 2008 13:30:58 -0800 (PST)
Message-ID: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com>
Date: Wed, 26 Nov 2008 16:30:58 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_21520_7245256.1227735058906"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 21:31:15 -0000
Status: RO
Content-Length: 1828

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

I've reviewed the draft and will be posting a few suggested changes. This is
the first.
802.1 bridges have a Maximum Bridge Transit Delay. They are required to
discard frames that have been inside the bridge for longer than this time.
It is configurable with a recommended value of 1 second and maximum value of
4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a
sentence or two to indicate that RBridges have this parameter configurable
per RBridge and enforce a maximum RBridge transit delay.

Thanks,Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com

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

I&#39;ve reviewed the draft and will be posting a few suggested changes. This is the first.<div><br></div><div>802.1 bridges have a Maximum Bridge Transit Delay. They are required to discard frames that have been inside the bridge for longer than this time. It is configurable with a recommended value of 1 second and maximum value of 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a sentence or two to indicate that&nbsp;RBridges have this parameter configurable per RBridge and enforce a maximum RBridge transit delay.<br clear="all">
<br>Thanks,<div>Donald<br>=============================<br> Donald E. Eastlake 3rd &nbsp; +1-508-634-2066 (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:d3e3e3@gmail.com" target="_blank">d3e3e3@gmail.com</a><br>

</div></div>

------=_Part_21520_7245256.1227735058906--

Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQJPLPZ014387 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rbridge@postel.org>; Wed, 26 Nov 2008 11:25:22 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,670,1220227200"; d="scan'208";a="202278960"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2008 19:25:21 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAQJPKE9016982;  Wed, 26 Nov 2008 11:25:20 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQJPKau003158; Wed, 26 Nov 2008 19:25:20 GMT
Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 26 Nov 2008 11:25:19 -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: Wed, 26 Nov 2008 11:25:18 -0800
Message-ID: <AE36820147909644AD2A7CA014B1FB5206D5AF79@xmb-sjc-222.amer.cisco.com>
In-Reply-To: <492D92F5.4000902@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Thread-Index: AclP9jObGzJO07H/RhGq1YK9qJmHmwABZYnQ
References: <49147147.50605@sun.com> <492D92F5.4000902@cisco.com>
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Mike Shand (mshand)" <mshand@cisco.com>, "Erik Nordmark" <erik.nordmark@sun.com>
X-OriginalArrivalTime: 26 Nov 2008 19:25:19.0773 (UTC) FILETIME=[B836ECD0:01C94FFC]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5945; t=1227727521; x=1228591521; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ginsberg@cisco.com; z=From:=20=22Les=20Ginsberg=20(ginsberg)=22=20<ginsberg@cisc o.com> |Subject:=20RE=3A=20[rbridge]=20WG=20last=20call=20on=20dra ft-trill-rbridge-protocol-10.txt |Sender:=20; bh=QvtPKUHxfWJkcaQIUnr76H8OfAGJF9Wc3rbpBHyegIg=; b=Fr+YkfbrojUYpWiqrJrBLEqIhRcQqm7p6HfzPubBraf5SBqlLoFSVxQjNy p44rjkFP7+ghrvjr852JihPgp6aMsfjc8sMvwdvHYM5Q4ip3BUFgPyOUXrwI qw2uL1s0a19NhU6iigKAuB2wBzmoIszexK9bPOg/yUnS2UYrDbgUk=;
Authentication-Results: sj-dkim-1; header.From=ginsberg@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: ginsberg@cisco.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id mAQJPLPZ014387
Cc: rbridge@postel.org
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 19:26:05 -0000
Status: RO
Content-Length: 5764

In support of Mike's comments, I would also suggest we look at this in
the context of the recent agreement that draft-ward-l2isis be the home
for all L2 IS-IS extensions. We therefore want to minimize the overlap
between the architecture document and draft-ward-l2isis so as to avoid
even the appearance of diverging specifications.

It may make sense for the architecture document to discuss the required
functionality at a high level, but currently there is considerable text
which specifies the procedural extensions of an L2-IS-IS instance - and
that clearly is the province of draft-ward-l2isis.

So in addition to working out the technical issues on points Mike
describes below, the architecture document needs to be revised in such a
way as to not duplicate or be in conflict with the protocol extensions
draft as it develops.

   Les

> -----Original Message-----
> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org]
On
> Behalf Of Mike Shand (mshand)
> Sent: Wednesday, November 26, 2008 10:18 AM
> To: Erik Nordmark
> Cc: rbridge@postel.org
> Subject: Re: [rbridge] WG last call on
draft-trill-rbridge-protocol-10.txt
> 
> I have reviewed the draft from the viewpoint of IS-IS, and I have the
> following comments. In view of the dependency on IS-IS protocol
encoding
> AND protocol operation changes, I believe it is important that we get
> agreement with the IS-IS WG on those aspects that affect the operation
> of the IS-IS protocol before this draft is set in stone.
> 
> The points where I believe some discussion between the working groups
is
> required include, but may not be limited to, the items I have
enumerated
> below.
> 
> 1. The problem of IIH space limitations (typically a maximum of < 1500
> octets) and potential number of VLAN tags (4.2.3.1.1) is not
discussed.
> Even if some range based compression is used there is the possibility
of
> pathological distributions of VLAN ids (e.g. just the odd ones)
causing
> problems. There needs to be some guidance on what limitations this may
> impose etc.
> 
> 2. The number of IIHs required to be sent when large numbers of VLANs
> are in use (4.2.3.1.1) is of some concern. Again there needs to be
some
> discussion of what impact this may have in terms of limiting the
> scaleability of the protocol, and whether such limitations are
acceptable.
> 
> 3. The loop avoidance mechanisms described in 4.2.3.3 needs to be
> verified by the IS-IS WG. In addition the last bullet needs some
further
> explanation as to what aspect "already provided in IS-IS" is being
> referenced.  IS-IS will normally only elect a single DIS in such
> circumstances, but there is no provision for disabling forwarding as
is
> implied here.
> 
> 4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by
IS-IS
> WG. In particular the mechanism of setting the  mapping detected bit
in
> the next 5 hellos seems dangerous, since such messages could be lost
in
> the looping which would ensue when mapping was configured. This should
> either be latched until reset, or at the very least latched until it
is
> detected that it has been actioned by the DRB.
> 
> 5. It is not clear how the existing VLAN mapping detection will
> interoperate with the proposed VLAN mapping extensions discussed in
> Minneapolis.
> 
> 6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID
> USUALLY by appending another octet to the 6 octet system ID owned by
the
> DRB. This suggests that the possibility of some other way is intended.
> If so this needs to be described.
> 
> 7. The second para of 4.2.4.1 (ESADI participation) needs some
rational
> for the sending of CSNPs by the non-DRB.
> 
> 8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol
is
> not IS-IS NSAP..." What does this mean?
> 
> 
> Mike
> 
> 
> Erik Nordmark wrote:
> > This message begins a working group last call on
> > draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
> > document, it will run for three weeks until Wednesday, November
26th.
> >
> > There are three issues in connection with this draft that you may
wish
> > to note:
> >    1. A method of doing VLAN mapping was discussed on the working
> > group mailing list. This protocol draft is compatible with that
method
> > which has been written up in
> > draft-perlman-trill-rbridge-vlan-mapping-00. This separate draft
could
> > be considered for adoption as a working group draft and be
progressed
> > separately or it could be considered as material to add to the
> > protocol draft, perhaps as an appendix.
> >    2. The protocol draft does incorporate a change in the
> > encapsulation of TRILL IS-IS frames (they are no longer encapsulated
> > but are always sent to a different multicast address) and a minor
> > change in the encapsulation of TRILL ESADI frames (they have a
> > different new inner multicast address). There was discussion of this
> > on the mailing list but sufficiently little that it was hard to
gauge
> > working group opinion.
> >    3. There was discussion on the mailing list of alternatives for
> > distribution tree root selection and announcement but no changes
along
> > these lines were made in the draft.
> >
> > At least items 1 and 3 above are expected to be discussed at the
> > working group meeting in Minneapolis. Should those discussions
result in
> > any changes to the base draft then we will separately last call
those
> > changes.
> >
> > Erik and Donald
> > _______________________________________________
> > rbridge mailing list
> > rbridge@postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQJ5JCA008409 for <rbridge@postel.org>; Wed, 26 Nov 2008 11:05:20 -0800 (PST)
Received: by yw-out-2324.google.com with SMTP id 5so285753ywh.75 for <rbridge@postel.org>; Wed, 26 Nov 2008 11:05:19 -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=VDBNZQcyX5kXSwJzPxtMCVR3wcyPWGmGzDGt2AQkzIQ=; b=QH90RJKFOEFkYmPnQqtQAcypQfR2vFWQYLWLY48awjJOSMZjmZXhSQYlooVqBaOcm6 Ses4Naorm7UMShQiEizkG37U2UEwFuV+d939h49E/r0POv144oJeWeAJuNaO9d4Uh+CR o4LDiehbGNLnqJKXUBq7htK7174IVEnqsLJnw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=xtcqNM5gCEDdymUgh4LUFDYjX/9tc0oCbnwAQZ1up7qGOikM3k8q074E03lNUIn9uT L9F6VPqHpTpmYiYnOafQerX5qLuPnJsAhP9RK1HN+JWAYrDSmmQt2TvLzQcM2F5BRUwl 9VHIig21id8VDYk1GrTk+cPHo2RpzSGfrBiO4=
Received: by 10.90.102.14 with SMTP id z14mr5222agb.44.1227726318487; Wed, 26 Nov 2008 11:05:18 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Wed, 26 Nov 2008 11:05:18 -0800 (PST)
Message-ID: <1028365c0811261105t523f02cdpc1e5537518c6f0d4@mail.gmail.com>
Date: Wed, 26 Nov 2008 14:05:18 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_31247_14338146.1227726318463"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
Subject: [rbridge] draft-eastlake-trill-rbridge-options-01.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 19:05:46 -0000
Status: RO
Content-Length: 3005

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

   - *To*: i-d-announce at ietf.org <i-d-announce@DOMAIN.HIDDEN>
   - *Subject*: I-D ACTION:draft-eastlake-trill-rbridge-options-01.txt
   - *From*: Internet-Drafts at ietf.org <Internet-Drafts@DOMAIN.HIDDEN>
   - *Date*: Mon, 24 Nov 2008 14:45:02 -0800 (PST)
   - *List-archive*: <http://www.ietf.org/pipermail/i-d-announce>
   - *List-id*: Internet Draft Announcements only <i-d-announce.ietf.org>

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

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

	Title		: Rbridges: TRILL Header Options
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-rbridge-options-01.txt
	Pages		: 17
	Date		: 2008-11-24

The TRILL base protocol specification, draft-ietf-trill-rbridge-
   protocol-10.txt, specifies minimal hooks for options. This draft more
   fully describes the format for options and an initial set of options.

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

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

------=_Part_31247_14338146.1227726318463
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; "><ul><li><em>To</em>:&nbsp;<a href="mailto:i-d-announce@DOMAIN.HIDDEN">i-d-announce at ietf.org</a></li><li><em>Subject</em>: I-D ACTION:draft-eastlake-trill-rbridge-options-01.txt</li>
<li><em>From</em>:&nbsp;<a href="mailto:Internet-Drafts@DOMAIN.HIDDEN">Internet-Drafts at ietf.org</a></li><li><em>Date</em>: Mon, 24 Nov 2008 14:45:02 -0800 (PST)</li><li><em>List-archive</em>: &lt;<a href="http://www.ietf.org/pipermail/i-d-announce">http://www.ietf.org/pipermail/i-d-announce</a>&gt;<br>
</li><li><em>List-id</em>: Internet Draft Announcements only &lt;<a href="http://i-d-announce.ietf.org">i-d-announce.ietf.org</a>&gt;</li></ul><hr><pre>A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Rbridges: TRILL Header Options
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-rbridge-options-01.txt
	Pages		: 17
	Date		: 2008-11-24

The TRILL base protocol specification, draft-ietf-trill-rbridge-
   protocol-10.txt, specifies minimal hooks for options. This draft more
   fully describes the format for options and an initial set of options.

A URL for this Internet-Draft is:
<a rel="nofollow" href="http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-01.txt">http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-01.txt</a>

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

------=_Part_31247_14338146.1227726318463--

Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQImgpC001989 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rbridge@postel.org>; Wed, 26 Nov 2008 10:48:42 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,670,1220227200"; d="scan'208";a="54297164"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2008 18:48:41 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAQImfC6008764;  Wed, 26 Nov 2008 10:48:41 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQImfk2028126; Wed, 26 Nov 2008 18:48:41 GMT
Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 26 Nov 2008 10:48:41 -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: Wed, 26 Nov 2008 10:48:40 -0800
Message-ID: <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Thread-Index: AclBAIv/xHh6e9VhR7Ki0wLefo4ciQOjhrcQABoJ4zA=
References: <49147147.50605@sun.com> 
From: "Ayan Banerjee (ayabaner)" <ayabaner@cisco.com>
To: "Erik Nordmark" <erik.nordmark@sun.com>, <rbridge@postel.org>
X-OriginalArrivalTime: 26 Nov 2008 18:48:41.0334 (UTC) FILETIME=[99D7C160:01C94FF7]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9908; t=1227725321; x=1228589321; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ayabaner@cisco.com; z=From:=20=22Ayan=20Banerjee=20(ayabaner)=22=20<ayabaner@cis co.com> |Subject:=20RE=3A=20[rbridge]=20WG=20last=20call=20on=20dra ft-trill-rbridge-protocol-10.txt |Sender:=20; bh=lVhtmhj+zBUn/jvs/LAvxZwTUkWIjx9L0nXQ8jogz/s=; b=Da3Vpl94JJtmT0bgybWngg1OQtub9ubFw4uAEGV28apWPXrQ/fUiGPGbb0 StVABkqtGfh/N/lEsuAJA2/HW48ntLFoJfUyzsc66t1/HC4P2KWktuzHo3yI uZbwBpb+vo;
Authentication-Results: sj-dkim-2; header.From=ayabaner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: ayabaner@cisco.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id mAQImgpC001989
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 18:49:32 -0000
Status: RO
Content-Length: 9608

All,

Please see attached comments to the last call on
draft-ietf-trill-rbridge-protocol-10.txt.

Thanks,
Ayan
------------------------------------------------------------------------
-----------------------

Item 1: Section 1.3, can we change the order of control
frame/trill-frame/native-frame (editing nits) 

Item 2: Section 2.1 has reference to ESADI as an IS-IS instance. I
believe we said that this is no 
        longer an IS-IS protocol. Can we please update the draft
accordingly. 

Item 3: Section 2.3.1 - Spraying of hellos, scalability concerns, text
is unclear Consider the following topology and the following scenarios.

      |            |              |
     RB1--------- RB2 ---------- RB3
      |            |              |
      |p1          |p2            |p3

The Rbi's are connected on the top to a TRILL cloud consisting of only
Rbridges (for ease of discussion). They are connected on the bottom to
CE switches/network via ports p1, p2, and p3. 

Scenario 1: All ports (p1, p2, and p3) are configured to be access ports
(as defined in Appendix A of the draft). 
In this case, Rbi's will spray with hellos on all VLANs configured on
their respective ports. The intent is if a hello is received by other
Rbi's and an "adjacency" can be formed, then we want to block ports to
prevent loops. The intent is such a link should not get in the LSP-DB;
this is inverse of the operation desired with a traditional-isis-hello.
Only one port remains forwarding and the others are blocked; if so I
could not figure out from the draft which one is forwarding (is
system-id etc used as a tie?). Once this is blocked, it remains blocked
till we "loose" the adjacency again. It is possible that the requirement
will be to send in the order of 10,000s hellos/per sec per node. This
solution of spraying poses scalability concerns for the protocol. Also,
the announcement of the vlan list (however compressed) may not fit
within the isis-hello-pdu. 

Scenario 2: All ports (p1, p2, and p3) are configured to be trunk ports
(as defined in Appendix A of the draft). 
Once again, Rbi's spray hello on all VLANs. In this case, forming of
adjacencies is desired, in the sense this links gets in the LSP-DB. Once
a DRB is elected, only the DRB continues spraying with hellos such that
future nodes can discover and join the designated vlan to send hellos.
Nodes other than the DIS after the initial spraying will move to sending
hellos on the designated vlan only. Question: What happens if the DRB
does not capture all the vlans, for example RB1 became DRB, but has
vlans 2,3 on p1 and the others p2 and p3, have vlan 2,3,4. Can a new
RB4, with vlan 4 configured on it enter this Rbridge LAN and create
issues? Can we have some text to clearly show the desired operation. 

Scenario 3: Some ports are configured to be trunk and some others access
(could be due to mis-configuration or error in cabling) Not sure what is
the desired behavior? Are we saying that "adjacency" must not be formed
with hellos that have the access "AC" bit set, however, must be formed
with others. If p1 is the only with AC set, then does it "block" or
"forward" traffic? I believe that the above scenarios needs to be
addressed in the TRILL base spec. 

Item 4: Section 3.7.3 - An RBridge that will not act as an ingress,
egress, or tree root need not have a nickname.
        Do we really want this statement in the base spec ? What if it
does vlan-mapping, etc. Can we just delete
        this statement from the dradt. 

Item 5: Section 4.1 - please replace on Ethernet links with (on
multi-access links). I am hoping that we can be 
        sensitive to running a P2P mode (configured albeit) on Ethernet
links. 

Item 6: Section 4.1.2 - ESADI is a single instance or multiple instances
per vlan as currently defined. I 
        believe that I had raised scalability concerns with ESADI being
multiple instances.  

Item 7: Section 4.1.3 - There is talk about TRILL-IS-IS Hellos and outer
encapsulation. [This is to be 
        removed as per the last call note 2]. 

Item 8: Section 4.2.2 - TRILL-IS-IS frames must be ALL-Rbridges
multicast address (unicast address how?)
        Updates to this section are not in sync with 4.1.3 

Item 9: Section 4.2.3.1 - one rbridge is elected DRB for LAN case, but
in P2P case there should be no 
        such thing. I believe that the confusion could be due to the
fact 
        the base spec talks about TRILL-IS-IS in terms of LAN IIHs,
however, P2P IIHs (with a config option) 
        need to be accounted.  We want text in the base protocol spec
that says that in the event a link 
        is configured to be P2P, such DRB election is not needed (as per
base IS-IS protocol). Also, 
        with P2P mode configuration, there need not be any spraying of
hellos. 

Item 10: Section 4.2.3.5 - New section -- I think that we are better
served with a P2P IIH section in the draft. 

Item 11: Section 4.2.3.1.1 - Are Core IS-IS hellos tagged ? Maybe okay
for LAN, but is this true for P2P 

Item 12: Section 4.2.3.1.1 - Last sentence ?? Not sure I follow this,
can this be re-written please.

Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear. 

Item 14: Section 4.2.3.1.2 - Based on feedback from the IS-IS WG should
we remove this optimization (delete last 3 paras) 

Item 15: section 4.2.3.2 - (note 1) - designated vlan to be used for
trill data frames, does this imply that 
                            vlans are getting tunneled with a different
outer vlan-id. Just want to make this 
                            explicit.

Item 16: Section 4.2.3.3 - (last note - should this must be the
ext-ckt-id for P2P, and in a lan. This implies
                           that we should mandate 3-way handshake for
P2P links.

Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose
all (see note 3 in the last call) 

Item 18: Section 4.3 - Distribution tree (see note 3 in last call and
please see draft-ward) 

Item 19: Section 4.3.1 - Talk about parallel links and what needs to
break them 

Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address
and go everywhere) 

Item 21: Section 4.4.1.2 - Second last paragraph - please change the
last sentence. 

Item 22: Section 4.4.2.2 - the forwarding rbridge need not be a AF on
the link (paragraph 2, consider a P2P case).
                           Or make a statement, that on a P2P, rbridges
are automatically AFs.

Item 23: Section 4.5 needs more text on forwarding of various classes of
multicast control plane packets
                     some are forwarded using a special address while
other are flooded.

Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. 

Item 25: Section 4.6.3 - Not sure if mis-configuration detection being
carried in the LSP is a good idea. 
                         Assuming that it stays there, I do not see any
text on what to do when things are 
                         mis-configured. If this is just a log, I would
suggest that we take this out-of-band
                         and configuration mismatch issues be handled
separately. 

Item 26: Section 4.7.1 - Text is confusing since we are talking about
creating adjacencies, pseudo-node
                         LSPs etc. Please see item 3 above and text
needs to make the scenarios outlined
                         there clearer.

Item 27: Section 4.7.3.3 - Last sentence, do rbridges with access ports,
run STP ? If not, why not? I am 
                           guessing that statement is talking about
trunk ports; if so can we make that 
                           explicit.

Item 28: Section A.2 - Solution 4 to problem 1- what optional feature?

-----Original Message-----
From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On
Behalf Of Erik Nordmark
Sent: Friday, November 07, 2008 8:48 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

This message begins a working group last call on
draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
document, it will run for three weeks until Wednesday, November 26th.

There are three issues in connection with this draft that you may wish
to note:
   1. A method of doing VLAN mapping was discussed on the working group
mailing list. This protocol draft is compatible with that method which
has been written up in draft-perlman-trill-rbridge-vlan-mapping-00. This
separate draft could be considered for adoption as a working group draft
and be progressed separately or it could be considered as material to
add to the protocol draft, perhaps as an appendix.
   2. The protocol draft does incorporate a change in the encapsulation
of TRILL IS-IS frames (they are no longer encapsulated but are always
sent to a different multicast address) and a minor change in the
encapsulation of TRILL ESADI frames (they have a different new inner
multicast address). There was discussion of this on the mailing list but
sufficiently little that it was hard to gauge working group opinion.
   3. There was discussion on the mailing list of alternatives for
distribution tree root selection and announcement but no changes along
these lines were made in the draft.

At least items 1 and 3 above are expected to be discussed at the working
group meeting in Minneapolis. Should those discussions result in any
changes to the base draft then we will separately last call those
changes.

Erik and Donald
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAQIIg2X022606 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rbridge@postel.org>; Wed, 26 Nov 2008 10:18:44 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,670,1220227200"; d="scan'208";a="26912189"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2008 18:18:31 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAQIIVhv017480;  Wed, 26 Nov 2008 19:18:31 +0100
Received: from [10.61.85.135] (ams3-vpn-dhcp5512.cisco.com [10.61.85.135]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQIIUUT012238; Wed, 26 Nov 2008 18:18:31 GMT
Message-ID: <492D92F5.4000902@cisco.com>
Date: Wed, 26 Nov 2008 18:18:29 +0000
From: mike shand <mshand@cisco.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Erik Nordmark <erik.nordmark@sun.com>
References: <49147147.50605@sun.com>
In-Reply-To: <49147147.50605@sun.com>
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=4409; t=1227723511; x=1228587511; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshand@cisco.com; z=From:=20mike=20shand=20<mshand@cisco.com> |Subject:=20Re=3A=20[rbridge]=20WG=20last=20call=20on=20dra ft-trill-rbridge-protocol-10.txt |Sender:=20; bh=M5Xoace3QtoUEQy5C1k6DbfJx6d9+VIdjAwMhH8MmFA=; b=aiGrZorSMsi2VBeaH79M2EV+ZT/tUXH8+Pi7Y5fSp2M2h7hL2CPgEpdOLJ 7WDaIvTC3QBsSqJeDI5f1i/62l/XMXpEb+kS57jkgst8OrEax4WQcsUxBvC6 OS9f6Jfuw9;
Authentication-Results: ams-dkim-1; header.From=mshand@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: mshand@cisco.com
Cc: rbridge@postel.org
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2008 18:19:16 -0000
Status: RO
Content-Length: 4318

I have reviewed the draft from the viewpoint of IS-IS, and I have the 
following comments. In view of the dependency on IS-IS protocol encoding 
AND protocol operation changes, I believe it is important that we get 
agreement with the IS-IS WG on those aspects that affect the operation 
of the IS-IS protocol before this draft is set in stone.

The points where I believe some discussion between the working groups is 
required include, but may not be limited to, the items I have enumerated 
below.

1. The problem of IIH space limitations (typically a maximum of < 1500 
octets) and potential number of VLAN tags (4.2.3.1.1) is not discussed. 
Even if some range based compression is used there is the possibility of 
pathological distributions of VLAN ids (e.g. just the odd ones) causing 
problems. There needs to be some guidance on what limitations this may 
impose etc.

2. The number of IIHs required to be sent when large numbers of VLANs 
are in use (4.2.3.1.1) is of some concern. Again there needs to be some 
discussion of what impact this may have in terms of limiting the 
scaleability of the protocol, and whether such limitations are acceptable.

3. The loop avoidance mechanisms described in 4.2.3.3 needs to be 
verified by the IS-IS WG. In addition the last bullet needs some further 
explanation as to what aspect "already provided in IS-IS" is being 
referenced.  IS-IS will normally only elect a single DIS in such 
circumstances, but there is no provision for disabling forwarding as is 
implied here.

4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by IS-IS 
WG. In particular the mechanism of setting the  mapping detected bit in 
the next 5 hellos seems dangerous, since such messages could be lost in 
the looping which would ensue when mapping was configured. This should 
either be latched until reset, or at the very least latched until it is 
detected that it has been actioned by the DRB.

5. It is not clear how the existing VLAN mapping detection will 
interoperate with the proposed VLAN mapping extensions discussed in 
Minneapolis.

6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID 
USUALLY by appending another octet to the 6 octet system ID owned by the 
DRB. This suggests that the possibility of some other way is intended. 
If so this needs to be described.

7. The second para of 4.2.4.1 (ESADI participation) needs some rational 
for the sending of CSNPs by the non-DRB.

8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is 
not IS-IS NSAP..." What does this mean?

Mike

Erik Nordmark wrote:
> This message begins a working group last call on
> draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
> document, it will run for three weeks until Wednesday, November 26th.
>
> There are three issues in connection with this draft that you may wish 
> to note:
>    1. A method of doing VLAN mapping was discussed on the working
> group mailing list. This protocol draft is compatible with that method
> which has been written up in 
> draft-perlman-trill-rbridge-vlan-mapping-00. This separate draft could
> be considered for adoption as a working group draft and be progressed
> separately or it could be considered as material to add to the
> protocol draft, perhaps as an appendix.
>    2. The protocol draft does incorporate a change in the
> encapsulation of TRILL IS-IS frames (they are no longer encapsulated
> but are always sent to a different multicast address) and a minor
> change in the encapsulation of TRILL ESADI frames (they have a
> different new inner multicast address). There was discussion of this
> on the mailing list but sufficiently little that it was hard to gauge
> working group opinion.
>    3. There was discussion on the mailing list of alternatives for
> distribution tree root selection and announcement but no changes along
> these lines were made in the draft.
>
> At least items 1 and 3 above are expected to be discussed at the
> working group meeting in Minneapolis. Should those discussions result in 
> any changes to the base draft then we will separately last call those 
> changes.
>
> Erik and Donald
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAL0VMMZ018631 for <rbridge@postel.org>; Thu, 20 Nov 2008 16:31:22 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAL0VL7u003893 for <rbridge@postel.org>; Fri, 21 Nov 2008 00:31:21 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAL0VG26209983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 16:31:17 -0800 (PST)
Message-ID: <4926014F.1090000@sun.com>
Date: Thu, 20 Nov 2008 16:31:11 -0800
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20081023)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: erik.nordmark@sun.com
Subject: [rbridge] Merging of draft-eastlake-trill-rbridge-isis and draft-ward-l2isis
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Nov 2008 00:31:45 -0000
Status: RO
Content-Length: 996

The allocation of IS-IS code-points and the specification of encoding
for information in IS-IS to support Layer-2 routing were discussed in
the TRILL and ISIS working group meetings earlier this week. There
were also presentations in the ISIS working group meeting on TRILL and
on IEEE 802.1aq. (The IEEE 802.1aq project has expanded to include
Layer-2 use of IS-IS.)

The conclusion was that the existing draft-eastlake-trill-rbridge-isis
draft should be merged into draft-ward-l2isis and corrected and, in
addition, the IEEE 802.1aq requirements should also be merged into the
resulting "kitchen sink" document which would be processed as an ISIS
working group document. The plan is that Ayan Banerjee, a current
author of ward-l2isis, and Donald Eastlake would be two of the
co-authors of the resulting document.

People should indicate sometime in the next week if they object to this 
plan.

If there are no objections we will request that ISIS make this a WG 
document.

   Erik and Donald

Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAI41MEX000196 for <rbridge@postel.org>; Mon, 17 Nov 2008 20:01:23 -0800 (PST)
Received: by an-out-0708.google.com with SMTP id d11so1154182and.30 for <rbridge@postel.org>; Mon, 17 Nov 2008 20:01:22 -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=QhUuD/oGnUnBB6TXIK7PiObF835j1uepwn6AWvAmC9Y=; b=W1Z0m6/Wkm+mpxtwQwzkdTNYcr52rWc10OT6++mVZmW6/70L2bFYNzWeQFP1dpnP6R RIzNxPfs48khaQA6w55t1quen56hAyfBbZoLAU8pGhXlKvC6BATLIuz6DcDYISoGvTNI sbssR7kRvb+P+B4xtZowhna2/o9+qSeEE10BI=
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=b2cLxqG3yMd8vHq+1WPrTtKa28huZsF0AvZdv0bzp4EAWh9GOVmFLQ5tRZHcQbzXic vH33LwuEVwn4qUIZhMwqa0AF4ABlsQBNc5CsXhJL0c9ce97gVvUb9Lb56TGuxq6NduQF N+U/1C7WxfTzXyrvejjoYsDKEavFlobUdmpG0=
Received: by 10.100.131.13 with SMTP id e13mr1947879and.57.1226980882483; Mon, 17 Nov 2008 20:01:22 -0800 (PST)
Received: by 10.100.13.4 with HTTP; Mon, 17 Nov 2008 20:01:22 -0800 (PST)
Message-ID: <1028365c0811172001g79d17de9oe09971413e916aad@mail.gmail.com>
Date: Mon, 17 Nov 2008 23:01:22 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
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: d3e3e3@gmail.com
Subject: [rbridge] Minneapolis Presentations
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2008 04:01:56 -0000
Status: RO
Content-Length: 335

Hi,

All of the presentations given at today's TRILL WG meeting have been
uploaded/updated on the Meeting Materials page at
https://datatracker.ietf.org/meeting/73/materials.html.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3@gmail.com

Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAHLcd6s009236 for <rbridge@postel.org>; Mon, 17 Nov 2008 13:38:40 -0800 (PST)
Received: by core3.amsl.com (Postfix, from userid 30) id 57DC828C0F3; Mon, 17 Nov 2008 13:38:08 -0800 (PST)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20081117213809.57DC828C0F3@core3.amsl.com>
Date: Mon, 17 Nov 2008 13:38:09 -0800 (PST)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: wwwrun@core3.amsl.com
Cc: rbridge@postel.org
Subject: [rbridge] Last Call: draft-ietf-trill-prob (Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement) to Informational RFC
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: ietf@ietf.org
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2008 21:39:14 -0000
Status: RO
Content-Length: 856

The IESG has received a request from the Transparent Interconnection of 
Lots of Links WG (trill) to consider the following document:

- 'Transparent Interconnection of Lots of Links (TRILL): Problem and 
   Applicability Statement '
   <draft-ietf-trill-prob-05.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2008-12-01. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14771&rfc_flag=0

Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mA7GmGC8022703 for <rbridge@postel.org>; Fri, 7 Nov 2008 08:48:17 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.108.38]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA7GmGNj023187 for <rbridge@postel.org>; Fri, 7 Nov 2008 16:48:16 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA7Gm8dX698881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 08:48:12 -0800 (PST)
Message-ID: <49147147.50605@sun.com>
Date: Fri, 07 Nov 2008 08:48:07 -0800
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080923)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: erik.nordmark@sun.com
Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2008 16:48:31 -0000
Status: RO
Content-Length: 1510

This message begins a working group last call on
draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
document, it will run for three weeks until Wednesday, November 26th.

There are three issues in connection with this draft that you may wish 
to note:
   1. A method of doing VLAN mapping was discussed on the working
group mailing list. This protocol draft is compatible with that method
which has been written up in 
draft-perlman-trill-rbridge-vlan-mapping-00. This separate draft could
be considered for adoption as a working group draft and be progressed
separately or it could be considered as material to add to the
protocol draft, perhaps as an appendix.
   2. The protocol draft does incorporate a change in the
encapsulation of TRILL IS-IS frames (they are no longer encapsulated
but are always sent to a different multicast address) and a minor
change in the encapsulation of TRILL ESADI frames (they have a
different new inner multicast address). There was discussion of this
on the mailing list but sufficiently little that it was hard to gauge
working group opinion.
   3. There was discussion on the mailing list of alternatives for
distribution tree root selection and announcement but no changes along
these lines were made in the draft.

At least items 1 and 3 above are expected to be discussed at the
working group meeting in Minneapolis. Should those discussions result in 
any changes to the base draft then we will separately last call those 
changes.

Erik and Donald

Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mA4HsddG012125 for <rbridge@postel.org>; Tue, 4 Nov 2008 09:54:41 -0800 (PST)
Received: by yw-out-2324.google.com with SMTP id 5so1158623ywh.75 for <rbridge@postel.org>; Tue, 04 Nov 2008 09:54:39 -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=o8BqTFoR9HQ9iamqhUkIERM4FNWBEEjSA6VHvN5TyF0=; b=DH5Mfh1qWWwd67OfBitG496BY7uPsTj6bzrf+2lr6AwKstUjDtlpaLj/su2ibuKnDt UXiIEIpZf4Ta7RqfpuId1g8ObMZIsNBnjTmfWH9q3/Q1401BeibTqV/cyC/mbCyJKTFa fER+flSIxBA9ZKqS5x1zHYO4tQckwuQQrKbiA=
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=eGHdgbLntTTYKPYbpXSA0qZEY5MdhbFJeYmS5p5DyKVCsA9NKeSLUS2Bxu6ROuLkmB wzT7JcZ0H2eJtJskWUOVDkf6BsCMfWolWXF1T0G/pS3mcY5TRhPi69a51hh+CpkT3YSd 1qwogVXMUcp8HzrRzehJQ8NjTKxEcXWYtAIwQ=
Received: by 10.100.125.9 with SMTP id x9mr881139anc.139.1225821279299; Tue, 04 Nov 2008 09:54:39 -0800 (PST)
Received: by 10.100.13.4 with HTTP; Tue, 4 Nov 2008 09:54:39 -0800 (PST)
Message-ID: <1028365c0811040954t23d9f9b6xe28b6ff7288ab9ab@mail.gmail.com>
Date: Tue, 4 Nov 2008 12:54:39 -0500
From: "Donald Eastlake" <d3e3e3@gmail.com>
To: "Developing a hybrid router/bridge." <rbridge@postel.org>
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: d3e3e3@gmail.com
Subject: [rbridge] draft-eastlake-trill-rbridge-isis-02.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2008 17:55:18 -0000
Status: RO
Content-Length: 1015

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

	Title		: RBridges: Use of IS-IS
	Author(s)	: D. Eastlake 3rd, R. Perlman, D. Dutt
	Filename	: draft-eastlake-trill-rbridge-isis-02.txt
	Pages		: 19
	Date		: 2008-11-3

RBridges implement the TRILL protocol, which in turn makes use of an
   extended version of the IS-IS (Intermediate System to Intermediate
   System) routing protocol to determine topology and frame forwarding
   and for the distribution and synchronization of data. RBridges
   provide optimal pair-wise forwarding with zero configuration, safe
   forwarding even during periods of temporary loops, and multipathing
   for both unicast and multicast traffic. Rbridges also support VLANs.
   This document specifies some details of IS-IS PDUs used in TRILL.

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

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

Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mA3NUU0T009276 for <rbridge@postel.org>; Mon, 3 Nov 2008 15:30:30 -0800 (PST)
Received: by core3.amsl.com (Postfix, from userid 0) id 4556528C3AD; Mon,  3 Nov 2008 15:30:00 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20081103233001.4556528C3AD@core3.amsl.com>
Date: Mon,  3 Nov 2008 15:30:01 -0800 (PST)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: root@core3.amsl.com
Cc: rbridge@postel.org
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-10.txt
X-BeenThere: rbridge@postel.org
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:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Nov 2008 23:30:42 -0000
Status: RO
Content-Length: 1923

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman
	Filename	: draft-ietf-trill-rbridge-protocol-10.txt
	Pages		: 86
	Date		: 2008-11-3

RBridges provide optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and support for multipathing of both unicast and multicast
   traffic. They achieve these goals using IS-IS routing and
   encapsulation of traffic with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 customer bridges as
   well as IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs and optimization of the distribution of
   multi-destination frames based on VLAN and IP derived multicast
   groups.  It also allows forwarding tables to be sized according to
   the number of RBridges (rather than the number of end nodes), which
   allows internal forwarding tables to be substantially smaller than in
   conventional bridges.

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-protocol-10.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2008-11-3152113.I-D@ietf.org>

--NextPart--