[rbridge] TRILL Header/Tag

[Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)]

Hi,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Friday, June 29, 2007 4:11 AM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

I can see some value in this, but given that
existing bridges wouldn't do any better than
the coarse pruning based on the fields that
I mentioned, I think this functionality should
be listed in the draft as a SHOULD/MAY rather 
than as a MUST.

@@@ If you say so, I'm sure some bridges prune based on the fields you
list. In any case, both types of pruning, VLAN and multicast, are only
"SHOULD" in the current protocol draft. However, I think the draft needs
to be fixed up to describe correctly how to implement state-of-the-art
multicast pruning, taking into account James Carlson's comments and
further taking account of RFC 4541. It also needs to describe how to
correctly not do multicast pruning. Of course, an Rbridge could do
something between these two points. You may have a campus with some
Rbridges doing all of RFC 4541 multicast pruning things and some doing
none and some doing the "coarse grained pruning" you describe. If you
are not careful, some multicast traffic or IGMP/MLDs from Rbridges which
are pruning may not get to the links connected to the Rbridges ignoring
multicast pruning.

Anoop 

-----Original Message-----
From: J. R. Rivers [mailto:jrrivers at nuovasystems.com] 
Sent: Thursday, June 28, 2007 4:24 PM
To: James Carlson; Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] TRILL Header/Tag

With IP multicast pruning in bridges, the traditional mode of operation
has been... if you don't know for sure, don't prune.  This is what
allows various implementations to be deployed in the face of no real
specification covering the functionality (and changes in IGMP versions
along the way).

@@@ I'm not sure what you mean by "real specification" but RFC 4541
seems reasonably close to me. Sure, you can always not optimize by
flooding something. But it seems to me that TRILL should make it
possible for Rbridges to do the best job they reasonably can on IP
derived multicast pruning.

JR

@@@ All I'm aiming for in this case it to make it possible for Rbridges
that want to prune IP derived multicast according to the only
comprehensive document on the subject (RFC 4541) to be able to do so
efficiently. To me, that means that if there are Rbridges (perhaps
including the ingress Rbridge but possibly starting at a transit
Rbridge) doing full IP derived multicast pruning, only the first one
that sees a frame should have to do the complete analysis. The results
of that analysis can be encoded by selecting one of the three values of
the V field and used by any subsequent Rbridges that wish to do so. An
Rbridge that doesn't want to do IP multicast pruning can just ignore V
as long as it's in the range indicating the current version of TRILL.

@@@ In this scheme, to accommodate Rbridges that don't want to do
multicast optimization, there probably has to be one additional V value
to indicate that analysis of the frame has not been done from the point
of view of RFC 4541 IP multicast pruning.
	
@@@ Thanks,
@@@ Donald

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
> Sent: Thursday, June 28, 2007 11:49 AM
> To: Eastlake III Donald-LDE008
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] TRILL Header/Tag
> 
> Eastlake III Donald-LDE008 writes:
> > For example, both 224.0.0.42 and 225.128.0.42 are valid 
> IPv4 multicast
> > addresses from which the same MAC address, namely 01-00-5E-00-00-2A,
> > would be derived. You would want to prune traffic to 
> 225.128.0.42 but
> > you can't validly prune traffic to 224.0.0.42 because, 
> according to RFC
> > 4541, hosts do not consistently issue IGMPs for IPv4 
> addresses in the
> > 224.0.0.0/24 range.
> 
> Yep; exactly.  224.0.0.0/24 is both "link-local" and "well-known" and
> thus expected to work right without the help or interference of
> multicast routers.  (Where, "right" means that all stations on the
> link can receive it.)
> 
> > I haven't studied all the IGMP stuff for different versions but, for
> > IGMP (and MLD), at best you have the problem in the 
> paragraph above and
> > at worst even the IP multicast address would be inadequate 
> and you would
> > have to look deeper into the frame to check the IP 
> protocol, etc., in
> > order to decide whether to prune just to branches with IP multicast
> > routers.
> 
> For IGMPv2, you'll need to look deeper, because the IGMP Report
> messages from hosts themselves are sent on the group address (RFC 2236
> section 9).  With IGMPv3, the Report messages are directed to a common
> multicast address (224.0.0.22; RFC 3376 section 4.2.14).
> 
> -- 
> James Carlson, Solaris Networking              
> <james.d.carlson at sun.com>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l611rhFU021881 for <[e-mail]>; Sat, 30 Jun 2007 18:53:43 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-119.messagelabs.com!1183254821!18136812!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 9805 invoked from network); 1 Jul 2007 01:53:42 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 1 Jul 2007 01:53:42 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l611rfvG002159 for <[e-mail]>; Sat, 30 Jun 2007 18:53:41 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l611rfNX014067 for <[e-mail]>; Sat, 30 Jun 2007 20:53:41 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l611ren2014062 for <[e-mail]>; Sat, 30 Jun 2007 20:53:40 -0500 (CDT)
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: Sat, 30 Jun 2007 21:53:38 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
thread-index: Ace5vNf5PlPSmvvBQba+K7DMh3DNDAABSiawAEBeUkA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l611rhFU021881
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 01 Jul 2007 01:54:04 -0000
Status: RO
Content-Length: 5237

Hi,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Friday, June 29, 2007 4:11 AM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

I can see some value in this, but given that
existing bridges wouldn't do any better than
the coarse pruning based on the fields that
I mentioned, I think this functionality should
be listed in the draft as a SHOULD/MAY rather 
than as a MUST.

@@@ If you say so, I'm sure some bridges prune based on the fields you
list. In any case, both types of pruning, VLAN and multicast, are only
"SHOULD" in the current protocol draft. However, I think the draft needs
to be fixed up to describe correctly how to implement state-of-the-art
multicast pruning, taking into account James Carlson's comments and
further taking account of RFC 4541. It also needs to describe how to
correctly not do multicast pruning. Of course, an Rbridge could do
something between these two points. You may have a campus with some
Rbridges doing all of RFC 4541 multicast pruning things and some doing
none and some doing the "coarse grained pruning" you describe. If you
are not careful, some multicast traffic or IGMP/MLDs from Rbridges which
are pruning may not get to the links connected to the Rbridges ignoring
multicast pruning.

Anoop 

-----Original Message-----
From: J. R. Rivers [mailto:[e-mail]] 
Sent: Thursday, June 28, 2007 4:24 PM
To: James Carlson; Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] TRILL Header/Tag

With IP multicast pruning in bridges, the traditional mode of operation
has been... if you don't know for sure, don't prune.  This is what
allows various implementations to be deployed in the face of no real
specification covering the functionality (and changes in IGMP versions
along the way).

@@@ I'm not sure what you mean by "real specification" but RFC 4541
seems reasonably close to me. Sure, you can always not optimize by
flooding something. But it seems to me that TRILL should make it
possible for Rbridges to do the best job they reasonably can on IP
derived multicast pruning.

JR

@@@ All I'm aiming for in this case it to make it possible for Rbridges
that want to prune IP derived multicast according to the only
comprehensive document on the subject (RFC 4541) to be able to do so
efficiently. To me, that means that if there are Rbridges (perhaps
including the ingress Rbridge but possibly starting at a transit
Rbridge) doing full IP derived multicast pruning, only the first one
that sees a frame should have to do the complete analysis. The results
of that analysis can be encoded by selecting one of the three values of
the V field and used by any subsequent Rbridges that wish to do so. An
Rbridge that doesn't want to do IP multicast pruning can just ignore V
as long as it's in the range indicating the current version of TRILL.

@@@ In this scheme, to accommodate Rbridges that don't want to do
multicast optimization, there probably has to be one additional V value
to indicate that analysis of the frame has not been done from the point
of view of RFC 4541 IP multicast pruning.
	
@@@ Thanks,
@@@ Donald

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Carlson
> Sent: Thursday, June 28, 2007 11:49 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header/Tag
> 
> Eastlake III Donald-LDE008 writes:
> > For example, both 224.0.0.42 and 225.128.0.42 are valid 
> IPv4 multicast
> > addresses from which the same MAC address, namely 01-00-5E-00-00-2A,
> > would be derived. You would want to prune traffic to 
> 225.128.0.42 but
> > you can't validly prune traffic to 224.0.0.42 because, 
> according to RFC
> > 4541, hosts do not consistently issue IGMPs for IPv4 
> addresses in the
> > 224.0.0.0/24 range.
> 
> Yep; exactly.  224.0.0.0/24 is both "link-local" and "well-known" and
> thus expected to work right without the help or interference of
> multicast routers.  (Where, "right" means that all stations on the
> link can receive it.)
> 
> > I haven't studied all the IGMP stuff for different versions but, for
> > IGMP (and MLD), at best you have the problem in the 
> paragraph above and
> > at worst even the IP multicast address would be inadequate 
> and you would
> > have to look deeper into the frame to check the IP 
> protocol, etc., in
> > order to decide whether to prune just to branches with IP multicast
> > routers.
> 
> For IGMPv2, you'll need to look deeper, because the IGMP Report
> messages from hosts themselves are sent on the group address (RFC 2236
> section 9).  With IGMPv3, the Report messages are directed to a common
> multicast address (224.0.0.22; RFC 3376 section 4.2.14).
> 
> -- 
> James Carlson, Solaris Networking              
> <[e-mail]>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



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 l5U5n0ON019381 for <[e-mail]>; Fri, 29 Jun 2007 22:49:00 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 29 Jun 2007 22:49:00 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.227]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 29 Jun 2007 22:48:58 -0700 (PDT)
Date: Fri, 29 Jun 2007 22:49:44 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 30 Jun 2007 05:49:31 -0000
Status: RO
Content-Length: 8751

I think your analysis is correct.

Radia


Eastlake III Donald-LDE008 wrote:
> Hi,
>
> I've been thinking about this some more and come to the conclusion that,
> with the arrangement added in protocol specification -04 where a TRILL
> Header is always present, we don't need a bit to distinguish TRILL IS-IS
> frames from TRILL data frames. That's because we can do so using the
> inner MAC destination address.  There isn't any need for any additional
> multicast addresses.
>
> There are different ways to order the tests that are equivalent but here
> is how I think of it (leaving out some details like VLANs for clarity):
>
> The first thing to do is to test if the Ethertype is TRILL.
>
> (1) If the Ethertype is not TRILL, you have a native frame and I believe
> the processing described in the -04 draft, while it could be more
> detailed, is correct, starting with discarding the frame unless you are
> acting as the Designated Rbridge (DRB).
>
> (2) If the Ethertype is TRILL, your DRB status doesn't matter. If the
> frame is well formed, the outer MAC destination address will either be
> All Rbridges or a unicast address. If its unicast and not addressed to
> you, you discard the frame. At this point, you can check the inner MAC
> destination address.
>
> (2A) If the inner MAC destination address is not All Rbridges, you have
> a TRILL data frame.
>
> (2B) If the inner MAC destination address is All Rbridges, you have a
> TRILL IS-IS frame. If the inner VLAN tag is absent, it is a core
> instance frame. If the inner VLAN tag is present, it is a per VLAN
> instance frame.
>
> So, it now appears to me that a Header flag bit to distinguish TRILL
> data from TRILL IS-IS is not necessary.
>
> Thanks,
> Donald
>
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Friday, June 29, 2007 3:10 PM
> To: Silvano Gai; Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
>
> Silvano/Donald/Radia,
>
> I would prefer to see a different multicast address
> used for the TRILL IS-IS instances.  Was there any
> consensus on this at the time it was discussed.  I
> do remember seeing the discussion, but I can't remember
> how it concluded.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: Silvano Gai [mailto:[e-mail]] 
>> Sent: Thursday, June 28, 2007 1:54 PM
>> To: Eastlake III Donald-LDE008; Anoop Ghanwani
>> Cc: [e-mail]
>> Subject: RE: [rbridge] a clarification about the core IS-IS instance
>>
>> Donald,
>>
>> Radia confirmed that all the ISIS messages are sent to multicast
>> addresses and therefore we discussed the possibility to use separate
>> multicast addresses instead of the V bit
>>
>> -- Silvano
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>>       
>> On
>>     
>>> Behalf Of Eastlake III Donald-LDE008
>>> Sent: Thursday, June 28, 2007 8:46 AM
>>> To: Anoop Ghanwani
>>> Cc: [e-mail]
>>> Subject: Re: [rbridge] a clarification about the core IS-IS instance
>>>
>>> If it were not for the V bit, how would you distinguish an IS-IS
>>>       
>> routing
>>     
>>> packet conveying layer 3 routing information being sent 
>>>       
>> inside a TRILL
>>     
>>> data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
>>>       
>> inside
>>     
>>> a TRILL IS-IS frame?
>>>
>>> Donald
>>>
>>> -----Original Message-----
>>> From: Anoop Ghanwani [mailto:[e-mail]]
>>> Sent: Thursday, June 28, 2007 10:34 AM
>>> To: Eastlake III Donald-LDE008
>>> Cc: [e-mail]
>>> Subject: RE: [rbridge] a clarification about the core IS-IS instance
>>>
>>> Hi Donald,
>>>
>>> Thanks again.
>>>
>>> What's the function of the V-bit in all
>>> of this?  What does an RBridge gain by looking
>>> at this, that it cannot get by looking at
>>> fields that it already has to?
>>>
>>> Anoop
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Eastlake III Donald-LDE008
>>>> [mailto:[e-mail]]
>>>> Sent: Thursday, June 28, 2007 7:30 AM
>>>> To: Anoop Ghanwani
>>>> Cc: [e-mail]
>>>> Subject: RE: [rbridge] a clarification about the core 
>>>>         
>> IS-IS instance
>>     
>>>> Hi Anoop,
>>>>
>>>> That looks about right, although you also have to check that
>>>> the inner length/type field is in the length range. And if
>>>> you determine that a TRILL IS-IS frame is for a per VLAN
>>>> instance, you still don't know if you should process as well
>>>> as forwarding it until you check whether you are DRB for a
>>>> link with an end station in that VLAN.
>>>>
>>>> Donald
>>>>
>>>> -----Original Message-----
>>>> From: Anoop Ghanwani [mailto:[e-mail]]
>>>> Sent: Thursday, June 28, 2007 10:00 AM
>>>> To: Eastlake III Donald-LDE008
>>>> Cc: [e-mail]
>>>> Subject: RE: [rbridge] a clarification about the core 
>>>>         
>> IS-IS instance
>>     
>>>> Hi Donald,
>>>>
>>>> Thanks for the clarification.  Yes, I do remember the
>>>> discussion on the list.  At that time it looked like the
>>>> Ethertype would tell if the frame was IS-IS.
>>>> It now looks like even the core IS-IS instance will use a
>>>> DSAP/SSAP (for some reason I thought we were going to use a
>>>> new Ethertype for the core IS-IS instance).
>>>>
>>>> So, to identify a core IS-IS frame (which all RBridges should
>>>> be interested in) one would have to check for:
>>>> outer.etype = trill
>>>> inner.dsap = xx
>>>> inner.ssap = xx
>>>> inner.ctl = yy
>>>> inner.vlan = not present
>>>>
>>>> The V bit doesn't really seem all that useful since both the
>>>> core frames and the per-VLAN instance have it set, so that
>>>> bit doesn't tell one whether or the packet needs to be
>>>> processed as a control packet at a given RBridge.  The above
>>>> fields are necessary and sufficient.  Please let me know if
>>>> I'm missing something re the V bit.
>>>>
>>>> Thanks,
>>>> Anoop
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Eastlake III Donald-LDE008
>>>>> [mailto:[e-mail]]
>>>>> Sent: Wednesday, June 27, 2007 9:09 PM
>>>>> To: Anoop Ghanwani
>>>>> Cc: [e-mail]
>>>>> Subject: RE: [rbridge] a clarification about the core IS-IS
>>>>>           
>> instance
>>     
>>>>> Hi Anoop,
>>>>>
>>>>> Yes, that was a change that was extensively discussed on
>>>>>           
>>>> the mailing
>>>>         
>>>>> list. There wasn't a formal consensus determination but it
>>>>>           
>>>> was clear
>>>>         
>>>>> that the sentiment of the group was to always have a TRILL
>>>>>           
>>>> Header on
>>>>         
>>>>> TRILL IS-IS frames and use a formerly reserved bit in the header
>>>>>           
>> to
>>     
>>>>> distinguish a TRILL IS-IS frame from a TRILL data frame
>>>>>           
>>>> whose contents
>>>>         
>>>>> happens to be a (presumably layer 3) IS-IS message.
>>>>>
>>>>> I believe your second point is correct. Checking for the TRILL
>>>>> Ethertype is the key to deciding whether to process a frame
>>>>>           
>>>> if you are
>>>>         
>>>>> not DRB on that port and VLAN. (This ignores the
>>>>>           
>>>> bridging/media frames
>>>>         
>>>>> sent to the block of multicast 16 addresses reserved for that
>>>>> purpose.)
>>>>>
>>>>> Thanks,
>>>>> Donald
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail]
>>>>> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
>>>>> Sent: Wednesday, June 27, 2007 9:42 PM
>>>>> To: [e-mail]
>>>>> Subject: [rbridge] a clarification about the core IS-IS instance
>>>>>
>>>>> From reading the previous version of the draft I got the
>>>>>           
>> impression
>>     
>>>>> that frames sent as part of the core IS-IS would not
>>>>>           
>>>> contain a trill
>>>>         
>>>>> header or inner header.  However, on reading this version, it
>>>>>           
>> looks
>>     
>>>>> like the core IS-IS instance would in fact contain a 
>>>>>           
>> trill header.
>>     
>>>>> Assuming that the above is true, would it be safe to assume that
>>>>>           
>> an
>>     
>>>>> RBridge, for a port that is connected to a LAN for which it
>>>>>           
>>>> is not a
>>>>         
>>>>> DRB, will drop all frames whose Ethertype does not 
>>>>>           
>> indicate trill?
>>     
>>>>> Anoop
>>>>>
>>>>>           
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>       
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5U5QNO5012746 for <[e-mail]>; Fri, 29 Jun 2007 22:26:24 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 29 Jun 2007 22:25:59 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.16.227]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 29 Jun 2007 22:25:59 -0700 (PDT)
Date: Fri, 29 Jun 2007 22:26:44 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 30 Jun 2007 05:26:34 -0000
Status: RO
Content-Length: 7089

At the time I thought there might be some IS-IS messages sent unicast. 
If that were
true (which it turns out it isn't), then
differentiating based on multicast addresses would not have worked.

I don't think this is a big deal either way, and I don't think anyone 
had strong opinions about it.

Radia




Anoop Ghanwani wrote:
> Silvano/Donald/Radia,
>
> I would prefer to see a different multicast address
> used for the TRILL IS-IS instances.  Was there any
> consensus on this at the time it was discussed.  I
> do remember seeing the discussion, but I can't remember
> how it concluded.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: Silvano Gai [mailto:[e-mail]] 
>> Sent: Thursday, June 28, 2007 1:54 PM
>> To: Eastlake III Donald-LDE008; Anoop Ghanwani
>> Cc: [e-mail]
>> Subject: RE: [rbridge] a clarification about the core IS-IS instance
>>
>>
>> Donald,
>>
>> Radia confirmed that all the ISIS messages are sent to multicast
>> addresses and therefore we discussed the possibility to use separate
>> multicast addresses instead of the V bit
>>
>> -- Silvano
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>>       
>> On
>>     
>>> Behalf Of Eastlake III Donald-LDE008
>>> Sent: Thursday, June 28, 2007 8:46 AM
>>> To: Anoop Ghanwani
>>> Cc: [e-mail]
>>> Subject: Re: [rbridge] a clarification about the core IS-IS instance
>>>
>>> If it were not for the V bit, how would you distinguish an IS-IS
>>>       
>> routing
>>     
>>> packet conveying layer 3 routing information being sent 
>>>       
>> inside a TRILL
>>     
>>> data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
>>>       
>> inside
>>     
>>> a TRILL IS-IS frame?
>>>
>>> Donald
>>>
>>> -----Original Message-----
>>> From: Anoop Ghanwani [mailto:[e-mail]]
>>> Sent: Thursday, June 28, 2007 10:34 AM
>>> To: Eastlake III Donald-LDE008
>>> Cc: [e-mail]
>>> Subject: RE: [rbridge] a clarification about the core IS-IS instance
>>>
>>> Hi Donald,
>>>
>>> Thanks again.
>>>
>>> What's the function of the V-bit in all
>>> of this?  What does an RBridge gain by looking
>>> at this, that it cannot get by looking at
>>> fields that it already has to?
>>>
>>> Anoop
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Eastlake III Donald-LDE008
>>>> [mailto:[e-mail]]
>>>> Sent: Thursday, June 28, 2007 7:30 AM
>>>> To: Anoop Ghanwani
>>>> Cc: [e-mail]
>>>> Subject: RE: [rbridge] a clarification about the core 
>>>>         
>> IS-IS instance
>>     
>>>> Hi Anoop,
>>>>
>>>> That looks about right, although you also have to check that
>>>> the inner length/type field is in the length range. And if
>>>> you determine that a TRILL IS-IS frame is for a per VLAN
>>>> instance, you still don't know if you should process as well
>>>> as forwarding it until you check whether you are DRB for a
>>>> link with an end station in that VLAN.
>>>>
>>>> Donald
>>>>
>>>> -----Original Message-----
>>>> From: Anoop Ghanwani [mailto:[e-mail]]
>>>> Sent: Thursday, June 28, 2007 10:00 AM
>>>> To: Eastlake III Donald-LDE008
>>>> Cc: [e-mail]
>>>> Subject: RE: [rbridge] a clarification about the core 
>>>>         
>> IS-IS instance
>>     
>>>> Hi Donald,
>>>>
>>>> Thanks for the clarification.  Yes, I do remember the
>>>> discussion on the list.  At that time it looked like the
>>>> Ethertype would tell if the frame was IS-IS.
>>>> It now looks like even the core IS-IS instance will use a
>>>> DSAP/SSAP (for some reason I thought we were going to use a
>>>> new Ethertype for the core IS-IS instance).
>>>>
>>>> So, to identify a core IS-IS frame (which all RBridges should
>>>> be interested in) one would have to check for:
>>>> outer.etype = trill
>>>> inner.dsap = xx
>>>> inner.ssap = xx
>>>> inner.ctl = yy
>>>> inner.vlan = not present
>>>>
>>>> The V bit doesn't really seem all that useful since both the
>>>> core frames and the per-VLAN instance have it set, so that
>>>> bit doesn't tell one whether or the packet needs to be
>>>> processed as a control packet at a given RBridge.  The above
>>>> fields are necessary and sufficient.  Please let me know if
>>>> I'm missing something re the V bit.
>>>>
>>>> Thanks,
>>>> Anoop
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Eastlake III Donald-LDE008
>>>>> [mailto:[e-mail]]
>>>>> Sent: Wednesday, June 27, 2007 9:09 PM
>>>>> To: Anoop Ghanwani
>>>>> Cc: [e-mail]
>>>>> Subject: RE: [rbridge] a clarification about the core IS-IS
>>>>>           
>> instance
>>     
>>>>> Hi Anoop,
>>>>>
>>>>> Yes, that was a change that was extensively discussed on
>>>>>           
>>>> the mailing
>>>>         
>>>>> list. There wasn't a formal consensus determination but it
>>>>>           
>>>> was clear
>>>>         
>>>>> that the sentiment of the group was to always have a TRILL
>>>>>           
>>>> Header on
>>>>         
>>>>> TRILL IS-IS frames and use a formerly reserved bit in the header
>>>>>           
>> to
>>     
>>>>> distinguish a TRILL IS-IS frame from a TRILL data frame
>>>>>           
>>>> whose contents
>>>>         
>>>>> happens to be a (presumably layer 3) IS-IS message.
>>>>>
>>>>> I believe your second point is correct. Checking for the TRILL
>>>>> Ethertype is the key to deciding whether to process a frame
>>>>>           
>>>> if you are
>>>>         
>>>>> not DRB on that port and VLAN. (This ignores the
>>>>>           
>>>> bridging/media frames
>>>>         
>>>>> sent to the block of multicast 16 addresses reserved for that
>>>>> purpose.)
>>>>>
>>>>> Thanks,
>>>>> Donald
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail]
>>>>> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
>>>>> Sent: Wednesday, June 27, 2007 9:42 PM
>>>>> To: [e-mail]
>>>>> Subject: [rbridge] a clarification about the core IS-IS instance
>>>>>
>>>>> From reading the previous version of the draft I got the
>>>>>           
>> impression
>>     
>>>>> that frames sent as part of the core IS-IS would not
>>>>>           
>>>> contain a trill
>>>>         
>>>>> header or inner header.  However, on reading this version, it
>>>>>           
>> looks
>>     
>>>>> like the core IS-IS instance would in fact contain a 
>>>>>           
>> trill header.
>>     
>>>>> Assuming that the above is true, would it be safe to assume that
>>>>>           
>> an
>>     
>>>>> RBridge, for a port that is connected to a LAN for which it
>>>>>           
>>>> is not a
>>>>         
>>>>> DRB, will drop all frames whose Ethertype does not 
>>>>>           
>> indicate trill?
>>     
>>>>> Anoop
>>>>>
>>>>>           
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>       
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5TJtlSA000473 for <[e-mail]>; Fri, 29 Jun 2007 12:55:47 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-128.messagelabs.com!1183146946!5034297!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 29688 invoked from network); 29 Jun 2007 19:55:46 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 29 Jun 2007 19:55:46 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5TJtkLi024124 for <[e-mail]>; Fri, 29 Jun 2007 12:55:46 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l5TJtjB7006843 for <[e-mail]>; Fri, 29 Jun 2007 14:55:45 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5TJtinP006835 for <[e-mail]>; Fri, 29 Jun 2007 14:55:45 -0500 (CDT)
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: Fri, 29 Jun 2007 15:55:43 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
thread-index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAIJkIAAA3F7wAAC+B5AADIKnAAAuo+SgAABr+bA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5TJtlSA000473
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2007 19:56:37 -0000
Status: RO
Content-Length: 7988

Hi,

I've been thinking about this some more and come to the conclusion that,
with the arrangement added in protocol specification -04 where a TRILL
Header is always present, we don't need a bit to distinguish TRILL IS-IS
frames from TRILL data frames. That's because we can do so using the
inner MAC destination address.  There isn't any need for any additional
multicast addresses.

There are different ways to order the tests that are equivalent but here
is how I think of it (leaving out some details like VLANs for clarity):

The first thing to do is to test if the Ethertype is TRILL.

(1) If the Ethertype is not TRILL, you have a native frame and I believe
the processing described in the -04 draft, while it could be more
detailed, is correct, starting with discarding the frame unless you are
acting as the Designated Rbridge (DRB).

(2) If the Ethertype is TRILL, your DRB status doesn't matter. If the
frame is well formed, the outer MAC destination address will either be
All Rbridges or a unicast address. If its unicast and not addressed to
you, you discard the frame. At this point, you can check the inner MAC
destination address.

(2A) If the inner MAC destination address is not All Rbridges, you have
a TRILL data frame.

(2B) If the inner MAC destination address is All Rbridges, you have a
TRILL IS-IS frame. If the inner VLAN tag is absent, it is a core
instance frame. If the inner VLAN tag is present, it is a per VLAN
instance frame.

So, it now appears to me that a Header flag bit to distinguish TRILL
data from TRILL IS-IS is not necessary.

Thanks,
Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Friday, June 29, 2007 3:10 PM
To: Silvano Gai; Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] a clarification about the core IS-IS instance

Silvano/Donald/Radia,

I would prefer to see a different multicast address
used for the TRILL IS-IS instances.  Was there any
consensus on this at the time it was discussed.  I
do remember seeing the discussion, but I can't remember
how it concluded.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 1:54 PM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Donald,
> 
> Radia confirmed that all the ISIS messages are sent to multicast
> addresses and therefore we discussed the possibility to use separate
> multicast addresses instead of the V bit
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Thursday, June 28, 2007 8:46 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: Re: [rbridge] a clarification about the core IS-IS instance
> > 
> > If it were not for the V bit, how would you distinguish an IS-IS
> routing
> > packet conveying layer 3 routing information being sent 
> inside a TRILL
> > data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
> inside
> > a TRILL IS-IS frame?
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Thursday, June 28, 2007 10:34 AM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Hi Donald,
> > 
> > Thanks again.
> > 
> > What's the function of the V-bit in all
> > of this?  What does an RBridge gain by looking
> > at this, that it cannot get by looking at
> > fields that it already has to?
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Thursday, June 28, 2007 7:30 AM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > >
> > > Hi Anoop,
> > >
> > > That looks about right, although you also have to check that
> > > the inner length/type field is in the length range. And if
> > > you determine that a TRILL IS-IS frame is for a per VLAN
> > > instance, you still don't know if you should process as well
> > > as forwarding it until you check whether you are DRB for a
> > > link with an end station in that VLAN.
> > >
> > > Donald
> > >
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Thursday, June 28, 2007 10:00 AM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > >
> > > Hi Donald,
> > >
> > > Thanks for the clarification.  Yes, I do remember the
> > > discussion on the list.  At that time it looked like the
> > > Ethertype would tell if the frame was IS-IS.
> > > It now looks like even the core IS-IS instance will use a
> > > DSAP/SSAP (for some reason I thought we were going to use a
> > > new Ethertype for the core IS-IS instance).
> > >
> > > So, to identify a core IS-IS frame (which all RBridges should
> > > be interested in) one would have to check for:
> > > outer.etype = trill
> > > inner.dsap = xx
> > > inner.ssap = xx
> > > inner.ctl = yy
> > > inner.vlan = not present
> > >
> > > The V bit doesn't really seem all that useful since both the
> > > core frames and the per-VLAN instance have it set, so that
> > > bit doesn't tell one whether or the packet needs to be
> > > processed as a control packet at a given RBridge.  The above
> > > fields are necessary and sufficient.  Please let me know if
> > > I'm missing something re the V bit.
> > >
> > > Thanks,
> > > Anoop
> > >
> > > > -----Original Message-----
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[e-mail]]
> > > > Sent: Wednesday, June 27, 2007 9:09 PM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]
> > > > Subject: RE: [rbridge] a clarification about the core IS-IS
> instance
> > > >
> > > > Hi Anoop,
> > > >
> > > > Yes, that was a change that was extensively discussed on
> > > the mailing
> > > > list. There wasn't a formal consensus determination but it
> > > was clear
> > > > that the sentiment of the group was to always have a TRILL
> > > Header on
> > > > TRILL IS-IS frames and use a formerly reserved bit in the header
> to
> > > > distinguish a TRILL IS-IS frame from a TRILL data frame
> > > whose contents
> > > > happens to be a (presumably layer 3) IS-IS message.
> > > >
> > > > I believe your second point is correct. Checking for the TRILL
> > > > Ethertype is the key to deciding whether to process a frame
> > > if you are
> > > > not DRB on that port and VLAN. (This ignores the
> > > bridging/media frames
> > > > sent to the block of multicast 16 addresses reserved for that
> > > > purpose.)
> > > >
> > > > Thanks,
> > > > Donald
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> > > > Sent: Wednesday, June 27, 2007 9:42 PM
> > > > To: [e-mail]
> > > > Subject: [rbridge] a clarification about the core IS-IS instance
> > > >
> > > > From reading the previous version of the draft I got the
> impression
> > > > that frames sent as part of the core IS-IS would not
> > > contain a trill
> > > > header or inner header.  However, on reading this version, it
> looks
> > > > like the core IS-IS instance would in fact contain a 
> trill header.
> > > >
> > > > Assuming that the above is true, would it be safe to assume that
> an
> > > > RBridge, for a port that is connected to a LAN for which it
> > > is not a
> > > > DRB, will drop all frames whose Ethertype does not 
> indicate trill?
> > > >
> > > > Anoop
> > > >
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5TJAsLM018684 for <[e-mail]>; Fri, 29 Jun 2007 12:10:54 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 29 Jun 2007 12:10:52 -0700
X-IronPort-AV: i="4.16,476,1175497200";  d="scan'208"; a="11309744:sNHT20123782"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 8F1FC23836C; Fri, 29 Jun 2007 12:08:17 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jun 2007 12:10:52 -0700
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: Fri, 29 Jun 2007 12:10:21 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
Thread-Index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAIJkIAAA3F7wAAC+B5AADIKnAAAuo+Sg
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 29 Jun 2007 19:10:52.0058 (UTC) FILETIME=[35DD1FA0:01C7BA81]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5TJAsLM018684
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2007 19:11:16 -0000
Status: RO
Content-Length: 6156

Silvano/Donald/Radia,

I would prefer to see a different multicast address
used for the TRILL IS-IS instances.  Was there any
consensus on this at the time it was discussed.  I
do remember seeing the discussion, but I can't remember
how it concluded.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 1:54 PM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> 
> Donald,
> 
> Radia confirmed that all the ISIS messages are sent to multicast
> addresses and therefore we discussed the possibility to use separate
> multicast addresses instead of the V bit
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Thursday, June 28, 2007 8:46 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: Re: [rbridge] a clarification about the core IS-IS instance
> > 
> > If it were not for the V bit, how would you distinguish an IS-IS
> routing
> > packet conveying layer 3 routing information being sent 
> inside a TRILL
> > data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
> inside
> > a TRILL IS-IS frame?
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Thursday, June 28, 2007 10:34 AM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Hi Donald,
> > 
> > Thanks again.
> > 
> > What's the function of the V-bit in all
> > of this?  What does an RBridge gain by looking
> > at this, that it cannot get by looking at
> > fields that it already has to?
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Thursday, June 28, 2007 7:30 AM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > >
> > > Hi Anoop,
> > >
> > > That looks about right, although you also have to check that
> > > the inner length/type field is in the length range. And if
> > > you determine that a TRILL IS-IS frame is for a per VLAN
> > > instance, you still don't know if you should process as well
> > > as forwarding it until you check whether you are DRB for a
> > > link with an end station in that VLAN.
> > >
> > > Donald
> > >
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Thursday, June 28, 2007 10:00 AM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > >
> > > Hi Donald,
> > >
> > > Thanks for the clarification.  Yes, I do remember the
> > > discussion on the list.  At that time it looked like the
> > > Ethertype would tell if the frame was IS-IS.
> > > It now looks like even the core IS-IS instance will use a
> > > DSAP/SSAP (for some reason I thought we were going to use a
> > > new Ethertype for the core IS-IS instance).
> > >
> > > So, to identify a core IS-IS frame (which all RBridges should
> > > be interested in) one would have to check for:
> > > outer.etype = trill
> > > inner.dsap = xx
> > > inner.ssap = xx
> > > inner.ctl = yy
> > > inner.vlan = not present
> > >
> > > The V bit doesn't really seem all that useful since both the
> > > core frames and the per-VLAN instance have it set, so that
> > > bit doesn't tell one whether or the packet needs to be
> > > processed as a control packet at a given RBridge.  The above
> > > fields are necessary and sufficient.  Please let me know if
> > > I'm missing something re the V bit.
> > >
> > > Thanks,
> > > Anoop
> > >
> > > > -----Original Message-----
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[e-mail]]
> > > > Sent: Wednesday, June 27, 2007 9:09 PM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]
> > > > Subject: RE: [rbridge] a clarification about the core IS-IS
> instance
> > > >
> > > > Hi Anoop,
> > > >
> > > > Yes, that was a change that was extensively discussed on
> > > the mailing
> > > > list. There wasn't a formal consensus determination but it
> > > was clear
> > > > that the sentiment of the group was to always have a TRILL
> > > Header on
> > > > TRILL IS-IS frames and use a formerly reserved bit in the header
> to
> > > > distinguish a TRILL IS-IS frame from a TRILL data frame
> > > whose contents
> > > > happens to be a (presumably layer 3) IS-IS message.
> > > >
> > > > I believe your second point is correct. Checking for the TRILL
> > > > Ethertype is the key to deciding whether to process a frame
> > > if you are
> > > > not DRB on that port and VLAN. (This ignores the
> > > bridging/media frames
> > > > sent to the block of multicast 16 addresses reserved for that
> > > > purpose.)
> > > >
> > > > Thanks,
> > > > Donald
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> > > > Sent: Wednesday, June 27, 2007 9:42 PM
> > > > To: [e-mail]
> > > > Subject: [rbridge] a clarification about the core IS-IS instance
> > > >
> > > > From reading the previous version of the draft I got the
> impression
> > > > that frames sent as part of the core IS-IS would not
> > > contain a trill
> > > > header or inner header.  However, on reading this version, it
> looks
> > > > like the core IS-IS instance would in fact contain a 
> trill header.
> > > >
> > > > Assuming that the above is true, would it be safe to assume that
> an
> > > > RBridge, for a port that is connected to a LAN for which it
> > > is not a
> > > > DRB, will drop all frames whose Ethertype does not 
> indicate trill?
> > > >
> > > > Anoop
> > > >
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5T8C1YI025737 for <[e-mail]>; Fri, 29 Jun 2007 01:12:01 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 29 Jun 2007 01:12:01 -0700
X-IronPort-AV: i="4.16,474,1175497200";  d="scan'208"; a="14385182:sNHT30435447"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 241F223836C; Fri, 29 Jun 2007 01:09:27 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jun 2007 01:12:01 -0700
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: Fri, 29 Jun 2007 01:11:29 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
Thread-Index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiAAjFbNEABfljBQADB5xbAAAD7YMAAlBNgQ
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 29 Jun 2007 08:12:01.0376 (UTC) FILETIME=[2BBDBE00:01C7BA25]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5T8C1YI025737
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2007 08:12:26 -0000
Status: RO
Content-Length: 21653

Donald,

I can see some value in this, but given that
existing bridges wouldn't do any better than
the coarse pruning based on the fields that
I mentioned, I think this functionality should
be listed in the draft as a SHOULD/MAY rather 
than as a MUST.

Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 10:53 AM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] TRILL Header/Tag
> 
> Hi Anoop,
> 
> If you want to prune IP multicast and you believe RFC 4541, then the
> fields you enumerated are inadequate to determine how to 
> forward a frame
> at a transit Rbridge.
> 
> Although, on re-reading the stuff in RFC 4541, things may not 
> be as bad
> as I thought they were for IPv6, nevertheless there are IP derived MAC
> multicast addresses for both IPv4 and IPv6 where you should prune for
> some values of the original IP address and must broadcast for other
> values.
> 
> For example, both 224.0.0.42 and 225.128.0.42 are valid IPv4 multicast
> addresses from which the same MAC address, namely 01-00-5E-00-00-2A,
> would be derived. You would want to prune traffic to 225.128.0.42 but
> you can't validly prune traffic to 224.0.0.42 because, 
> according to RFC
> 4541, hosts do not consistently issue IGMPs for IPv4 addresses in the
> 224.0.0.0/24 range.
> 
> I haven't studied all the IGMP stuff for different versions but, for
> IGMP (and MLD), at best you have the problem in the paragraph 
> above and
> at worst even the IP multicast address would be inadequate 
> and you would
> have to look deeper into the frame to check the IP protocol, etc., in
> order to decide whether to prune just to branches with IP multicast
> routers.
> 
> So I believe the very simple change of adding a few more V 
> values would
> vastly simplify processing at transit Rbridges. This change is
> independent of whether or not fields are moved.
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 10:26 AM
> To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] TRILL Header/Tag
> 
> I'm with Silvano on this; I'd rather not
> see the fields moved around.
> 
> I'm also skeptical about the need for the
> several flavors of the V-bits.  I think
> the Rbridge nickname, inner MAC address, and 
> inner VLAN combo should be enough to tell
> one how to forward the frame.
> 
> Anoop
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Silvano Gai
> > Sent: Wednesday, June 27, 2007 8:18 AM
> > To: Eastlake III Donald-LDE008; [e-mail]
> > Subject: Re: [rbridge] TRILL Header/Tag
> > 
> > 
> > Donald,
> > 
> > The information contained in your email was known and 
> discussed at the
> > time of the consensus on the header format. I don't see any 
> reason to
> > change and I remain strongly in favor of the current format.
> > 
> > -- Silvano
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Eastlake III Donald-LDE008
> > > Sent: Monday, June 25, 2007 11:09 AM
> > > To: [e-mail]
> > > Subject: [rbridge] TRILL Header/Tag
> > > 
> > > Hi,
> > > 
> > > The current TRILL data frame on an 802.3 link looks like this (the
> > Outer
> > > VLAN Tag is not always present):
> > > 
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                  Outer Destination MAC Address       
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | Outer Destination MAC Address | Outer Source MAC 
> Address      |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Outer Source MAC Address          
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag 
> Information   |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > Start "TRILL Header":
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | Ethertype = TRILL             |  V  |M|R|Op-Length| 
> Hop Count |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |    Egress (RB2) Nickname      |    Ingress (RB1) 
> Nickname     |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > :End "TRILL Header"
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |               Inner Destination MAC Address          
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | Inner Destination MAC Address |  Inner Source MAC 
> Address     |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Inner Source MAC Address          
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | Ethertype = IEEE 802.1Q       |  Inner.VLAN Tag 
> Information   |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |       Payload Ethertype       |                      
>          |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Payload        
>          |
> > >    |                                                      
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                      FCS (Frame CheckSum)            
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > > Where the V field is two zero bits, for Version 0, followed 
> > by another
> > > zero bit for a TRILL data frame (or a 1 bit for a TRILL 
> > IS-IS frame).
> > > That is, V=0 (or V=1). See 
> draft-ietf-trill-rbridge-protocol-04.txt.
> > > 
> > > (Side note: there should be a separate discussion about Q-tags
> > > versus/and/or S-tags but I think that is pretty 
> orthogonal to what I
> > > want to talk about here.)
> > > 
> > > There is no question that this format "works". But I don't 
> > see that as
> > > the point. After all, 803.3 Ethernet would "work" if you moved the
> > > Destination Address to the end of the frame. But it 
> wouldn't be good
> > > engineering, because cut through switching or similar 
> optimizations
> > > would be impossible.
> > > 
> > > What I am primarily worried about is the fast path at transit
> > Rbridges.
> > > There doesn't seem to be any way to avoid a fair amount of 
> > work at the
> > > ingress Rbridge. And it could be that there would be some
> > > implementations that wouldn't mind having to grovel deep 
> > into a frame
> > at
> > > every transit Rbridge. But I think most implementations will want
> > > transit Rbridge processing of TRILL data frames to be as simple as
> > > possible. And I should think that anyone who is worrying about
> > Rbridging
> > > 10Gbps Ethernet or even fast optical channels should be having
> > problems
> > > looking at the current TRILL protocol specification.
> > > 
> > > First, lets look at unicast. Seems really nice and efficient, even
> > with
> > > the present design. You just decrement the hop count and, if it is
> > > non-zero, use the egress Rbridge nickname to look up the next hop
> > > destination MAC address, output port, and Outer VLAN ID 
> if any, and
> > off
> > > you go. Well, I think it is just a little more complex 
> than that. In
> > > particular, what do you do about the Outer VLAN Tag 
> > priority field? An
> > > Outer VLAN Tag added by the previous Rbridge could have 
> > been stripped
> > or
> > > changed by bridges. You could imagine wanting to configure various
> > > strategies but I think the right zero configuration default is to
> > simply
> > > get the priority from the Inner VLAN Tag. (Of course, if 
> that turns
> > out
> > > to be the default priority and no Outer VLAN is needed for
> > connectivity
> > > to the next hop Rbridge, no Outer VLAN Tag may be needed at 
> > all.) And
> > > then there are options. They start right after ingress 
> nickname and,
> > > even if you can get around the priority problem, if there 
> > are options
> > > present, you probably have to look at the first bit or two of the
> > > options area to determine that none of them apply to you...
> > > 
> > > So unicast isn't too bad, but even there I think you have 
> to check a
> > > couple of bits beyond the header if options are present 
> and the best
> > > default strategy requires you to delve into the inner 
> frame to check
> > the
> > > data priority.
> > > 
> > > It's multi-destination frames that are the real problem with the
> > current
> > > design for a high speed transit Rbridge that wants to prune the
> > > distribution tree. And, based on comments on this working group
> > mailing
> > > list, many developers will want to prune.
> > > 
> > > So, say we receive a multi-destination data frame. You know the
> > > distribution tree from the "egress" nickname field. But if 
> > you want to
> > > do any pruning, you have to look beyond the TRILL Header. 
> > Getting the
> > > information for pruning by VLAN, you need to look at the 
> > Inner VLAN ID
> > > which may require skipping over options.
> > > 
> > > Then we get to multicast pruning. To do that, you might 
> > first look at
> > > the Destination MAC Address. That comes even before the 
> > Inner VLAN Tag
> > > that you had to look at for VLAN pruning, so this doesn't 
> sound too
> > > hard. But it also turns out that it is not adequate. RFC 
> > 4541 on IGMP
> > > snooping and the like is now out and it points out that there are
> > ranges
> > > of special IPv4 and IPv6 multicast addresses for which 
> > hosts don't, or
> > > at least can not be depended on to, issue IGMPs (or MLDs or IPv6).
> > > Therefore, frames sent to those IP multicast addresses have to be
> > > treated as broadcast and distribution can't be pruned. 
> But, these IP
> > > multicast addresses are translated ambiguously to MAC multicast
> > > addresses just like other IP multicast addresses. So, if 
> we look at
> > the
> > > Destination MAC address and find it is an IP derived 
> > multicast, we are
> > > not done.
> > > 
> > > For IPv4 derived multicast MAC addresses, there is a range of such
> > > multicast addresses for which you have to dig even deeper into the
> > frame
> > > and look at the actual IPv4 address to see if you can prune 
> > or have to
> > > broadcast. True, for IPv4 it is only a small fraction of 
> > the possible
> > IP
> > > derived multicast addresses, and an alternative might be to always
> > > broadcast frames to those IPv4 derived MAC multicast 
> > addresses; but if
> > > some group just happens to be sending their streaming video over a
> > > multicast group that just happens to map into this area, 
> it may not
> > work
> > > out so well for your network that those frames are 
> getting broadcast
> > > everywhere in that VLAN.
> > > 
> > > The situation it much worse for IPv6. In the case of IPv6 
> > derived MAC
> > > multicast addresses, 100% are potentially for special 
> IPv6 multicast
> > > addresses that you must broadcast. As a result, if you 
> are going to
> > > prune IPv6 derived multicast, you *always* have to go look at the
> > actual
> > > IPv6 destination address deeper in the frame to decide 
> > whether or not
> > to
> > > prune.
> > > 
> > > Finally, we come to the worst case, detecting IGMP, MLD, etc.
> > messages.
> > > Here you have to go beyond the IPv4 or IPv6 destination 
> > address, delve
> > > deeper into the IP header and, in some cases, into the IP packet
> > content
> > > just to figure out whether you need to prune the 
> > distribution tree to
> > > branches with IP multicast routers on them for IGMP and 
> MLD (and RFC
> > > 4541 specifically recommends, due to confusions that can happen
> > between
> > > IGMPv3 and earlier version of IGMP, not sending such 
> > message to links
> > > unless they have an IP multicast router on the).
> > > 
> > > I really don't think you want to have to look into the 
> content of IP
> > > packets to make forwarding decisions at transit Rbridges.
> > > 
> > > So, what I suggest is something more like the following:
> > > 
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                  Outer Destination MAC Address       
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | Outer Destination MAC Address | Outer Source MAC 
> Address      |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |          Outer Source MAC Address  (last four bytes) 
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag 
> Information   |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > Start "TRILL Tag":
> > >  = 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  = |         TRILL Ethertype       |   V   |M|Op-Length| 
> Hop Count |
> > >  = 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  = |   Egress RBridge Nickname     |  Inner VLAN Tag 
> information   |
> > >  = 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  = |        Inner Destination MAC Address (first four 
> bytes)       |
> > >  = 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  = |   Inner Dest MAC Adr          |  Ingress RBridge 
> Nickname     |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |           Inner Source MAC Address (first four 
> bytes)         |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   Rest of Inner Src MAC Adr   |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > End "TRILL Tag":                   
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >                                    |       Payload 
> Ethertype       |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   Payload ...
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  Final Checksum:
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                       Frame Check Sum                
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > where
> > >    V = 0 for TRILL IS-IS frames
> > >    V = 1 for TRILL data pruned only on VLAN
> > >    V = 2 for TRILL data pruned on VLAN and IP multicast 
> MAC address
> > >    V = 3 for TRILL data pruned on VLAN and IP multicast routers
> > location
> > > 
> > > This puts everything that is needed for a transit Rbridge 
> to forward
> > > frames in the first 128 bits of what I have labeled the 
> > TRILL Tag (see
> > > "=" in left margin). Why did I label it "Tag" rather than 
> "Header"?
> > > Well, the header paradigm seems to connote that we are 
> > adding a header
> > > in front of an almost complete Ethernet frame. Tag seems 
> > like a better
> > > word if we are constructing a block that goes in front of a frame
> > > contents, not a frame. In some ways, it just depends on 
> how you look
> > at
> > > it.
> > > 
> > > For multicast optimization, the investigation into the frame as to
> > > whether the distribution tree should be (1) only VLAN pruned, (2)
> > pruned
> > > on VLAN and based on multicast destination address, or 
> (3) pruned on
> > > VLAN and branches that have multicast routers, needs to 
> be made only
> > > once, at the ingress Rbridge, and is then encoded into V.
> > > 
> > > The current header is 64-bits and 64-bit aligned 
> (starting after the
> > > Outer VLAN tag) which is nice, but you always have to 
> look beyond it
> > for
> > > every frame. Sometimes way beyond it, including skipping over any
> > TRILL
> > > options and IP options, to look into the content of IP packets.
> > > 
> > > The suggested TRILL tag is 176 bits long but, unless you 
> > are an egress
> > > Rbridge, you only have to look at the first 128 bits which 
> > is 128-bit
> > > aligned (ignoring the outer VLAN tag like I did for the current
> > header).
> > > But since fields are mostly just being moved around, at 
> > worst you gain
> > > or lose two bytes total length over previous proposals. 
> > Options would
> > > start after the destination MAC address so, even if options are
> > present,
> > > you can check the first few bits of the options area without going
> > > outside this 128-bit area.
> > > 
> > > This proposal does suppress the Ethertype for the inner VLAN Tag
> > > information but there is some precedent for that sort of 
> thing. For
> > > example, 802.16 has a header suppression feature where you can set
> > some
> > > flag bits and then leave out Q-tag and/or IPv4 or IPv6 Ethertypes.
> > > 
> > > So, while various minor changes could be made, the above is my
> > > suggestion for significantly improving the simplicity and 
> > cut through
> > > switching latency of handling TRILL data frames at 
> transit Rbridges.
> > > 
> > > Since there was a consensus determination in favor of the current
> > TRILL
> > > Header, there needs to be a consensus to re-open the question. If
> > there
> > > isn't, my fall back position would be to suggest expanding 
> > the values
> > of
> > > V in the TRILL Header to encode the correct pruning strategy for a
> > > frame, as listed with the TRILL Tag proposal above. This would not
> > > eliminate the need to delve into the inner frame whenever a TRILL
> > frame
> > > is handled by a transit Rbridge, but would reduce to depth and
> > > complexity of such delving...
> > > 
> > > Thanks,
> > > Donald
> > > 
> > > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Anoop Ghanwani
> > > Sent: Friday, June 22, 2007 6:44 PM
> > > To: Silvano Gai; Radia Perlman
> > > Cc: [e-mail]
> > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > 
> > > I don't see much of an advantage to changing things because
> > > it doesn't change the fact that rBridges rely on the
> > > "inner frame" to get correct pruning behavior for multicasts.
> > > 
> > > However, I agree with Silvano.  _If_ something is going
> > > to change, let's try and settle it as soon as we possibly can.
> > > 
> > > Anoop
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Thursday, June 21, 2007 7:09 AM
> > > > To: Radia Perlman; Anoop Ghanwani
> > > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [e-mail]
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > Radia,
> > > >
> > > > This information was known at the time of the consensus.
> > > > I still remain in favor of the header we selected.
> > > > If somebody wants to change his/her mind they can email this
> > > > list (SOON).
> > > >
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Radia Perlman [mailto:[e-mail]]
> > > > > Sent: Wednesday, June 20, 2007 12:57 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
> > > > [e-mail]
> > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > As Anoop said, core RBridges need to look inside the
> > > > tunneled packet
> > > > > at the inner packet in order to do multicast pruning as
> > > > well as VLAN
> > > > > pruning on multicast packets.
> > > > >
> > > > > Which is why Don was proposing moving both the VLAN 
> tag and the
> > > > > destination multicast address to the TRILL header. (and
> > > > removing the
> > > > > VLAN tag and DA from the inner packet so that it wouldn't
> > > > mean adding
> > > > > an extra 6 bytes to an encapsulated frame).
> > > > >
> > > > > Seemed like people didn't like doing that, but I want to
> > > > make sure if
> > > > > the WG really is deciding not to do that, that they really
> > > > understand
> > > > > what they are deciding against.
> > > > > Often in the email threads so many different things 
> are kind of
> > > > > discussed at the same time that it's obvious that people
> > > > (definitely
> > > > > including me) are getting confused.
> > > > >
> > > > > Radia
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Anoop Ghanwani wrote:
> > > > > >
> > > > > > They're snooping because they too care about pruning
> > > > their trees for
> > > > > > a given multicast group and that would be one of the ways
> > > > to achieve
> > > > > > it.
> > > > > > Otherwise, all multicasts would have to be broadcast on
> > > > the spanning
> > > > > > tree interconnecting the bridged network that sits
> > > > between the two
> > > > > > rBridges.
> > > > > >
> > > > > >
> > > > > > If we didn't care about multicast pruning, we wouldn't
> > > > need to worry
> > > > > > about any of this.
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5T83R8V023776 for <[e-mail]>; Fri, 29 Jun 2007 01:03:32 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 29 Jun 2007 01:03:19 -0700
X-IronPort-AV: i="4.16,474,1175497200";  d="scan'208"; a="14384899:sNHT18935623"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id EBA2F23836C; Fri, 29 Jun 2007 01:00:45 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jun 2007 01:03:20 -0700
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: Fri, 29 Jun 2007 01:02:47 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
Thread-Index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAIJkIAAA3F7wAAC+B5AAI+gh8A==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 29 Jun 2007 08:03:20.0172 (UTC) FILETIME=[F51452C0:01C7BA23]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5T83R8V023776
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2007 08:03:57 -0000
Status: RO
Content-Length: 5139

Donald,

Yes, I kind of got that after sending this note.
I guess it would be needed if someone intended
to use the per VLAN IS-IS instances.

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 8:46 AM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> If it were not for the V bit, how would you distinguish an 
> IS-IS routing
> packet conveying layer 3 routing information being sent inside a TRILL
> data frame from a layer 2 TRILL per VLAN IS-IS packet being 
> sent inside
> a TRILL IS-IS frame?
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 10:34 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Donald,
> 
> Thanks again.
> 
> What's the function of the V-bit in all
> of this?  What does an RBridge gain by looking
> at this, that it cannot get by looking at
> fields that it already has to?
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Thursday, June 28, 2007 7:30 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Hi Anoop,
> > 
> > That looks about right, although you also have to check that 
> > the inner length/type field is in the length range. And if 
> > you determine that a TRILL IS-IS frame is for a per VLAN 
> > instance, you still don't know if you should process as well 
> > as forwarding it until you check whether you are DRB for a 
> > link with an end station in that VLAN.
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Thursday, June 28, 2007 10:00 AM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Hi Donald,
> > 
> > Thanks for the clarification.  Yes, I do remember the 
> > discussion on the list.  At that time it looked like the 
> > Ethertype would tell if the frame was IS-IS.
> > It now looks like even the core IS-IS instance will use a 
> > DSAP/SSAP (for some reason I thought we were going to use a 
> > new Ethertype for the core IS-IS instance).
> > 
> > So, to identify a core IS-IS frame (which all RBridges should 
> > be interested in) one would have to check for:
> > outer.etype = trill
> > inner.dsap = xx
> > inner.ssap = xx
> > inner.ctl = yy
> > inner.vlan = not present
> > 
> > The V bit doesn't really seem all that useful since both the 
> > core frames and the per-VLAN instance have it set, so that 
> > bit doesn't tell one whether or the packet needs to be 
> > processed as a control packet at a given RBridge.  The above 
> > fields are necessary and sufficient.  Please let me know if 
> > I'm missing something re the V bit.
> > 
> > Thanks,
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Wednesday, June 27, 2007 9:09 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > > 
> > > Hi Anoop,
> > > 
> > > Yes, that was a change that was extensively discussed on 
> > the mailing 
> > > list. There wasn't a formal consensus determination but it 
> > was clear 
> > > that the sentiment of the group was to always have a TRILL 
> > Header on 
> > > TRILL IS-IS frames and use a formerly reserved bit in the 
> header to 
> > > distinguish a TRILL IS-IS frame from a TRILL data frame 
> > whose contents 
> > > happens to be a (presumably layer 3) IS-IS message.
> > > 
> > > I believe your second point is correct. Checking for the TRILL 
> > > Ethertype is the key to deciding whether to process a frame 
> > if you are 
> > > not DRB on that port and VLAN. (This ignores the 
> > bridging/media frames 
> > > sent to the block of multicast 16 addresses reserved for that 
> > > purpose.)
> > > 
> > > Thanks,
> > > Donald
> > > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> > > Sent: Wednesday, June 27, 2007 9:42 PM
> > > To: [e-mail]
> > > Subject: [rbridge] a clarification about the core IS-IS instance
> > > 
> > > From reading the previous version of the draft I got the 
> impression 
> > > that frames sent as part of the core IS-IS would not 
> > contain a trill 
> > > header or inner header.  However, on reading this 
> version, it looks 
> > > like the core IS-IS instance would in fact contain a trill header.
> > > 
> > > Assuming that the above is true, would it be safe to 
> assume that an 
> > > RBridge, for a port that is connected to a LAN for which it 
> > is not a 
> > > DRB, will drop all frames whose Ethertype does not indicate trill?
> > > 
> > > Anoop
> > > 
> > 
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5SKsCoP012080 for <[e-mail]>; Thu, 28 Jun 2007 13:54:12 -0700 (PDT)
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: Thu, 28 Jun 2007 13:53:49 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
Thread-Index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAIJkIAAA3F7wAAC+B5AADIKnAA==
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SKsCoP012080
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 20:55:14 -0000
Status: RO
Content-Length: 5286

Donald,

Radia confirmed that all the ISIS messages are sent to multicast
addresses and therefore we discussed the possibility to use separate
multicast addresses instead of the V bit

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Thursday, June 28, 2007 8:46 AM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: Re: [rbridge] a clarification about the core IS-IS instance
> 
> If it were not for the V bit, how would you distinguish an IS-IS
routing
> packet conveying layer 3 routing information being sent inside a TRILL
> data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
inside
> a TRILL IS-IS frame?
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Thursday, June 28, 2007 10:34 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Donald,
> 
> Thanks again.
> 
> What's the function of the V-bit in all
> of this?  What does an RBridge gain by looking
> at this, that it cannot get by looking at
> fields that it already has to?
> 
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Thursday, June 28, 2007 7:30 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> >
> > Hi Anoop,
> >
> > That looks about right, although you also have to check that
> > the inner length/type field is in the length range. And if
> > you determine that a TRILL IS-IS frame is for a per VLAN
> > instance, you still don't know if you should process as well
> > as forwarding it until you check whether you are DRB for a
> > link with an end station in that VLAN.
> >
> > Donald
> >
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Thursday, June 28, 2007 10:00 AM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> >
> > Hi Donald,
> >
> > Thanks for the clarification.  Yes, I do remember the
> > discussion on the list.  At that time it looked like the
> > Ethertype would tell if the frame was IS-IS.
> > It now looks like even the core IS-IS instance will use a
> > DSAP/SSAP (for some reason I thought we were going to use a
> > new Ethertype for the core IS-IS instance).
> >
> > So, to identify a core IS-IS frame (which all RBridges should
> > be interested in) one would have to check for:
> > outer.etype = trill
> > inner.dsap = xx
> > inner.ssap = xx
> > inner.ctl = yy
> > inner.vlan = not present
> >
> > The V bit doesn't really seem all that useful since both the
> > core frames and the per-VLAN instance have it set, so that
> > bit doesn't tell one whether or the packet needs to be
> > processed as a control packet at a given RBridge.  The above
> > fields are necessary and sufficient.  Please let me know if
> > I'm missing something re the V bit.
> >
> > Thanks,
> > Anoop
> >
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Wednesday, June 27, 2007 9:09 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] a clarification about the core IS-IS
instance
> > >
> > > Hi Anoop,
> > >
> > > Yes, that was a change that was extensively discussed on
> > the mailing
> > > list. There wasn't a formal consensus determination but it
> > was clear
> > > that the sentiment of the group was to always have a TRILL
> > Header on
> > > TRILL IS-IS frames and use a formerly reserved bit in the header
to
> > > distinguish a TRILL IS-IS frame from a TRILL data frame
> > whose contents
> > > happens to be a (presumably layer 3) IS-IS message.
> > >
> > > I believe your second point is correct. Checking for the TRILL
> > > Ethertype is the key to deciding whether to process a frame
> > if you are
> > > not DRB on that port and VLAN. (This ignores the
> > bridging/media frames
> > > sent to the block of multicast 16 addresses reserved for that
> > > purpose.)
> > >
> > > Thanks,
> > > Donald
> > >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> > > Sent: Wednesday, June 27, 2007 9:42 PM
> > > To: [e-mail]
> > > Subject: [rbridge] a clarification about the core IS-IS instance
> > >
> > > From reading the previous version of the draft I got the
impression
> > > that frames sent as part of the core IS-IS would not
> > contain a trill
> > > header or inner header.  However, on reading this version, it
looks
> > > like the core IS-IS instance would in fact contain a trill header.
> > >
> > > Assuming that the above is true, would it be safe to assume that
an
> > > RBridge, for a port that is connected to a LAN for which it
> > is not a
> > > DRB, will drop all frames whose Ethertype does not indicate trill?
> > >
> > > Anoop
> > >
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5SKNqdh001928 for <[e-mail]>; Thu, 28 Jun 2007 13:23:52 -0700 (PDT)
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: Thu, 28 Jun 2007 13:23:47 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
Thread-Index: Ace5vNf5PlPSmvvBQba+K7DMh3DNDAABSiaw
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: "James Carlson" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SKNqdh001928
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 20:24:20 -0000
Status: RO
Content-Length: 2321

With IP multicast pruning in bridges, the traditional mode of operation
has been... if you don't know for sure, don't prune.  This is what
allows various implementations to be deployed in the face of no real
specification covering the functionality (and changes in IGMP versions
along the way).

JR
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Carlson
> Sent: Thursday, June 28, 2007 11:49 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] TRILL Header/Tag
> 
> Eastlake III Donald-LDE008 writes:
> > For example, both 224.0.0.42 and 225.128.0.42 are valid 
> IPv4 multicast
> > addresses from which the same MAC address, namely 01-00-5E-00-00-2A,
> > would be derived. You would want to prune traffic to 
> 225.128.0.42 but
> > you can't validly prune traffic to 224.0.0.42 because, 
> according to RFC
> > 4541, hosts do not consistently issue IGMPs for IPv4 
> addresses in the
> > 224.0.0.0/24 range.
> 
> Yep; exactly.  224.0.0.0/24 is both "link-local" and "well-known" and
> thus expected to work right without the help or interference of
> multicast routers.  (Where, "right" means that all stations on the
> link can receive it.)
> 
> > I haven't studied all the IGMP stuff for different versions but, for
> > IGMP (and MLD), at best you have the problem in the 
> paragraph above and
> > at worst even the IP multicast address would be inadequate 
> and you would
> > have to look deeper into the frame to check the IP 
> protocol, etc., in
> > order to decide whether to prune just to branches with IP multicast
> > routers.
> 
> For IGMPv2, you'll need to look deeper, because the IGMP Report
> messages from hosts themselves are sent on the group address (RFC 2236
> section 9).  With IGMPv3, the Report messages are directed to a common
> multicast address (224.0.0.22; RFC 3376 section 4.2.14).
> 
> -- 
> James Carlson, Solaris Networking              
> <[e-mail]>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



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 l5SJQrUG016191 for <[e-mail]>; Thu, 28 Jun 2007 12:26:54 -0700 (PDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5SJQq54023150 for <[e-mail]>; Thu, 28 Jun 2007 19:26:52 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l5SJQqgM022854 for <[e-mail]>; Thu, 28 Jun 2007 15:26:52 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5SInLLH011092; Thu, 28 Jun 2007 14:49:21 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5SInJ20011089; Thu, 28 Jun 2007 14:49:19 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 28 Jun 2007 14:49:19 -0400
From: James Carlson <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 19:27:05 -0000
Status: RO
Content-Length: 1505

Eastlake III Donald-LDE008 writes:
> For example, both 224.0.0.42 and 225.128.0.42 are valid IPv4 multicast
> addresses from which the same MAC address, namely 01-00-5E-00-00-2A,
> would be derived. You would want to prune traffic to 225.128.0.42 but
> you can't validly prune traffic to 224.0.0.42 because, according to RFC
> 4541, hosts do not consistently issue IGMPs for IPv4 addresses in the
> 224.0.0.0/24 range.

Yep; exactly.  224.0.0.0/24 is both "link-local" and "well-known" and
thus expected to work right without the help or interference of
multicast routers.  (Where, "right" means that all stations on the
link can receive it.)

> I haven't studied all the IGMP stuff for different versions but, for
> IGMP (and MLD), at best you have the problem in the paragraph above and
> at worst even the IP multicast address would be inadequate and you would
> have to look deeper into the frame to check the IP protocol, etc., in
> order to decide whether to prune just to branches with IP multicast
> routers.

For IGMPv2, you'll need to look deeper, because the IGMP Report
messages from hosts themselves are sent on the group address (RFC 2236
section 9).  With IGMPv3, the Report messages are directed to a common
multicast address (224.0.0.22; RFC 3376 section 4.2.14).

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 1 Network Drive         71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5SHrCd3018087 for <[e-mail]>; Thu, 28 Jun 2007 10:53:13 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-153.messagelabs.com!1183053191!1837932!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 23434 invoked from network); 28 Jun 2007 17:53:12 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 28 Jun 2007 17:53:12 -0000
Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5SHrBMn019817 for <[e-mail]>; Thu, 28 Jun 2007 10:53:11 -0700 (MST)
Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5SHrAsM015985 for <[e-mail]>; Thu, 28 Jun 2007 12:53:10 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5SHr9dX015971 for <[e-mail]>; Thu, 28 Jun 2007 12:53:09 -0500 (CDT)
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: Thu, 28 Jun 2007 13:53:05 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
thread-index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiAAjFbNEABfljBQADB5xbAAAD7YMA==
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SHrCd3018087
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 17:53:46 -0000
Status: RO
Content-Length: 19909

Hi Anoop,

If you want to prune IP multicast and you believe RFC 4541, then the
fields you enumerated are inadequate to determine how to forward a frame
at a transit Rbridge.

Although, on re-reading the stuff in RFC 4541, things may not be as bad
as I thought they were for IPv6, nevertheless there are IP derived MAC
multicast addresses for both IPv4 and IPv6 where you should prune for
some values of the original IP address and must broadcast for other
values.

For example, both 224.0.0.42 and 225.128.0.42 are valid IPv4 multicast
addresses from which the same MAC address, namely 01-00-5E-00-00-2A,
would be derived. You would want to prune traffic to 225.128.0.42 but
you can't validly prune traffic to 224.0.0.42 because, according to RFC
4541, hosts do not consistently issue IGMPs for IPv4 addresses in the
224.0.0.0/24 range.

I haven't studied all the IGMP stuff for different versions but, for
IGMP (and MLD), at best you have the problem in the paragraph above and
at worst even the IP multicast address would be inadequate and you would
have to look deeper into the frame to check the IP protocol, etc., in
order to decide whether to prune just to branches with IP multicast
routers.

So I believe the very simple change of adding a few more V values would
vastly simplify processing at transit Rbridges. This change is
independent of whether or not fields are moved.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Thursday, June 28, 2007 10:26 AM
To: Silvano Gai; Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] TRILL Header/Tag

I'm with Silvano on this; I'd rather not
see the fields moved around.

I'm also skeptical about the need for the
several flavors of the V-bits.  I think
the Rbridge nickname, inner MAC address, and 
inner VLAN combo should be enough to tell
one how to forward the frame.

Anoop

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Silvano Gai
> Sent: Wednesday, June 27, 2007 8:18 AM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] TRILL Header/Tag
> 
> 
> Donald,
> 
> The information contained in your email was known and discussed at the
> time of the consensus on the header format. I don't see any reason to
> change and I remain strongly in favor of the current format.
> 
> -- Silvano
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Monday, June 25, 2007 11:09 AM
> > To: [e-mail]
> > Subject: [rbridge] TRILL Header/Tag
> > 
> > Hi,
> > 
> > The current TRILL data frame on an 802.3 link looks like this (the
> Outer
> > VLAN Tag is not always present):
> > 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                  Outer Destination MAC Address                |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Outer Destination MAC Address | Outer Source MAC Address      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Outer Source MAC Address                   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > Start "TRILL Header":
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = TRILL             |  V  |M|R|Op-Length| Hop Count |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |    Egress (RB2) Nickname      |    Ingress (RB1) Nickname     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > :End "TRILL Header"
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |               Inner Destination MAC Address                   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Inner Destination MAC Address |  Inner Source MAC Address     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Inner Source MAC Address                   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = IEEE 802.1Q       |  Inner.VLAN Tag Information   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |       Payload Ethertype       |                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Payload                 |
> >    |                                                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                      FCS (Frame CheckSum)                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Where the V field is two zero bits, for Version 0, followed 
> by another
> > zero bit for a TRILL data frame (or a 1 bit for a TRILL 
> IS-IS frame).
> > That is, V=0 (or V=1). See draft-ietf-trill-rbridge-protocol-04.txt.
> > 
> > (Side note: there should be a separate discussion about Q-tags
> > versus/and/or S-tags but I think that is pretty orthogonal to what I
> > want to talk about here.)
> > 
> > There is no question that this format "works". But I don't 
> see that as
> > the point. After all, 803.3 Ethernet would "work" if you moved the
> > Destination Address to the end of the frame. But it wouldn't be good
> > engineering, because cut through switching or similar optimizations
> > would be impossible.
> > 
> > What I am primarily worried about is the fast path at transit
> Rbridges.
> > There doesn't seem to be any way to avoid a fair amount of 
> work at the
> > ingress Rbridge. And it could be that there would be some
> > implementations that wouldn't mind having to grovel deep 
> into a frame
> at
> > every transit Rbridge. But I think most implementations will want
> > transit Rbridge processing of TRILL data frames to be as simple as
> > possible. And I should think that anyone who is worrying about
> Rbridging
> > 10Gbps Ethernet or even fast optical channels should be having
> problems
> > looking at the current TRILL protocol specification.
> > 
> > First, lets look at unicast. Seems really nice and efficient, even
> with
> > the present design. You just decrement the hop count and, if it is
> > non-zero, use the egress Rbridge nickname to look up the next hop
> > destination MAC address, output port, and Outer VLAN ID if any, and
> off
> > you go. Well, I think it is just a little more complex than that. In
> > particular, what do you do about the Outer VLAN Tag 
> priority field? An
> > Outer VLAN Tag added by the previous Rbridge could have 
> been stripped
> or
> > changed by bridges. You could imagine wanting to configure various
> > strategies but I think the right zero configuration default is to
> simply
> > get the priority from the Inner VLAN Tag. (Of course, if that turns
> out
> > to be the default priority and no Outer VLAN is needed for
> connectivity
> > to the next hop Rbridge, no Outer VLAN Tag may be needed at 
> all.) And
> > then there are options. They start right after ingress nickname and,
> > even if you can get around the priority problem, if there 
> are options
> > present, you probably have to look at the first bit or two of the
> > options area to determine that none of them apply to you...
> > 
> > So unicast isn't too bad, but even there I think you have to check a
> > couple of bits beyond the header if options are present and the best
> > default strategy requires you to delve into the inner frame to check
> the
> > data priority.
> > 
> > It's multi-destination frames that are the real problem with the
> current
> > design for a high speed transit Rbridge that wants to prune the
> > distribution tree. And, based on comments on this working group
> mailing
> > list, many developers will want to prune.
> > 
> > So, say we receive a multi-destination data frame. You know the
> > distribution tree from the "egress" nickname field. But if 
> you want to
> > do any pruning, you have to look beyond the TRILL Header. 
> Getting the
> > information for pruning by VLAN, you need to look at the 
> Inner VLAN ID
> > which may require skipping over options.
> > 
> > Then we get to multicast pruning. To do that, you might 
> first look at
> > the Destination MAC Address. That comes even before the 
> Inner VLAN Tag
> > that you had to look at for VLAN pruning, so this doesn't sound too
> > hard. But it also turns out that it is not adequate. RFC 
> 4541 on IGMP
> > snooping and the like is now out and it points out that there are
> ranges
> > of special IPv4 and IPv6 multicast addresses for which 
> hosts don't, or
> > at least can not be depended on to, issue IGMPs (or MLDs or IPv6).
> > Therefore, frames sent to those IP multicast addresses have to be
> > treated as broadcast and distribution can't be pruned. But, these IP
> > multicast addresses are translated ambiguously to MAC multicast
> > addresses just like other IP multicast addresses. So, if we look at
> the
> > Destination MAC address and find it is an IP derived 
> multicast, we are
> > not done.
> > 
> > For IPv4 derived multicast MAC addresses, there is a range of such
> > multicast addresses for which you have to dig even deeper into the
> frame
> > and look at the actual IPv4 address to see if you can prune 
> or have to
> > broadcast. True, for IPv4 it is only a small fraction of 
> the possible
> IP
> > derived multicast addresses, and an alternative might be to always
> > broadcast frames to those IPv4 derived MAC multicast 
> addresses; but if
> > some group just happens to be sending their streaming video over a
> > multicast group that just happens to map into this area, it may not
> work
> > out so well for your network that those frames are getting broadcast
> > everywhere in that VLAN.
> > 
> > The situation it much worse for IPv6. In the case of IPv6 
> derived MAC
> > multicast addresses, 100% are potentially for special IPv6 multicast
> > addresses that you must broadcast. As a result, if you are going to
> > prune IPv6 derived multicast, you *always* have to go look at the
> actual
> > IPv6 destination address deeper in the frame to decide 
> whether or not
> to
> > prune.
> > 
> > Finally, we come to the worst case, detecting IGMP, MLD, etc.
> messages.
> > Here you have to go beyond the IPv4 or IPv6 destination 
> address, delve
> > deeper into the IP header and, in some cases, into the IP packet
> content
> > just to figure out whether you need to prune the 
> distribution tree to
> > branches with IP multicast routers on them for IGMP and MLD (and RFC
> > 4541 specifically recommends, due to confusions that can happen
> between
> > IGMPv3 and earlier version of IGMP, not sending such 
> message to links
> > unless they have an IP multicast router on the).
> > 
> > I really don't think you want to have to look into the content of IP
> > packets to make forwarding decisions at transit Rbridges.
> > 
> > So, what I suggest is something more like the following:
> > 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                  Outer Destination MAC Address                |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Outer Destination MAC Address | Outer Source MAC Address      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |          Outer Source MAC Address  (last four bytes)          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > Start "TRILL Tag":
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |         TRILL Ethertype       |   V   |M|Op-Length| Hop Count |
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |   Egress RBridge Nickname     |  Inner VLAN Tag information   |
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |        Inner Destination MAC Address (first four bytes)       |
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |   Inner Dest MAC Adr          |  Ingress RBridge Nickname     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |           Inner Source MAC Address (first four bytes)         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Rest of Inner Src MAC Adr   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > End "TRILL Tag":                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                                    |       Payload Ethertype       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Payload ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  Final Checksum:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                       Frame Check Sum                         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > where
> >    V = 0 for TRILL IS-IS frames
> >    V = 1 for TRILL data pruned only on VLAN
> >    V = 2 for TRILL data pruned on VLAN and IP multicast MAC address
> >    V = 3 for TRILL data pruned on VLAN and IP multicast routers
> location
> > 
> > This puts everything that is needed for a transit Rbridge to forward
> > frames in the first 128 bits of what I have labeled the 
> TRILL Tag (see
> > "=" in left margin). Why did I label it "Tag" rather than "Header"?
> > Well, the header paradigm seems to connote that we are 
> adding a header
> > in front of an almost complete Ethernet frame. Tag seems 
> like a better
> > word if we are constructing a block that goes in front of a frame
> > contents, not a frame. In some ways, it just depends on how you look
> at
> > it.
> > 
> > For multicast optimization, the investigation into the frame as to
> > whether the distribution tree should be (1) only VLAN pruned, (2)
> pruned
> > on VLAN and based on multicast destination address, or (3) pruned on
> > VLAN and branches that have multicast routers, needs to be made only
> > once, at the ingress Rbridge, and is then encoded into V.
> > 
> > The current header is 64-bits and 64-bit aligned (starting after the
> > Outer VLAN tag) which is nice, but you always have to look beyond it
> for
> > every frame. Sometimes way beyond it, including skipping over any
> TRILL
> > options and IP options, to look into the content of IP packets.
> > 
> > The suggested TRILL tag is 176 bits long but, unless you 
> are an egress
> > Rbridge, you only have to look at the first 128 bits which 
> is 128-bit
> > aligned (ignoring the outer VLAN tag like I did for the current
> header).
> > But since fields are mostly just being moved around, at 
> worst you gain
> > or lose two bytes total length over previous proposals. 
> Options would
> > start after the destination MAC address so, even if options are
> present,
> > you can check the first few bits of the options area without going
> > outside this 128-bit area.
> > 
> > This proposal does suppress the Ethertype for the inner VLAN Tag
> > information but there is some precedent for that sort of thing. For
> > example, 802.16 has a header suppression feature where you can set
> some
> > flag bits and then leave out Q-tag and/or IPv4 or IPv6 Ethertypes.
> > 
> > So, while various minor changes could be made, the above is my
> > suggestion for significantly improving the simplicity and 
> cut through
> > switching latency of handling TRILL data frames at transit Rbridges.
> > 
> > Since there was a consensus determination in favor of the current
> TRILL
> > Header, there needs to be a consensus to re-open the question. If
> there
> > isn't, my fall back position would be to suggest expanding 
> the values
> of
> > V in the TRILL Header to encode the correct pruning strategy for a
> > frame, as listed with the TRILL Tag proposal above. This would not
> > eliminate the need to delve into the inner frame whenever a TRILL
> frame
> > is handled by a transit Rbridge, but would reduce to depth and
> > complexity of such delving...
> > 
> > Thanks,
> > Donald
> > 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Friday, June 22, 2007 6:44 PM
> > To: Silvano Gai; Radia Perlman
> > Cc: [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > 
> > I don't see much of an advantage to changing things because
> > it doesn't change the fact that rBridges rely on the
> > "inner frame" to get correct pruning behavior for multicasts.
> > 
> > However, I agree with Silvano.  _If_ something is going
> > to change, let's try and settle it as soon as we possibly can.
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Thursday, June 21, 2007 7:09 AM
> > > To: Radia Perlman; Anoop Ghanwani
> > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > >
> > > Radia,
> > >
> > > This information was known at the time of the consensus.
> > > I still remain in favor of the header we selected.
> > > If somebody wants to change his/her mind they can email this
> > > list (SOON).
> > >
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Radia Perlman [mailto:[e-mail]]
> > > > Sent: Wednesday, June 20, 2007 12:57 PM
> > > > To: Anoop Ghanwani
> > > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
> > > [e-mail]
> > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > As Anoop said, core RBridges need to look inside the
> > > tunneled packet
> > > > at the inner packet in order to do multicast pruning as
> > > well as VLAN
> > > > pruning on multicast packets.
> > > >
> > > > Which is why Don was proposing moving both the VLAN tag and the
> > > > destination multicast address to the TRILL header. (and
> > > removing the
> > > > VLAN tag and DA from the inner packet so that it wouldn't
> > > mean adding
> > > > an extra 6 bytes to an encapsulated frame).
> > > >
> > > > Seemed like people didn't like doing that, but I want to
> > > make sure if
> > > > the WG really is deciding not to do that, that they really
> > > understand
> > > > what they are deciding against.
> > > > Often in the email threads so many different things are kind of
> > > > discussed at the same time that it's obvious that people
> > > (definitely
> > > > including me) are getting confused.
> > > >
> > > > Radia
> > > >
> > > >
> > > >
> > > >
> > > > Anoop Ghanwani wrote:
> > > > >
> > > > > They're snooping because they too care about pruning
> > > their trees for
> > > > > a given multicast group and that would be one of the ways
> > > to achieve
> > > > > it.
> > > > > Otherwise, all multicasts would have to be broadcast on
> > > the spanning
> > > > > tree interconnecting the bridged network that sits
> > > between the two
> > > > > rBridges.
> > > > >
> > > > >
> > > > > If we didn't care about multicast pruning, we wouldn't
> > > need to worry
> > > > > about any of this.
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5SFjxJB010263 for <[e-mail]>; Thu, 28 Jun 2007 08:46:00 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-6.tower-153.messagelabs.com!1183045558!1070228!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 5677 invoked from network); 28 Jun 2007 15:45:58 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 28 Jun 2007 15:45:58 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5SFjwr1007232 for <[e-mail]>; Thu, 28 Jun 2007 08:45:58 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l5SFjvlY017891 for <[e-mail]>; Thu, 28 Jun 2007 10:45:57 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5SFjuiE017880 for <[e-mail]>; Thu, 28 Jun 2007 10:45:57 -0500 (CDT)
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: Thu, 28 Jun 2007 11:45:53 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
thread-index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAIJkIAAA3F7wAAC+B5A=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SFjxJB010263
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 15:46:47 -0000
Status: RO
Content-Length: 4435

If it were not for the V bit, how would you distinguish an IS-IS routing
packet conveying layer 3 routing information being sent inside a TRILL
data frame from a layer 2 TRILL per VLAN IS-IS packet being sent inside
a TRILL IS-IS frame?

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Thursday, June 28, 2007 10:34 AM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] a clarification about the core IS-IS instance

Hi Donald,

Thanks again.

What's the function of the V-bit in all
of this?  What does an RBridge gain by looking
at this, that it cannot get by looking at
fields that it already has to?

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 7:30 AM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Anoop,
> 
> That looks about right, although you also have to check that 
> the inner length/type field is in the length range. And if 
> you determine that a TRILL IS-IS frame is for a per VLAN 
> instance, you still don't know if you should process as well 
> as forwarding it until you check whether you are DRB for a 
> link with an end station in that VLAN.
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Thursday, June 28, 2007 10:00 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Donald,
> 
> Thanks for the clarification.  Yes, I do remember the 
> discussion on the list.  At that time it looked like the 
> Ethertype would tell if the frame was IS-IS.
> It now looks like even the core IS-IS instance will use a 
> DSAP/SSAP (for some reason I thought we were going to use a 
> new Ethertype for the core IS-IS instance).
> 
> So, to identify a core IS-IS frame (which all RBridges should 
> be interested in) one would have to check for:
> outer.etype = trill
> inner.dsap = xx
> inner.ssap = xx
> inner.ctl = yy
> inner.vlan = not present
> 
> The V bit doesn't really seem all that useful since both the 
> core frames and the per-VLAN instance have it set, so that 
> bit doesn't tell one whether or the packet needs to be 
> processed as a control packet at a given RBridge.  The above 
> fields are necessary and sufficient.  Please let me know if 
> I'm missing something re the V bit.
> 
> Thanks,
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Wednesday, June 27, 2007 9:09 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Hi Anoop,
> > 
> > Yes, that was a change that was extensively discussed on 
> the mailing 
> > list. There wasn't a formal consensus determination but it 
> was clear 
> > that the sentiment of the group was to always have a TRILL 
> Header on 
> > TRILL IS-IS frames and use a formerly reserved bit in the header to 
> > distinguish a TRILL IS-IS frame from a TRILL data frame 
> whose contents 
> > happens to be a (presumably layer 3) IS-IS message.
> > 
> > I believe your second point is correct. Checking for the TRILL 
> > Ethertype is the key to deciding whether to process a frame 
> if you are 
> > not DRB on that port and VLAN. (This ignores the 
> bridging/media frames 
> > sent to the block of multicast 16 addresses reserved for that 
> > purpose.)
> > 
> > Thanks,
> > Donald
> > 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> > Sent: Wednesday, June 27, 2007 9:42 PM
> > To: [e-mail]
> > Subject: [rbridge] a clarification about the core IS-IS instance
> > 
> > From reading the previous version of the draft I got the impression 
> > that frames sent as part of the core IS-IS would not 
> contain a trill 
> > header or inner header.  However, on reading this version, it looks 
> > like the core IS-IS instance would in fact contain a trill header.
> > 
> > Assuming that the above is true, would it be safe to assume that an 
> > RBridge, for a port that is connected to a LAN for which it 
> is not a 
> > DRB, will drop all frames whose Ethertype does not indicate trill?
> > 
> > Anoop
> > 
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5SEl0EW022701 for <[e-mail]>; Thu, 28 Jun 2007 07:47:00 -0700 (PDT)
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: Thu, 28 Jun 2007 07:46:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
Thread-Index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAb/e4A==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SEl0EW022701
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 14:48:09 -0000
Status: RO
Content-Length: 3495

If we want to use the "inner.vlan = not present" to distinguish the core
instance from the per VLAN instance, we must specify that all TRILL
frames MUST have an explicit inner.vlan unless they are the ISIS core
instance.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Thursday, June 28, 2007 7:00 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Donald,
> 
> Thanks for the clarification.  Yes, I do remember
> the discussion on the list.  At that time it looked
> like the Ethertype would tell if the frame was IS-IS.
> It now looks like even the core IS-IS instance will
> use a DSAP/SSAP (for some reason I thought we were
> going to use a new Ethertype for the core IS-IS
> instance).
> 
> So, to identify a core IS-IS frame (which all RBridges
> should be interested in) one would have to check for:
> outer.etype = trill
> inner.dsap = xx
> inner.ssap = xx
> inner.ctl = yy
> inner.vlan = not present
> 
> The V bit doesn't really seem all that useful since
> both the core frames and the per-VLAN instance have
> it set, so that bit doesn't tell one whether or
> the packet needs to be processed as a control
> packet at a given RBridge.  The above fields are
> necessary and sufficient.  Please let me know if
> I'm missing something re the V bit.
> 
> Thanks,
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Wednesday, June 27, 2007 9:09 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> >
> > Hi Anoop,
> >
> > Yes, that was a change that was extensively discussed on the
> > mailing list. There wasn't a formal consensus determination
> > but it was clear that the sentiment of the group was to
> > always have a TRILL Header on TRILL IS-IS frames and use a
> > formerly reserved bit in the header to distinguish a TRILL
> > IS-IS frame from a TRILL data frame whose contents happens to
> > be a (presumably layer 3) IS-IS message.
> >
> > I believe your second point is correct. Checking for the
> > TRILL Ethertype is the key to deciding whether to process a
> > frame if you are not DRB on that port and VLAN. (This ignores
> > the bridging/media frames sent to the block of multicast 16
> > addresses reserved for that purpose.)
> >
> > Thanks,
> > Donald
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> > Sent: Wednesday, June 27, 2007 9:42 PM
> > To: [e-mail]
> > Subject: [rbridge] a clarification about the core IS-IS instance
> >
> > From reading the previous version of the draft I got the
> > impression that frames sent as part of the core IS-IS would
> > not contain a trill header or inner header.  However, on
> > reading this version, it looks like the core IS-IS instance
> > would in fact contain a trill header.
> >
> > Assuming that the above is true, would it be safe to assume
> > that an RBridge, for a port that is connected to a LAN for
> > which it is not a DRB, will drop all frames whose Ethertype
> > does not indicate trill?
> >
> > Anoop
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5SEYDqG018253 for <[e-mail]>; Thu, 28 Jun 2007 07:34:13 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 28 Jun 2007 07:34:13 -0700
X-IronPort-AV: i="4.16,471,1175497200";  d="scan'208"; a="14337478:sNHT18653054"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 1E2A923836C; Thu, 28 Jun 2007 07:31:40 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jun 2007 07:34:12 -0700
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: Thu, 28 Jun 2007 07:33:42 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
Thread-Index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAIJkIAAA3F7w
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 28 Jun 2007 14:34:12.0984 (UTC) FILETIME=[65A1AF80:01C7B991]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SEYDqG018253
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 14:34:28 -0000
Status: RO
Content-Length: 3950

Hi Donald,

Thanks again.

What's the function of the V-bit in all
of this?  What does an RBridge gain by looking
at this, that it cannot get by looking at
fields that it already has to?

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Thursday, June 28, 2007 7:30 AM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Anoop,
> 
> That looks about right, although you also have to check that 
> the inner length/type field is in the length range. And if 
> you determine that a TRILL IS-IS frame is for a per VLAN 
> instance, you still don't know if you should process as well 
> as forwarding it until you check whether you are DRB for a 
> link with an end station in that VLAN.
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Thursday, June 28, 2007 10:00 AM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Donald,
> 
> Thanks for the clarification.  Yes, I do remember the 
> discussion on the list.  At that time it looked like the 
> Ethertype would tell if the frame was IS-IS.
> It now looks like even the core IS-IS instance will use a 
> DSAP/SSAP (for some reason I thought we were going to use a 
> new Ethertype for the core IS-IS instance).
> 
> So, to identify a core IS-IS frame (which all RBridges should 
> be interested in) one would have to check for:
> outer.etype = trill
> inner.dsap = xx
> inner.ssap = xx
> inner.ctl = yy
> inner.vlan = not present
> 
> The V bit doesn't really seem all that useful since both the 
> core frames and the per-VLAN instance have it set, so that 
> bit doesn't tell one whether or the packet needs to be 
> processed as a control packet at a given RBridge.  The above 
> fields are necessary and sufficient.  Please let me know if 
> I'm missing something re the V bit.
> 
> Thanks,
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Wednesday, June 27, 2007 9:09 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Hi Anoop,
> > 
> > Yes, that was a change that was extensively discussed on 
> the mailing 
> > list. There wasn't a formal consensus determination but it 
> was clear 
> > that the sentiment of the group was to always have a TRILL 
> Header on 
> > TRILL IS-IS frames and use a formerly reserved bit in the header to 
> > distinguish a TRILL IS-IS frame from a TRILL data frame 
> whose contents 
> > happens to be a (presumably layer 3) IS-IS message.
> > 
> > I believe your second point is correct. Checking for the TRILL 
> > Ethertype is the key to deciding whether to process a frame 
> if you are 
> > not DRB on that port and VLAN. (This ignores the 
> bridging/media frames 
> > sent to the block of multicast 16 addresses reserved for that 
> > purpose.)
> > 
> > Thanks,
> > Donald
> > 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> > Sent: Wednesday, June 27, 2007 9:42 PM
> > To: [e-mail]
> > Subject: [rbridge] a clarification about the core IS-IS instance
> > 
> > From reading the previous version of the draft I got the impression 
> > that frames sent as part of the core IS-IS would not 
> contain a trill 
> > header or inner header.  However, on reading this version, it looks 
> > like the core IS-IS instance would in fact contain a trill header.
> > 
> > Assuming that the above is true, would it be safe to assume that an 
> > RBridge, for a port that is connected to a LAN for which it 
> is not a 
> > DRB, will drop all frames whose Ethertype does not indicate trill?
> > 
> > Anoop
> > 
> 



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5SETZTC017370 for <[e-mail]>; Thu, 28 Jun 2007 07:29:35 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-128.messagelabs.com!1183040974!12131120!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 8029 invoked from network); 28 Jun 2007 14:29:34 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 28 Jun 2007 14:29:34 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5SETY6h007876 for <[e-mail]>; Thu, 28 Jun 2007 07:29:34 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l5SETXOG022010 for <[e-mail]>; Thu, 28 Jun 2007 09:29:33 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5SETW5T021997 for <[e-mail]>; Thu, 28 Jun 2007 09:29:33 -0500 (CDT)
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: Thu, 28 Jun 2007 10:29:30 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
thread-index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNAAAIJkIA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SETZTC017370
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 14:30:01 -0000
Status: RO
Content-Length: 3283

Hi Anoop,

That looks about right, although you also have to check that the inner
length/type field is in the length range. And if you determine that a
TRILL IS-IS frame is for a per VLAN instance, you still don't know if
you should process as well as forwarding it until you check whether you
are DRB for a link with an end station in that VLAN.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Thursday, June 28, 2007 10:00 AM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] a clarification about the core IS-IS instance

Hi Donald,

Thanks for the clarification.  Yes, I do remember
the discussion on the list.  At that time it looked
like the Ethertype would tell if the frame was IS-IS.
It now looks like even the core IS-IS instance will
use a DSAP/SSAP (for some reason I thought we were
going to use a new Ethertype for the core IS-IS
instance).

So, to identify a core IS-IS frame (which all RBridges
should be interested in) one would have to check for:
outer.etype = trill
inner.dsap = xx
inner.ssap = xx
inner.ctl = yy
inner.vlan = not present

The V bit doesn't really seem all that useful since
both the core frames and the per-VLAN instance have
it set, so that bit doesn't tell one whether or 
the packet needs to be processed as a control 
packet at a given RBridge.  The above fields are
necessary and sufficient.  Please let me know if
I'm missing something re the V bit.

Thanks,
Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 27, 2007 9:09 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Anoop,
> 
> Yes, that was a change that was extensively discussed on the 
> mailing list. There wasn't a formal consensus determination 
> but it was clear that the sentiment of the group was to 
> always have a TRILL Header on TRILL IS-IS frames and use a 
> formerly reserved bit in the header to distinguish a TRILL 
> IS-IS frame from a TRILL data frame whose contents happens to 
> be a (presumably layer 3) IS-IS message.
> 
> I believe your second point is correct. Checking for the 
> TRILL Ethertype is the key to deciding whether to process a 
> frame if you are not DRB on that port and VLAN. (This ignores 
> the bridging/media frames sent to the block of multicast 16 
> addresses reserved for that purpose.)
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 27, 2007 9:42 PM
> To: [e-mail]
> Subject: [rbridge] a clarification about the core IS-IS instance
> 
> From reading the previous version of the draft I got the 
> impression that frames sent as part of the core IS-IS would 
> not contain a trill header or inner header.  However, on 
> reading this version, it looks like the core IS-IS instance 
> would in fact contain a trill header.
> 
> Assuming that the above is true, would it be safe to assume 
> that an RBridge, for a port that is connected to a LAN for 
> which it is not a DRB, will drop all frames whose Ethertype 
> does not indicate trill?
> 
> Anoop
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5SEQi8h016382 for <[e-mail]>; Thu, 28 Jun 2007 07:26:44 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 28 Jun 2007 07:26:44 -0700
X-IronPort-AV: i="4.16,471,1175497200";  d="scan'208"; a="14336979:sNHT24403659"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 0E32D23836C; Thu, 28 Jun 2007 07:24:11 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jun 2007 07:26:44 -0700
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: Thu, 28 Jun 2007 07:26:12 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
Thread-Index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiAAjFbNEABfljBQADB5xbA=
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Jun 2007 14:26:44.0299 (UTC) FILETIME=[5A31C9B0:01C7B990]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SEQi8h016382
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 14:27:23 -0000
Status: RO
Content-Length: 18297

I'm with Silvano on this; I'd rather not
see the fields moved around.

I'm also skeptical about the need for the
several flavors of the V-bits.  I think
the Rbridge nickname, inner MAC address, and 
inner VLAN combo should be enough to tell
one how to forward the frame.

Anoop

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Silvano Gai
> Sent: Wednesday, June 27, 2007 8:18 AM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] TRILL Header/Tag
> 
> 
> Donald,
> 
> The information contained in your email was known and discussed at the
> time of the consensus on the header format. I don't see any reason to
> change and I remain strongly in favor of the current format.
> 
> -- Silvano
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Monday, June 25, 2007 11:09 AM
> > To: [e-mail]
> > Subject: [rbridge] TRILL Header/Tag
> > 
> > Hi,
> > 
> > The current TRILL data frame on an 802.3 link looks like this (the
> Outer
> > VLAN Tag is not always present):
> > 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                  Outer Destination MAC Address                |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Outer Destination MAC Address | Outer Source MAC Address      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Outer Source MAC Address                   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > Start "TRILL Header":
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = TRILL             |  V  |M|R|Op-Length| Hop Count |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |    Egress (RB2) Nickname      |    Ingress (RB1) Nickname     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > :End "TRILL Header"
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |               Inner Destination MAC Address                   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Inner Destination MAC Address |  Inner Source MAC Address     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Inner Source MAC Address                   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = IEEE 802.1Q       |  Inner.VLAN Tag Information   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |       Payload Ethertype       |                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Payload                 |
> >    |                                                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                      FCS (Frame CheckSum)                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Where the V field is two zero bits, for Version 0, followed 
> by another
> > zero bit for a TRILL data frame (or a 1 bit for a TRILL 
> IS-IS frame).
> > That is, V=0 (or V=1). See draft-ietf-trill-rbridge-protocol-04.txt.
> > 
> > (Side note: there should be a separate discussion about Q-tags
> > versus/and/or S-tags but I think that is pretty orthogonal to what I
> > want to talk about here.)
> > 
> > There is no question that this format "works". But I don't 
> see that as
> > the point. After all, 803.3 Ethernet would "work" if you moved the
> > Destination Address to the end of the frame. But it wouldn't be good
> > engineering, because cut through switching or similar optimizations
> > would be impossible.
> > 
> > What I am primarily worried about is the fast path at transit
> Rbridges.
> > There doesn't seem to be any way to avoid a fair amount of 
> work at the
> > ingress Rbridge. And it could be that there would be some
> > implementations that wouldn't mind having to grovel deep 
> into a frame
> at
> > every transit Rbridge. But I think most implementations will want
> > transit Rbridge processing of TRILL data frames to be as simple as
> > possible. And I should think that anyone who is worrying about
> Rbridging
> > 10Gbps Ethernet or even fast optical channels should be having
> problems
> > looking at the current TRILL protocol specification.
> > 
> > First, lets look at unicast. Seems really nice and efficient, even
> with
> > the present design. You just decrement the hop count and, if it is
> > non-zero, use the egress Rbridge nickname to look up the next hop
> > destination MAC address, output port, and Outer VLAN ID if any, and
> off
> > you go. Well, I think it is just a little more complex than that. In
> > particular, what do you do about the Outer VLAN Tag 
> priority field? An
> > Outer VLAN Tag added by the previous Rbridge could have 
> been stripped
> or
> > changed by bridges. You could imagine wanting to configure various
> > strategies but I think the right zero configuration default is to
> simply
> > get the priority from the Inner VLAN Tag. (Of course, if that turns
> out
> > to be the default priority and no Outer VLAN is needed for
> connectivity
> > to the next hop Rbridge, no Outer VLAN Tag may be needed at 
> all.) And
> > then there are options. They start right after ingress nickname and,
> > even if you can get around the priority problem, if there 
> are options
> > present, you probably have to look at the first bit or two of the
> > options area to determine that none of them apply to you...
> > 
> > So unicast isn't too bad, but even there I think you have to check a
> > couple of bits beyond the header if options are present and the best
> > default strategy requires you to delve into the inner frame to check
> the
> > data priority.
> > 
> > It's multi-destination frames that are the real problem with the
> current
> > design for a high speed transit Rbridge that wants to prune the
> > distribution tree. And, based on comments on this working group
> mailing
> > list, many developers will want to prune.
> > 
> > So, say we receive a multi-destination data frame. You know the
> > distribution tree from the "egress" nickname field. But if 
> you want to
> > do any pruning, you have to look beyond the TRILL Header. 
> Getting the
> > information for pruning by VLAN, you need to look at the 
> Inner VLAN ID
> > which may require skipping over options.
> > 
> > Then we get to multicast pruning. To do that, you might 
> first look at
> > the Destination MAC Address. That comes even before the 
> Inner VLAN Tag
> > that you had to look at for VLAN pruning, so this doesn't sound too
> > hard. But it also turns out that it is not adequate. RFC 
> 4541 on IGMP
> > snooping and the like is now out and it points out that there are
> ranges
> > of special IPv4 and IPv6 multicast addresses for which 
> hosts don't, or
> > at least can not be depended on to, issue IGMPs (or MLDs or IPv6).
> > Therefore, frames sent to those IP multicast addresses have to be
> > treated as broadcast and distribution can't be pruned. But, these IP
> > multicast addresses are translated ambiguously to MAC multicast
> > addresses just like other IP multicast addresses. So, if we look at
> the
> > Destination MAC address and find it is an IP derived 
> multicast, we are
> > not done.
> > 
> > For IPv4 derived multicast MAC addresses, there is a range of such
> > multicast addresses for which you have to dig even deeper into the
> frame
> > and look at the actual IPv4 address to see if you can prune 
> or have to
> > broadcast. True, for IPv4 it is only a small fraction of 
> the possible
> IP
> > derived multicast addresses, and an alternative might be to always
> > broadcast frames to those IPv4 derived MAC multicast 
> addresses; but if
> > some group just happens to be sending their streaming video over a
> > multicast group that just happens to map into this area, it may not
> work
> > out so well for your network that those frames are getting broadcast
> > everywhere in that VLAN.
> > 
> > The situation it much worse for IPv6. In the case of IPv6 
> derived MAC
> > multicast addresses, 100% are potentially for special IPv6 multicast
> > addresses that you must broadcast. As a result, if you are going to
> > prune IPv6 derived multicast, you *always* have to go look at the
> actual
> > IPv6 destination address deeper in the frame to decide 
> whether or not
> to
> > prune.
> > 
> > Finally, we come to the worst case, detecting IGMP, MLD, etc.
> messages.
> > Here you have to go beyond the IPv4 or IPv6 destination 
> address, delve
> > deeper into the IP header and, in some cases, into the IP packet
> content
> > just to figure out whether you need to prune the 
> distribution tree to
> > branches with IP multicast routers on them for IGMP and MLD (and RFC
> > 4541 specifically recommends, due to confusions that can happen
> between
> > IGMPv3 and earlier version of IGMP, not sending such 
> message to links
> > unless they have an IP multicast router on the).
> > 
> > I really don't think you want to have to look into the content of IP
> > packets to make forwarding decisions at transit Rbridges.
> > 
> > So, what I suggest is something more like the following:
> > 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                  Outer Destination MAC Address                |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Outer Destination MAC Address | Outer Source MAC Address      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |          Outer Source MAC Address  (last four bytes)          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > Start "TRILL Tag":
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |         TRILL Ethertype       |   V   |M|Op-Length| Hop Count |
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |   Egress RBridge Nickname     |  Inner VLAN Tag information   |
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |        Inner Destination MAC Address (first four bytes)       |
> >  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  = |   Inner Dest MAC Adr          |  Ingress RBridge Nickname     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |           Inner Source MAC Address (first four bytes)         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Rest of Inner Src MAC Adr   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > End "TRILL Tag":                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                                    |       Payload Ethertype       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Payload ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  Final Checksum:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                       Frame Check Sum                         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > where
> >    V = 0 for TRILL IS-IS frames
> >    V = 1 for TRILL data pruned only on VLAN
> >    V = 2 for TRILL data pruned on VLAN and IP multicast MAC address
> >    V = 3 for TRILL data pruned on VLAN and IP multicast routers
> location
> > 
> > This puts everything that is needed for a transit Rbridge to forward
> > frames in the first 128 bits of what I have labeled the 
> TRILL Tag (see
> > "=" in left margin). Why did I label it "Tag" rather than "Header"?
> > Well, the header paradigm seems to connote that we are 
> adding a header
> > in front of an almost complete Ethernet frame. Tag seems 
> like a better
> > word if we are constructing a block that goes in front of a frame
> > contents, not a frame. In some ways, it just depends on how you look
> at
> > it.
> > 
> > For multicast optimization, the investigation into the frame as to
> > whether the distribution tree should be (1) only VLAN pruned, (2)
> pruned
> > on VLAN and based on multicast destination address, or (3) pruned on
> > VLAN and branches that have multicast routers, needs to be made only
> > once, at the ingress Rbridge, and is then encoded into V.
> > 
> > The current header is 64-bits and 64-bit aligned (starting after the
> > Outer VLAN tag) which is nice, but you always have to look beyond it
> for
> > every frame. Sometimes way beyond it, including skipping over any
> TRILL
> > options and IP options, to look into the content of IP packets.
> > 
> > The suggested TRILL tag is 176 bits long but, unless you 
> are an egress
> > Rbridge, you only have to look at the first 128 bits which 
> is 128-bit
> > aligned (ignoring the outer VLAN tag like I did for the current
> header).
> > But since fields are mostly just being moved around, at 
> worst you gain
> > or lose two bytes total length over previous proposals. 
> Options would
> > start after the destination MAC address so, even if options are
> present,
> > you can check the first few bits of the options area without going
> > outside this 128-bit area.
> > 
> > This proposal does suppress the Ethertype for the inner VLAN Tag
> > information but there is some precedent for that sort of thing. For
> > example, 802.16 has a header suppression feature where you can set
> some
> > flag bits and then leave out Q-tag and/or IPv4 or IPv6 Ethertypes.
> > 
> > So, while various minor changes could be made, the above is my
> > suggestion for significantly improving the simplicity and 
> cut through
> > switching latency of handling TRILL data frames at transit Rbridges.
> > 
> > Since there was a consensus determination in favor of the current
> TRILL
> > Header, there needs to be a consensus to re-open the question. If
> there
> > isn't, my fall back position would be to suggest expanding 
> the values
> of
> > V in the TRILL Header to encode the correct pruning strategy for a
> > frame, as listed with the TRILL Tag proposal above. This would not
> > eliminate the need to delve into the inner frame whenever a TRILL
> frame
> > is handled by a transit Rbridge, but would reduce to depth and
> > complexity of such delving...
> > 
> > Thanks,
> > Donald
> > 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Friday, June 22, 2007 6:44 PM
> > To: Silvano Gai; Radia Perlman
> > Cc: [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > 
> > I don't see much of an advantage to changing things because
> > it doesn't change the fact that rBridges rely on the
> > "inner frame" to get correct pruning behavior for multicasts.
> > 
> > However, I agree with Silvano.  _If_ something is going
> > to change, let's try and settle it as soon as we possibly can.
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Thursday, June 21, 2007 7:09 AM
> > > To: Radia Perlman; Anoop Ghanwani
> > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > >
> > > Radia,
> > >
> > > This information was known at the time of the consensus.
> > > I still remain in favor of the header we selected.
> > > If somebody wants to change his/her mind they can email this
> > > list (SOON).
> > >
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Radia Perlman [mailto:[e-mail]]
> > > > Sent: Wednesday, June 20, 2007 12:57 PM
> > > > To: Anoop Ghanwani
> > > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
> > > [e-mail]
> > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > As Anoop said, core RBridges need to look inside the
> > > tunneled packet
> > > > at the inner packet in order to do multicast pruning as
> > > well as VLAN
> > > > pruning on multicast packets.
> > > >
> > > > Which is why Don was proposing moving both the VLAN tag and the
> > > > destination multicast address to the TRILL header. (and
> > > removing the
> > > > VLAN tag and DA from the inner packet so that it wouldn't
> > > mean adding
> > > > an extra 6 bytes to an encapsulated frame).
> > > >
> > > > Seemed like people didn't like doing that, but I want to
> > > make sure if
> > > > the WG really is deciding not to do that, that they really
> > > understand
> > > > what they are deciding against.
> > > > Often in the email threads so many different things are kind of
> > > > discussed at the same time that it's obvious that people
> > > (definitely
> > > > including me) are getting confused.
> > > >
> > > > Radia
> > > >
> > > >
> > > >
> > > >
> > > > Anoop Ghanwani wrote:
> > > > >
> > > > > They're snooping because they too care about pruning
> > > their trees for
> > > > > a given multicast group and that would be one of the ways
> > > to achieve
> > > > > it.
> > > > > Otherwise, all multicasts would have to be broadcast on
> > > the spanning
> > > > > tree interconnecting the bridged network that sits
> > > between the two
> > > > > rBridges.
> > > > >
> > > > >
> > > > > If we didn't care about multicast pruning, we wouldn't
> > > need to worry
> > > > > about any of this.
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5SE0jhQ008919 for <[e-mail]>; Thu, 28 Jun 2007 07:01:00 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 28 Jun 2007 07:00:41 -0700
X-IronPort-AV: i="4.16,470,1175497200";  d="scan'208"; a="14335239:sNHT18253697"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 3356023836C; Thu, 28 Jun 2007 06:58:08 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jun 2007 07:00:41 -0700
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: Thu, 28 Jun 2007 07:00:10 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
Thread-Index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6gABTgcNA=
References: <[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 28 Jun 2007 14:00:41.0374 (UTC) FILETIME=[B69E5BE0:01C7B98C]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5SE0jhQ008919
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 14:02:04 -0000
Status: RO
Content-Length: 2688

Hi Donald,

Thanks for the clarification.  Yes, I do remember
the discussion on the list.  At that time it looked
like the Ethertype would tell if the frame was IS-IS.
It now looks like even the core IS-IS instance will
use a DSAP/SSAP (for some reason I thought we were
going to use a new Ethertype for the core IS-IS
instance).

So, to identify a core IS-IS frame (which all RBridges
should be interested in) one would have to check for:
outer.etype = trill
inner.dsap = xx
inner.ssap = xx
inner.ctl = yy
inner.vlan = not present

The V bit doesn't really seem all that useful since
both the core frames and the per-VLAN instance have
it set, so that bit doesn't tell one whether or 
the packet needs to be processed as a control 
packet at a given RBridge.  The above fields are
necessary and sufficient.  Please let me know if
I'm missing something re the V bit.

Thanks,
Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 27, 2007 9:09 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Anoop,
> 
> Yes, that was a change that was extensively discussed on the 
> mailing list. There wasn't a formal consensus determination 
> but it was clear that the sentiment of the group was to 
> always have a TRILL Header on TRILL IS-IS frames and use a 
> formerly reserved bit in the header to distinguish a TRILL 
> IS-IS frame from a TRILL data frame whose contents happens to 
> be a (presumably layer 3) IS-IS message.
> 
> I believe your second point is correct. Checking for the 
> TRILL Ethertype is the key to deciding whether to process a 
> frame if you are not DRB on that port and VLAN. (This ignores 
> the bridging/media frames sent to the block of multicast 16 
> addresses reserved for that purpose.)
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 27, 2007 9:42 PM
> To: [e-mail]
> Subject: [rbridge] a clarification about the core IS-IS instance
> 
> From reading the previous version of the draft I got the 
> impression that frames sent as part of the core IS-IS would 
> not contain a trill header or inner header.  However, on 
> reading this version, it looks like the core IS-IS instance 
> would in fact contain a trill header.
> 
> Assuming that the above is true, would it be safe to assume 
> that an RBridge, for a port that is connected to a LAN for 
> which it is not a DRB, will drop all frames whose Ethertype 
> does not indicate trill?
> 
> Anoop
> 



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5S48enN029585 for <[e-mail]>; Wed, 27 Jun 2007 21:08:40 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-128.messagelabs.com!1183003719!4878582!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 28068 invoked from network); 28 Jun 2007 04:08:39 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 28 Jun 2007 04:08:39 -0000
Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5S48cb1026495 for <[e-mail]>; Wed, 27 Jun 2007 21:08:38 -0700 (MST)
Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5S48bho024899 for <[e-mail]>; Wed, 27 Jun 2007 23:08:38 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5S48at3024887 for <[e-mail]>; Wed, 27 Jun 2007 23:08:37 -0500 (CDT)
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: Thu, 28 Jun 2007 00:08:34 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] a clarification about the core IS-IS instance
thread-index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVAAEqm6g
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5S48enN029585
Cc: [e-mail]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 04:09:25 -0000
Status: RO
Content-Length: 1443

Hi Anoop,

Yes, that was a change that was extensively discussed on the mailing
list. There wasn't a formal consensus determination but it was clear
that the sentiment of the group was to always have a TRILL Header on
TRILL IS-IS frames and use a formerly reserved bit in the header to
distinguish a TRILL IS-IS frame from a TRILL data frame whose contents
happens to be a (presumably layer 3) IS-IS message.

I believe your second point is correct. Checking for the TRILL Ethertype
is the key to deciding whether to process a frame if you are not DRB on
that port and VLAN. (This ignores the bridging/media frames sent to the
block of multicast 16 addresses reserved for that purpose.)

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 27, 2007 9:42 PM
To: [e-mail]
Subject: [rbridge] a clarification about the core IS-IS instance

>From reading the previous version of the draft
I got the impression that frames sent as part
of the core IS-IS would not contain a trill header
or inner header.  However, on reading this version,
it looks like the core IS-IS instance would in 
fact contain a trill header.

Assuming that the above is true, would it be safe
to assume that an RBridge, for a port that is
connected to a LAN for which it is not a DRB,
will drop all frames whose Ethertype does not
indicate trill?

Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5S1gDT0025616 for <[e-mail]>; Wed, 27 Jun 2007 18:42:17 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 27 Jun 2007 18:42:13 -0700
X-IronPort-AV: i="4.16,468,1175497200";  d="scan'208,223"; a="11274402:sNHT15915935"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 6B11E238372 for <[e-mail]>; Wed, 27 Jun 2007 18:39:41 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jun 2007 18:42:13 -0700
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, 27 Jun 2007 18:41:42 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: a clarification about the core IS-IS instance
Thread-Index: Ace5JXp8kwUIdcP4Si2Qq3qvm5MEVA==
From: "Anoop Ghanwani" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 28 Jun 2007 01:42:14.0127 (UTC) FILETIME=[8D70FFF0:01C7B925]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5S1gDT0025616
Subject: [rbridge] a clarification about the core IS-IS instance
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 01:42:36 -0000
Status: RO
Content-Length: 488

>From reading the previous version of the draft
I got the impression that frames sent as part
of the core IS-IS would not contain a trill header
or inner header.  However, on reading this version,
it looks like the core IS-IS instance would in 
fact contain a trill header.

Assuming that the above is true, would it be safe
to assume that an RBridge, for a port that is
connected to a LAN for which it is not a DRB,
will drop all frames whose Ethertype does not
indicate trill?

Anoop



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5RGcJxG019290 for <[e-mail]>; Wed, 27 Jun 2007 09:38:19 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-128.messagelabs.com!1182962297!19283041!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12661 invoked from network); 27 Jun 2007 16:38:17 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 27 Jun 2007 16:38:17 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5RGcHDx007638 for <[e-mail]>; Wed, 27 Jun 2007 09:38:17 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l5RGcG2X002111 for <[e-mail]>; Wed, 27 Jun 2007 11:38:16 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5RGcF6S002095 for <[e-mail]>; Wed, 27 Jun 2007 11:38:16 -0500 (CDT)
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, 27 Jun 2007 12:38:10 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
thread-index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiAAjFbNEABfljBQAAHzGIAAANcDAA==
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5RGcJxG019290
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 16:38:53 -0000
Status: RO
Content-Length: 1733

Sorry, a point I left out in my message below:

At the time of the previous discussion, I believed, and I think most
people believed, that there was no reason for a transit Rbridge to look
beyond the TRILL Header for unicast traffic. However, that may not be
true because the transit Rbridge may have to dig down to the inner VLAN
tag to find the priority.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Wednesday, June 27, 2007 12:17 PM
To: Silvano Gai
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header/Tag

Hi Silvano,

It is true that most of the information was know.

However I didn't know, and I don't recall it being discussed, that an IP
derived multicast destination MAC address is insufficient to tell
whether or not you can multicast prune the distribution tree.  I don't
know about other people, but I didn't know that until I looked at RFC
4541.

Do you object to changing from 2 message types to 4 message types so
that the type of distribution tree pruning that would be advisable is
encoded into the message type?

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Wednesday, June 27, 2007 11:18 AM
To: Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

The information contained in your email was known and discussed at the
time of the consensus on the header format. I don't see any reason to
change and I remain strongly in favor of the current format.

-- Silvano

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



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5RGGsMs013277 for <[e-mail]>; Wed, 27 Jun 2007 09:16:55 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-119.messagelabs.com!1182961013!16308470!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 2608 invoked from network); 27 Jun 2007 16:16:54 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 27 Jun 2007 16:16:54 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5RGGrH6001083 for <[e-mail]>; Wed, 27 Jun 2007 09:16:53 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5RGGr0c009552 for <[e-mail]>; Wed, 27 Jun 2007 11:16:53 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5RGGqWf009541 for <[e-mail]>; Wed, 27 Jun 2007 11:16:52 -0500 (CDT)
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, 27 Jun 2007 12:16:34 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
thread-index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiAAjFbNEABfljBQAAHzGIA=
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5RGGsMs013277
Cc: [e-mail]
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 16:17:22 -0000
Status: RO
Content-Length: 971

Hi Silvano,

It is true that most of the information was know.

However I didn't know, and I don't recall it being discussed, that an IP
derived multicast destination MAC address is insufficient to tell
whether or not you can multicast prune the distribution tree.  I don't
know about other people, but I didn't know that until I looked at RFC
4541.

Do you object to changing from 2 message types to 4 message types so
that the type of distribution tree pruning that would be advisable is
encoded into the message type?

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Wednesday, June 27, 2007 11:18 AM
To: Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

The information contained in your email was known and discussed at the
time of the consensus on the header format. I don't see any reason to
change and I remain strongly in favor of the current format.

-- Silvano



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5RFHx0S023053 for <[e-mail]>; Wed, 27 Jun 2007 08:17:59 -0700 (PDT)
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, 27 Jun 2007 08:17:33 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] TRILL Header/Tag
Thread-Index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiAAjFbNEABfljBQ
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5RFHx0S023053
Subject: Re: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 15:18:25 -0000
Status: RO
Content-Length: 16739

Donald,

The information contained in your email was known and discussed at the
time of the consensus on the header format. I don't see any reason to
change and I remain strongly in favor of the current format.

-- Silvano



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Monday, June 25, 2007 11:09 AM
> To: [e-mail]
> Subject: [rbridge] TRILL Header/Tag
> 
> Hi,
> 
> The current TRILL data frame on an 802.3 link looks like this (the
Outer
> VLAN Tag is not always present):
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Outer Destination MAC Address                |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Outer Destination MAC Address | Outer Source MAC Address      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Outer Source MAC Address                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Start "TRILL Header":
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Ethertype = TRILL             |  V  |M|R|Op-Length| Hop Count |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Egress (RB2) Nickname      |    Ingress (RB1) Nickname     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :End "TRILL Header"
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               Inner Destination MAC Address                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Inner Destination MAC Address |  Inner Source MAC Address     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Inner Source MAC Address                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Ethertype = IEEE 802.1Q       |  Inner.VLAN Tag Information   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       Payload Ethertype       |                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Payload                 |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      FCS (Frame CheckSum)                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Where the V field is two zero bits, for Version 0, followed by another
> zero bit for a TRILL data frame (or a 1 bit for a TRILL IS-IS frame).
> That is, V=0 (or V=1). See draft-ietf-trill-rbridge-protocol-04.txt.
> 
> (Side note: there should be a separate discussion about Q-tags
> versus/and/or S-tags but I think that is pretty orthogonal to what I
> want to talk about here.)
> 
> There is no question that this format "works". But I don't see that as
> the point. After all, 803.3 Ethernet would "work" if you moved the
> Destination Address to the end of the frame. But it wouldn't be good
> engineering, because cut through switching or similar optimizations
> would be impossible.
> 
> What I am primarily worried about is the fast path at transit
Rbridges.
> There doesn't seem to be any way to avoid a fair amount of work at the
> ingress Rbridge. And it could be that there would be some
> implementations that wouldn't mind having to grovel deep into a frame
at
> every transit Rbridge. But I think most implementations will want
> transit Rbridge processing of TRILL data frames to be as simple as
> possible. And I should think that anyone who is worrying about
Rbridging
> 10Gbps Ethernet or even fast optical channels should be having
problems
> looking at the current TRILL protocol specification.
> 
> First, lets look at unicast. Seems really nice and efficient, even
with
> the present design. You just decrement the hop count and, if it is
> non-zero, use the egress Rbridge nickname to look up the next hop
> destination MAC address, output port, and Outer VLAN ID if any, and
off
> you go. Well, I think it is just a little more complex than that. In
> particular, what do you do about the Outer VLAN Tag priority field? An
> Outer VLAN Tag added by the previous Rbridge could have been stripped
or
> changed by bridges. You could imagine wanting to configure various
> strategies but I think the right zero configuration default is to
simply
> get the priority from the Inner VLAN Tag. (Of course, if that turns
out
> to be the default priority and no Outer VLAN is needed for
connectivity
> to the next hop Rbridge, no Outer VLAN Tag may be needed at all.) And
> then there are options. They start right after ingress nickname and,
> even if you can get around the priority problem, if there are options
> present, you probably have to look at the first bit or two of the
> options area to determine that none of them apply to you...
> 
> So unicast isn't too bad, but even there I think you have to check a
> couple of bits beyond the header if options are present and the best
> default strategy requires you to delve into the inner frame to check
the
> data priority.
> 
> It's multi-destination frames that are the real problem with the
current
> design for a high speed transit Rbridge that wants to prune the
> distribution tree. And, based on comments on this working group
mailing
> list, many developers will want to prune.
> 
> So, say we receive a multi-destination data frame. You know the
> distribution tree from the "egress" nickname field. But if you want to
> do any pruning, you have to look beyond the TRILL Header. Getting the
> information for pruning by VLAN, you need to look at the Inner VLAN ID
> which may require skipping over options.
> 
> Then we get to multicast pruning. To do that, you might first look at
> the Destination MAC Address. That comes even before the Inner VLAN Tag
> that you had to look at for VLAN pruning, so this doesn't sound too
> hard. But it also turns out that it is not adequate. RFC 4541 on IGMP
> snooping and the like is now out and it points out that there are
ranges
> of special IPv4 and IPv6 multicast addresses for which hosts don't, or
> at least can not be depended on to, issue IGMPs (or MLDs or IPv6).
> Therefore, frames sent to those IP multicast addresses have to be
> treated as broadcast and distribution can't be pruned. But, these IP
> multicast addresses are translated ambiguously to MAC multicast
> addresses just like other IP multicast addresses. So, if we look at
the
> Destination MAC address and find it is an IP derived multicast, we are
> not done.
> 
> For IPv4 derived multicast MAC addresses, there is a range of such
> multicast addresses for which you have to dig even deeper into the
frame
> and look at the actual IPv4 address to see if you can prune or have to
> broadcast. True, for IPv4 it is only a small fraction of the possible
IP
> derived multicast addresses, and an alternative might be to always
> broadcast frames to those IPv4 derived MAC multicast addresses; but if
> some group just happens to be sending their streaming video over a
> multicast group that just happens to map into this area, it may not
work
> out so well for your network that those frames are getting broadcast
> everywhere in that VLAN.
> 
> The situation it much worse for IPv6. In the case of IPv6 derived MAC
> multicast addresses, 100% are potentially for special IPv6 multicast
> addresses that you must broadcast. As a result, if you are going to
> prune IPv6 derived multicast, you *always* have to go look at the
actual
> IPv6 destination address deeper in the frame to decide whether or not
to
> prune.
> 
> Finally, we come to the worst case, detecting IGMP, MLD, etc.
messages.
> Here you have to go beyond the IPv4 or IPv6 destination address, delve
> deeper into the IP header and, in some cases, into the IP packet
content
> just to figure out whether you need to prune the distribution tree to
> branches with IP multicast routers on them for IGMP and MLD (and RFC
> 4541 specifically recommends, due to confusions that can happen
between
> IGMPv3 and earlier version of IGMP, not sending such message to links
> unless they have an IP multicast router on the).
> 
> I really don't think you want to have to look into the content of IP
> packets to make forwarding decisions at transit Rbridges.
> 
> So, what I suggest is something more like the following:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Outer Destination MAC Address                |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Outer Destination MAC Address | Outer Source MAC Address      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Outer Source MAC Address  (last four bytes)          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Start "TRILL Tag":
>  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  = |         TRILL Ethertype       |   V   |M|Op-Length| Hop Count |
>  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  = |   Egress RBridge Nickname     |  Inner VLAN Tag information   |
>  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  = |        Inner Destination MAC Address (first four bytes)       |
>  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  = |   Inner Dest MAC Adr          |  Ingress RBridge Nickname     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |           Inner Source MAC Address (first four bytes)         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Rest of Inner Src MAC Adr   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> End "TRILL Tag":                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    |       Payload Ethertype       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Payload ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  Final Checksum:
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Frame Check Sum                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> where
>    V = 0 for TRILL IS-IS frames
>    V = 1 for TRILL data pruned only on VLAN
>    V = 2 for TRILL data pruned on VLAN and IP multicast MAC address
>    V = 3 for TRILL data pruned on VLAN and IP multicast routers
location
> 
> This puts everything that is needed for a transit Rbridge to forward
> frames in the first 128 bits of what I have labeled the TRILL Tag (see
> "=" in left margin). Why did I label it "Tag" rather than "Header"?
> Well, the header paradigm seems to connote that we are adding a header
> in front of an almost complete Ethernet frame. Tag seems like a better
> word if we are constructing a block that goes in front of a frame
> contents, not a frame. In some ways, it just depends on how you look
at
> it.
> 
> For multicast optimization, the investigation into the frame as to
> whether the distribution tree should be (1) only VLAN pruned, (2)
pruned
> on VLAN and based on multicast destination address, or (3) pruned on
> VLAN and branches that have multicast routers, needs to be made only
> once, at the ingress Rbridge, and is then encoded into V.
> 
> The current header is 64-bits and 64-bit aligned (starting after the
> Outer VLAN tag) which is nice, but you always have to look beyond it
for
> every frame. Sometimes way beyond it, including skipping over any
TRILL
> options and IP options, to look into the content of IP packets.
> 
> The suggested TRILL tag is 176 bits long but, unless you are an egress
> Rbridge, you only have to look at the first 128 bits which is 128-bit
> aligned (ignoring the outer VLAN tag like I did for the current
header).
> But since fields are mostly just being moved around, at worst you gain
> or lose two bytes total length over previous proposals. Options would
> start after the destination MAC address so, even if options are
present,
> you can check the first few bits of the options area without going
> outside this 128-bit area.
> 
> This proposal does suppress the Ethertype for the inner VLAN Tag
> information but there is some precedent for that sort of thing. For
> example, 802.16 has a header suppression feature where you can set
some
> flag bits and then leave out Q-tag and/or IPv4 or IPv6 Ethertypes.
> 
> So, while various minor changes could be made, the above is my
> suggestion for significantly improving the simplicity and cut through
> switching latency of handling TRILL data frames at transit Rbridges.
> 
> Since there was a consensus determination in favor of the current
TRILL
> Header, there needs to be a consensus to re-open the question. If
there
> isn't, my fall back position would be to suggest expanding the values
of
> V in the TRILL Header to encode the correct pruning strategy for a
> frame, as listed with the TRILL Tag proposal above. This would not
> eliminate the need to delve into the inner frame whenever a TRILL
frame
> is handled by a transit Rbridge, but would reduce to depth and
> complexity of such delving...
> 
> Thanks,
> Donald
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Friday, June 22, 2007 6:44 PM
> To: Silvano Gai; Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> 
> I don't see much of an advantage to changing things because
> it doesn't change the fact that rBridges rely on the
> "inner frame" to get correct pruning behavior for multicasts.
> 
> However, I agree with Silvano.  _If_ something is going
> to change, let's try and settle it as soon as we possibly can.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Thursday, June 21, 2007 7:09 AM
> > To: Radia Perlman; Anoop Ghanwani
> > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >
> > Radia,
> >
> > This information was known at the time of the consensus.
> > I still remain in favor of the header we selected.
> > If somebody wants to change his/her mind they can email this
> > list (SOON).
> >
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:[e-mail]]
> > > Sent: Wednesday, June 20, 2007 12:57 PM
> > > To: Anoop Ghanwani
> > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
> > [e-mail]
> > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > >
> > > As Anoop said, core RBridges need to look inside the
> > tunneled packet
> > > at the inner packet in order to do multicast pruning as
> > well as VLAN
> > > pruning on multicast packets.
> > >
> > > Which is why Don was proposing moving both the VLAN tag and the
> > > destination multicast address to the TRILL header. (and
> > removing the
> > > VLAN tag and DA from the inner packet so that it wouldn't
> > mean adding
> > > an extra 6 bytes to an encapsulated frame).
> > >
> > > Seemed like people didn't like doing that, but I want to
> > make sure if
> > > the WG really is deciding not to do that, that they really
> > understand
> > > what they are deciding against.
> > > Often in the email threads so many different things are kind of
> > > discussed at the same time that it's obvious that people
> > (definitely
> > > including me) are getting confused.
> > >
> > > Radia
> > >
> > >
> > >
> > >
> > > Anoop Ghanwani wrote:
> > > >
> > > > They're snooping because they too care about pruning
> > their trees for
> > > > a given multicast group and that would be one of the ways
> > to achieve
> > > > it.
> > > > Otherwise, all multicasts would have to be broadcast on
> > the spanning
> > > > tree interconnecting the bridged network that sits
> > between the two
> > > > rBridges.
> > > >
> > > >
> > > > If we didn't care about multicast pruning, we wouldn't
> > need to worry
> > > > about any of this.
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5Q3Er4i016668 for <[e-mail]>; Mon, 25 Jun 2007 20:14:53 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-6.tower-128.messagelabs.com!1182827692!21509943!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 26418 invoked from network); 26 Jun 2007 03:14:52 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 26 Jun 2007 03:14:52 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5Q3Eqed014972 for <[e-mail]>; Mon, 25 Jun 2007 20:14:52 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5Q3Eprf017623 for <[e-mail]>; Mon, 25 Jun 2007 22:14:51 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5Q3EoPL017613 for <[e-mail]>; Mon, 25 Jun 2007 22:14:51 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 25 Jun 2007 23:14:48 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] multicast router discovery: what's PIM got to do with it?
thread-index: Ace3SlXEmysGIdDFQYuoxqiED0lEtgAU3WQw
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "James Carlson" <[e-mail]>, "TRILL/RBridge Working Group" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5Q3Er4i016668
Subject: Re: [rbridge] multicast router discovery: what's PIM got to do with it?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 26 Jun 2007 03:15:05 -0000
Status: RO
Content-Length: 3552

You may be right. The provisions in the current draft were developed
based on earlier discussions in the working group and IETF meeting
hallways before RFC 4541 came out.

Donald 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of James Carlson
Sent: Monday, June 25, 2007 12:44 PM
To: TRILL/RBridge Working Group
Subject: [rbridge] multicast router discovery: what's PIM got to do with
it?

I've read through the list archives, and I'd like some clarification
on the mechanism chosen for detecting multicast routers in the latest
(*-protocol-04) draft.

Section 4.5.1.2 has this text:

   If the frame is a PIM or MRD [RFC4286] message, RB1 learns that there
   is an IP multicast router (for the specified VLAN) on its link, and
   adds that information for the appropriate VLAN in its IS-IS link
   state.

and 4.7 has this:

   Until Multicast Router Discovery (MRD) [RFC4286] is universally
   deployed, RBridges discover IP multicast routers through their
   transmission of PIM messages. So an RBridge concludes there is an IP
   multicast router on its port if it either receives an MRD message or
   a PIM message on that port. A PIM message is recognized because the
   protocol type in the IP header is decimal 103.

This seems odd to me.  RFC 4541 (also referenced) doesn't talk at all
about listening to PIM as part of an IGMP snooping strategy, or any
need to tie IGMP L2 forwarding behavior to any particular multicast
routing protocol.

IGMPv0 (RFC 988) didn't have 'queries', but it also didn't have the
suppression logic that later versions have, and it seems to be dead,
so it shouldn't be an issue.

IGMPv1 (RFC 1112) requires multicast routers (regardless of what
higher-level routing protocol they're using -- PIM or otherwise) to
send periodic IGMP Host Membership Query messages.  You'll know that
they're present by seeing these messages.

Similarly, IGMPv2 (RFC 2236) and MLDv1 (RFC 2710) require routers to
send periodic IGMP Membership Query and MLD Multicast Listener Query
messages.

IGMPv3 (RFC 3376) and MLDv2 (RFC 3810) do the same.  It seems likely
that future versions will be similar.

IGMP and MLD version compatibility depends on having periodic queries
present on the link, so if there's any functioning multicast routing
at all, these messages will be available.  Perhaps more importantly,
listing to PIM "correctly" would mean paying attention not just to the
presence of PIM, but to PIM's DR election, so that IGMP/MLD Report
messages are sent to the right router for the network to make upstream
Joins happen -- sending to the wrong LANs if you misinterpret PIM DR
selection produces the same unintended result as not paying any
attention and forwarding IGMP everywhere.

I don't think it should be necessary to tie RBridge behavior to any
particular multicast routing protocol.  In fact, I don't see an
interoperability issue here at all in simply saying that bridges
SHOULD NOT send IGMP/MLD Report messages to host-only networks, MUST
set the link-state bit appropriately, and leaving it as an
implementation matter to determine how (and if) that's done in any
given implementation.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 1 Network Drive         71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5PI94qG027915 for <[e-mail]>; Mon, 25 Jun 2007 11:09:05 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-6.tower-119.messagelabs.com!1182794942!13221461!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 20237 invoked from network); 25 Jun 2007 18:09:02 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 25 Jun 2007 18:09:02 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5PI92JJ007396 for <[e-mail]>; Mon, 25 Jun 2007 11:09:02 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l5PI91O6014802 for <[e-mail]>; Mon, 25 Jun 2007 13:09:02 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5PI91Ao014796 for <[e-mail]>; Mon, 25 Jun 2007 13:09:01 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 25 Jun 2007 14:08:52 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TRILL Header/Tag
thread-index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiAAjFbNEA==
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5PI94qG027915
Subject: [rbridge] TRILL Header/Tag
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Jun 2007 18:09:25 -0000
Status: RO
Content-Length: 15565

Hi,

The current TRILL data frame on an 802.3 link looks like this (the Outer
VLAN Tag is not always present):

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  Outer Destination MAC Address                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Outer Destination MAC Address | Outer Source MAC Address      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Outer Source MAC Address                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Start "TRILL Header":
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = TRILL             |  V  |M|R|Op-Length| Hop Count | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Egress (RB2) Nickname      |    Ingress (RB1) Nickname     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:End "TRILL Header"
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |               Inner Destination MAC Address                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Inner Destination MAC Address |  Inner Source MAC Address     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Inner Source MAC Address                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = IEEE 802.1Q       |  Inner.VLAN Tag Information   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Payload Ethertype       |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Payload                 | 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      FCS (Frame CheckSum)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Where the V field is two zero bits, for Version 0, followed by another
zero bit for a TRILL data frame (or a 1 bit for a TRILL IS-IS frame).
That is, V=0 (or V=1). See draft-ietf-trill-rbridge-protocol-04.txt.

(Side note: there should be a separate discussion about Q-tags
versus/and/or S-tags but I think that is pretty orthogonal to what I
want to talk about here.)

There is no question that this format "works". But I don't see that as
the point. After all, 803.3 Ethernet would "work" if you moved the
Destination Address to the end of the frame. But it wouldn't be good
engineering, because cut through switching or similar optimizations
would be impossible.

What I am primarily worried about is the fast path at transit Rbridges.
There doesn't seem to be any way to avoid a fair amount of work at the
ingress Rbridge. And it could be that there would be some
implementations that wouldn't mind having to grovel deep into a frame at
every transit Rbridge. But I think most implementations will want
transit Rbridge processing of TRILL data frames to be as simple as
possible. And I should think that anyone who is worrying about Rbridging
10Gbps Ethernet or even fast optical channels should be having problems
looking at the current TRILL protocol specification.

First, lets look at unicast. Seems really nice and efficient, even with
the present design. You just decrement the hop count and, if it is
non-zero, use the egress Rbridge nickname to look up the next hop
destination MAC address, output port, and Outer VLAN ID if any, and off
you go. Well, I think it is just a little more complex than that. In
particular, what do you do about the Outer VLAN Tag priority field? An
Outer VLAN Tag added by the previous Rbridge could have been stripped or
changed by bridges. You could imagine wanting to configure various
strategies but I think the right zero configuration default is to simply
get the priority from the Inner VLAN Tag. (Of course, if that turns out
to be the default priority and no Outer VLAN is needed for connectivity
to the next hop Rbridge, no Outer VLAN Tag may be needed at all.) And
then there are options. They start right after ingress nickname and,
even if you can get around the priority problem, if there are options
present, you probably have to look at the first bit or two of the
options area to determine that none of them apply to you...

So unicast isn't too bad, but even there I think you have to check a
couple of bits beyond the header if options are present and the best
default strategy requires you to delve into the inner frame to check the
data priority.

It's multi-destination frames that are the real problem with the current
design for a high speed transit Rbridge that wants to prune the
distribution tree. And, based on comments on this working group mailing
list, many developers will want to prune.

So, say we receive a multi-destination data frame. You know the
distribution tree from the "egress" nickname field. But if you want to
do any pruning, you have to look beyond the TRILL Header. Getting the
information for pruning by VLAN, you need to look at the Inner VLAN ID
which may require skipping over options.

Then we get to multicast pruning. To do that, you might first look at
the Destination MAC Address. That comes even before the Inner VLAN Tag
that you had to look at for VLAN pruning, so this doesn't sound too
hard. But it also turns out that it is not adequate. RFC 4541 on IGMP
snooping and the like is now out and it points out that there are ranges
of special IPv4 and IPv6 multicast addresses for which hosts don't, or
at least can not be depended on to, issue IGMPs (or MLDs or IPv6).
Therefore, frames sent to those IP multicast addresses have to be
treated as broadcast and distribution can't be pruned. But, these IP
multicast addresses are translated ambiguously to MAC multicast
addresses just like other IP multicast addresses. So, if we look at the
Destination MAC address and find it is an IP derived multicast, we are
not done.

For IPv4 derived multicast MAC addresses, there is a range of such
multicast addresses for which you have to dig even deeper into the frame
and look at the actual IPv4 address to see if you can prune or have to
broadcast. True, for IPv4 it is only a small fraction of the possible IP
derived multicast addresses, and an alternative might be to always
broadcast frames to those IPv4 derived MAC multicast addresses; but if
some group just happens to be sending their streaming video over a
multicast group that just happens to map into this area, it may not work
out so well for your network that those frames are getting broadcast
everywhere in that VLAN.

The situation it much worse for IPv6. In the case of IPv6 derived MAC
multicast addresses, 100% are potentially for special IPv6 multicast
addresses that you must broadcast. As a result, if you are going to
prune IPv6 derived multicast, you *always* have to go look at the actual
IPv6 destination address deeper in the frame to decide whether or not to
prune.

Finally, we come to the worst case, detecting IGMP, MLD, etc. messages.
Here you have to go beyond the IPv4 or IPv6 destination address, delve
deeper into the IP header and, in some cases, into the IP packet content
just to figure out whether you need to prune the distribution tree to
branches with IP multicast routers on them for IGMP and MLD (and RFC
4541 specifically recommends, due to confusions that can happen between
IGMPv3 and earlier version of IGMP, not sending such message to links
unless they have an IP multicast router on the).

I really don't think you want to have to look into the content of IP
packets to make forwarding decisions at transit Rbridges.

So, what I suggest is something more like the following:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  Outer Destination MAC Address                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Outer Destination MAC Address | Outer Source MAC Address      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Outer Source MAC Address  (last four bytes)          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Start "TRILL Tag":
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |         TRILL Ethertype       |   V   |M|Op-Length| Hop Count |
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |   Egress RBridge Nickname     |  Inner VLAN Tag information   |
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |        Inner Destination MAC Address (first four bytes)       |
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |   Inner Dest MAC Adr          |  Ingress RBridge Nickname     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Inner Source MAC Address (first four bytes)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Rest of Inner Src MAC Adr   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
End "TRILL Tag":                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |       Payload Ethertype       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Payload ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Final Checksum:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Frame Check Sum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
   V = 0 for TRILL IS-IS frames
   V = 1 for TRILL data pruned only on VLAN
   V = 2 for TRILL data pruned on VLAN and IP multicast MAC address
   V = 3 for TRILL data pruned on VLAN and IP multicast routers location

This puts everything that is needed for a transit Rbridge to forward
frames in the first 128 bits of what I have labeled the TRILL Tag (see
"=" in left margin). Why did I label it "Tag" rather than "Header"?
Well, the header paradigm seems to connote that we are adding a header
in front of an almost complete Ethernet frame. Tag seems like a better
word if we are constructing a block that goes in front of a frame
contents, not a frame. In some ways, it just depends on how you look at
it. 

For multicast optimization, the investigation into the frame as to
whether the distribution tree should be (1) only VLAN pruned, (2) pruned
on VLAN and based on multicast destination address, or (3) pruned on
VLAN and branches that have multicast routers, needs to be made only
once, at the ingress Rbridge, and is then encoded into V.

The current header is 64-bits and 64-bit aligned (starting after the
Outer VLAN tag) which is nice, but you always have to look beyond it for
every frame. Sometimes way beyond it, including skipping over any TRILL
options and IP options, to look into the content of IP packets.

The suggested TRILL tag is 176 bits long but, unless you are an egress
Rbridge, you only have to look at the first 128 bits which is 128-bit
aligned (ignoring the outer VLAN tag like I did for the current header).
But since fields are mostly just being moved around, at worst you gain
or lose two bytes total length over previous proposals. Options would
start after the destination MAC address so, even if options are present,
you can check the first few bits of the options area without going
outside this 128-bit area.

This proposal does suppress the Ethertype for the inner VLAN Tag
information but there is some precedent for that sort of thing. For
example, 802.16 has a header suppression feature where you can set some
flag bits and then leave out Q-tag and/or IPv4 or IPv6 Ethertypes.

So, while various minor changes could be made, the above is my
suggestion for significantly improving the simplicity and cut through
switching latency of handling TRILL data frames at transit Rbridges.

Since there was a consensus determination in favor of the current TRILL
Header, there needs to be a consensus to re-open the question. If there
isn't, my fall back position would be to suggest expanding the values of
V in the TRILL Header to encode the correct pruning strategy for a
frame, as listed with the TRILL Tag proposal above. This would not
eliminate the need to delve into the inner frame whenever a TRILL frame
is handled by a transit Rbridge, but would reduce to depth and
complexity of such delving...

Thanks,
Donald
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 22, 2007 6:44 PM
To: Silvano Gai; Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS


I don't see much of an advantage to changing things because 
it doesn't change the fact that rBridges rely on the 
"inner frame" to get correct pruning behavior for multicasts.

However, I agree with Silvano.  _If_ something is going 
to change, let's try and settle it as soon as we possibly can.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, June 21, 2007 7:09 AM
> To: Radia Perlman; Anoop Ghanwani
> Cc: Caitlin Bestler; Eric Gray (LO/EUS); [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Radia,
> 
> This information was known at the time of the consensus.
> I still remain in favor of the header we selected.
> If somebody wants to change his/her mind they can email this 
> list (SOON).
> 
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 12:57 PM
> > To: Anoop Ghanwani
> > Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
> [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > As Anoop said, core RBridges need to look inside the 
> tunneled packet 
> > at the inner packet in order to do multicast pruning as 
> well as VLAN 
> > pruning on multicast packets.
> > 
> > Which is why Don was proposing moving both the VLAN tag and the 
> > destination multicast address to the TRILL header. (and 
> removing the 
> > VLAN tag and DA from the inner packet so that it wouldn't 
> mean adding 
> > an extra 6 bytes to an encapsulated frame).
> > 
> > Seemed like people didn't like doing that, but I want to 
> make sure if 
> > the WG really is deciding not to do that, that they really 
> understand 
> > what they are deciding against.
> > Often in the email threads so many different things are kind of 
> > discussed at the same time that it's obvious that people 
> (definitely 
> > including me) are getting confused.
> > 
> > Radia
> > 
> > 
> > 
> > 
> > Anoop Ghanwani wrote:
> > >
> > > They're snooping because they too care about pruning 
> their trees for 
> > > a given multicast group and that would be one of the ways 
> to achieve 
> > > it.
> > > Otherwise, all multicasts would have to be broadcast on 
> the spanning 
> > > tree interconnecting the bridged network that sits 
> between the two 
> > > rBridges.
> > >
> > >
> > > If we didn't care about multicast pruning, we wouldn't 
> need to worry 
> > > about any of this.



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 l5PGpNON005082 for <[e-mail]>; Mon, 25 Jun 2007 09:51:23 -0700 (PDT)
Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5PGpMDu011493 for <[e-mail]>; Mon, 25 Jun 2007 16:51:23 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l5PGpMSU022595 for <[e-mail]>; Mon, 25 Jun 2007 12:51:22 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5PGhqrh026508 for <[e-mail]>; Mon, 25 Jun 2007 12:43:52 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5PGhh96026503; Mon, 25 Jun 2007 12:43:43 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 25 Jun 2007 12:43:43 -0400
From: James Carlson <[e-mail]>
To: TRILL/RBridge Working Group <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] multicast router discovery: what's PIM got to do with it?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Jun 2007 16:51:46 -0000
Status: RO
Content-Length: 2961

I've read through the list archives, and I'd like some clarification
on the mechanism chosen for detecting multicast routers in the latest
(*-protocol-04) draft.

Section 4.5.1.2 has this text:

   If the frame is a PIM or MRD [RFC4286] message, RB1 learns that there
   is an IP multicast router (for the specified VLAN) on its link, and
   adds that information for the appropriate VLAN in its IS-IS link
   state.

and 4.7 has this:

   Until Multicast Router Discovery (MRD) [RFC4286] is universally
   deployed, RBridges discover IP multicast routers through their
   transmission of PIM messages. So an RBridge concludes there is an IP
   multicast router on its port if it either receives an MRD message or
   a PIM message on that port. A PIM message is recognized because the
   protocol type in the IP header is decimal 103.

This seems odd to me.  RFC 4541 (also referenced) doesn't talk at all
about listening to PIM as part of an IGMP snooping strategy, or any
need to tie IGMP L2 forwarding behavior to any particular multicast
routing protocol.

IGMPv0 (RFC 988) didn't have 'queries', but it also didn't have the
suppression logic that later versions have, and it seems to be dead,
so it shouldn't be an issue.

IGMPv1 (RFC 1112) requires multicast routers (regardless of what
higher-level routing protocol they're using -- PIM or otherwise) to
send periodic IGMP Host Membership Query messages.  You'll know that
they're present by seeing these messages.

Similarly, IGMPv2 (RFC 2236) and MLDv1 (RFC 2710) require routers to
send periodic IGMP Membership Query and MLD Multicast Listener Query
messages.

IGMPv3 (RFC 3376) and MLDv2 (RFC 3810) do the same.  It seems likely
that future versions will be similar.

IGMP and MLD version compatibility depends on having periodic queries
present on the link, so if there's any functioning multicast routing
at all, these messages will be available.  Perhaps more importantly,
listing to PIM "correctly" would mean paying attention not just to the
presence of PIM, but to PIM's DR election, so that IGMP/MLD Report
messages are sent to the right router for the network to make upstream
Joins happen -- sending to the wrong LANs if you misinterpret PIM DR
selection produces the same unintended result as not paying any
attention and forwarding IGMP everywhere.

I don't think it should be necessary to tie RBridge behavior to any
particular multicast routing protocol.  In fact, I don't see an
interoperability issue here at all in simply saying that bridges
SHOULD NOT send IGMP/MLD Report messages to host-only networks, MUST
set the link-state bit appropriately, and leaving it as an
implementation matter to determine how (and if) that's done in any
given implementation.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 1 Network Drive         71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5MNIoZW004998 for <[e-mail]>; Fri, 22 Jun 2007 16:18:50 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 22 Jun 2007 16:18:50 -0700
X-IronPort-AV: i="4.16,453,1175497200";  d="scan'208"; a="11187527:sNHT17774134"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 054BA238396; Fri, 22 Jun 2007 16:16:25 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jun 2007 16:18:50 -0700
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: Fri, 22 Jun 2007 16:18:20 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAAMvlTAAAl1RsAEtvCdgADeFvSA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 22 Jun 2007 23:18:50.0870 (UTC) FILETIME=[B16F6960:01C7B523]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5MNIoZW004998
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2007 23:19:02 -0000
Status: RO
Content-Length: 1099

 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Thursday, June 21, 2007 9:24 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Looking at the rest of the Rbridge campus in question, no "core
> Rbridge", that is Rbridges that only connect to other Rbridges, would
> have any per VLAN IS-IS instances. Per VLAN IS-IS instances are only
> needed in the "edge Rbridges", that is, ones with end 
> stations attached
> in that VLAN for which they are DRB. I would guess that most of them
> would have, at most, a handful of per VLAN IS-IS instances. Of course
> the "edge Rbridges" that connect to the bridged LAN are 
> actually see it
> as one big multi-access link with, under the assumptions above, end
> stations in 100 VLANs.
> 
> In any case, the per VLAN instances of IS-IS are optional 
> anyway, so you
> don't have to have them

That this feature will be optional is good to know.  
I don't see it being applicable for the problem I'm
trying to solve.

Thanks,
Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5MMi2vB026498 for <[e-mail]>; Fri, 22 Jun 2007 15:44:02 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 22 Jun 2007 15:44:02 -0700
X-IronPort-AV: i="4.16,453,1175497200";  d="scan'208"; a="11187127:sNHT17425716"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id AFFA1238396; Fri, 22 Jun 2007 15:41:36 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jun 2007 15:44:02 -0700
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: Fri, 22 Jun 2007 15:43:32 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8awAEQrMiA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 22 Jun 2007 22:44:02.0531 (UTC) FILETIME=[D4B02B30:01C7B51E]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5MMi2vB026498
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2007 22:44:26 -0000
Status: RO
Content-Length: 2487

I don't see much of an advantage to changing things because 
it doesn't change the fact that rBridges rely on the 
"inner frame" to get correct pruning behavior for multicasts.

However, I agree with Silvano.  _If_ something is going 
to change, let's try and settle it as soon as we possibly can.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, June 21, 2007 7:09 AM
> To: Radia Perlman; Anoop Ghanwani
> Cc: Caitlin Bestler; Eric Gray (LO/EUS); [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Radia,
> 
> This information was known at the time of the consensus.
> I still remain in favor of the header we selected.
> If somebody wants to change his/her mind they can email this 
> list (SOON).
> 
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 12:57 PM
> > To: Anoop Ghanwani
> > Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
> [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > As Anoop said, core RBridges need to look inside the 
> tunneled packet 
> > at the inner packet in order to do multicast pruning as 
> well as VLAN 
> > pruning on multicast packets.
> > 
> > Which is why Don was proposing moving both the VLAN tag and the 
> > destination multicast address to the TRILL header. (and 
> removing the 
> > VLAN tag and DA from the inner packet so that it wouldn't 
> mean adding 
> > an extra 6 bytes to an encapsulated frame).
> > 
> > Seemed like people didn't like doing that, but I want to 
> make sure if 
> > the WG really is deciding not to do that, that they really 
> understand 
> > what they are deciding against.
> > Often in the email threads so many different things are kind of 
> > discussed at the same time that it's obvious that people 
> (definitely 
> > including me) are getting confused.
> > 
> > Radia
> > 
> > 
> > 
> > 
> > Anoop Ghanwani wrote:
> > >
> > > They're snooping because they too care about pruning 
> their trees for 
> > > a given multicast group and that would be one of the ways 
> to achieve 
> > > it.
> > > Otherwise, all multicasts would have to be broadcast on 
> the spanning 
> > > tree interconnecting the bridged network that sits 
> between the two 
> > > rBridges.
> > >
> > >
> > > If we didn't care about multicast pruning, we wouldn't 
> need to worry 
> > > about any of this.
> > >
> > >
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5MLn5Gf012462 for <[e-mail]>; Fri, 22 Jun 2007 14:49:05 -0700 (PDT)
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: Fri, 22 Jun 2007 14:49:04 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAAMvlTAAAl1RsAEtvCdgACaPIuA=
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5MLn5Gf012462
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2007 21:49:26 -0000
Status: RO
Content-Length: 4043

Donald,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Thursday, June 21, 2007 9:24 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> These bridged systems with 4K VLANs... It is my impression that they
> don't usually have 4K different communities that need to be isolated
> from each other. Rather, they are multiplying VLANs to use various
> configured mechanisms to try to get around the problems of spanning
> tree.
> 

Not true in general, hosting companies have exactly this problem

Cheers

-- Silvano


> What you say below gives me an image of a bridged LAN directly
connected
> to an Rbridge campus. This is probably not the best arrangement. If
they
> are multiply connected, all the traffic will end up going through one
> Designated Rbridge unless you set the different Rbridges that connect
to
> the bridged LAN to different priorities for becoming DRB for different
> VLANs or the like.
> 
> Anyway, just because the "core" bridges in this hypothetical case are
> carrying traffic tagged for 4K VLANs does not imply much of anything
> about the attached Rbridge campus. As I say, there is a per VLAN
> instance of IS-IS running in an RBridge ONLY if that Rbridge is DRB
for
> one or more end stations in that VLAN and it is configured to accept
> that VLAN.
> 
> To be more specific, we need to make some numeric assumptions. Let's
> assume that, although this big bridged LAN has 4K VLANs in it, the
> attached Rbridge campus only uses 100 of them. Then, if there was only
> one Rbridge connecting to the bridged LAN, that one Rbridge would end
up
> with 100 per VLAN instances of IS-IS running in it. But this seems
kind
> of implausible. With such a large network, it seems like you would
want
> some load spreading. So lets say there were 4 Rbridges at the "edge"
of
> the campus connected to the bridged LAN and they divide up the VLANs
> through priority configuration. Then each might have 25 per VLAN IS-IS
> instances.
> 
> Looking at the rest of the Rbridge campus in question, no "core
> Rbridge", that is Rbridges that only connect to other Rbridges, would
> have any per VLAN IS-IS instances. Per VLAN IS-IS instances are only
> needed in the "edge Rbridges", that is, ones with end stations
attached
> in that VLAN for which they are DRB. I would guess that most of them
> would have, at most, a handful of per VLAN IS-IS instances. Of course
> the "edge Rbridges" that connect to the bridged LAN are actually see
it
> as one big multi-access link with, under the assumptions above, end
> stations in 100 VLANs.
> 
> In any case, the per VLAN instances of IS-IS are optional anyway, so
you
> don't have to have them
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Friday, June 15, 2007 4:47 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Friday, June 15, 2007 12:41 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >
> > You only have an instance of IS-IS for VLAN x in Rbridge y is
> > Rbridge y
> > is advertising that it has directly connected end stations in
> > VLAN x. Is
> > it plausible that an Rbridge would be reporting that it has directly
> > connected end stations in all of 4K VLANs?
> 
> I understand that.  But it's not completely
> out of the world to have 4K VLANs configured
> in a "core" switch.  If you had RBridge
> network attached to one of these, you'd have
> to be able to deal with the 4K instances.
> 
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5MJo3Ae009422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 22 Jun 2007 12:50:03 -0700 (PDT)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7A1433298A; Fri, 22 Jun 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1p8s-0008S7-C2; Fri, 22 Jun 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 22 Jun 2007 15:50:02 -0400
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-04.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2007 19:50:23 -0000
Status: RO
Content-Length: 3401

--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, et al.
	Filename	: draft-ietf-trill-rbridge-protocol-04.txt
	Pages		: 68
	Date		: 2007-6-22
	
RBridges allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and multipathing for 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 bridges as well as
   current IPv4 and IPv6 routers and endnodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design also supports VLANs, and allows forwarding tables to be
   based on RBridge destinations (rather than endnode destinations),
   which allows internal forwarding tables to be substantially smaller
   than in conventional bridge systems.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-protocol-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-04.txt

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

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart--


Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5M4O4UW015078 for <[e-mail]>; Thu, 21 Jun 2007 21:24:04 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-119.messagelabs.com!1182486243!17708155!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 23123 invoked from network); 22 Jun 2007 04:24:03 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 22 Jun 2007 04:24:03 -0000
Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5M4O0Bl016776 for <[e-mail]>; Thu, 21 Jun 2007 21:24:02 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5M4Nxhe013490 for <[e-mail]>; Thu, 21 Jun 2007 23:23:59 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5M4Nwt0013476 for <[e-mail]>; Thu, 21 Jun 2007 23:23:58 -0500 (CDT)
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: Fri, 22 Jun 2007 00:23:56 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAAMvlTAAAl1RsAEtvCdg
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5M4O4UW015078
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2007 04:24:37 -0000
Status: RO
Content-Length: 3361

Hi Anoop,

These bridged systems with 4K VLANs... It is my impression that they
don't usually have 4K different communities that need to be isolated
from each other. Rather, they are multiplying VLANs to use various
configured mechanisms to try to get around the problems of spanning
tree.

What you say below gives me an image of a bridged LAN directly connected
to an Rbridge campus. This is probably not the best arrangement. If they
are multiply connected, all the traffic will end up going through one
Designated Rbridge unless you set the different Rbridges that connect to
the bridged LAN to different priorities for becoming DRB for different
VLANs or the like.

Anyway, just because the "core" bridges in this hypothetical case are
carrying traffic tagged for 4K VLANs does not imply much of anything
about the attached Rbridge campus. As I say, there is a per VLAN
instance of IS-IS running in an RBridge ONLY if that Rbridge is DRB for
one or more end stations in that VLAN and it is configured to accept
that VLAN.

To be more specific, we need to make some numeric assumptions. Let's
assume that, although this big bridged LAN has 4K VLANs in it, the
attached Rbridge campus only uses 100 of them. Then, if there was only
one Rbridge connecting to the bridged LAN, that one Rbridge would end up
with 100 per VLAN instances of IS-IS running in it. But this seems kind
of implausible. With such a large network, it seems like you would want
some load spreading. So lets say there were 4 Rbridges at the "edge" of
the campus connected to the bridged LAN and they divide up the VLANs
through priority configuration. Then each might have 25 per VLAN IS-IS
instances.

Looking at the rest of the Rbridge campus in question, no "core
Rbridge", that is Rbridges that only connect to other Rbridges, would
have any per VLAN IS-IS instances. Per VLAN IS-IS instances are only
needed in the "edge Rbridges", that is, ones with end stations attached
in that VLAN for which they are DRB. I would guess that most of them
would have, at most, a handful of per VLAN IS-IS instances. Of course
the "edge Rbridges" that connect to the bridged LAN are actually see it
as one big multi-access link with, under the assumptions above, end
stations in 100 VLANs.

In any case, the per VLAN instances of IS-IS are optional anyway, so you
don't have to have them

Thanks,
Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Friday, June 15, 2007 4:47 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]; Radia Perlman
Subject: RE: [rbridge] per-VLAN instances of IS-IS


> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Friday, June 15, 2007 12:41 PM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> You only have an instance of IS-IS for VLAN x in Rbridge y is 
> Rbridge y
> is advertising that it has directly connected end stations in 
> VLAN x. Is
> it plausible that an Rbridge would be reporting that it has directly
> connected end stations in all of 4K VLANs?

I understand that.  But it's not completely
out of the world to have 4K VLANs configured
in a "core" switch.  If you had RBridge 
network attached to one of these, you'd have
to be able to deal with the 4K instances.

Anoop



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5M0qXnH026504 for <[e-mail]>; Thu, 21 Jun 2007 17:52:33 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 21 Jun 2007 17:52:29 -0700
X-IronPort-AV: i="4.16,449,1175497200";  d="scan'208"; a="14013128:sNHT27717431"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 5CC64238372; Thu, 21 Jun 2007 17:50:05 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jun 2007 17:52:29 -0700
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: Thu, 21 Jun 2007 17:51:15 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSswAAJcTuAADT48EAAuCVEg
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 22 Jun 2007 00:52:29.0669 (UTC) FILETIME=[9C165950:01C7B467]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5M0qXnH026504
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2007 00:52:53 -0000
Status: RO
Content-Length: 18717

 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 8:53 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> See below at @@@ 
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 5:55 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> This thread was started because of the assertion
> that the current rbridge proposal is "opaque" and
> is completely compatible with bridges.
> 
> @@@ Of course, that depends on what "completely compatible" means. The
> protocol specification just says "compatible", not "completely
> compatible" :-)
> 
> I pointed out that it breaks snooping once the
> frames are trill encap'ed and this snooping is
> required if you have 2 rbridges interconnected
> by a regular LAN that doesn't have any end nodes
> that are interested in seeing that multicast.
> 
> @@@ You may have found a problem, but I really don't think it is the
> problem you believe it is, as I will try to explain below. 
> Furthermore,
> I can't see why the bridges in the bridged LAN need to snoop if there
> are no multicast listeners or IP multicast routers inside the bridged
> LAN.

If they could actually snoop, the flow of 
multicast data within that bridged LAN would
have been limited to only those parties
interested in the multicast.

> 
> To which Donald responded saying that the DRB
> for the bridged LAN would be sending a decap'ed
> version of the control packets to the LAN 
> anyway, and so snooping would continue to work.
> 
> @@@ Well, I was trying to say something more like the DRB 
> would send in
> any traffic that nodes inside the bridged LAN had indicated 
> any interest
> in.
> 
> I still don't think it works.  Consider
> the following network.
> 
> 
>   Multicast router
>    |
>    Rb1 (DRB for the LAN)
>    |
>  bridged LAN with 10 bridges and hosts
>  in some random configuration
>    |
>    Rb2
>    |
>    B
> 
> In the above example, B is the only
> participant in a multicast.  No one
> on the intermediate LAN is interested
> in receiving the multicast.
> 
> When B sends a join, it gets trill encap'ed
> by Rb2 and forwarded to Rb1.  The bridges
> in the LAN can't snoop that because they
> don't understand the trill etype.
> 
> @@@ Right, stuff with a TRILL Header is opaque to boxes which don't
> understand how to parse it. So boxes that are not Rbridges, including
> the bridges on this bridged LAN, will be in the dark.
> 
> When multicast data are forwarded from Rb1
> to Rb2 it is encap'ed as trill and sent
> to the all-rbridges address.  The bridges
> on the LAN (all 10 of them) will see this
> frame and copy it to all stations on that
> LAN.
> 
> @@@ That is correct with the current protocol spec. But I would point
> out that at the expense of slightly more complex conditionals, the
> protocol could notice that there is only one IS-IS adjacency on that
> link out of RB1 and unicast the TRILL data frames even if the
> encapsulated frame had a multicast destination. (Of course, it would
> want to keep multicasting the TRILL IS-IS frames in case 
> another Rbridge
> shows up.) There is nothing peculiar about a unicast TRILL data frame.
> If there is unicast data being forwarded from RB1 to RB2, it would be
> unicast. But I am digressing.

What happens if you have 10 rbridges attached
to that bridged LAN and only 2 of them were
interested in the multicast.  The other 8
would see it too.

> 
> That the bridges on the LAN see a 
> decap'ed version of the Join doesn't
> mean anything, because the multicast
> traffic between the routers goes has the
> all-rbridges address as the MAC DA.
> In this way, we have broken "compatibility"
> with bridges.
> 
> @@@ Just above is where you lose me. The TRILL encapsulated data has
> nothing to do with the  problem... If any listener inside the 
> bridge LAN
> had spoken up, the native form of the multicast data would be getting
> forwarded into the bridged LAN also...

Yes, I was a bit confused there.  Please
ignore the stuff about the decap'ed frames
for now.  But we still have a problem...

> @@@ It seems to me there are four possibilities for what is in the
> bridged LAN between RB1 and RB2: (1) There are no IP multicast routers
> or multicast listeners; (2) There are one or more listeners but no IP
> multicast router; (3) there is an IP multicast router but no 
> listeners;
> and (4) there is both an IP multicast router and one or more 
> listeners.
> 
> @@@ In case 1, we are obviously fine. B joins the group, the IP
> multicast router at the top send multicast to B, everything 
> is fine and
> it doesn't matter that stuff is encapsulated because there is 
> no reason
> for any box in the bridged LAN to care.

Except that it does in fact get delivered
to all of the rbridges in the LAN.

> @@@ In case 2, we have a listener inside the bridged LAN. It will send
> an IGMP (I'll ignore IPv6 for this discussion for simplicity.) Either
> RB1 or RB2 will be the Designated Rbridge (DRB) for the bridged LAN
> (which looks to the Rbridges like a multi-access link). 
> Whichever is the
> DRB receives and processes the frame. It will then forward it 
> in native
> form on any local links that seem to have an IP multicast 
> router on them
> and for which it is DRB. So if RB1 is the DRB for the bridged LAN and
> the DRB for the link at the top with the IP multicast router (which it
> would obviously be if it was the only Rbridge on that link), it would
> forward it in native form to that IP multicast router. The 
> DRB receiving
> the original native IGMP will also encapsulate this IGMP and 
> forward it
> over a distribution tree to all other Rbridges that advertise they are
> DRB for some local link with an IP multicast router on that link. And
> those Rbridges will decapsulate it and deliver it to those IP 
> multicast
> routers on those link.
> @@@ For example, if RB2 is the DRB for the bridged LAN, it 
> would receive
> the native IGMP from the listener inside the bridged LAN, encapsulate
> it, and send it to RB1 which would decapsulate it and deliver 
> it to the
> IP multicast router at the top.
> @@@ In any case, we have a listener inside the bridged LAN; its IGMP
> gets to all IP multicast routers as described above. Furthermore, the
> Rbridge that is DRB for the bridged LAN also remembers and advertises
> that it saw this IGMP and there is a Listener inside the bridge LAN so
> it will get and decapsulate appropriate multicast data and send it in
> native form into the bridge LAN.
> @@@ In other words, everything works fine in this case.
> 
> @@@ OK, on to case 3. There is an IP multicast router inside 
> the bridged
> LAN but no Listeners. If this IP multicast router ever sends a PIM or
> MRD, it will be noticed by the DRB for the bridged LAN which will
> remember this and advertise in the link state that it has an IP
> multicast router attached. This advertisement will cause it to start
> receiving all IGMPs and multicast data, if it wasn't already receiving
> that traffic, and it will decapsulate that traffic and send 
> it into the
> bridged LAN.
> @@@ The possible problem is if the IP multicast router inside the
> bridged LAN is silent. Then the DRB doesn't know to hook things up and
> start decapsulating the relevant frames and sending them into the
> bridged LAN.
> 
> @@@ It doesn't seem worth going through case 4, which is kind of a
> combination of cases 2 and 3.
> 
> @@@ All right, now that I have gone through all that, consider the
> following:
> 
> @@@   Multicast router
> @@@   |
> @@@   Rb1 (DRB for the LAN)
> @@@   |
> @@@   RB3---X
> @@@   |
> @@@   Rb2
> @@@   |
> @@@   B
> 
> @@@ Now consider what if X is, possibly, a multicast listener for the
> group in question or an IP multicast router, or neither, or both.
> Exactly the same questions occur as to whether or not RB3, assuming it
> is the only Rbridge on the link to X and thus DRB, sends IGMPs and/or
> multicast data to X in native form after decapsulating it. 
> (Since, other
> than X, RB3 is shown as only connected to other Rbridges, it 
> would never
> get a native IGMP or multicast frame it could just forward to X in
> native form, as well as encapsulating and sending to other 
> Rbridges...)
> @@@ The situation for X is, as far as I can see, exactly the 
> same as it
> was for assorted end stations/bridges inside the bridged LAN in your
> diagram except that X can't get at stuff not sent to it even if it
> understands TRILL frames which boxes inside the bridged LAN could be
> haired up to understand TRILL frames, although that is not necessary.
> 
> @@@ For the above reasons, the only problem I see is the silent IP
> multicast router. Everything else works fine and in the same way
> regardless of whether or not one or more bridges and/or a 
> bridge LAN are
> involved.
> 
> With something like MMRP (a native 802.1
> protocol), things are even worse.  Rb1 
> would terminate any MMRPDUs (just as
> it would STP BPDUs).
> 
> @@@ Sure. I assume MMRP is some form of GMRP made more complex to work
> with MSTP. As I recall, GMRP is optional for 802.1 bridges. Is MMRP
> mandatory? Anyway, I'm sure with enough work you could add almost any
> additional bridge related protocols to Rbridges, but would it be worth
> the effort?

GMRP already worked with MSTP.  MMRP runs
on top of MRP which replaces GARP.

> We cannot says we are backwards compatible
> with bridges just because we restrict traffic 
> flow to a single symmetric tree within the trill 
> network.  We are breaking compatibility in
> other ways.  We need to be explicit about 
> what compatibility we are trying to preserve.
> 
> @@@ I don't think "we restrict traffic flow to a single symmetric tree
> within" and Rbridge network. But maybe we are interpreting something
> differently.
> 
> @@@ Sure, feel free to suggest text clarifying this.
> 
> @@@ One assertion is that you can incrementally replace unconfigured
> bridges with unconfigured Rbridges and the network will still operate
> "correctly", although some topologies may be inefficient.

Yes, that some topologies will be inefficient
is key.  In that respect we don't really have to
be 100% backwards compatible with bridges.
 
> @@@ Generally speaking, the most efficient topologies in incremental
> replacement is to maximally partition the remnant bridged 
> LAN, splitting
> it with Rbridges into pieces that are as small as possible.

And in the limit, making the "core" consist of
only rBridges.  That is what would be most efficient
from a forwarding standpoint.

Anoop

> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Wednesday, June 20, 2007 12:23 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Hi Anoop,
> > 
> > It seems to me that what you are saying is that the strategy 
> > in TRILL of only sending IGMP/MLD to links that appear to 
> > have IP multicast routers on them due to the detection of 
> > PIM/MRD messages doesn't work. That, at least occasionally, 
> > IGMP/MLD have to be flooded to every link just in case there 
> > might be an IP multicast router on it that has been silent.
> > 
> > If that's a problem, it has nothing to do with bridges or 
> > bridged LANs.
> > All it takes to demonstrate the problem is a silent IP 
> > multicast router point-to-point connected to an Rbridge 
> > somewhere. If that IP multicast router has never send an PIM 
> > or MRD message, then the Rbridge has no way of knowing to 
> > send it IGMPs or MLDs (or multicast data traffic)...
> > 
> > Donald 
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 3:14 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > 
> > And we now go full circle back to...
> > 
> > What if we a bridged LAN between 2 rbridges
> > and there were no stations on this bridged LAN
> > (other than the rbridges) that were interested
> > in receiving that multicast?  You wouldn't
> > see any of the control packet that you mention.
> > The only control packets of that type would be
> > the ones which were going between the rBridges and
> > those would be trill encap'ed.  So the regular
> > bridges between these rbridges wouldn't 
> > understand them (for snooping).
> > 
> > Anoop 
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008 
> > > [mailto:[e-mail]] 
> > > Sent: Wednesday, June 20, 2007 12:11 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Hi Anoop,
> > > 
> > > From two places. They should see native IGMP/MLD/PIM/MRD from 
> > > end stations that are directly attached to them. And, to the 
> > > extent that they let any surrounding Rbridges see any PIM/MRD 
> > > messages, the Designated Rbridge will send IGMP/MLDs in 
> > > native form into the bridged LAN. I should think this would 
> > > give the bridges enough information to figure out how to do 
> > > an optimized forwarding of IP derived multicast address traffic.
> > > 
> > > Donald 
> > > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Wednesday, June 20, 2007 2:53 PM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Donald,
> > > 
> > > So then the bridges in the LAN between the
> > > 2 rbridges need some information to do their
> > > pruning.   Where do they get it from?
> > > 
> > > Anoop 
> > > 
> > > > -----Original Message-----
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 7:16 PM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > Hi Anoop,
> > > > 
> > > > No, it shouldn't get delivered to every end station 
> unless it is 
> > > > broadcast or a layer 2 multicast not derived from an IP address.
> > > > 
> > > > If it is an layer 2 multicast address derived from an IP 
> > > address, then 
> > > > Rbridges should prune the distribution tree and the links they 
> > > > decapsulate and forward onto to those with listeners for an IP 
> > > > multicast address that corresponds to that layer 2 
> > > multicast address 
> > > > or with an IP multicast router.
> > > > 
> > > > Donald
> > > > 
> > > > PS: All the above is scoped by VLAN as well.
> > > > 
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 7:32 PM
> > > > To: Eastlake III Donald-LDE008
> > > > Cc: [e-mail]; Caitlin Bestler
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > Donald,
> > > > 
> > > > What if there are no IP multicast routers or listeners in 
> > > the bridged 
> > > > LAN between the rBridges?  Does that mean a copy of the 
> > trill frame 
> > > > gets delivered to every station in that LAN?
> > > > 
> > > > Anoop
> > > > 
> > > > > -----Original Message-----
> > > > > From: Eastlake III Donald-LDE008
> > > > > [mailto:[e-mail]]
> > > > > Sent: Tuesday, June 19, 2007 12:51 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [e-mail]; Caitlin Bestler
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > 
> > > > > In addition to what Caitlin says, I would point out that,
> > > > if there are
> > > > > multicast listeners or IP multicast routers in this bridged
> > > > LAN (which
> > > > > looks to the Rbridges pretty much like a single 
> > > multi-access link), 
> > > > > then the Rbridges should have heard about them and the 
> > Designated 
> > > > > Rbridge for the VLAN in question for that cloud will also 
> > > > > decapsulate
> > > > appropriate
> > > > > data/multicast-control and send it into the cloud as native
> > > > > (non-TRILL)
> > > > > frames whose distribution within the cloud the bridges are
> > > > welcome to
> > > > > try to optimize as much as they like.
> > > > > 
> > > > > Donald
> > > > > 
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of 
> Caitlin Bestler
> > > > > Sent: Tuesday, June 19, 2007 3:16 PM
> > > > > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > > 
> > > > > [e-mail] wrote:
> > > > > > Eric,
> > > > > > 
> > > > > > It depends on what we mean by compatibility.
> > > > > > One can always say that if one cares about such and such 
> > > > > > compatibility then here's a way to solve it.
> > > > > > 
> > > > > > Even if trill were to impose the constraint you 
> suggest, many 
> > > > > > things will break.  For example, if I have a 
> topology with a 
> > > > > > bridged cloud between 2 trill devices, then the 
> traffic going 
> > > > > > between the trill devices will not be "snoopable" by 
> > > the bridges 
> > > > > > because they won't understand trill encapsulation.
> > > > > > 
> > > > > 
> > > > > Why are these intermediate bridges snooping?
> > > > > 
> > > > > The only service being requested of them is to relay 
> > > Ethernet frames 
> > > > > from the ingress rbridge to the egress rbridge. Is that 
> > > not implied 
> > > > > by their being a cloud *between* 2 trill devices?
> > > > > 
> > > > > How is this different from any tunnel? You have 
> traffic that a 
> > > > > middlebox might have optimized had it been untunelled, 
> > > but that it 
> > > > > does not see when tunneled. It cannot provide its 
> > > service, but it is 
> > > > > not being asked to do so.
> > > > > 
> > > > > A non-rbridge bridge forwards packets without 
> > understanding that 
> > > > > they are rbridge encapsulated frames. I always thought 
> > > that this was 
> > > > > a strength of the proposal, not a weakness. You can't be 
> > > snoopable 
> > > > > and opaque. Opaque is better.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > rbridge mailing list
> > > > > [e-mail]
> > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > > 
> > > > 
> > > 
> > 
> 



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5M0VOCE021190 for <[e-mail]>; Thu, 21 Jun 2007 17:31:24 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 21 Jun 2007 17:31:23 -0700
X-IronPort-AV: i="4.16,449,1175497200";  d="scan'208"; a="11168438:sNHT19970734"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 8223E238372; Thu, 21 Jun 2007 17:28:59 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jun 2007 17:31:23 -0700
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: Thu, 21 Jun 2007 17:30:21 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSswAAJcTuAADT48EAAdXKKQABAnXSA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 22 Jun 2007 00:31:23.0742 (UTC) FILETIME=[A98937E0:01C7B464]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5M0VOCE021190
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2007 00:31:56 -0000
Status: RO
Content-Length: 5225

Caitlin,

All of your points are valid.  All I'm trying to
point out is that things as defined break how
bridges currently operate.  They still work, just
not as well as they do without RBridges.

What is likely, what is not likely, what can
be optimized, etc. are all valid points/concerns.
We just have to be clear that regardless of
what we do, we can't pretend that the effect
of using RBridges in a network will not have
an impact on operation of existing bridges.

Anoop 

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]] 
> Sent: Thursday, June 21, 2007 10:32 AM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> [e-mail] wrote:
> > Hi Anoop,
> > 
> > See below at @@@
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 5:55 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > This thread was started because of the assertion that the current 
> > rbridge proposal is "opaque" and is completely compatible with 
> > bridges.
> > 
> > @@@ Of course, that depends on what "completely compatible"
> > means. The protocol specification just says "compatible", not 
> > "completely compatible" :-)
> > 
> > I pointed out that it breaks snooping once the frames are trill 
> > encap'ed and this snooping is required if you have 2 rbridges 
> > interconnected by a regular LAN that doesn't have any end 
> nodes that 
> > are interested in seeing that multicast.
> > 
> > @@@ You may have found a problem, but I really don't think 
> it is the 
> > problem you believe it is, as I will try to explain below. 
> > Furthermore, I can't see why the bridges in the bridged LAN need to 
> > snoop if there are no multicast listeners or IP multicast routers 
> > inside the bridged LAN.
> > 
> > To which Donald responded saying that the DRB for the bridged LAN 
> > would be sending a decap'ed version of the control packets 
> to the LAN 
> > anyway, and so snooping would continue to work.
> > 
> > @@@ Well, I was trying to say something more like the DRB 
> would send 
> > in any traffic that nodes inside the bridged LAN had indicated any 
> > interest in.
> > 
> > I still don't think it works.  Consider the following network.
> > 
> > 
> >   Multicast router
> >    |
> >    Rb1 (DRB for the LAN)
> >    |
> >  bridged LAN with 10 bridges and hosts  in some random configuration
> >    |
> >    Rb2
> >    |
> >    B
> > 
> > In the above example, B is the only
> > participant in a multicast.  No one
> > on the intermediate LAN is interested
> > in receiving the multicast.
> > 
> > When B sends a join, it gets trill encap'ed by Rb2 and forwarded to 
> > Rb1.  The bridges in the LAN can't snoop that because they don't 
> > understand the trill etype.
> > 
> > @@@ Right, stuff with a TRILL Header is opaque to boxes which don't 
> > understand how to parse it. So boxes that are not Rbridges, 
> including 
> > the bridges on this bridged LAN, will be in the dark.
> > 
> > When multicast data are forwarded from Rb1 to Rb2 it is encap'ed as 
> > trill and sent to the all-rbridges address.  The bridges on the LAN 
> > (all 10 of them) will see this frame and copy it to all stations on 
> > that LAN.
> > 
> > @@@ That is correct with the current protocol spec. But I 
> would point 
> > out that at the expense of slightly more complex conditionals, the 
> > protocol could notice that there is only one IS-IS 
> adjacency on that 
> > link out of RB1 and unicast the TRILL data frames even if the 
> > encapsulated frame had a multicast destination. (Of course, 
> it would 
> > want to keep multicasting the TRILL IS-IS frames in case another 
> > Rbridge shows up.) There is nothing peculiar about a unicast TRILL 
> > data frame.
> > If there is unicast data being forwarded from RB1 to RB2, 
> it would be 
> > unicast. But I am digressing.
> > 
> 
> I would actually consider that a local implementation optimization.
> If there is any language that might seem to forbid this it 
> would be nice to rephrase it.
> 
> So the "missed optimization" here is when:
> 
> a) there is a single cloud that connects multiple RBridges.
> b) More than one of these RBridges should receive an encapsulated
>    multicast frame, but the remaining RBridges have no use for it.
> c) Because it will be multicast to "all rbridges" some rbridges
>    will receive the frame, and then determine that they have no
>    local target, and the won't deliver it.
> d) because of encapsulation, a non-RBRidge bridge that did
>    transparent IGMP snooping would not be able to optimize
>    the forwarding of this message through the cloud.
> 
> Aren't *all* of the following scenarios far more common?
> 
> - There is snooping Bridge in the cloud.
> - The traffic is relevant to *all* RBridges attached to the cloud,
>   especially when "all" is really "both".
> - The traffic is relevant only to a single RBridge.
> 
> Further, aren't RBridges capable of providing this 
> optimization themselves rather than relying on the snooping bridges?
> 



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5LIxtjj023298 for <[e-mail]>; Thu, 21 Jun 2007 11:59:55 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-153.messagelabs.com!1182452392!2102089!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 28089 invoked from network); 21 Jun 2007 18:59:52 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 21 Jun 2007 18:59:52 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5LIxlRJ014859 for <[e-mail]>; Thu, 21 Jun 2007 11:59:51 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5LIxl77014106 for <[e-mail]>; Thu, 21 Jun 2007 13:59:47 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5LIxkEI014098 for <[e-mail]>; Thu, 21 Jun 2007 13:59:46 -0500 (CDT)
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: Thu, 21 Jun 2007 14:59:42 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSswAAJcTuAADT48EAAdXKKQAAJu3uA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LIxtjj023298
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 19:00:17 -0000
Status: RO
Content-Length: 4509

Hi Caitlin,

See below at @@@

-----Original Message-----
From: Caitlin Bestler [mailto:[e-mail]] 
Sent: Thursday, June 21, 2007 1:32 PM
To: Eastlake III Donald-LDE008; Anoop Ghanwani
Cc: [e-mail]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

...

I would actually consider that a local implementation optimization.
If there is any language that might seem to forbid this it would
be nice to rephrase it.

@@@ I agree that it is a relatively minor optimization and should be a
MAY, but it is not quite local. It means that an Rbridge about to
forward a multi-destination frame out a particular port to send it down
a branch of the pruned distribution tree notices that there is only one
intended next hop receiver. It then sticks the MAC address of that
Rbridge into the Outer DA rather than the All Rbridges multicast
address. I think the specification should be modified to say this
behavior is a MAY.

@@@ But, a change is also needed at the receiver. A unicast TRILL
Ethertype frame with the multi-destination bit on in the TRILL Header
never occurs currently and so might well be discarded as an erroneous
frame. Alternatively, an Rbridge might conclude, since the only unicast
TRILL data frames currently are known unicast, that the frame must be a
known unicast data frame, ignore the multi-destination bit, and treat
the egress Rbridge nickname as the destination rather than the tree
root! So I believe you would also have to say that all Rbridges MUST
accept such frame and process them the same they would if it had been
addressed to the All Rbridge multicast address.

@@@ Note that if an Rbridge is sending some multi-destination frame out
several ports, it might be able to do this optimization on some ports
and not others. So you would have one multicast version of the frame and
possible several slightly different (just Outer DA and FCS) unicast
versions of the frame going out, which might be inconvenient for some
Rbridge architectures. So it shouldn't be mandatory to do this
optimization.

So the "missed optimization" here is when:

a) there is a single cloud that connects multiple RBridges.
b) More than one of these RBridges should receive an encapsulated
   multicast frame, but the remaining RBridges have no use for it.

@@@ If the path between these Rbridges is a bridged LAN, then all the
bridges and any end stations will also get it, in general, because the
bridges will flood it on their spanning tree.

c) Because it will be multicast to "all rbridges" some rbridges
   will receive the frame, and then determine that they have no
   local target, and the won't deliver it.
d) because of encapsulation, a non-RBRidge bridge that did
   transparent IGMP snooping would not be able to optimize
   the forwarding of this message through the cloud.

Aren't *all* of the following scenarios far more common?

- There is snooping Bridge in the cloud.

@@@ Well, actually, since the All Rbridges multicast address is not an
IP derived multicast, it is not clear that IGMP snooping bridges can
optimize such frames.

- The traffic is relevant to *all* RBridges attached to the cloud,
  especially when "all" is really "both".
- The traffic is relevant only to a single RBridge.

@@@ Sure, whether this optimization helps is highly dependent on network
topology. But it is quite possible, if you have several Rbridges on a
multi-access link, that broadcast traffic being sent by one on a
distribution tree, after that tree is pruned for VLAN, would only be
destined for one of the Rbridges attached to that link. This seems even
more likely if the traffic is multicast and the tree is pruned by not
just VLAN but also for multicast listeners and IP multicast routers. On
the other hand, if you have a network with just Rbridges and endstations
connected entirely by point-to-point links, notice that there is always
exactly one receiver out any particular port and it generally makes no
difference whether you use a unicast or the All Rbridge multicast
address for TRILL frames between Rbridges in such a network.

Further, aren't RBridges capable of providing this optimization
themselves rather than relying on the snooping bridges?

@@@ Yes, the optimization I have been talking about, at least, which is,
when appropriate, sending an encapsulated multi-destination TRILL frame
out a particular port unicast rather than multicast, would be
implemented just in Rbridges and doesn't have any particular
relationship to bridges.

@@@ Thanks,
@@@ Donald



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LHVuV2029379 for <[e-mail]>; Thu, 21 Jun 2007 10:31:57 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 21 Jun 2007 10:31:35 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C9F262AF; Thu, 21 Jun 2007 10:31:35 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B4F712AE; Thu, 21 Jun 2007 10:31:35 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FKD49469; Thu, 21 Jun 2007 10:31:35 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id E8C7469CA5; Thu, 21 Jun 2007 10:31:34 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 21 Jun 2007 10:31:33 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSswAAJcTuAADT48EAAdXKKQ
From: "Caitlin Bestler" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-WSS-ID: 6A646A7D37046996030-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LHVuV2029379
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 17:32:11 -0000
Status: RO
Content-Length: 4223

[e-mail] wrote:
> Hi Anoop,
> 
> See below at @@@
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 5:55 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> This thread was started because of the assertion that the
> current rbridge proposal is "opaque" and is completely
> compatible with bridges.
> 
> @@@ Of course, that depends on what "completely compatible"
> means. The protocol specification just says "compatible", not
> "completely compatible" :-) 
> 
> I pointed out that it breaks snooping once the frames are
> trill encap'ed and this snooping is required if you have 2
> rbridges interconnected by a regular LAN that doesn't have
> any end nodes that are interested in seeing that multicast.
> 
> @@@ You may have found a problem, but I really don't think it
> is the problem you believe it is, as I will try to explain
> below. Furthermore, I can't see why the bridges in the
> bridged LAN need to snoop if there are no multicast listeners
> or IP multicast routers inside the bridged LAN.
> 
> To which Donald responded saying that the DRB for the bridged
> LAN would be sending a decap'ed version of the control
> packets to the LAN anyway, and so snooping would continue to work.
> 
> @@@ Well, I was trying to say something more like the DRB
> would send in any traffic that nodes inside the bridged LAN
> had indicated any interest in.
> 
> I still don't think it works.  Consider
> the following network.
> 
> 
>   Multicast router
>    |
>    Rb1 (DRB for the LAN)
>    |
>  bridged LAN with 10 bridges and hosts
>  in some random configuration
>    |
>    Rb2
>    |
>    B
> 
> In the above example, B is the only
> participant in a multicast.  No one
> on the intermediate LAN is interested
> in receiving the multicast.
> 
> When B sends a join, it gets trill encap'ed by Rb2 and
> forwarded to Rb1.  The bridges in the LAN can't snoop that
> because they don't understand the trill etype.
> 
> @@@ Right, stuff with a TRILL Header is opaque to boxes which
> don't understand how to parse it. So boxes that are not
> Rbridges, including the bridges on this bridged LAN, will be
> in the dark.
> 
> When multicast data are forwarded from Rb1 to Rb2 it is
> encap'ed as trill and sent to the all-rbridges address.  The
> bridges on the LAN (all 10 of them) will see this frame and
> copy it to all stations on that LAN.
> 
> @@@ That is correct with the current protocol spec. But I
> would point out that at the expense of slightly more complex
> conditionals, the protocol could notice that there is only
> one IS-IS adjacency on that link out of RB1 and unicast the
> TRILL data frames even if the encapsulated frame had a
> multicast destination. (Of course, it would want to keep
> multicasting the TRILL IS-IS frames in case another Rbridge
> shows up.) There is nothing peculiar about a unicast TRILL data frame.
> If there is unicast data being forwarded from RB1 to RB2, it
> would be unicast. But I am digressing.
> 

I would actually consider that a local implementation optimization.
If there is any language that might seem to forbid this it would
be nice to rephrase it.

So the "missed optimization" here is when:

a) there is a single cloud that connects multiple RBridges.
b) More than one of these RBridges should receive an encapsulated
   multicast frame, but the remaining RBridges have no use for it.
c) Because it will be multicast to "all rbridges" some rbridges
   will receive the frame, and then determine that they have no
   local target, and the won't deliver it.
d) because of encapsulation, a non-RBRidge bridge that did
   transparent IGMP snooping would not be able to optimize
   the forwarding of this message through the cloud.

Aren't *all* of the following scenarios far more common?

- There is snooping Bridge in the cloud.
- The traffic is relevant to *all* RBridges attached to the cloud,
  especially when "all" is really "both".
- The traffic is relevant only to a single RBridge.

Further, aren't RBridges capable of providing this optimization
themselves rather than relying on the snooping bridges?




Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LGXV8E012114 for <[e-mail]>; Thu, 21 Jun 2007 09:33:31 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 21 Jun 2007 09:33:30 -0700
X-IronPort-AV: i="4.16,448,1175497200";  d="scan'208"; a="13986949:sNHT22450407"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id E5E7223837F; Thu, 21 Jun 2007 09:31:06 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jun 2007 09:33:30 -0700
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: Thu, 21 Jun 2007 09:33:05 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIAAI8kMwAAHz+XAAJwbhIAAFFp4Q
From: "Anoop Ghanwani" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 21 Jun 2007 16:33:30.0932 (UTC) FILETIME=[E7359F40:01C7B421]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LGXV8E012114
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 16:34:08 -0000
Status: RO
Content-Length: 13586

I was just responding to Eric's comment about
lack of consensus for ECMP.  It looks like we
have that.

I didn't mention anything about flows, so
that's not a concern for me.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Thursday, June 21, 2007 7:08 AM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> 
> Anoop,
> 
> I agree with Donald,
> 
> I think the draft is fine, it does not prevent ECMP.
> No protocol that I know specify how "to determine flows".
> 
> I don't see any action needed.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Wednesday, June 20, 2007 12:37 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > What exactly do you think we need to do and to get consensus on?
> > 
> > I think it is clear enough from the draft that an ingress 
> Rbridge can 
> > multipath multidestination traffic by selecting different tree roots
> for
> > different frames. So the only question is unicast. Other than a few 
> > words saying that don't have to always send unicast traffic 
> on the one 
> > path selected by the tie breaker rule, but MAY multipath, 
> what more is 
> > needed?
> > 
> > Presumably the tricky thing is how best to determine flows, where
> frames
> > in a flow would follow only one of the multiple paths, 
> except during 
> > transients. I don't think the TRILL WG should get into defining
> flows...
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Wednesday, June 20, 2007 2:43 PM
> > To: Eric Gray (LO/EUS); Silvano Gai
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > Personally, I would like the group to get to a consensus on 
> the ECMP 
> > issue fairly quickly.
> > 
> > I too, just like Silvano, thought it was going to be done.
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Wednesday, June 20, 2007 7:29 AM
> > > To: Silvano Gai; Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > >
> > > Silvano,
> > >
> > > 	Yes, that was probably discussed earlier in May.
> > >
> > > 	AFAIK, discussion != consensus.
> > >
> > > 	Possibly your customers need to explain to you that the 
> difference 
> > > between "core" and "not core" is not always as clear cut as you 
> > > apparently think it is.  Nor is it necessarily going to be simple 
> > > for a device to determine which of the available equal cost paths 
> > > only contain core elements.
> > >
> > > 	Also, ECMP - at least in the traditional sense - takes 
> place where 
> > > equal costs exist in a "routing" domain.  That is at 
> least as likely 
> > > to occur in locii containing one or more edge components, 
> as it is 
> > > anywhere else.
> > >
> > > 	There are certainly limited applications - typically requiring 
> > > careful configuration to restrict ECMP-like activity to very 
> > > specifically defined equal cost paths - where it will be 
> possible to 
> > > say "we do ECMP only in the core."  I personally wonder why 
> > > link-bundling wouldn't be a better solution in those 
> cases, however.
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 11:39 PM
> > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > >
> > > > We had this discussion on May 8th, 2007 on this mailing list.
> > > >
> > > > In a nutshell: we do ECMP only in the core, but we don't
> > > learn in the
> > > > core, so I don't see the problem.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Tuesday, June 19, 2007 7:14 AM
> > > > > To: Silvano Gai; Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > Silvano,
> > > > >
> > > > > 	Your response is confusing.  If we are not expected to
> > preserve
> > > > > forwarding symmetry, have we given up on presumed
> > > compatibility with
> > > > > standard bridges?
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > Importance: High
> > > > > >
> > > > > >
> > > > > > Eric,
> > > > > >
> > > > > > You say: "we're expected to preserve forwarding symmetry".
> > > > > >
> > > > > > WE ARE NOT.
> > > > > >
> > > > > > Where does the current draft preserve forwarding symmetry?
> > > > > >
> > > > > > In regard to your conclusions, many of us (Anoop , Dinesh
> > > > and I for
> > > > > > sure) are participating because we are building 
> real products.
> > > > > >
> > > > > > I don't buy your argument that "Very uninteresting
> > > > > > (technology) is very
> > > > > > good."
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > [mailto:[e-mail]]
> > > > > > On
> > > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > > > >
> > > > > > > Anoop,
> > > > > > >
> > > > > > > 	I think we strongly disagree on what it means
> > > > to incorporate
> > > > > > > something in the control protocol.  From there, it is
> > > > likely that
> > > > > > > we also disagree on how best to avoid doing so.
> > > > > > >
> > > > > > > 	Figuring out how to correctly carry
> > > > IGMP-snooped information
> > > > > > > in TRILL protocol is effectively the same thing as
> > > incorporating
> > > > > > > IGMP in the control protocol.
> > > > > > >
> > > > > > > 	Making a list of everything that bridges snoop
> > > > and ensuring
> > > > > > > we can also include that information in IS-IS is
> > > > exactly the sort
> > > > > > > of thing we should be trying to avoid.  The good news
> > > is that it
> > > > > > > also should be easy to avoid.
> > > > > > >
> > > > > > > 	Whatever protocols we might use, TRILL is
> > > > essentially a layer
> > > > > > > two forwarding technology.  The messages that layer two
> > > > forwarding
> > > > > > > technologies want to snoop are visible to the devices
> > > > involved in
> > > > > > > forwarding.  Unless devices actively interfere with
> > > > "normal" layer
> > > > > > > two forwarding, "external" control messages should be
> > > > no different
> > > > > > > than any other form of data - as far as RBridges are
> > > concerned -
> > > > > > > and should be forwarded in the same way.
> > > > > > >
> > > > > > > 	We know that we're expected to preserve
> > > > forwarding symmetry
> > > > > > > - at least for the layer two encapsulation of TRILL
> > > > frames. In the
> > > > > > > same way, and for similar reasons, we may need to
> > > preserve path
> > > > > > > congruency.  This is implicit in the decision to
> > > learn from data
> > > > > > > in the unicast case.
> > > > > > >
> > > > > > > 	What we don't know is the complete list of
> > > > things that depend
> > > > > > > on our doing that.  But we can compose a partial list, and
> it
> > > > seems
> > > > > > > to me that "snooping" (in general) is one example,
> > > OA&M may well
> > > > be
> > > > > > > another and there are bound to be more.
> > > > > > >
> > > > > > > 	As for the notion of "crippling the technology
> > > > and making it
> > > > > > > very uninteresting" - well, to many people, technology
> becomes
> > > > very
> > > > > > > interesting when it is very complicated to make it
> > > > work.  For the
> > > > > > > users of any technology, it is only truly useful when
> > > it is not
> > > > very
> > > > > > > interesting.
> > > > > > >
> > > > > > > 	Paraphrasing something a colleague once told
> > > > me: a technology
> > > > > > > is only really useful when the interesting thing in
> > > using it is
> > > > not
> > > > > > > about the technology, but about its use.  Put another way,
> you
> > > > know
> > > > > > > that transportation is useful when the interesting thing
> about
> > > > using
> > > > > > > it is arriving at the destination - rather than the
> > > trip itself.
> > > > > > >
> > > > > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > > > > >
> > > > > > > --
> > > > > > > Eric Gray
> > > > > > > Principal Engineer
> > > > > > > Ericsson
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > > > > To: Eric Gray (LO/EUS)
> > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > > Importance: High
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Eric Gray (LO/EUS) 
> [mailto:[e-mail]]
> > > > > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > > > > To: Anoop Ghanwani
> > > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > > >
> > > > > > > > > Anoop,
> > > > > > > > >
> > > > > > > > > 	I tend to view your response below as yet
> > > another reason
> > > > > > > > > why RBridges MUST use a common path for unicast and 
> > > > > > > > > multicast (as well as broadcast and flooded) traffic.
> In
> > > > > > > > > fact, it is a very good reason to limit use of
> > > > "multipathing"
> > > > > > > > > in general.
> > > > > > > >
> > > > > > > > If we do place those constraints then it would 
> cripple the 
> > > > > > > > technology and make it very uninteresting (at least to
> me).
> > > > > > > >
> > > > > > > > > 	It is not clear exactly what you mean by your
> > > reference to
> > > > > > > > > differences between control and data paths.  Control 
> > > > > > > > > messages are from one RBridge to another and -
> > > presumably -
> > > > > > > > > follow the same path as data addressed from 
> RBridge to 
> > > > > > > > > RBridge.  That path may be different from data
> > > > transitting an
> > > > > > > > > RBridge campus, but there is no RBridge "control"
> traffic
> > > > > > > > > that transits a campus.
> > > > > > > > >
> > > > > > > > > 	Are you suggesting that IGMP should be treated
> > > as a control
> > > > > > > > > protocol within TRILL?
> > > > > > > >
> > > > > > > > In this case, when I said control I meant IGMP
> > > (since that is
> > > > > > > > what is being used to effect pruning).  If we 
> snoop on the 
> > > > > > > > information at the edge of the trill cloud and 
> pass this 
> > > > > > > > information around in IS-IS, then we don't need to
> > > worry about
> > > > > > > > treating it as a separate control protocol.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 	Nor is it very clear why this observation is
> > > specific to
> > > > > > > > > our discussion of multicast optimization.  As 
> a general 
> > > > > > > > > rule, if there is one reasonably well know
> > > application that
> > > > > > > > > relies on path congruency for proper operation, there
> are
> > > > > > > > > probably others.
> > > > > > > > >
> > > > > > > > > 	Do you think we should provide a logical
> > > control-function
> > > > > > > > > "bridging" service for all such
> > > > applications
> > > > > > > > > as a result of path divergences we introduce? 
>  Should we 
> > > > > > > > > conduct a research project to determine what
> > > other "control
> > > > > > > > > protocols" we need to include in TRILL?
> > > > > > > >
> > > > > > > > We would need to make a list of everything that
> > > bridges snoop
> > > > > > > > on and make sure we have ways of sending that
> > > around in IS-IS
> > > > > > > > (if we care about those functions).
> > > > > > > > I'm not aware of anything other than IGMP that 
> trill would 
> > > > > > > > need to worry about, though.
> > > > > > > >
> > > > > > > > Anoop
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rbridge mailing list
> > > > > > > [e-mail]
> > > > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > > >
> > > >
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LEEbxd002967 for <[e-mail]>; Thu, 21 Jun 2007 07:14:37 -0700 (PDT)
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: Thu, 21 Jun 2007 07:14:18 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIAAI8kMwAAHz+XAAAj/GYAAk/yhg
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LEEbxd002967
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 14:15:04 -0000
Status: RO
Content-Length: 13475

Anoop,

It is OK to agree to disagree with Eric.
 
The current draft says:
"ECMP (Equal Cost MultiPath) may be supported, but it may introduce
frame reordering."

Donald has offered to add some additional wording.

I think we are fine

-- Silvano


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 1:33 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> We need to convince Eric that we have
> consensus.  He doesn't seem to think so.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 12:37 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >
> > Anoop,
> >
> > What exactly do you think we need to do and to get consensus on?
> >
> > I think it is clear enough from the draft that an ingress Rbridge
can
> > multipath multidestination traffic by selecting different
> > tree roots for
> > different frames. So the only question is unicast. Other than a few
> > words saying that don't have to always send unicast traffic on the
one
> > path selected by the tie breaker rule, but MAY multipath, what more
is
> > needed?
> >
> > Presumably the tricky thing is how best to determine flows,
> > where frames
> > in a flow would follow only one of the multiple paths, except during
> > transients. I don't think the TRILL WG should get into
> > defining flows...
> >
> > Donald
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On
> > Behalf Of Anoop Ghanwani
> > Sent: Wednesday, June 20, 2007 2:43 PM
> > To: Eric Gray (LO/EUS); Silvano Gai
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> >
> > Personally, I would like the group to get to a
> > consensus on the ECMP issue fairly quickly.
> >
> > I too, just like Silvano, thought it was going
> > to be done.
> >
> > Anoop
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Wednesday, June 20, 2007 7:29 AM
> > > To: Silvano Gai; Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > >
> > > Silvano,
> > >
> > > 	Yes, that was probably discussed earlier in May.
> > >
> > > 	AFAIK, discussion != consensus.
> > >
> > > 	Possibly your customers need to explain to you that the
> > > difference between "core" and "not core" is not always as
> > > clear cut as you apparently think it is.  Nor is it
> > > necessarily going to be simple for a device to determine
> > > which of the available equal cost paths only contain core
elements.
> > >
> > > 	Also, ECMP - at least in the traditional sense - takes
> > > place where equal costs exist in a "routing" domain.  That is
> > > at least as likely to occur in locii containing one or more
> > > edge components, as it is anywhere else.
> > >
> > > 	There are certainly limited applications - typically
> > > requiring careful configuration to restrict ECMP-like
> > > activity to very specifically defined equal cost paths -
> > > where it will be possible to say "we do ECMP only in the
> > > core."  I personally wonder why link-bundling wouldn't be a
> > > better solution in those cases, however.
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 11:39 PM
> > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > >
> > > > We had this discussion on May 8th, 2007 on this mailing list.
> > > >
> > > > In a nutshell: we do ECMP only in the core, but we don't
> > > learn in the
> > > > core, so I don't see the problem.
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Tuesday, June 19, 2007 7:14 AM
> > > > > To: Silvano Gai; Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > Silvano,
> > > > >
> > > > > 	Your response is confusing.  If we are not
> > expected to preserve
> > > > > forwarding symmetry, have we given up on presumed
> > > compatibility with
> > > > > standard bridges?
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > Importance: High
> > > > > >
> > > > > >
> > > > > > Eric,
> > > > > >
> > > > > > You say: "we're expected to preserve forwarding symmetry".
> > > > > >
> > > > > > WE ARE NOT.
> > > > > >
> > > > > > Where does the current draft preserve forwarding symmetry?
> > > > > >
> > > > > > In regard to your conclusions, many of us (Anoop , Dinesh
> > > > and I for
> > > > > > sure) are participating because we are building real
products.
> > > > > >
> > > > > > I don't buy your argument that "Very uninteresting
> > > > > > (technology) is very
> > > > > > good."
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > [mailto:[e-mail]]
> > > > > > On
> > > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > > > >
> > > > > > > Anoop,
> > > > > > >
> > > > > > > 	I think we strongly disagree on what it means
> > > > to incorporate
> > > > > > > something in the control protocol.  From there, it is
> > > > likely that
> > > > > > > we also disagree on how best to avoid doing so.
> > > > > > >
> > > > > > > 	Figuring out how to correctly carry
> > > > IGMP-snooped information
> > > > > > > in TRILL protocol is effectively the same thing as
> > > incorporating
> > > > > > > IGMP in the control protocol.
> > > > > > >
> > > > > > > 	Making a list of everything that bridges snoop
> > > > and ensuring
> > > > > > > we can also include that information in IS-IS is
> > > > exactly the sort
> > > > > > > of thing we should be trying to avoid.  The good news
> > > is that it
> > > > > > > also should be easy to avoid.
> > > > > > >
> > > > > > > 	Whatever protocols we might use, TRILL is
> > > > essentially a layer
> > > > > > > two forwarding technology.  The messages that layer two
> > > > forwarding
> > > > > > > technologies want to snoop are visible to the devices
> > > > involved in
> > > > > > > forwarding.  Unless devices actively interfere with
> > > > "normal" layer
> > > > > > > two forwarding, "external" control messages should be
> > > > no different
> > > > > > > than any other form of data - as far as RBridges are
> > > concerned -
> > > > > > > and should be forwarded in the same way.
> > > > > > >
> > > > > > > 	We know that we're expected to preserve
> > > > forwarding symmetry
> > > > > > > - at least for the layer two encapsulation of TRILL
> > > > frames. In the
> > > > > > > same way, and for similar reasons, we may need to
> > > preserve path
> > > > > > > congruency.  This is implicit in the decision to
> > > learn from data
> > > > > > > in the unicast case.
> > > > > > >
> > > > > > > 	What we don't know is the complete list of
> > > > things that depend
> > > > > > > on our doing that.  But we can compose a partial
> > list, and it
> > > > seems
> > > > > > > to me that "snooping" (in general) is one example,
> > > OA&M may well
> > > > be
> > > > > > > another and there are bound to be more.
> > > > > > >
> > > > > > > 	As for the notion of "crippling the technology
> > > > and making it
> > > > > > > very uninteresting" - well, to many people,
> > technology becomes
> > > > very
> > > > > > > interesting when it is very complicated to make it
> > > > work.  For the
> > > > > > > users of any technology, it is only truly useful when
> > > it is not
> > > > very
> > > > > > > interesting.
> > > > > > >
> > > > > > > 	Paraphrasing something a colleague once told
> > > > me: a technology
> > > > > > > is only really useful when the interesting thing in
> > > using it is
> > > > not
> > > > > > > about the technology, but about its use.  Put
> > another way, you
> > > > know
> > > > > > > that transportation is useful when the interesting
> > thing about
> > > > using
> > > > > > > it is arriving at the destination - rather than the
> > > trip itself.
> > > > > > >
> > > > > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > > > > >
> > > > > > > --
> > > > > > > Eric Gray
> > > > > > > Principal Engineer
> > > > > > > Ericsson
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > > > > To: Eric Gray (LO/EUS)
> > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > > Importance: High
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Eric Gray (LO/EUS)
[mailto:[e-mail]]
> > > > > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > > > > To: Anoop Ghanwani
> > > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > > >
> > > > > > > > > Anoop,
> > > > > > > > >
> > > > > > > > > 	I tend to view your response below as yet
> > > another reason
> > > > > > > > > why RBridges MUST use a common path for unicast and
> > > > > > > > > multicast (as well as broadcast and flooded)
> > traffic.  In
> > > > > > > > > fact, it is a very good reason to limit use of
> > > > "multipathing"
> > > > > > > > > in general.
> > > > > > > >
> > > > > > > > If we do place those constraints then it would
> > cripple the
> > > > > > > > technology and make it very uninteresting (at
> > least to me).
> > > > > > > >
> > > > > > > > > 	It is not clear exactly what you mean by your
> > > reference to
> > > > > > > > > differences between control and data paths.  Control
> > > > > > > > > messages are from one RBridge to another and -
> > > presumably -
> > > > > > > > > follow the same path as data addressed from RBridge to
> > > > > > > > > RBridge.  That path may be different from data
> > > > transitting an
> > > > > > > > > RBridge campus, but there is no RBridge
> > "control" traffic
> > > > > > > > > that transits a campus.
> > > > > > > > >
> > > > > > > > > 	Are you suggesting that IGMP should be treated
> > > as a control
> > > > > > > > > protocol within TRILL?
> > > > > > > >
> > > > > > > > In this case, when I said control I meant IGMP
> > > (since that is
> > > > > > > > what is being used to effect pruning).  If we
> > snoop on the
> > > > > > > > information at the edge of the trill cloud and pass this
> > > > > > > > information around in IS-IS, then we don't need to
> > > worry about
> > > > > > > > treating it as a separate control protocol.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 	Nor is it very clear why this observation is
> > > specific to
> > > > > > > > > our discussion of multicast optimization.  As a
general
> > > > > > > > > rule, if there is one reasonably well know
> > > application that
> > > > > > > > > relies on path congruency for proper operation,
> > there are
> > > > > > > > > probably others.
> > > > > > > > >
> > > > > > > > > 	Do you think we should provide a logical
> > > control-function
> > > > > > > > > "bridging" service for all such
> > > > applications
> > > > > > > > > as a result of path divergences we introduce?
> > Should we
> > > > > > > > > conduct a research project to determine what
> > > other "control
> > > > > > > > > protocols" we need to include in TRILL?
> > > > > > > >
> > > > > > > > We would need to make a list of everything that
> > > bridges snoop
> > > > > > > > on and make sure we have ways of sending that
> > > around in IS-IS
> > > > > > > > (if we care about those functions).
> > > > > > > > I'm not aware of anything other than IGMP that
> > trill would
> > > > > > > > need to worry about, though.
> > > > > > > >
> > > > > > > > Anoop
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rbridge mailing list
> > > > > > > [e-mail]
> > > > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > > >
> > > >
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LEBwOK002170 for <[e-mail]>; Thu, 21 Jun 2007 07:11:58 -0700 (PDT)
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: Thu, 21 Jun 2007 07:11:40 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcezdYBrKA6bvaYlTqq6vdzqAVBznQAAgCnQACWdZ+A=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LEBwOK002170
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 14:12:36 -0000
Status: RO
Content-Length: 3727

Anoop,

If the language in my email is the problem, I take it back.
I am happy with the language in the draft.

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 1:22 PM
> To: Radia Perlman; Anoop Ghanwani
> Cc: Silvano Gai; [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Radia, et al,
> 
> 	I was not challenging consensus on multi-pathing, for either
> unicast or multicast.  What I was objecting to was the assertion
> that we ONLY do ECMP in "core" RBridges - which Silvano had stated
> as if a WG decision.  Since I seriously doubt that we could ever
> arrive at a consensus as to exactly what sort of real-world device
> would be a "core" RBridge, I don't think we have concluded that we
> ONLY do <anything you choose to talk about> in such a beasty.
> 
> 	See Silvano's original comments toward the very end of this
> (snipped) message.
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 4:00 PM
> > To: Anoop Ghanwani
> > Cc: Eric Gray (LO/EUS); Silvano Gai; [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> >
> > I'm also assuming we are doing multipathing, not just of unicast,
but
> > also multicast.
> >
> > Radia
> >
> >
> > Anoop Ghanwani wrote:
> > > Personally, I would like the group to get to a
> > > consensus on the ECMP issue fairly quickly.
> > >
> > > I too, just like Silvano, thought it was going
> > > to be done.
> > >
> > > Anoop
> > >
> > >
> > >> -----Original Message-----
> > >> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > >> Sent: Wednesday, June 20, 2007 7:29 AM
> > >> To: Silvano Gai; Anoop Ghanwani
> > >> Cc: [e-mail]; Radia Perlman
> > >> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > >>
> > >> Silvano,
> > >>
> > >> 	Yes, that was probably discussed earlier in May.
> > >>
> > >> 	AFAIK, discussion != consensus.
> > >>
> > >> 	Possibly your customers need to explain to you that the
> > >> difference between "core" and "not core" is not always as
> > >> clear cut as you apparently think it is.  Nor is it
> > >> necessarily going to be simple for a device to determine
> > >> which of the available equal cost paths only contain core
elements.
> > >>
> > >> 	Also, ECMP - at least in the traditional sense - takes
> > >> place where equal costs exist in a "routing" domain.  That is
> > >> at least as likely to occur in locii containing one or more
> > >> edge components, as it is anywhere else.
> > >>
> > >> 	There are certainly limited applications - typically
> > >> requiring careful configuration to restrict ECMP-like
> > >> activity to very specifically defined equal cost paths -
> > >> where it will be possible to say "we do ECMP only in the
> > >> core."  I personally wonder why link-bundling wouldn't be a
> > >> better solution in those cases, however.
> > >>
> > >> Thanks!
> > >>
> > >> --
> > >> Eric Gray
> > >> Principal Engineer
> > >> Ericsson
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Silvano Gai [mailto:[e-mail]]
> > >>> Sent: Tuesday, June 19, 2007 11:39 PM
> > >>> To: Eric Gray (LO/EUS); Anoop Ghanwani
> > >>> Cc: [e-mail]; Radia Perlman
> > >>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > >>> Importance: High
> > >>>
> > >>> We had this discussion on May 8th, 2007 on this mailing list.
> > >>>
> > >>> In a nutshell: we do ECMP only in the core, but we don't
> > >>>
> > >> learn in the
> > >>
> > >>> core, so I don't see the problem.
> > >>>
> > >>> -- Silvano
> --- SNIP ---



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LEA0Cj001926 for <[e-mail]>; Thu, 21 Jun 2007 07:10:00 -0700 (PDT)
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: Thu, 21 Jun 2007 07:09:42 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcezdXsXDOE7Age4TkC0P/QycKC3sgAmFCuA
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LEA0Cj001926
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 14:10:34 -0000
Status: RO
Content-Length: 11280

Sure

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 1:00 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); Silvano Gai; [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> I'm also assuming we are doing multipathing, not just of unicast, but
> also multicast.
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> > Personally, I would like the group to get to a
> > consensus on the ECMP issue fairly quickly.
> >
> > I too, just like Silvano, thought it was going
> > to be done.
> >
> > Anoop
> >
> >
> >> -----Original Message-----
> >> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> >> Sent: Wednesday, June 20, 2007 7:29 AM
> >> To: Silvano Gai; Anoop Ghanwani
> >> Cc: [e-mail]; Radia Perlman
> >> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>
> >> Silvano,
> >>
> >> 	Yes, that was probably discussed earlier in May.
> >>
> >> 	AFAIK, discussion != consensus.
> >>
> >> 	Possibly your customers need to explain to you that the
> >> difference between "core" and "not core" is not always as
> >> clear cut as you apparently think it is.  Nor is it
> >> necessarily going to be simple for a device to determine
> >> which of the available equal cost paths only contain core elements.
> >>
> >> 	Also, ECMP - at least in the traditional sense - takes
> >> place where equal costs exist in a "routing" domain.  That is
> >> at least as likely to occur in locii containing one or more
> >> edge components, as it is anywhere else.
> >>
> >> 	There are certainly limited applications - typically
> >> requiring careful configuration to restrict ECMP-like
> >> activity to very specifically defined equal cost paths -
> >> where it will be possible to say "we do ECMP only in the
> >> core."  I personally wonder why link-bundling wouldn't be a
> >> better solution in those cases, however.
> >>
> >> Thanks!
> >>
> >> --
> >> Eric Gray
> >> Principal Engineer
> >> Ericsson
> >>
> >>
> >>> -----Original Message-----
> >>> From: Silvano Gai [mailto:[e-mail]]
> >>> Sent: Tuesday, June 19, 2007 11:39 PM
> >>> To: Eric Gray (LO/EUS); Anoop Ghanwani
> >>> Cc: [e-mail]; Radia Perlman
> >>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>> Importance: High
> >>>
> >>> We had this discussion on May 8th, 2007 on this mailing list.
> >>>
> >>> In a nutshell: we do ECMP only in the core, but we don't
> >>>
> >> learn in the
> >>
> >>> core, so I don't see the problem.
> >>>
> >>> -- Silvano
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> >>>> Sent: Tuesday, June 19, 2007 7:14 AM
> >>>> To: Silvano Gai; Anoop Ghanwani
> >>>> Cc: [e-mail]; Radia Perlman
> >>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>>>
> >>>> Silvano,
> >>>>
> >>>> 	Your response is confusing.  If we are not expected to preserve
> >>>> forwarding symmetry, have we given up on presumed
> >>>>
> >> compatibility with
> >>
> >>>> standard bridges?
> >>>>
> >>>> --
> >>>> Eric Gray
> >>>> Principal Engineer
> >>>> Ericsson
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Silvano Gai [mailto:[e-mail]]
> >>>>> Sent: Tuesday, June 19, 2007 9:13 AM
> >>>>> To: Eric Gray (LO/EUS); Anoop Ghanwani
> >>>>> Cc: [e-mail]; Radia Perlman
> >>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>>>> Importance: High
> >>>>>
> >>>>>
> >>>>> Eric,
> >>>>>
> >>>>> You say: "we're expected to preserve forwarding symmetry".
> >>>>>
> >>>>> WE ARE NOT.
> >>>>>
> >>>>> Where does the current draft preserve forwarding symmetry?
> >>>>>
> >>>>> In regard to your conclusions, many of us (Anoop , Dinesh
> >>>>>
> >>> and I for
> >>>
> >>>>> sure) are participating because we are building real products.
> >>>>>
> >>>>> I don't buy your argument that "Very uninteresting
> >>>>> (technology) is very
> >>>>> good."
> >>>>>
> >>>>> -- Silvano
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail]
> >>>>>>
> >>> [mailto:[e-mail]]
> >>>
> >>>>> On
> >>>>>
> >>>>>> Behalf Of Eric Gray (LO/EUS)
> >>>>>> Sent: Tuesday, June 19, 2007 5:27 AM
> >>>>>> To: Anoop Ghanwani
> >>>>>> Cc: [e-mail]; Radia Perlman
> >>>>>> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> >>>>>>
> >>>>>> Anoop,
> >>>>>>
> >>>>>> 	I think we strongly disagree on what it means
> >>>>>>
> >>> to incorporate
> >>>
> >>>>>> something in the control protocol.  From there, it is
> >>>>>>
> >>> likely that
> >>>
> >>>>>> we also disagree on how best to avoid doing so.
> >>>>>>
> >>>>>> 	Figuring out how to correctly carry
> >>>>>>
> >>> IGMP-snooped information
> >>>
> >>>>>> in TRILL protocol is effectively the same thing as
> >>>>>>
> >> incorporating
> >>
> >>>>>> IGMP in the control protocol.
> >>>>>>
> >>>>>> 	Making a list of everything that bridges snoop
> >>>>>>
> >>> and ensuring
> >>>
> >>>>>> we can also include that information in IS-IS is
> >>>>>>
> >>> exactly the sort
> >>>
> >>>>>> of thing we should be trying to avoid.  The good news
> >>>>>>
> >> is that it
> >>
> >>>>>> also should be easy to avoid.
> >>>>>>
> >>>>>> 	Whatever protocols we might use, TRILL is
> >>>>>>
> >>> essentially a layer
> >>>
> >>>>>> two forwarding technology.  The messages that layer two
> >>>>>>
> >>> forwarding
> >>>
> >>>>>> technologies want to snoop are visible to the devices
> >>>>>>
> >>> involved in
> >>>
> >>>>>> forwarding.  Unless devices actively interfere with
> >>>>>>
> >>> "normal" layer
> >>>
> >>>>>> two forwarding, "external" control messages should be
> >>>>>>
> >>> no different
> >>>
> >>>>>> than any other form of data - as far as RBridges are
> >>>>>>
> >> concerned -
> >>
> >>>>>> and should be forwarded in the same way.
> >>>>>>
> >>>>>> 	We know that we're expected to preserve
> >>>>>>
> >>> forwarding symmetry
> >>>
> >>>>>> - at least for the layer two encapsulation of TRILL
> >>>>>>
> >>> frames. In the
> >>>
> >>>>>> same way, and for similar reasons, we may need to
> >>>>>>
> >> preserve path
> >>
> >>>>>> congruency.  This is implicit in the decision to
> >>>>>>
> >> learn from data
> >>
> >>>>>> in the unicast case.
> >>>>>>
> >>>>>> 	What we don't know is the complete list of
> >>>>>>
> >>> things that depend
> >>>
> >>>>>> on our doing that.  But we can compose a partial list, and it
> >>>>>>
> >>> seems
> >>>
> >>>>>> to me that "snooping" (in general) is one example,
> >>>>>>
> >> OA&M may well
> >>
> >>> be
> >>>
> >>>>>> another and there are bound to be more.
> >>>>>>
> >>>>>> 	As for the notion of "crippling the technology
> >>>>>>
> >>> and making it
> >>>
> >>>>>> very uninteresting" - well, to many people, technology becomes
> >>>>>>
> >>> very
> >>>
> >>>>>> interesting when it is very complicated to make it
> >>>>>>
> >>> work.  For the
> >>>
> >>>>>> users of any technology, it is only truly useful when
> >>>>>>
> >> it is not
> >>
> >>> very
> >>>
> >>>>>> interesting.
> >>>>>>
> >>>>>> 	Paraphrasing something a colleague once told
> >>>>>>
> >>> me: a technology
> >>>
> >>>>>> is only really useful when the interesting thing in
> >>>>>>
> >> using it is
> >>
> >>> not
> >>>
> >>>>>> about the technology, but about its use.  Put another way, you
> >>>>>>
> >>> know
> >>>
> >>>>>> that transportation is useful when the interesting thing about
> >>>>>>
> >>> using
> >>>
> >>>>>> it is arriving at the destination - rather than the
> >>>>>>
> >> trip itself.
> >>
> >>>>>> 	Uninteresting is good.  Very uninteresting is very good.
> >>>>>>
> >>>>>> --
> >>>>>> Eric Gray
> >>>>>> Principal Engineer
> >>>>>> Ericsson
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Anoop Ghanwani [mailto:[e-mail]]
> >>>>>>> Sent: Monday, June 18, 2007 7:08 PM
> >>>>>>> To: Eric Gray (LO/EUS)
> >>>>>>> Cc: [e-mail]; Radia Perlman
> >>>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>>>>>> Importance: High
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> >>>>>>>> Sent: Monday, June 18, 2007 11:43 AM
> >>>>>>>> To: Anoop Ghanwani
> >>>>>>>> Cc: [e-mail]; Radia Perlman
> >>>>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>>>>>>>
> >>>>>>>> Anoop,
> >>>>>>>>
> >>>>>>>> 	I tend to view your response below as yet
> >>>>>>>>
> >> another reason
> >>
> >>>>>>>> why RBridges MUST use a common path for unicast and
> >>>>>>>> multicast (as well as broadcast and flooded) traffic.  In
> >>>>>>>> fact, it is a very good reason to limit use of
> >>>>>>>>
> >>> "multipathing"
> >>>
> >>>>>>>> in general.
> >>>>>>>>
> >>>>>>> If we do place those constraints then it would cripple the
> >>>>>>> technology and make it very uninteresting (at least to me).
> >>>>>>>
> >>>>>>>
> >>>>>>>> 	It is not clear exactly what you mean by your
> >>>>>>>>
> >> reference to
> >>
> >>>>>>>> differences between control and data paths.  Control
> >>>>>>>> messages are from one RBridge to another and -
> >>>>>>>>
> >> presumably -
> >>
> >>>>>>>> follow the same path as data addressed from RBridge to
> >>>>>>>> RBridge.  That path may be different from data
> >>>>>>>>
> >>> transitting an
> >>>
> >>>>>>>> RBridge campus, but there is no RBridge "control" traffic
> >>>>>>>> that transits a campus.
> >>>>>>>>
> >>>>>>>> 	Are you suggesting that IGMP should be treated
> >>>>>>>>
> >> as a control
> >>
> >>>>>>>> protocol within TRILL?
> >>>>>>>>
> >>>>>>> In this case, when I said control I meant IGMP
> >>>>>>>
> >> (since that is
> >>
> >>>>>>> what is being used to effect pruning).  If we snoop on the
> >>>>>>> information at the edge of the trill cloud and pass this
> >>>>>>> information around in IS-IS, then we don't need to
> >>>>>>>
> >> worry about
> >>
> >>>>>>> treating it as a separate control protocol.
> >>>>>>>
> >>>>>>>
> >>>>>>>> 	Nor is it very clear why this observation is
> >>>>>>>>
> >> specific to
> >>
> >>>>>>>> our discussion of multicast optimization.  As a general
> >>>>>>>> rule, if there is one reasonably well know
> >>>>>>>>
> >> application that
> >>
> >>>>>>>> relies on path congruency for proper operation, there are
> >>>>>>>> probably others.
> >>>>>>>>
> >>>>>>>> 	Do you think we should provide a logical
> >>>>>>>>
> >> control-function
> >>
> >>>>>>>> "bridging" service for all such
> >>>>>>>>
> >>> applications
> >>>
> >>>>>>>> as a result of path divergences we introduce?  Should we
> >>>>>>>> conduct a research project to determine what
> >>>>>>>>
> >> other "control
> >>
> >>>>>>>> protocols" we need to include in TRILL?
> >>>>>>>>
> >>>>>>> We would need to make a list of everything that
> >>>>>>>
> >> bridges snoop
> >>
> >>>>>>> on and make sure we have ways of sending that
> >>>>>>>
> >> around in IS-IS
> >>
> >>>>>>> (if we care about those functions).
> >>>>>>> I'm not aware of anything other than IGMP that trill would
> >>>>>>> need to worry about, though.
> >>>>>>>
> >>>>>>> Anoop
> >>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> rbridge mailing list
> >>>>>> [e-mail]
> >>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>>>




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LE9ke2001909 for <[e-mail]>; Thu, 21 Jun 2007 07:09:46 -0700 (PDT)
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: Thu, 21 Jun 2007 07:09:28 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcezdQFqF5OHl0DBRp29QhzuFTT5NQAmI8aw
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LE9ke2001909
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 14:10:00 -0000
Status: RO
Content-Length: 1757

Radia,

This information was known at the time of the consensus.
I still remain in favor of the header we selected.
If somebody wants to change his/her mind they can email this list
(SOON).


-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 12:57 PM
> To: Anoop Ghanwani
> Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
[e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> As Anoop said, core RBridges need to look inside the tunneled
> packet at the inner packet in order to do multicast pruning
> as well as VLAN pruning on multicast packets.
> 
> Which is why Don was proposing moving both the VLAN tag and the
> destination multicast address to the TRILL header. (and removing the
> VLAN tag
> and DA from the
> inner packet so that it wouldn't mean adding an extra 6 bytes to an
> encapsulated frame).
> 
> Seemed like people didn't like doing that, but I want to make sure if
> the WG really
> is deciding not to do that, that they really understand what they are
> deciding against.
> Often in the email threads so many different things are kind of
> discussed at the same time
> that it's obvious that people (definitely including me) are getting
> confused.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> >
> > They're snooping because they too care about
> > pruning their trees for a given multicast group
> > and that would be one of the ways to achieve it.
> > Otherwise, all multicasts would have to be
> > broadcast on the spanning tree interconnecting
> > the bridged network that sits between the two
> > rBridges.
> >
> >
> > If we didn't care about multicast pruning,
> > we wouldn't need to worry about any of this.
> >
> >




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LE849r001331 for <[e-mail]>; Thu, 21 Jun 2007 07:08:05 -0700 (PDT)
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: Thu, 21 Jun 2007 07:07:45 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIAAI8kMwAAHz+XAAJwbhIA==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LE849r001331
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 14:08:59 -0000
Status: RO
Content-Length: 12352

Anoop,

I agree with Donald,

I think the draft is fine, it does not prevent ECMP.
No protocol that I know specify how "to determine flows".

I don't see any action needed.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Wednesday, June 20, 2007 12:37 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> What exactly do you think we need to do and to get consensus on?
> 
> I think it is clear enough from the draft that an ingress Rbridge can
> multipath multidestination traffic by selecting different tree roots
for
> different frames. So the only question is unicast. Other than a few
> words saying that don't have to always send unicast traffic on the one
> path selected by the tie breaker rule, but MAY multipath, what more is
> needed?
> 
> Presumably the tricky thing is how best to determine flows, where
frames
> in a flow would follow only one of the multiple paths, except during
> transients. I don't think the TRILL WG should get into defining
flows...
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 2:43 PM
> To: Eric Gray (LO/EUS); Silvano Gai
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Personally, I would like the group to get to a
> consensus on the ECMP issue fairly quickly.
> 
> I too, just like Silvano, thought it was going
> to be done.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 7:29 AM
> > To: Silvano Gai; Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >
> > Silvano,
> >
> > 	Yes, that was probably discussed earlier in May.
> >
> > 	AFAIK, discussion != consensus.
> >
> > 	Possibly your customers need to explain to you that the
> > difference between "core" and "not core" is not always as
> > clear cut as you apparently think it is.  Nor is it
> > necessarily going to be simple for a device to determine
> > which of the available equal cost paths only contain core elements.
> >
> > 	Also, ECMP - at least in the traditional sense - takes
> > place where equal costs exist in a "routing" domain.  That is
> > at least as likely to occur in locii containing one or more
> > edge components, as it is anywhere else.
> >
> > 	There are certainly limited applications - typically
> > requiring careful configuration to restrict ECMP-like
> > activity to very specifically defined equal cost paths -
> > where it will be possible to say "we do ECMP only in the
> > core."  I personally wonder why link-bundling wouldn't be a
> > better solution in those cases, however.
> >
> > Thanks!
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> >
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 11:39 PM
> > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > >
> > > We had this discussion on May 8th, 2007 on this mailing list.
> > >
> > > In a nutshell: we do ECMP only in the core, but we don't
> > learn in the
> > > core, so I don't see the problem.
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 7:14 AM
> > > > To: Silvano Gai; Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > Silvano,
> > > >
> > > > 	Your response is confusing.  If we are not expected to
> preserve
> > > > forwarding symmetry, have we given up on presumed
> > compatibility with
> > > > standard bridges?
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > Importance: High
> > > > >
> > > > >
> > > > > Eric,
> > > > >
> > > > > You say: "we're expected to preserve forwarding symmetry".
> > > > >
> > > > > WE ARE NOT.
> > > > >
> > > > > Where does the current draft preserve forwarding symmetry?
> > > > >
> > > > > In regard to your conclusions, many of us (Anoop , Dinesh
> > > and I for
> > > > > sure) are participating because we are building real products.
> > > > >
> > > > > I don't buy your argument that "Very uninteresting
> > > > > (technology) is very
> > > > > good."
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > > > On
> > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > > >
> > > > > > Anoop,
> > > > > >
> > > > > > 	I think we strongly disagree on what it means
> > > to incorporate
> > > > > > something in the control protocol.  From there, it is
> > > likely that
> > > > > > we also disagree on how best to avoid doing so.
> > > > > >
> > > > > > 	Figuring out how to correctly carry
> > > IGMP-snooped information
> > > > > > in TRILL protocol is effectively the same thing as
> > incorporating
> > > > > > IGMP in the control protocol.
> > > > > >
> > > > > > 	Making a list of everything that bridges snoop
> > > and ensuring
> > > > > > we can also include that information in IS-IS is
> > > exactly the sort
> > > > > > of thing we should be trying to avoid.  The good news
> > is that it
> > > > > > also should be easy to avoid.
> > > > > >
> > > > > > 	Whatever protocols we might use, TRILL is
> > > essentially a layer
> > > > > > two forwarding technology.  The messages that layer two
> > > forwarding
> > > > > > technologies want to snoop are visible to the devices
> > > involved in
> > > > > > forwarding.  Unless devices actively interfere with
> > > "normal" layer
> > > > > > two forwarding, "external" control messages should be
> > > no different
> > > > > > than any other form of data - as far as RBridges are
> > concerned -
> > > > > > and should be forwarded in the same way.
> > > > > >
> > > > > > 	We know that we're expected to preserve
> > > forwarding symmetry
> > > > > > - at least for the layer two encapsulation of TRILL
> > > frames. In the
> > > > > > same way, and for similar reasons, we may need to
> > preserve path
> > > > > > congruency.  This is implicit in the decision to
> > learn from data
> > > > > > in the unicast case.
> > > > > >
> > > > > > 	What we don't know is the complete list of
> > > things that depend
> > > > > > on our doing that.  But we can compose a partial list, and
it
> > > seems
> > > > > > to me that "snooping" (in general) is one example,
> > OA&M may well
> > > be
> > > > > > another and there are bound to be more.
> > > > > >
> > > > > > 	As for the notion of "crippling the technology
> > > and making it
> > > > > > very uninteresting" - well, to many people, technology
becomes
> > > very
> > > > > > interesting when it is very complicated to make it
> > > work.  For the
> > > > > > users of any technology, it is only truly useful when
> > it is not
> > > very
> > > > > > interesting.
> > > > > >
> > > > > > 	Paraphrasing something a colleague once told
> > > me: a technology
> > > > > > is only really useful when the interesting thing in
> > using it is
> > > not
> > > > > > about the technology, but about its use.  Put another way,
you
> > > know
> > > > > > that transportation is useful when the interesting thing
about
> > > using
> > > > > > it is arriving at the destination - rather than the
> > trip itself.
> > > > > >
> > > > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > > > To: Eric Gray (LO/EUS)
> > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > Importance: High
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > > > To: Anoop Ghanwani
> > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > >
> > > > > > > > Anoop,
> > > > > > > >
> > > > > > > > 	I tend to view your response below as yet
> > another reason
> > > > > > > > why RBridges MUST use a common path for unicast and
> > > > > > > > multicast (as well as broadcast and flooded) traffic.
In
> > > > > > > > fact, it is a very good reason to limit use of
> > > "multipathing"
> > > > > > > > in general.
> > > > > > >
> > > > > > > If we do place those constraints then it would cripple the
> > > > > > > technology and make it very uninteresting (at least to
me).
> > > > > > >
> > > > > > > > 	It is not clear exactly what you mean by your
> > reference to
> > > > > > > > differences between control and data paths.  Control
> > > > > > > > messages are from one RBridge to another and -
> > presumably -
> > > > > > > > follow the same path as data addressed from RBridge to
> > > > > > > > RBridge.  That path may be different from data
> > > transitting an
> > > > > > > > RBridge campus, but there is no RBridge "control"
traffic
> > > > > > > > that transits a campus.
> > > > > > > >
> > > > > > > > 	Are you suggesting that IGMP should be treated
> > as a control
> > > > > > > > protocol within TRILL?
> > > > > > >
> > > > > > > In this case, when I said control I meant IGMP
> > (since that is
> > > > > > > what is being used to effect pruning).  If we snoop on the
> > > > > > > information at the edge of the trill cloud and pass this
> > > > > > > information around in IS-IS, then we don't need to
> > worry about
> > > > > > > treating it as a separate control protocol.
> > > > > > >
> > > > > > > >
> > > > > > > > 	Nor is it very clear why this observation is
> > specific to
> > > > > > > > our discussion of multicast optimization.  As a general
> > > > > > > > rule, if there is one reasonably well know
> > application that
> > > > > > > > relies on path congruency for proper operation, there
are
> > > > > > > > probably others.
> > > > > > > >
> > > > > > > > 	Do you think we should provide a logical
> > control-function
> > > > > > > > "bridging" service for all such
> > > applications
> > > > > > > > as a result of path divergences we introduce?  Should we
> > > > > > > > conduct a research project to determine what
> > other "control
> > > > > > > > protocols" we need to include in TRILL?
> > > > > > >
> > > > > > > We would need to make a list of everything that
> > bridges snoop
> > > > > > > on and make sure we have ways of sending that
> > around in IS-IS
> > > > > > > (if we care about those functions).
> > > > > > > I'm not aware of anything other than IGMP that trill would
> > > > > > > need to worry about, though.
> > > > > > >
> > > > > > > Anoop
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rbridge mailing list
> > > > > > [e-mail]
> > > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > >
> > >
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5LDGGJ4017635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 21 Jun 2007 06:16:16 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5LDHjrF024499; Thu, 21 Jun 2007 08:17:45 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 21 Jun 2007 08:16:07 -0500
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: Thu, 21 Jun 2007 08:16:02 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSswAAJcTuAAIuzmEA==
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 21 Jun 2007 13:16:07.0924 (UTC) FILETIME=[543A0340:01C7B406]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5LDGGJ4017635
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 13:17:03 -0000
Status: RO
Content-Length: 11772

Anoop,

	I agree with Donald, and I am still having difficulty in seeing
why you think this doesn't work.  See specific comments in line (after
your diagram) below.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 5:55 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> 
> This thread was started because of the assertion
> that the current rbridge proposal is "opaque" and
> is completely compatible with bridges.
> 
> I pointed out that it breaks snooping once the
> frames are trill encap'ed and this snooping is
> required if you have 2 rbridges interconnected
> by a regular LAN that doesn't have any end nodes
> that are interested in seeing that multicast.
> 
> To which Donald responded saying that the DRB
> for the bridged LAN would be sending a decap'ed
> version of the control packets to the LAN 
> anyway, and so snooping would continue to work.
> 
> I still don't think it works.  Consider
> the following network.
> 
> 
>   Multicast router
>    |
>    Rb1 (DRB for the LAN)
>    |
>  bridged LAN with 10 bridges and hosts
>  in some random configuration
>    |
>    Rb2
>    |
>    B
> 
> In the above example, B is the only
> participant in a multicast.  No one
> on the intermediate LAN is interested
> in receiving the multicast.
> 
> When B sends a join, it gets trill encap'ed
> by Rb2 and forwarded to Rb1.  The bridges
> in the LAN can't snoop that because they
> don't understand the trill etype.

Here is - IMO - where your argument breaks down.

In this case, assuming that Rb1 and Rb2 are the only two 
RBridges attached to the LAN between them, either Rb1 or
Rb2 will be the designated RBridge for that LAN.

One of the small inefficiencies of the way that the TRILL
design works, is that - in this situation - if Rb1 is the
designated RBridge, the join frame will traverse the LAN
once (as a TRILL encapsulated frame) from Rb2 to Rb1, and
then will be decapsulated and forwarded "in the raw" to
the stations on the LAN.

That is precisely why I said that - unless you expect us
to perform some kind of inappropriate filtering - control
frames will be seen throughout a (V)LAN.

The reason why this occurs is that Rb1 - as the desginated
RBridge in this case - is required to ensure that the IGMP
join (which it MUST treat as an external data frame in any
case) is delivered throughout the broadcast domain.  This
is because - without special knowledge (such as might be
configured) - Rb1 has no reason to believe that the target
for the join message is not on the local LAN.

> 
> When multicast data are forwarded from Rb1
> to Rb2 it is encap'ed as trill and sent
> to the all-rbridges address.  The bridges
> on the LAN (all 10 of them) will see this
> frame and copy it to all stations on that
> LAN.
> 
> That the bridges on the LAN see a 
> decap'ed version of the Join doesn't
> mean anything, because the multicast
> traffic between the routers goes has the
> all-rbridges address as the MAC DA.
> In this way, we have broken "compatibility"
> with bridges.
> 
> With something like MMRP (a native 802.1
> protocol), things are even worse.  Rb1 
> would terminate any MMRPDUs (just as
> it would STP BPDUs).
> 
> We cannot says we are backwards compatible
> with bridges just because we restrict traffic 
> flow to a single symmetric tree within the trill 
> network.  We are breaking compatibility in
> other ways.  We need to be explicit about 
> what compatibility we are trying to preserve.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Wednesday, June 20, 2007 12:23 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Hi Anoop,
> > 
> > It seems to me that what you are saying is that the strategy 
> > in TRILL of only sending IGMP/MLD to links that appear to 
> > have IP multicast routers on them due to the detection of 
> > PIM/MRD messages doesn't work. That, at least occasionally, 
> > IGMP/MLD have to be flooded to every link just in case there 
> > might be an IP multicast router on it that has been silent.
> > 
> > If that's a problem, it has nothing to do with bridges or 
> > bridged LANs.
> > All it takes to demonstrate the problem is a silent IP 
> > multicast router point-to-point connected to an Rbridge 
> > somewhere. If that IP multicast router has never send an PIM 
> > or MRD message, then the Rbridge has no way of knowing to 
> > send it IGMPs or MLDs (or multicast data traffic)...
> > 
> > Donald 
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 3:14 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > 
> > And we now go full circle back to...
> > 
> > What if we a bridged LAN between 2 rbridges
> > and there were no stations on this bridged LAN
> > (other than the rbridges) that were interested
> > in receiving that multicast?  You wouldn't
> > see any of the control packet that you mention.
> > The only control packets of that type would be
> > the ones which were going between the rBridges and
> > those would be trill encap'ed.  So the regular
> > bridges between these rbridges wouldn't 
> > understand them (for snooping).
> > 
> > Anoop 
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008 
> > > [mailto:[e-mail]] 
> > > Sent: Wednesday, June 20, 2007 12:11 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Hi Anoop,
> > > 
> > > From two places. They should see native IGMP/MLD/PIM/MRD from 
> > > end stations that are directly attached to them. And, to the 
> > > extent that they let any surrounding Rbridges see any PIM/MRD 
> > > messages, the Designated Rbridge will send IGMP/MLDs in 
> > > native form into the bridged LAN. I should think this would 
> > > give the bridges enough information to figure out how to do 
> > > an optimized forwarding of IP derived multicast address traffic.
> > > 
> > > Donald 
> > > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Wednesday, June 20, 2007 2:53 PM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Donald,
> > > 
> > > So then the bridges in the LAN between the
> > > 2 rbridges need some information to do their
> > > pruning.   Where do they get it from?
> > > 
> > > Anoop 
> > > 
> > > > -----Original Message-----
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 7:16 PM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > Hi Anoop,
> > > > 
> > > > No, it shouldn't get delivered to every end station 
> unless it is 
> > > > broadcast or a layer 2 multicast not derived from an IP address.
> > > > 
> > > > If it is an layer 2 multicast address derived from an IP 
> > > address, then 
> > > > Rbridges should prune the distribution tree and the links they 
> > > > decapsulate and forward onto to those with listeners for an IP 
> > > > multicast address that corresponds to that layer 2 
> > > multicast address 
> > > > or with an IP multicast router.
> > > > 
> > > > Donald
> > > > 
> > > > PS: All the above is scoped by VLAN as well.
> > > > 
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 7:32 PM
> > > > To: Eastlake III Donald-LDE008
> > > > Cc: [e-mail]; Caitlin Bestler
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > Donald,
> > > > 
> > > > What if there are no IP multicast routers or listeners in 
> > > the bridged 
> > > > LAN between the rBridges?  Does that mean a copy of the 
> > trill frame 
> > > > gets delivered to every station in that LAN?
> > > > 
> > > > Anoop
> > > > 
> > > > > -----Original Message-----
> > > > > From: Eastlake III Donald-LDE008
> > > > > [mailto:[e-mail]]
> > > > > Sent: Tuesday, June 19, 2007 12:51 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [e-mail]; Caitlin Bestler
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > 
> > > > > In addition to what Caitlin says, I would point out that,
> > > > if there are
> > > > > multicast listeners or IP multicast routers in this bridged
> > > > LAN (which
> > > > > looks to the Rbridges pretty much like a single 
> > > multi-access link), 
> > > > > then the Rbridges should have heard about them and the 
> > Designated 
> > > > > Rbridge for the VLAN in question for that cloud will also 
> > > > > decapsulate
> > > > appropriate
> > > > > data/multicast-control and send it into the cloud as native
> > > > > (non-TRILL)
> > > > > frames whose distribution within the cloud the bridges are
> > > > welcome to
> > > > > try to optimize as much as they like.
> > > > > 
> > > > > Donald
> > > > > 
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of 
> Caitlin Bestler
> > > > > Sent: Tuesday, June 19, 2007 3:16 PM
> > > > > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > > 
> > > > > [e-mail] wrote:
> > > > > > Eric,
> > > > > > 
> > > > > > It depends on what we mean by compatibility.
> > > > > > One can always say that if one cares about such and such 
> > > > > > compatibility then here's a way to solve it.
> > > > > > 
> > > > > > Even if trill were to impose the constraint you 
> suggest, many 
> > > > > > things will break.  For example, if I have a 
> topology with a 
> > > > > > bridged cloud between 2 trill devices, then the 
> traffic going 
> > > > > > between the trill devices will not be "snoopable" by 
> > > the bridges 
> > > > > > because they won't understand trill encapsulation.
> > > > > > 
> > > > > 
> > > > > Why are these intermediate bridges snooping?
> > > > > 
> > > > > The only service being requested of them is to relay 
> > > Ethernet frames 
> > > > > from the ingress rbridge to the egress rbridge. Is that 
> > > not implied 
> > > > > by their being a cloud *between* 2 trill devices?
> > > > > 
> > > > > How is this different from any tunnel? You have 
> traffic that a 
> > > > > middlebox might have optimized had it been untunelled, 
> > > but that it 
> > > > > does not see when tunneled. It cannot provide its 
> > > service, but it is 
> > > > > not being asked to do so.
> > > > > 
> > > > > A non-rbridge bridge forwards packets without 
> > understanding that 
> > > > > they are rbridge encapsulated frames. I always thought 
> > > that this was 
> > > > > a strength of the proposal, not a weakness. You can't be 
> > > snoopable 
> > > > > and opaque. Opaque is better.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > rbridge mailing list
> > > > > [e-mail]
> > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > > 
> > > > 
> > > 
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5L3rOvo027413 for <[e-mail]>; Wed, 20 Jun 2007 20:53:24 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-128.messagelabs.com!1182398003!6818237!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 31691 invoked from network); 21 Jun 2007 03:53:23 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 21 Jun 2007 03:53:23 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5L3rJaF001038 for <[e-mail]>; Wed, 20 Jun 2007 20:53:23 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5L3rI4Y028629 for <[e-mail]>; Wed, 20 Jun 2007 22:53:19 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5L3rIOY028622 for <[e-mail]>; Wed, 20 Jun 2007 22:53:18 -0500 (CDT)
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, 20 Jun 2007 23:53:15 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSswAAJcTuAADT48EA==
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5L3rOvo027413
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 03:53:49 -0000
Status: RO
Content-Length: 16681

Hi Anoop,

See below at @@@ 

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Wednesday, June 20, 2007 5:55 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

This thread was started because of the assertion
that the current rbridge proposal is "opaque" and
is completely compatible with bridges.

@@@ Of course, that depends on what "completely compatible" means. The
protocol specification just says "compatible", not "completely
compatible" :-)

I pointed out that it breaks snooping once the
frames are trill encap'ed and this snooping is
required if you have 2 rbridges interconnected
by a regular LAN that doesn't have any end nodes
that are interested in seeing that multicast.

@@@ You may have found a problem, but I really don't think it is the
problem you believe it is, as I will try to explain below. Furthermore,
I can't see why the bridges in the bridged LAN need to snoop if there
are no multicast listeners or IP multicast routers inside the bridged
LAN.

To which Donald responded saying that the DRB
for the bridged LAN would be sending a decap'ed
version of the control packets to the LAN 
anyway, and so snooping would continue to work.

@@@ Well, I was trying to say something more like the DRB would send in
any traffic that nodes inside the bridged LAN had indicated any interest
in.

I still don't think it works.  Consider
the following network.


  Multicast router
   |
   Rb1 (DRB for the LAN)
   |
 bridged LAN with 10 bridges and hosts
 in some random configuration
   |
   Rb2
   |
   B

In the above example, B is the only
participant in a multicast.  No one
on the intermediate LAN is interested
in receiving the multicast.

When B sends a join, it gets trill encap'ed
by Rb2 and forwarded to Rb1.  The bridges
in the LAN can't snoop that because they
don't understand the trill etype.

@@@ Right, stuff with a TRILL Header is opaque to boxes which don't
understand how to parse it. So boxes that are not Rbridges, including
the bridges on this bridged LAN, will be in the dark.

When multicast data are forwarded from Rb1
to Rb2 it is encap'ed as trill and sent
to the all-rbridges address.  The bridges
on the LAN (all 10 of them) will see this
frame and copy it to all stations on that
LAN.

@@@ That is correct with the current protocol spec. But I would point
out that at the expense of slightly more complex conditionals, the
protocol could notice that there is only one IS-IS adjacency on that
link out of RB1 and unicast the TRILL data frames even if the
encapsulated frame had a multicast destination. (Of course, it would
want to keep multicasting the TRILL IS-IS frames in case another Rbridge
shows up.) There is nothing peculiar about a unicast TRILL data frame.
If there is unicast data being forwarded from RB1 to RB2, it would be
unicast. But I am digressing.

That the bridges on the LAN see a 
decap'ed version of the Join doesn't
mean anything, because the multicast
traffic between the routers goes has the
all-rbridges address as the MAC DA.
In this way, we have broken "compatibility"
with bridges.

@@@ Just above is where you lose me. The TRILL encapsulated data has
nothing to do with the  problem... If any listener inside the bridge LAN
had spoken up, the native form of the multicast data would be getting
forwarded into the bridged LAN also...

@@@ It seems to me there are four possibilities for what is in the
bridged LAN between RB1 and RB2: (1) There are no IP multicast routers
or multicast listeners; (2) There are one or more listeners but no IP
multicast router; (3) there is an IP multicast router but no listeners;
and (4) there is both an IP multicast router and one or more listeners.

@@@ In case 1, we are obviously fine. B joins the group, the IP
multicast router at the top send multicast to B, everything is fine and
it doesn't matter that stuff is encapsulated because there is no reason
for any box in the bridged LAN to care.

@@@ In case 2, we have a listener inside the bridged LAN. It will send
an IGMP (I'll ignore IPv6 for this discussion for simplicity.) Either
RB1 or RB2 will be the Designated Rbridge (DRB) for the bridged LAN
(which looks to the Rbridges like a multi-access link). Whichever is the
DRB receives and processes the frame. It will then forward it in native
form on any local links that seem to have an IP multicast router on them
and for which it is DRB. So if RB1 is the DRB for the bridged LAN and
the DRB for the link at the top with the IP multicast router (which it
would obviously be if it was the only Rbridge on that link), it would
forward it in native form to that IP multicast router. The DRB receiving
the original native IGMP will also encapsulate this IGMP and forward it
over a distribution tree to all other Rbridges that advertise they are
DRB for some local link with an IP multicast router on that link. And
those Rbridges will decapsulate it and deliver it to those IP multicast
routers on those link.
@@@ For example, if RB2 is the DRB for the bridged LAN, it would receive
the native IGMP from the listener inside the bridged LAN, encapsulate
it, and send it to RB1 which would decapsulate it and deliver it to the
IP multicast router at the top.
@@@ In any case, we have a listener inside the bridged LAN; its IGMP
gets to all IP multicast routers as described above. Furthermore, the
Rbridge that is DRB for the bridged LAN also remembers and advertises
that it saw this IGMP and there is a Listener inside the bridge LAN so
it will get and decapsulate appropriate multicast data and send it in
native form into the bridge LAN.
@@@ In other words, everything works fine in this case.

@@@ OK, on to case 3. There is an IP multicast router inside the bridged
LAN but no Listeners. If this IP multicast router ever sends a PIM or
MRD, it will be noticed by the DRB for the bridged LAN which will
remember this and advertise in the link state that it has an IP
multicast router attached. This advertisement will cause it to start
receiving all IGMPs and multicast data, if it wasn't already receiving
that traffic, and it will decapsulate that traffic and send it into the
bridged LAN.
@@@ The possible problem is if the IP multicast router inside the
bridged LAN is silent. Then the DRB doesn't know to hook things up and
start decapsulating the relevant frames and sending them into the
bridged LAN.

@@@ It doesn't seem worth going through case 4, which is kind of a
combination of cases 2 and 3.

@@@ All right, now that I have gone through all that, consider the
following:

@@@   Multicast router
@@@   |
@@@   Rb1 (DRB for the LAN)
@@@   |
@@@   RB3---X
@@@   |
@@@   Rb2
@@@   |
@@@   B

@@@ Now consider what if X is, possibly, a multicast listener for the
group in question or an IP multicast router, or neither, or both.
Exactly the same questions occur as to whether or not RB3, assuming it
is the only Rbridge on the link to X and thus DRB, sends IGMPs and/or
multicast data to X in native form after decapsulating it. (Since, other
than X, RB3 is shown as only connected to other Rbridges, it would never
get a native IGMP or multicast frame it could just forward to X in
native form, as well as encapsulating and sending to other Rbridges...)
@@@ The situation for X is, as far as I can see, exactly the same as it
was for assorted end stations/bridges inside the bridged LAN in your
diagram except that X can't get at stuff not sent to it even if it
understands TRILL frames which boxes inside the bridged LAN could be
haired up to understand TRILL frames, although that is not necessary.

@@@ For the above reasons, the only problem I see is the silent IP
multicast router. Everything else works fine and in the same way
regardless of whether or not one or more bridges and/or a bridge LAN are
involved.

With something like MMRP (a native 802.1
protocol), things are even worse.  Rb1 
would terminate any MMRPDUs (just as
it would STP BPDUs).

@@@ Sure. I assume MMRP is some form of GMRP made more complex to work
with MSTP. As I recall, GMRP is optional for 802.1 bridges. Is MMRP
mandatory? Anyway, I'm sure with enough work you could add almost any
additional bridge related protocols to Rbridges, but would it be worth
the effort?

We cannot says we are backwards compatible
with bridges just because we restrict traffic 
flow to a single symmetric tree within the trill 
network.  We are breaking compatibility in
other ways.  We need to be explicit about 
what compatibility we are trying to preserve.

@@@ I don't think "we restrict traffic flow to a single symmetric tree
within" and Rbridge network. But maybe we are interpreting something
differently.

@@@ Sure, feel free to suggest text clarifying this.

@@@ One assertion is that you can incrementally replace unconfigured
bridges with unconfigured Rbridges and the network will still operate
"correctly", although some topologies may be inefficient.

@@@ Generally speaking, the most efficient topologies in incremental
replacement is to maximally partition the remnant bridged LAN, splitting
it with Rbridges into pieces that are as small as possible.

Anoop

@@@ Thanks,
@@@ Donald

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 12:23 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> It seems to me that what you are saying is that the strategy 
> in TRILL of only sending IGMP/MLD to links that appear to 
> have IP multicast routers on them due to the detection of 
> PIM/MRD messages doesn't work. That, at least occasionally, 
> IGMP/MLD have to be flooded to every link just in case there 
> might be an IP multicast router on it that has been silent.
> 
> If that's a problem, it has nothing to do with bridges or 
> bridged LANs.
> All it takes to demonstrate the problem is a silent IP 
> multicast router point-to-point connected to an Rbridge 
> somewhere. If that IP multicast router has never send an PIM 
> or MRD message, then the Rbridge has no way of knowing to 
> send it IGMPs or MLDs (or multicast data traffic)...
> 
> Donald 
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 3:14 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> 
> And we now go full circle back to...
> 
> What if we a bridged LAN between 2 rbridges
> and there were no stations on this bridged LAN
> (other than the rbridges) that were interested
> in receiving that multicast?  You wouldn't
> see any of the control packet that you mention.
> The only control packets of that type would be
> the ones which were going between the rBridges and
> those would be trill encap'ed.  So the regular
> bridges between these rbridges wouldn't 
> understand them (for snooping).
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Wednesday, June 20, 2007 12:11 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Hi Anoop,
> > 
> > From two places. They should see native IGMP/MLD/PIM/MRD from 
> > end stations that are directly attached to them. And, to the 
> > extent that they let any surrounding Rbridges see any PIM/MRD 
> > messages, the Designated Rbridge will send IGMP/MLDs in 
> > native form into the bridged LAN. I should think this would 
> > give the bridges enough information to figure out how to do 
> > an optimized forwarding of IP derived multicast address traffic.
> > 
> > Donald 
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 2:53 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Donald,
> > 
> > So then the bridges in the LAN between the
> > 2 rbridges need some information to do their
> > pruning.   Where do they get it from?
> > 
> > Anoop 
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:16 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Hi Anoop,
> > > 
> > > No, it shouldn't get delivered to every end station unless it is 
> > > broadcast or a layer 2 multicast not derived from an IP address.
> > > 
> > > If it is an layer 2 multicast address derived from an IP 
> > address, then 
> > > Rbridges should prune the distribution tree and the links they 
> > > decapsulate and forward onto to those with listeners for an IP 
> > > multicast address that corresponds to that layer 2 
> > multicast address 
> > > or with an IP multicast router.
> > > 
> > > Donald
> > > 
> > > PS: All the above is scoped by VLAN as well.
> > > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:32 PM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [e-mail]; Caitlin Bestler
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Donald,
> > > 
> > > What if there are no IP multicast routers or listeners in 
> > the bridged 
> > > LAN between the rBridges?  Does that mean a copy of the 
> trill frame 
> > > gets delivered to every station in that LAN?
> > > 
> > > Anoop
> > > 
> > > > -----Original Message-----
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 12:51 PM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]; Caitlin Bestler
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > In addition to what Caitlin says, I would point out that,
> > > if there are
> > > > multicast listeners or IP multicast routers in this bridged
> > > LAN (which
> > > > looks to the Rbridges pretty much like a single 
> > multi-access link), 
> > > > then the Rbridges should have heard about them and the 
> Designated 
> > > > Rbridge for the VLAN in question for that cloud will also 
> > > > decapsulate
> > > appropriate
> > > > data/multicast-control and send it into the cloud as native
> > > > (non-TRILL)
> > > > frames whose distribution within the cloud the bridges are
> > > welcome to
> > > > try to optimize as much as they like.
> > > > 
> > > > Donald
> > > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Caitlin Bestler
> > > > Sent: Tuesday, June 19, 2007 3:16 PM
> > > > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > [e-mail] wrote:
> > > > > Eric,
> > > > > 
> > > > > It depends on what we mean by compatibility.
> > > > > One can always say that if one cares about such and such 
> > > > > compatibility then here's a way to solve it.
> > > > > 
> > > > > Even if trill were to impose the constraint you suggest, many 
> > > > > things will break.  For example, if I have a topology with a 
> > > > > bridged cloud between 2 trill devices, then the traffic going 
> > > > > between the trill devices will not be "snoopable" by 
> > the bridges 
> > > > > because they won't understand trill encapsulation.
> > > > > 
> > > > 
> > > > Why are these intermediate bridges snooping?
> > > > 
> > > > The only service being requested of them is to relay 
> > Ethernet frames 
> > > > from the ingress rbridge to the egress rbridge. Is that 
> > not implied 
> > > > by their being a cloud *between* 2 trill devices?
> > > > 
> > > > How is this different from any tunnel? You have traffic that a 
> > > > middlebox might have optimized had it been untunelled, 
> > but that it 
> > > > does not see when tunneled. It cannot provide its 
> > service, but it is 
> > > > not being asked to do so.
> > > > 
> > > > A non-rbridge bridge forwards packets without 
> understanding that 
> > > > they are rbridge encapsulated frames. I always thought 
> > that this was 
> > > > a strength of the proposal, not a weakness. You can't be 
> > snoopable 
> > > > and opaque. Opaque is better.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [e-mail]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > 
> > > 
> > 
> 



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KLtGxT000381 for <[e-mail]>; Wed, 20 Jun 2007 14:55:16 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 20 Jun 2007 14:55:16 -0700
X-IronPort-AV: i="4.16,444,1175497200";  d="scan'208"; a="11144766:sNHT21419041"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 3E2C623836C; Wed, 20 Jun 2007 14:52:53 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jun 2007 14:55:16 -0700
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, 20 Jun 2007 14:54:53 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSswAAJcTuA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 21:55:16.0175 (UTC) FILETIME=[AF9E2DF0:01C7B385]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KLtGxT000381
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 21:56:10 -0000
Status: RO
Content-Length: 9448

This thread was started because of the assertion
that the current rbridge proposal is "opaque" and
is completely compatible with bridges.

I pointed out that it breaks snooping once the
frames are trill encap'ed and this snooping is
required if you have 2 rbridges interconnected
by a regular LAN that doesn't have any end nodes
that are interested in seeing that multicast.

To which Donald responded saying that the DRB
for the bridged LAN would be sending a decap'ed
version of the control packets to the LAN 
anyway, and so snooping would continue to work.

I still don't think it works.  Consider
the following network.


  Multicast router
   |
   Rb1 (DRB for the LAN)
   |
 bridged LAN with 10 bridges and hosts
 in some random configuration
   |
   Rb2
   |
   B

In the above example, B is the only
participant in a multicast.  No one
on the intermediate LAN is interested
in receiving the multicast.

When B sends a join, it gets trill encap'ed
by Rb2 and forwarded to Rb1.  The bridges
in the LAN can't snoop that because they
don't understand the trill etype.

When multicast data are forwarded from Rb1
to Rb2 it is encap'ed as trill and sent
to the all-rbridges address.  The bridges
on the LAN (all 10 of them) will see this
frame and copy it to all stations on that
LAN.

That the bridges on the LAN see a 
decap'ed version of the Join doesn't
mean anything, because the multicast
traffic between the routers goes has the
all-rbridges address as the MAC DA.
In this way, we have broken "compatibility"
with bridges.

With something like MMRP (a native 802.1
protocol), things are even worse.  Rb1 
would terminate any MMRPDUs (just as
it would STP BPDUs).

We cannot says we are backwards compatible
with bridges just because we restrict traffic 
flow to a single symmetric tree within the trill 
network.  We are breaking compatibility in
other ways.  We need to be explicit about 
what compatibility we are trying to preserve.

Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 12:23 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> It seems to me that what you are saying is that the strategy 
> in TRILL of only sending IGMP/MLD to links that appear to 
> have IP multicast routers on them due to the detection of 
> PIM/MRD messages doesn't work. That, at least occasionally, 
> IGMP/MLD have to be flooded to every link just in case there 
> might be an IP multicast router on it that has been silent.
> 
> If that's a problem, it has nothing to do with bridges or 
> bridged LANs.
> All it takes to demonstrate the problem is a silent IP 
> multicast router point-to-point connected to an Rbridge 
> somewhere. If that IP multicast router has never send an PIM 
> or MRD message, then the Rbridge has no way of knowing to 
> send it IGMPs or MLDs (or multicast data traffic)...
> 
> Donald 
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 3:14 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> 
> And we now go full circle back to...
> 
> What if we a bridged LAN between 2 rbridges
> and there were no stations on this bridged LAN
> (other than the rbridges) that were interested
> in receiving that multicast?  You wouldn't
> see any of the control packet that you mention.
> The only control packets of that type would be
> the ones which were going between the rBridges and
> those would be trill encap'ed.  So the regular
> bridges between these rbridges wouldn't 
> understand them (for snooping).
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Wednesday, June 20, 2007 12:11 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Hi Anoop,
> > 
> > From two places. They should see native IGMP/MLD/PIM/MRD from 
> > end stations that are directly attached to them. And, to the 
> > extent that they let any surrounding Rbridges see any PIM/MRD 
> > messages, the Designated Rbridge will send IGMP/MLDs in 
> > native form into the bridged LAN. I should think this would 
> > give the bridges enough information to figure out how to do 
> > an optimized forwarding of IP derived multicast address traffic.
> > 
> > Donald 
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 2:53 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Donald,
> > 
> > So then the bridges in the LAN between the
> > 2 rbridges need some information to do their
> > pruning.   Where do they get it from?
> > 
> > Anoop 
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:16 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Hi Anoop,
> > > 
> > > No, it shouldn't get delivered to every end station unless it is 
> > > broadcast or a layer 2 multicast not derived from an IP address.
> > > 
> > > If it is an layer 2 multicast address derived from an IP 
> > address, then 
> > > Rbridges should prune the distribution tree and the links they 
> > > decapsulate and forward onto to those with listeners for an IP 
> > > multicast address that corresponds to that layer 2 
> > multicast address 
> > > or with an IP multicast router.
> > > 
> > > Donald
> > > 
> > > PS: All the above is scoped by VLAN as well.
> > > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:32 PM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [e-mail]; Caitlin Bestler
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Donald,
> > > 
> > > What if there are no IP multicast routers or listeners in 
> > the bridged 
> > > LAN between the rBridges?  Does that mean a copy of the 
> trill frame 
> > > gets delivered to every station in that LAN?
> > > 
> > > Anoop
> > > 
> > > > -----Original Message-----
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 12:51 PM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]; Caitlin Bestler
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > In addition to what Caitlin says, I would point out that,
> > > if there are
> > > > multicast listeners or IP multicast routers in this bridged
> > > LAN (which
> > > > looks to the Rbridges pretty much like a single 
> > multi-access link), 
> > > > then the Rbridges should have heard about them and the 
> Designated 
> > > > Rbridge for the VLAN in question for that cloud will also 
> > > > decapsulate
> > > appropriate
> > > > data/multicast-control and send it into the cloud as native
> > > > (non-TRILL)
> > > > frames whose distribution within the cloud the bridges are
> > > welcome to
> > > > try to optimize as much as they like.
> > > > 
> > > > Donald
> > > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Caitlin Bestler
> > > > Sent: Tuesday, June 19, 2007 3:16 PM
> > > > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > [e-mail] wrote:
> > > > > Eric,
> > > > > 
> > > > > It depends on what we mean by compatibility.
> > > > > One can always say that if one cares about such and such 
> > > > > compatibility then here's a way to solve it.
> > > > > 
> > > > > Even if trill were to impose the constraint you suggest, many 
> > > > > things will break.  For example, if I have a topology with a 
> > > > > bridged cloud between 2 trill devices, then the traffic going 
> > > > > between the trill devices will not be "snoopable" by 
> > the bridges 
> > > > > because they won't understand trill encapsulation.
> > > > > 
> > > > 
> > > > Why are these intermediate bridges snooping?
> > > > 
> > > > The only service being requested of them is to relay 
> > Ethernet frames 
> > > > from the ingress rbridge to the egress rbridge. Is that 
> > not implied 
> > > > by their being a cloud *between* 2 trill devices?
> > > > 
> > > > How is this different from any tunnel? You have traffic that a 
> > > > middlebox might have optimized had it been untunelled, 
> > but that it 
> > > > does not see when tunneled. It cannot provide its 
> > service, but it is 
> > > > not being asked to do so.
> > > > 
> > > > A non-rbridge bridge forwards packets without 
> understanding that 
> > > > they are rbridge encapsulated frames. I always thought 
> > that this was 
> > > > a strength of the proposal, not a weakness. You can't be 
> > snoopable 
> > > > and opaque. Opaque is better.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [e-mail]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > 
> > > 
> > 
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KKkVcV011911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 20 Jun 2007 13:46:32 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5KKnatt015421; Wed, 20 Jun 2007 15:49:36 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 20 Jun 2007 15:46:28 -0500
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, 20 Jun 2007 15:46:26 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIAAI8kMwAAHz+XAAAj/GYAAAbLpA
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 20:46:28.0276 (UTC) FILETIME=[1332C740:01C7B37C]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KKkVcV011911
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 20:47:03 -0000
Status: RO
Content-Length: 13647

Anoop,

	Apparently, our mail crossed.  I had already replied on this 
comment prior to receiving your mail.

	To repeat, what I felt we had no consensus on was the notion
that ECMP only occurs in "core" RBridges.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 4:33 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> We need to convince Eric that we have
> consensus.  He doesn't seem to think so.
> 
> Anoop
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Wednesday, June 20, 2007 12:37 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > What exactly do you think we need to do and to get consensus on?
> > 
> > I think it is clear enough from the draft that an ingress 
> Rbridge can
> > multipath multidestination traffic by selecting different 
> > tree roots for
> > different frames. So the only question is unicast. Other than a few
> > words saying that don't have to always send unicast traffic 
> on the one
> > path selected by the tie breaker rule, but MAY multipath, 
> what more is
> > needed?
> > 
> > Presumably the tricky thing is how best to determine flows, 
> > where frames
> > in a flow would follow only one of the multiple paths, except during
> > transients. I don't think the TRILL WG should get into 
> > defining flows...
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On
> > Behalf Of Anoop Ghanwani
> > Sent: Wednesday, June 20, 2007 2:43 PM
> > To: Eric Gray (LO/EUS); Silvano Gai
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > Personally, I would like the group to get to a
> > consensus on the ECMP issue fairly quickly.
> > 
> > I too, just like Silvano, thought it was going
> > to be done.
> > 
> > Anoop 
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> > > Sent: Wednesday, June 20, 2007 7:29 AM
> > > To: Silvano Gai; Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Silvano,
> > > 
> > > 	Yes, that was probably discussed earlier in May.
> > > 
> > > 	AFAIK, discussion != consensus.
> > > 
> > > 	Possibly your customers need to explain to you that the 
> > > difference between "core" and "not core" is not always as 
> > > clear cut as you apparently think it is.  Nor is it 
> > > necessarily going to be simple for a device to determine 
> > > which of the available equal cost paths only contain core 
> elements.
> > > 
> > > 	Also, ECMP - at least in the traditional sense - takes 
> > > place where equal costs exist in a "routing" domain.  That is 
> > > at least as likely to occur in locii containing one or more 
> > > edge components, as it is anywhere else.
> > > 
> > > 	There are certainly limited applications - typically 
> > > requiring careful configuration to restrict ECMP-like 
> > > activity to very specifically defined equal cost paths - 
> > > where it will be possible to say "we do ECMP only in the 
> > > core."  I personally wonder why link-bundling wouldn't be a 
> > > better solution in those cases, however.
> > > 
> > > Thanks!
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson  
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 11:39 PM
> > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > > 
> > > > We had this discussion on May 8th, 2007 on this mailing list.
> > > > 
> > > > In a nutshell: we do ECMP only in the core, but we don't 
> > > learn in the 
> > > > core, so I don't see the problem.
> > > > 
> > > > -- Silvano
> > > > 
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Tuesday, June 19, 2007 7:14 AM
> > > > > To: Silvano Gai; Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > 
> > > > > Silvano,
> > > > > 
> > > > > 	Your response is confusing.  If we are not 
> > expected to preserve 
> > > > > forwarding symmetry, have we given up on presumed 
> > > compatibility with 
> > > > > standard bridges?
> > > > > 
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > Importance: High
> > > > > >
> > > > > >
> > > > > > Eric,
> > > > > >
> > > > > > You say: "we're expected to preserve forwarding symmetry".
> > > > > >
> > > > > > WE ARE NOT.
> > > > > >
> > > > > > Where does the current draft preserve forwarding symmetry?
> > > > > >
> > > > > > In regard to your conclusions, many of us (Anoop , Dinesh
> > > > and I for
> > > > > > sure) are participating because we are building 
> real products.
> > > > > >
> > > > > > I don't buy your argument that "Very uninteresting
> > > > > > (technology) is very
> > > > > > good."
> > > > > >
> > > > > > -- Silvano
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > [mailto:[e-mail]]
> > > > > > On
> > > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > > > >
> > > > > > > Anoop,
> > > > > > >
> > > > > > > 	I think we strongly disagree on what it means
> > > > to incorporate
> > > > > > > something in the control protocol.  From there, it is
> > > > likely that
> > > > > > > we also disagree on how best to avoid doing so.
> > > > > > >
> > > > > > > 	Figuring out how to correctly carry
> > > > IGMP-snooped information
> > > > > > > in TRILL protocol is effectively the same thing as 
> > > incorporating 
> > > > > > > IGMP in the control protocol.
> > > > > > >
> > > > > > > 	Making a list of everything that bridges snoop
> > > > and ensuring
> > > > > > > we can also include that information in IS-IS is
> > > > exactly the sort
> > > > > > > of thing we should be trying to avoid.  The good news 
> > > is that it 
> > > > > > > also should be easy to avoid.
> > > > > > >
> > > > > > > 	Whatever protocols we might use, TRILL is
> > > > essentially a layer
> > > > > > > two forwarding technology.  The messages that layer two
> > > > forwarding
> > > > > > > technologies want to snoop are visible to the devices
> > > > involved in
> > > > > > > forwarding.  Unless devices actively interfere with
> > > > "normal" layer
> > > > > > > two forwarding, "external" control messages should be
> > > > no different
> > > > > > > than any other form of data - as far as RBridges are 
> > > concerned - 
> > > > > > > and should be forwarded in the same way.
> > > > > > >
> > > > > > > 	We know that we're expected to preserve
> > > > forwarding symmetry
> > > > > > > - at least for the layer two encapsulation of TRILL
> > > > frames. In the
> > > > > > > same way, and for similar reasons, we may need to 
> > > preserve path 
> > > > > > > congruency.  This is implicit in the decision to 
> > > learn from data 
> > > > > > > in the unicast case.
> > > > > > >
> > > > > > > 	What we don't know is the complete list of
> > > > things that depend
> > > > > > > on our doing that.  But we can compose a partial 
> > list, and it
> > > > seems
> > > > > > > to me that "snooping" (in general) is one example, 
> > > OA&M may well
> > > > be
> > > > > > > another and there are bound to be more.
> > > > > > >
> > > > > > > 	As for the notion of "crippling the technology
> > > > and making it
> > > > > > > very uninteresting" - well, to many people, 
> > technology becomes
> > > > very
> > > > > > > interesting when it is very complicated to make it
> > > > work.  For the
> > > > > > > users of any technology, it is only truly useful when 
> > > it is not
> > > > very
> > > > > > > interesting.
> > > > > > >
> > > > > > > 	Paraphrasing something a colleague once told
> > > > me: a technology
> > > > > > > is only really useful when the interesting thing in 
> > > using it is
> > > > not
> > > > > > > about the technology, but about its use.  Put 
> > another way, you
> > > > know
> > > > > > > that transportation is useful when the interesting 
> > thing about
> > > > using
> > > > > > > it is arriving at the destination - rather than the 
> > > trip itself.
> > > > > > >
> > > > > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > > > > >
> > > > > > > --
> > > > > > > Eric Gray
> > > > > > > Principal Engineer
> > > > > > > Ericsson
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > > > > To: Eric Gray (LO/EUS)
> > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > > Importance: High
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Eric Gray (LO/EUS) 
> [mailto:[e-mail]]
> > > > > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > > > > To: Anoop Ghanwani
> > > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > > >
> > > > > > > > > Anoop,
> > > > > > > > >
> > > > > > > > > 	I tend to view your response below as yet 
> > > another reason 
> > > > > > > > > why RBridges MUST use a common path for unicast and 
> > > > > > > > > multicast (as well as broadcast and flooded) 
> > traffic.  In 
> > > > > > > > > fact, it is a very good reason to limit use of
> > > > "multipathing"
> > > > > > > > > in general.
> > > > > > > >
> > > > > > > > If we do place those constraints then it would 
> > cripple the 
> > > > > > > > technology and make it very uninteresting (at 
> > least to me).
> > > > > > > >
> > > > > > > > > 	It is not clear exactly what you mean by your 
> > > reference to 
> > > > > > > > > differences between control and data paths.  Control 
> > > > > > > > > messages are from one RBridge to another and - 
> > > presumably - 
> > > > > > > > > follow the same path as data addressed from 
> RBridge to 
> > > > > > > > > RBridge.  That path may be different from data
> > > > transitting an
> > > > > > > > > RBridge campus, but there is no RBridge 
> > "control" traffic 
> > > > > > > > > that transits a campus.
> > > > > > > > >
> > > > > > > > > 	Are you suggesting that IGMP should be treated 
> > > as a control 
> > > > > > > > > protocol within TRILL?
> > > > > > > >
> > > > > > > > In this case, when I said control I meant IGMP 
> > > (since that is 
> > > > > > > > what is being used to effect pruning).  If we 
> > snoop on the 
> > > > > > > > information at the edge of the trill cloud and 
> pass this 
> > > > > > > > information around in IS-IS, then we don't need to 
> > > worry about 
> > > > > > > > treating it as a separate control protocol.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 	Nor is it very clear why this observation is 
> > > specific to 
> > > > > > > > > our discussion of multicast optimization.  As 
> a general 
> > > > > > > > > rule, if there is one reasonably well know 
> > > application that 
> > > > > > > > > relies on path congruency for proper operation, 
> > there are 
> > > > > > > > > probably others.
> > > > > > > > >
> > > > > > > > > 	Do you think we should provide a logical 
> > > control-function 
> > > > > > > > > "bridging" service for all such
> > > > applications
> > > > > > > > > as a result of path divergences we introduce?  
> > Should we 
> > > > > > > > > conduct a research project to determine what 
> > > other "control 
> > > > > > > > > protocols" we need to include in TRILL?
> > > > > > > >
> > > > > > > > We would need to make a list of everything that 
> > > bridges snoop 
> > > > > > > > on and make sure we have ways of sending that 
> > > around in IS-IS 
> > > > > > > > (if we care about those functions).
> > > > > > > > I'm not aware of anything other than IGMP that 
> > trill would 
> > > > > > > > need to worry about, though.
> > > > > > > >
> > > > > > > > Anoop
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rbridge mailing list
> > > > > > > [e-mail]
> > > > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > > >
> > > > 
> > > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KKXgFJ008214 for <[e-mail]>; Wed, 20 Jun 2007 13:33:42 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 20 Jun 2007 13:33:42 -0700
X-IronPort-AV: i="4.16,444,1175497200";  d="scan'208"; a="11143526:sNHT22469286"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 6226A23836C; Wed, 20 Jun 2007 13:31:19 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jun 2007 13:33:42 -0700
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, 20 Jun 2007 13:33:19 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIAAI8kMwAAHz+XAAAj/GYA==
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 20:33:42.0511 (UTC) FILETIME=[4AC44FF0:01C7B37A]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KKXgFJ008214
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 20:34:02 -0000
Status: RO
Content-Length: 12209

We need to convince Eric that we have
consensus.  He doesn't seem to think so.

Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 12:37 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> What exactly do you think we need to do and to get consensus on?
> 
> I think it is clear enough from the draft that an ingress Rbridge can
> multipath multidestination traffic by selecting different 
> tree roots for
> different frames. So the only question is unicast. Other than a few
> words saying that don't have to always send unicast traffic on the one
> path selected by the tie breaker rule, but MAY multipath, what more is
> needed?
> 
> Presumably the tricky thing is how best to determine flows, 
> where frames
> in a flow would follow only one of the multiple paths, except during
> transients. I don't think the TRILL WG should get into 
> defining flows...
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 2:43 PM
> To: Eric Gray (LO/EUS); Silvano Gai
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Personally, I would like the group to get to a
> consensus on the ECMP issue fairly quickly.
> 
> I too, just like Silvano, thought it was going
> to be done.
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> > Sent: Wednesday, June 20, 2007 7:29 AM
> > To: Silvano Gai; Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Silvano,
> > 
> > 	Yes, that was probably discussed earlier in May.
> > 
> > 	AFAIK, discussion != consensus.
> > 
> > 	Possibly your customers need to explain to you that the 
> > difference between "core" and "not core" is not always as 
> > clear cut as you apparently think it is.  Nor is it 
> > necessarily going to be simple for a device to determine 
> > which of the available equal cost paths only contain core elements.
> > 
> > 	Also, ECMP - at least in the traditional sense - takes 
> > place where equal costs exist in a "routing" domain.  That is 
> > at least as likely to occur in locii containing one or more 
> > edge components, as it is anywhere else.
> > 
> > 	There are certainly limited applications - typically 
> > requiring careful configuration to restrict ECMP-like 
> > activity to very specifically defined equal cost paths - 
> > where it will be possible to say "we do ECMP only in the 
> > core."  I personally wonder why link-bundling wouldn't be a 
> > better solution in those cases, however.
> > 
> > Thanks!
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 11:39 PM
> > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > > 
> > > We had this discussion on May 8th, 2007 on this mailing list.
> > > 
> > > In a nutshell: we do ECMP only in the core, but we don't 
> > learn in the 
> > > core, so I don't see the problem.
> > > 
> > > -- Silvano
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 7:14 AM
> > > > To: Silvano Gai; Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > Silvano,
> > > > 
> > > > 	Your response is confusing.  If we are not 
> expected to preserve 
> > > > forwarding symmetry, have we given up on presumed 
> > compatibility with 
> > > > standard bridges?
> > > > 
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > > 
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[e-mail]]
> > > > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > Importance: High
> > > > >
> > > > >
> > > > > Eric,
> > > > >
> > > > > You say: "we're expected to preserve forwarding symmetry".
> > > > >
> > > > > WE ARE NOT.
> > > > >
> > > > > Where does the current draft preserve forwarding symmetry?
> > > > >
> > > > > In regard to your conclusions, many of us (Anoop , Dinesh
> > > and I for
> > > > > sure) are participating because we are building real products.
> > > > >
> > > > > I don't buy your argument that "Very uninteresting
> > > > > (technology) is very
> > > > > good."
> > > > >
> > > > > -- Silvano
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > > > On
> > > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > > >
> > > > > > Anoop,
> > > > > >
> > > > > > 	I think we strongly disagree on what it means
> > > to incorporate
> > > > > > something in the control protocol.  From there, it is
> > > likely that
> > > > > > we also disagree on how best to avoid doing so.
> > > > > >
> > > > > > 	Figuring out how to correctly carry
> > > IGMP-snooped information
> > > > > > in TRILL protocol is effectively the same thing as 
> > incorporating 
> > > > > > IGMP in the control protocol.
> > > > > >
> > > > > > 	Making a list of everything that bridges snoop
> > > and ensuring
> > > > > > we can also include that information in IS-IS is
> > > exactly the sort
> > > > > > of thing we should be trying to avoid.  The good news 
> > is that it 
> > > > > > also should be easy to avoid.
> > > > > >
> > > > > > 	Whatever protocols we might use, TRILL is
> > > essentially a layer
> > > > > > two forwarding technology.  The messages that layer two
> > > forwarding
> > > > > > technologies want to snoop are visible to the devices
> > > involved in
> > > > > > forwarding.  Unless devices actively interfere with
> > > "normal" layer
> > > > > > two forwarding, "external" control messages should be
> > > no different
> > > > > > than any other form of data - as far as RBridges are 
> > concerned - 
> > > > > > and should be forwarded in the same way.
> > > > > >
> > > > > > 	We know that we're expected to preserve
> > > forwarding symmetry
> > > > > > - at least for the layer two encapsulation of TRILL
> > > frames. In the
> > > > > > same way, and for similar reasons, we may need to 
> > preserve path 
> > > > > > congruency.  This is implicit in the decision to 
> > learn from data 
> > > > > > in the unicast case.
> > > > > >
> > > > > > 	What we don't know is the complete list of
> > > things that depend
> > > > > > on our doing that.  But we can compose a partial 
> list, and it
> > > seems
> > > > > > to me that "snooping" (in general) is one example, 
> > OA&M may well
> > > be
> > > > > > another and there are bound to be more.
> > > > > >
> > > > > > 	As for the notion of "crippling the technology
> > > and making it
> > > > > > very uninteresting" - well, to many people, 
> technology becomes
> > > very
> > > > > > interesting when it is very complicated to make it
> > > work.  For the
> > > > > > users of any technology, it is only truly useful when 
> > it is not
> > > very
> > > > > > interesting.
> > > > > >
> > > > > > 	Paraphrasing something a colleague once told
> > > me: a technology
> > > > > > is only really useful when the interesting thing in 
> > using it is
> > > not
> > > > > > about the technology, but about its use.  Put 
> another way, you
> > > know
> > > > > > that transportation is useful when the interesting 
> thing about
> > > using
> > > > > > it is arriving at the destination - rather than the 
> > trip itself.
> > > > > >
> > > > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > > > To: Eric Gray (LO/EUS)
> > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > Importance: High
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > > > To: Anoop Ghanwani
> > > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > > >
> > > > > > > > Anoop,
> > > > > > > >
> > > > > > > > 	I tend to view your response below as yet 
> > another reason 
> > > > > > > > why RBridges MUST use a common path for unicast and 
> > > > > > > > multicast (as well as broadcast and flooded) 
> traffic.  In 
> > > > > > > > fact, it is a very good reason to limit use of
> > > "multipathing"
> > > > > > > > in general.
> > > > > > >
> > > > > > > If we do place those constraints then it would 
> cripple the 
> > > > > > > technology and make it very uninteresting (at 
> least to me).
> > > > > > >
> > > > > > > > 	It is not clear exactly what you mean by your 
> > reference to 
> > > > > > > > differences between control and data paths.  Control 
> > > > > > > > messages are from one RBridge to another and - 
> > presumably - 
> > > > > > > > follow the same path as data addressed from RBridge to 
> > > > > > > > RBridge.  That path may be different from data
> > > transitting an
> > > > > > > > RBridge campus, but there is no RBridge 
> "control" traffic 
> > > > > > > > that transits a campus.
> > > > > > > >
> > > > > > > > 	Are you suggesting that IGMP should be treated 
> > as a control 
> > > > > > > > protocol within TRILL?
> > > > > > >
> > > > > > > In this case, when I said control I meant IGMP 
> > (since that is 
> > > > > > > what is being used to effect pruning).  If we 
> snoop on the 
> > > > > > > information at the edge of the trill cloud and pass this 
> > > > > > > information around in IS-IS, then we don't need to 
> > worry about 
> > > > > > > treating it as a separate control protocol.
> > > > > > >
> > > > > > > >
> > > > > > > > 	Nor is it very clear why this observation is 
> > specific to 
> > > > > > > > our discussion of multicast optimization.  As a general 
> > > > > > > > rule, if there is one reasonably well know 
> > application that 
> > > > > > > > relies on path congruency for proper operation, 
> there are 
> > > > > > > > probably others.
> > > > > > > >
> > > > > > > > 	Do you think we should provide a logical 
> > control-function 
> > > > > > > > "bridging" service for all such
> > > applications
> > > > > > > > as a result of path divergences we introduce?  
> Should we 
> > > > > > > > conduct a research project to determine what 
> > other "control 
> > > > > > > > protocols" we need to include in TRILL?
> > > > > > >
> > > > > > > We would need to make a list of everything that 
> > bridges snoop 
> > > > > > > on and make sure we have ways of sending that 
> > around in IS-IS 
> > > > > > > (if we care about those functions).
> > > > > > > I'm not aware of anything other than IGMP that 
> trill would 
> > > > > > > need to worry about, though.
> > > > > > >
> > > > > > > Anoop
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rbridge mailing list
> > > > > > [e-mail]
> > > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > >
> > > 
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KKLmpj004897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 20 Jun 2007 13:21:48 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5KKOsfX010144; Wed, 20 Jun 2007 15:24:54 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 20 Jun 2007 15:21:46 -0500
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, 20 Jun 2007 15:21:44 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcezdYBrKA6bvaYlTqq6vdzqAVBznQAAgCnQ
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 20:21:46.0367 (UTC) FILETIME=[9FE968F0:01C7B378]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KKLmpj004897
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 20:22:00 -0000
Status: RO
Content-Length: 3190

Radia, et al,

	I was not challenging consensus on multi-pathing, for either
unicast or multicast.  What I was objecting to was the assertion
that we ONLY do ECMP in "core" RBridges - which Silvano had stated
as if a WG decision.  Since I seriously doubt that we could ever
arrive at a consensus as to exactly what sort of real-world device
would be a "core" RBridge, I don't think we have concluded that we
ONLY do <anything you choose to talk about> in such a beasty.

	See Silvano's original comments toward the very end of this
(snipped) message.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 4:00 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); Silvano Gai; [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> I'm also assuming we are doing multipathing, not just of unicast, but 
> also multicast.
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> > Personally, I would like the group to get to a
> > consensus on the ECMP issue fairly quickly.
> >
> > I too, just like Silvano, thought it was going
> > to be done.
> >
> > Anoop 
> >
> >   
> >> -----Original Message-----
> >> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> >> Sent: Wednesday, June 20, 2007 7:29 AM
> >> To: Silvano Gai; Anoop Ghanwani
> >> Cc: [e-mail]; Radia Perlman
> >> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>
> >> Silvano,
> >>
> >> 	Yes, that was probably discussed earlier in May.
> >>
> >> 	AFAIK, discussion != consensus.
> >>
> >> 	Possibly your customers need to explain to you that the 
> >> difference between "core" and "not core" is not always as 
> >> clear cut as you apparently think it is.  Nor is it 
> >> necessarily going to be simple for a device to determine 
> >> which of the available equal cost paths only contain core elements.
> >>
> >> 	Also, ECMP - at least in the traditional sense - takes 
> >> place where equal costs exist in a "routing" domain.  That is 
> >> at least as likely to occur in locii containing one or more 
> >> edge components, as it is anywhere else.
> >>
> >> 	There are certainly limited applications - typically 
> >> requiring careful configuration to restrict ECMP-like 
> >> activity to very specifically defined equal cost paths - 
> >> where it will be possible to say "we do ECMP only in the 
> >> core."  I personally wonder why link-bundling wouldn't be a 
> >> better solution in those cases, however.
> >>
> >> Thanks!
> >>
> >> --
> >> Eric Gray
> >> Principal Engineer
> >> Ericsson  
> >>
> >>     
> >>> -----Original Message-----
> >>> From: Silvano Gai [mailto:[e-mail]]
> >>> Sent: Tuesday, June 19, 2007 11:39 PM
> >>> To: Eric Gray (LO/EUS); Anoop Ghanwani
> >>> Cc: [e-mail]; Radia Perlman
> >>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >>> Importance: High
> >>>
> >>> We had this discussion on May 8th, 2007 on this mailing list.
> >>>
> >>> In a nutshell: we do ECMP only in the core, but we don't 
> >>>       
> >> learn in the 
> >>     
> >>> core, so I don't see the problem.
> >>>
> >>> -- Silvano
--- SNIP ---



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 l5KJxFNp028286 for <[e-mail]>; Wed, 20 Jun 2007 12:59:15 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 20 Jun 2007 12:59:15 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.17.136]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 20 Jun 2007 12:59:15 -0700 (PDT)
Date: Wed, 20 Jun 2007 12:59:56 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:59:39 -0000
Status: RO
Content-Length: 11427

I'm also assuming we are doing multipathing, not just of unicast, but 
also multicast.

Radia


Anoop Ghanwani wrote:
> Personally, I would like the group to get to a
> consensus on the ECMP issue fairly quickly.
>
> I too, just like Silvano, thought it was going
> to be done.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
>> Sent: Wednesday, June 20, 2007 7:29 AM
>> To: Silvano Gai; Anoop Ghanwani
>> Cc: [e-mail]; Radia Perlman
>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>
>> Silvano,
>>
>> 	Yes, that was probably discussed earlier in May.
>>
>> 	AFAIK, discussion != consensus.
>>
>> 	Possibly your customers need to explain to you that the 
>> difference between "core" and "not core" is not always as 
>> clear cut as you apparently think it is.  Nor is it 
>> necessarily going to be simple for a device to determine 
>> which of the available equal cost paths only contain core elements.
>>
>> 	Also, ECMP - at least in the traditional sense - takes 
>> place where equal costs exist in a "routing" domain.  That is 
>> at least as likely to occur in locii containing one or more 
>> edge components, as it is anywhere else.
>>
>> 	There are certainly limited applications - typically 
>> requiring careful configuration to restrict ECMP-like 
>> activity to very specifically defined equal cost paths - 
>> where it will be possible to say "we do ECMP only in the 
>> core."  I personally wonder why link-bundling wouldn't be a 
>> better solution in those cases, however.
>>
>> Thanks!
>>
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson  
>>
>>     
>>> -----Original Message-----
>>> From: Silvano Gai [mailto:[e-mail]]
>>> Sent: Tuesday, June 19, 2007 11:39 PM
>>> To: Eric Gray (LO/EUS); Anoop Ghanwani
>>> Cc: [e-mail]; Radia Perlman
>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>> Importance: High
>>>
>>> We had this discussion on May 8th, 2007 on this mailing list.
>>>
>>> In a nutshell: we do ECMP only in the core, but we don't 
>>>       
>> learn in the 
>>     
>>> core, so I don't see the problem.
>>>
>>> -- Silvano
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
>>>> Sent: Tuesday, June 19, 2007 7:14 AM
>>>> To: Silvano Gai; Anoop Ghanwani
>>>> Cc: [e-mail]; Radia Perlman
>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>
>>>> Silvano,
>>>>
>>>> 	Your response is confusing.  If we are not expected to preserve 
>>>> forwarding symmetry, have we given up on presumed 
>>>>         
>> compatibility with 
>>     
>>>> standard bridges?
>>>>
>>>> --
>>>> Eric Gray
>>>> Principal Engineer
>>>> Ericsson
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Silvano Gai [mailto:[e-mail]]
>>>>> Sent: Tuesday, June 19, 2007 9:13 AM
>>>>> To: Eric Gray (LO/EUS); Anoop Ghanwani
>>>>> Cc: [e-mail]; Radia Perlman
>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>> Importance: High
>>>>>
>>>>>
>>>>> Eric,
>>>>>
>>>>> You say: "we're expected to preserve forwarding symmetry".
>>>>>
>>>>> WE ARE NOT.
>>>>>
>>>>> Where does the current draft preserve forwarding symmetry?
>>>>>
>>>>> In regard to your conclusions, many of us (Anoop , Dinesh
>>>>>           
>>> and I for
>>>       
>>>>> sure) are participating because we are building real products.
>>>>>
>>>>> I don't buy your argument that "Very uninteresting
>>>>> (technology) is very
>>>>> good."
>>>>>
>>>>> -- Silvano
>>>>>
>>>>>           
>>>>>> -----Original Message-----
>>>>>> From: [e-mail]
>>>>>>             
>>> [mailto:[e-mail]]
>>>       
>>>>> On
>>>>>           
>>>>>> Behalf Of Eric Gray (LO/EUS)
>>>>>> Sent: Tuesday, June 19, 2007 5:27 AM
>>>>>> To: Anoop Ghanwani
>>>>>> Cc: [e-mail]; Radia Perlman
>>>>>> Subject: Re: [rbridge] per-VLAN instances of IS-IS
>>>>>>
>>>>>> Anoop,
>>>>>>
>>>>>> 	I think we strongly disagree on what it means
>>>>>>             
>>> to incorporate
>>>       
>>>>>> something in the control protocol.  From there, it is
>>>>>>             
>>> likely that
>>>       
>>>>>> we also disagree on how best to avoid doing so.
>>>>>>
>>>>>> 	Figuring out how to correctly carry
>>>>>>             
>>> IGMP-snooped information
>>>       
>>>>>> in TRILL protocol is effectively the same thing as 
>>>>>>             
>> incorporating 
>>     
>>>>>> IGMP in the control protocol.
>>>>>>
>>>>>> 	Making a list of everything that bridges snoop
>>>>>>             
>>> and ensuring
>>>       
>>>>>> we can also include that information in IS-IS is
>>>>>>             
>>> exactly the sort
>>>       
>>>>>> of thing we should be trying to avoid.  The good news 
>>>>>>             
>> is that it 
>>     
>>>>>> also should be easy to avoid.
>>>>>>
>>>>>> 	Whatever protocols we might use, TRILL is
>>>>>>             
>>> essentially a layer
>>>       
>>>>>> two forwarding technology.  The messages that layer two
>>>>>>             
>>> forwarding
>>>       
>>>>>> technologies want to snoop are visible to the devices
>>>>>>             
>>> involved in
>>>       
>>>>>> forwarding.  Unless devices actively interfere with
>>>>>>             
>>> "normal" layer
>>>       
>>>>>> two forwarding, "external" control messages should be
>>>>>>             
>>> no different
>>>       
>>>>>> than any other form of data - as far as RBridges are 
>>>>>>             
>> concerned - 
>>     
>>>>>> and should be forwarded in the same way.
>>>>>>
>>>>>> 	We know that we're expected to preserve
>>>>>>             
>>> forwarding symmetry
>>>       
>>>>>> - at least for the layer two encapsulation of TRILL
>>>>>>             
>>> frames. In the
>>>       
>>>>>> same way, and for similar reasons, we may need to 
>>>>>>             
>> preserve path 
>>     
>>>>>> congruency.  This is implicit in the decision to 
>>>>>>             
>> learn from data 
>>     
>>>>>> in the unicast case.
>>>>>>
>>>>>> 	What we don't know is the complete list of
>>>>>>             
>>> things that depend
>>>       
>>>>>> on our doing that.  But we can compose a partial list, and it
>>>>>>             
>>> seems
>>>       
>>>>>> to me that "snooping" (in general) is one example, 
>>>>>>             
>> OA&M may well
>>     
>>> be
>>>       
>>>>>> another and there are bound to be more.
>>>>>>
>>>>>> 	As for the notion of "crippling the technology
>>>>>>             
>>> and making it
>>>       
>>>>>> very uninteresting" - well, to many people, technology becomes
>>>>>>             
>>> very
>>>       
>>>>>> interesting when it is very complicated to make it
>>>>>>             
>>> work.  For the
>>>       
>>>>>> users of any technology, it is only truly useful when 
>>>>>>             
>> it is not
>>     
>>> very
>>>       
>>>>>> interesting.
>>>>>>
>>>>>> 	Paraphrasing something a colleague once told
>>>>>>             
>>> me: a technology
>>>       
>>>>>> is only really useful when the interesting thing in 
>>>>>>             
>> using it is
>>     
>>> not
>>>       
>>>>>> about the technology, but about its use.  Put another way, you
>>>>>>             
>>> know
>>>       
>>>>>> that transportation is useful when the interesting thing about
>>>>>>             
>>> using
>>>       
>>>>>> it is arriving at the destination - rather than the 
>>>>>>             
>> trip itself.
>>     
>>>>>> 	Uninteresting is good.  Very uninteresting is very good.
>>>>>>
>>>>>> --
>>>>>> Eric Gray
>>>>>> Principal Engineer
>>>>>> Ericsson
>>>>>>
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: Anoop Ghanwani [mailto:[e-mail]]
>>>>>>> Sent: Monday, June 18, 2007 7:08 PM
>>>>>>> To: Eric Gray (LO/EUS)
>>>>>>> Cc: [e-mail]; Radia Perlman
>>>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>>>> Importance: High
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> -----Original Message-----
>>>>>>>> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
>>>>>>>> Sent: Monday, June 18, 2007 11:43 AM
>>>>>>>> To: Anoop Ghanwani
>>>>>>>> Cc: [e-mail]; Radia Perlman
>>>>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>>>>>
>>>>>>>> Anoop,
>>>>>>>>
>>>>>>>> 	I tend to view your response below as yet 
>>>>>>>>                 
>> another reason 
>>     
>>>>>>>> why RBridges MUST use a common path for unicast and 
>>>>>>>> multicast (as well as broadcast and flooded) traffic.  In 
>>>>>>>> fact, it is a very good reason to limit use of
>>>>>>>>                 
>>> "multipathing"
>>>       
>>>>>>>> in general.
>>>>>>>>                 
>>>>>>> If we do place those constraints then it would cripple the 
>>>>>>> technology and make it very uninteresting (at least to me).
>>>>>>>
>>>>>>>               
>>>>>>>> 	It is not clear exactly what you mean by your 
>>>>>>>>                 
>> reference to 
>>     
>>>>>>>> differences between control and data paths.  Control 
>>>>>>>> messages are from one RBridge to another and - 
>>>>>>>>                 
>> presumably - 
>>     
>>>>>>>> follow the same path as data addressed from RBridge to 
>>>>>>>> RBridge.  That path may be different from data
>>>>>>>>                 
>>> transitting an
>>>       
>>>>>>>> RBridge campus, but there is no RBridge "control" traffic 
>>>>>>>> that transits a campus.
>>>>>>>>
>>>>>>>> 	Are you suggesting that IGMP should be treated 
>>>>>>>>                 
>> as a control 
>>     
>>>>>>>> protocol within TRILL?
>>>>>>>>                 
>>>>>>> In this case, when I said control I meant IGMP 
>>>>>>>               
>> (since that is 
>>     
>>>>>>> what is being used to effect pruning).  If we snoop on the 
>>>>>>> information at the edge of the trill cloud and pass this 
>>>>>>> information around in IS-IS, then we don't need to 
>>>>>>>               
>> worry about 
>>     
>>>>>>> treating it as a separate control protocol.
>>>>>>>
>>>>>>>               
>>>>>>>> 	Nor is it very clear why this observation is 
>>>>>>>>                 
>> specific to 
>>     
>>>>>>>> our discussion of multicast optimization.  As a general 
>>>>>>>> rule, if there is one reasonably well know 
>>>>>>>>                 
>> application that 
>>     
>>>>>>>> relies on path congruency for proper operation, there are 
>>>>>>>> probably others.
>>>>>>>>
>>>>>>>> 	Do you think we should provide a logical 
>>>>>>>>                 
>> control-function 
>>     
>>>>>>>> "bridging" service for all such
>>>>>>>>                 
>>> applications
>>>       
>>>>>>>> as a result of path divergences we introduce?  Should we 
>>>>>>>> conduct a research project to determine what 
>>>>>>>>                 
>> other "control 
>>     
>>>>>>>> protocols" we need to include in TRILL?
>>>>>>>>                 
>>>>>>> We would need to make a list of everything that 
>>>>>>>               
>> bridges snoop 
>>     
>>>>>>> on and make sure we have ways of sending that 
>>>>>>>               
>> around in IS-IS 
>>     
>>>>>>> (if we care about those functions).
>>>>>>> I'm not aware of anything other than IGMP that trill would 
>>>>>>> need to worry about, though.
>>>>>>>
>>>>>>> Anoop
>>>>>>>
>>>>>>>               
>>>>>> _______________________________________________
>>>>>> rbridge mailing list
>>>>>> [e-mail]
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>             



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 l5KJtpFr027540 for <[e-mail]>; Wed, 20 Jun 2007 12:55:51 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 20 Jun 2007 12:55:51 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.17.136]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 20 Jun 2007 12:55:51 -0700 (PDT)
Date: Wed, 20 Jun 2007 12:56:32 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:55:58 -0000
Status: RO
Content-Length: 1209

As Anoop said, core RBridges need to look inside the tunneled
packet at the inner packet in order to do multicast pruning
as well as VLAN pruning on multicast packets.

Which is why Don was proposing moving both the VLAN tag and the
destination multicast address to the TRILL header. (and removing the 
VLAN tag
and DA from the
inner packet so that it wouldn't mean adding an extra 6 bytes to an 
encapsulated frame).

Seemed like people didn't like doing that, but I want to make sure if 
the WG really
is deciding not to do that, that they really understand what they are 
deciding against.
Often in the email threads so many different things are kind of 
discussed at the same time
that it's obvious that people (definitely including me) are getting 
confused.

Radia




Anoop Ghanwani wrote:
>
> They're snooping because they too care about
> pruning their trees for a given multicast group
> and that would be one of the ways to achieve it.
> Otherwise, all multicasts would have to be 
> broadcast on the spanning tree interconnecting
> the bridged network that sits between the two
> rBridges.
>
>   
> If we didn't care about multicast pruning,
> we wouldn't need to worry about any of this.
>
>   



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5KJpHaT026284 for <[e-mail]>; Wed, 20 Jun 2007 12:51:17 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-153.messagelabs.com!1182369072!1791024!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 2615 invoked from network); 20 Jun 2007 19:51:12 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-153.messagelabs.com with SMTP; 20 Jun 2007 19:51:12 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l5KJpC8j019676 for <[e-mail]>; Wed, 20 Jun 2007 12:51:12 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5KJpB9L001162 for <[e-mail]>; Wed, 20 Jun 2007 14:51:11 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5KJp9nM001148 for <[e-mail]>; Wed, 20 Jun 2007 14:51:10 -0500 (CDT)
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, 20 Jun 2007 15:51:06 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
thread-index: AcezbyC9Vi8/omkEQGSpYByszrVhhAAACt9wAADdwaA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJpHaT026284
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:51:35 -0000
Status: RO
Content-Length: 5380

Anoop,

It just isn't the case that all Rbridges will be in networks that
strictly follow a division into edge and core Rbridges. Rbridges are
well suited to much more general meshes. So it takes a lot more than you
think to secure things. Although IS-IS messages can be secured by
existing IS-Is features, what's to stop some station, possibly on a
multi-access link, from injecting a TRILL data frame to pollute the
database of the egress Rbridge when it is decapsulated? There are other,
more complex scenarios.

You should also keep in mind that some people just plain would prefer to
learn via IS-IS messages than via decapsulated data, regardless of
security issues. It's partly a layer 3 versus layer 2 point of view
conflict.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 20, 2007 3:17 PM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list


Radia,

I don't see what this has to do with security.
If "secure enrolment" is a requirement, then
the edge rBridge won't transmit any frames
from an end node until it has completed secure
enrolment.  It won't learn the address, and 
nor will the egress rbridge.

I still don't get what the per-VLAN IS-IS 
instance would buy us.

Anoop

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 12:14 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> What I am referring to as "per-VLAN instance of IS-IS" consists of 
> announcing attached
> endnodes and includes only attached endnodes in a particular VLAN.
> 
> It's optional to announce, and it's optional to learn from it.
> 
> I think it would be valuable for R1 to use to proactively announce 
> endnodes that have
> explicitly enrolled with R1 through a procedure more secure 
> than simply 
> sending a data
> packet with a (claimed) source address.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> > Radia,
> >
> > Using learning at the edge Rbridges definitely
> > addresses the scaling issue for unicast.
> >
> > From your note below it's not clear if we're
> > still going to have per-VLAN instances of
> > IS-IS.  If we do, I still think we would 
> > have problems with it.
> >
> > One can always make an argument that a 
> > 802.1Q bridge doesn't realistically need
> > to support 2K or 4K or whatever number 
> > of VLANs.  However, they do support it, 
> > and there are customers out there that 
> > configure that many VLANs.
> >
> > If TRILL is even moderately successful,
> > we will likely encounter networks where
> > an rBridge needs to participate in 1000s
> > of VLANs.
> >
> > Anoop
> >
> >   
> >> -----Original Message-----
> >> From: [e-mail] 
> >> [mailto:[e-mail]] On Behalf Of Radia Perlman
> >> Sent: Friday, June 15, 2007 9:12 PM
> >> To: [e-mail]
> >> Subject: [rbridge] I got some answers from the IS-IS mailing list
> >>
> >> 1) They have deployed a variant of IS-IS, and the way they 
> >> distinguish their instances is based on having a new 
> >> multicast address. I wrongly remembered IS-IS, and thought 
> >> that PSNPs got unicast, but even those are multicast (and I 
> >> remember the reasoning at the time this was decided 100 years 
> >> ago, which was to suppress lots of routers sending the same 
> >> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> >> from layer 3 IS-IS by having a different multicast address. 
> >> The bit in the header works too, however.
> >>
> >> 2) I checked to make sure that "0" would be OK to use as an 
> >> area address, and it is.
> >>
> >> 3) The solution I proposed to the scalability issue of having 
> >> a zillion pseudonodes on a LAN (having the DR give the same 
> >> name to all the pseudonodes that get spawned by running the 
> >> Hello protocol on a link according to each VLAN the DR 
> >> supports) works. 
> >> I was worried
> >> about nontransitive connectivity (R1, the DR, names the 
> >> pseudonode R1.1, and issues an LSP on behalf of the 
> >> pseudonode claiming to be attached to all the RBridges on the 
> >> link that can talk to R1 via any of the VLAN tags. But even 
> >> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> >> to R1 (using VLAN Tab B) does not mean that
> >> R2 and R3
> >> can talk to each other.)
> >>
> >> Interestingly, way back when IS-IS was DECnet phase V, and we 
> >> were worried about weird hardware problems creating 
> >> nontransitive connectivity, we put in what R2 should do when 
> >> the link state database implies R2 can talk to R3 through the 
> >> pseudonode, but
> >> R2 can't really talk to R3 -- R2 sends to the DR).
> >>
> >> So we can use this solution. So does that (and learning from 
> >> data packets rather than announcing all endnodes in per-VLAN 
> >> instances of IS-IS) answer everyone's scalability concerns?
> >>
> >> Radia
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>     
> 

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



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KJmaNE025306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 20 Jun 2007 12:48:36 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5KJpZjn002437; Wed, 20 Jun 2007 14:51:35 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 20 Jun 2007 14:48:27 -0500
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, 20 Jun 2007 14:48:24 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAABIDAQ
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 19:48:27.0108 (UTC) FILETIME=[F842B240:01C7B373]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJmaNE025306
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:49:03 -0000
Status: RO
Content-Length: 7133

Anoop,

	I don't understand why you suppose that the control packets 
would not be seen.  With the usual VLAN scoping caveat, broadcast 
control frames would be seen by every station (within the VLAN).

	It sounds to me like you're assuming that - along with the
other control activities associated with IGMP that you would like
TRILL to take on - you're also assuming that control frames are
being inapproriately filtered...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 20, 2007 3:14 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> 
> And we now go full circle back to...
> 
> What if we a bridged LAN between 2 rbridges
> and there were no stations on this bridged LAN
> (other than the rbridges) that were interested
> in receiving that multicast?  You wouldn't
> see any of the control packet that you mention.
> The only control packets of that type would be
> the ones which were going between the rBridges and
> those would be trill encap'ed.  So the regular
> bridges between these rbridges wouldn't 
> understand them (for snooping).
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Wednesday, June 20, 2007 12:11 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Hi Anoop,
> > 
> > From two places. They should see native IGMP/MLD/PIM/MRD from 
> > end stations that are directly attached to them. And, to the 
> > extent that they let any surrounding Rbridges see any PIM/MRD 
> > messages, the Designated Rbridge will send IGMP/MLDs in 
> > native form into the bridged LAN. I should think this would 
> > give the bridges enough information to figure out how to do 
> > an optimized forwarding of IP derived multicast address traffic.
> > 
> > Donald 
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Wednesday, June 20, 2007 2:53 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Donald,
> > 
> > So then the bridges in the LAN between the
> > 2 rbridges need some information to do their
> > pruning.   Where do they get it from?
> > 
> > Anoop 
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:16 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Hi Anoop,
> > > 
> > > No, it shouldn't get delivered to every end station unless it is 
> > > broadcast or a layer 2 multicast not derived from an IP address.
> > > 
> > > If it is an layer 2 multicast address derived from an IP 
> > address, then 
> > > Rbridges should prune the distribution tree and the links they 
> > > decapsulate and forward onto to those with listeners for an IP 
> > > multicast address that corresponds to that layer 2 
> > multicast address 
> > > or with an IP multicast router.
> > > 
> > > Donald
> > > 
> > > PS: All the above is scoped by VLAN as well.
> > > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:32 PM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [e-mail]; Caitlin Bestler
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Donald,
> > > 
> > > What if there are no IP multicast routers or listeners in 
> > the bridged 
> > > LAN between the rBridges?  Does that mean a copy of the 
> trill frame 
> > > gets delivered to every station in that LAN?
> > > 
> > > Anoop
> > > 
> > > > -----Original Message-----
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 12:51 PM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]; Caitlin Bestler
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > In addition to what Caitlin says, I would point out that,
> > > if there are
> > > > multicast listeners or IP multicast routers in this bridged
> > > LAN (which
> > > > looks to the Rbridges pretty much like a single 
> > multi-access link), 
> > > > then the Rbridges should have heard about them and the 
> Designated 
> > > > Rbridge for the VLAN in question for that cloud will also 
> > > > decapsulate
> > > appropriate
> > > > data/multicast-control and send it into the cloud as native
> > > > (non-TRILL)
> > > > frames whose distribution within the cloud the bridges are
> > > welcome to
> > > > try to optimize as much as they like.
> > > > 
> > > > Donald
> > > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Caitlin Bestler
> > > > Sent: Tuesday, June 19, 2007 3:16 PM
> > > > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > 
> > > > [e-mail] wrote:
> > > > > Eric,
> > > > > 
> > > > > It depends on what we mean by compatibility.
> > > > > One can always say that if one cares about such and such 
> > > > > compatibility then here's a way to solve it.
> > > > > 
> > > > > Even if trill were to impose the constraint you suggest, many 
> > > > > things will break.  For example, if I have a topology with a 
> > > > > bridged cloud between 2 trill devices, then the traffic going 
> > > > > between the trill devices will not be "snoopable" by 
> > the bridges 
> > > > > because they won't understand trill encapsulation.
> > > > > 
> > > > 
> > > > Why are these intermediate bridges snooping?
> > > > 
> > > > The only service being requested of them is to relay 
> > Ethernet frames 
> > > > from the ingress rbridge to the egress rbridge. Is that 
> > not implied 
> > > > by their being a cloud *between* 2 trill devices?
> > > > 
> > > > How is this different from any tunnel? You have traffic that a 
> > > > middlebox might have optimized had it been untunelled, 
> > but that it 
> > > > does not see when tunneled. It cannot provide its 
> > service, but it is 
> > > > not being asked to do so.
> > > > 
> > > > A non-rbridge bridge forwards packets without 
> understanding that 
> > > > they are rbridge encapsulated frames. I always thought 
> > that this was 
> > > > a strength of the proposal, not a weakness. You can't be 
> > snoopable 
> > > > and opaque. Opaque is better.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [e-mail]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > 
> > > 
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5KJbXDw022128 for <[e-mail]>; Wed, 20 Jun 2007 12:37:33 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-119.messagelabs.com!1182368251!17632039!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.7]
Received: (qmail 29162 invoked from network); 20 Jun 2007 19:37:31 -0000
Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-15.tower-119.messagelabs.com with SMTP; 20 Jun 2007 19:37:31 -0000
Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l5KJbVCB021303 for <[e-mail]>; Wed, 20 Jun 2007 12:37:31 -0700 (MST)
Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5KJbU9F021438 for <[e-mail]>; Wed, 20 Jun 2007 14:37:30 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5KJbSVv021419 for <[e-mail]>; Wed, 20 Jun 2007 14:37:29 -0500 (CDT)
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, 20 Jun 2007 15:37:15 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIAAI8kMwAAHz+XA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJbXDw022128
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:38:10 -0000
Status: RO
Content-Length: 11176

Anoop,

What exactly do you think we need to do and to get consensus on?

I think it is clear enough from the draft that an ingress Rbridge can
multipath multidestination traffic by selecting different tree roots for
different frames. So the only question is unicast. Other than a few
words saying that don't have to always send unicast traffic on the one
path selected by the tie breaker rule, but MAY multipath, what more is
needed?

Presumably the tricky thing is how best to determine flows, where frames
in a flow would follow only one of the multiple paths, except during
transients. I don't think the TRILL WG should get into defining flows...

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 20, 2007 2:43 PM
To: Eric Gray (LO/EUS); Silvano Gai
Cc: [e-mail]; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Personally, I would like the group to get to a
consensus on the ECMP issue fairly quickly.

I too, just like Silvano, thought it was going
to be done.

Anoop 

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 7:29 AM
> To: Silvano Gai; Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Silvano,
> 
> 	Yes, that was probably discussed earlier in May.
> 
> 	AFAIK, discussion != consensus.
> 
> 	Possibly your customers need to explain to you that the 
> difference between "core" and "not core" is not always as 
> clear cut as you apparently think it is.  Nor is it 
> necessarily going to be simple for a device to determine 
> which of the available equal cost paths only contain core elements.
> 
> 	Also, ECMP - at least in the traditional sense - takes 
> place where equal costs exist in a "routing" domain.  That is 
> at least as likely to occur in locii containing one or more 
> edge components, as it is anywhere else.
> 
> 	There are certainly limited applications - typically 
> requiring careful configuration to restrict ECMP-like 
> activity to very specifically defined equal cost paths - 
> where it will be possible to say "we do ECMP only in the 
> core."  I personally wonder why link-bundling wouldn't be a 
> better solution in those cases, however.
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 11:39 PM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> > 
> > We had this discussion on May 8th, 2007 on this mailing list.
> > 
> > In a nutshell: we do ECMP only in the core, but we don't 
> learn in the 
> > core, so I don't see the problem.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:14 AM
> > > To: Silvano Gai; Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Silvano,
> > > 
> > > 	Your response is confusing.  If we are not expected to preserve 
> > > forwarding symmetry, have we given up on presumed 
> compatibility with 
> > > standard bridges?
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > >
> > > >
> > > > Eric,
> > > >
> > > > You say: "we're expected to preserve forwarding symmetry".
> > > >
> > > > WE ARE NOT.
> > > >
> > > > Where does the current draft preserve forwarding symmetry?
> > > >
> > > > In regard to your conclusions, many of us (Anoop , Dinesh
> > and I for
> > > > sure) are participating because we are building real products.
> > > >
> > > > I don't buy your argument that "Very uninteresting
> > > > (technology) is very
> > > > good."
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]]
> > > > On
> > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > Anoop,
> > > > >
> > > > > 	I think we strongly disagree on what it means
> > to incorporate
> > > > > something in the control protocol.  From there, it is
> > likely that
> > > > > we also disagree on how best to avoid doing so.
> > > > >
> > > > > 	Figuring out how to correctly carry
> > IGMP-snooped information
> > > > > in TRILL protocol is effectively the same thing as 
> incorporating 
> > > > > IGMP in the control protocol.
> > > > >
> > > > > 	Making a list of everything that bridges snoop
> > and ensuring
> > > > > we can also include that information in IS-IS is
> > exactly the sort
> > > > > of thing we should be trying to avoid.  The good news 
> is that it 
> > > > > also should be easy to avoid.
> > > > >
> > > > > 	Whatever protocols we might use, TRILL is
> > essentially a layer
> > > > > two forwarding technology.  The messages that layer two
> > forwarding
> > > > > technologies want to snoop are visible to the devices
> > involved in
> > > > > forwarding.  Unless devices actively interfere with
> > "normal" layer
> > > > > two forwarding, "external" control messages should be
> > no different
> > > > > than any other form of data - as far as RBridges are 
> concerned - 
> > > > > and should be forwarded in the same way.
> > > > >
> > > > > 	We know that we're expected to preserve
> > forwarding symmetry
> > > > > - at least for the layer two encapsulation of TRILL
> > frames. In the
> > > > > same way, and for similar reasons, we may need to 
> preserve path 
> > > > > congruency.  This is implicit in the decision to 
> learn from data 
> > > > > in the unicast case.
> > > > >
> > > > > 	What we don't know is the complete list of
> > things that depend
> > > > > on our doing that.  But we can compose a partial list, and it
> > seems
> > > > > to me that "snooping" (in general) is one example, 
> OA&M may well
> > be
> > > > > another and there are bound to be more.
> > > > >
> > > > > 	As for the notion of "crippling the technology
> > and making it
> > > > > very uninteresting" - well, to many people, technology becomes
> > very
> > > > > interesting when it is very complicated to make it
> > work.  For the
> > > > > users of any technology, it is only truly useful when 
> it is not
> > very
> > > > > interesting.
> > > > >
> > > > > 	Paraphrasing something a colleague once told
> > me: a technology
> > > > > is only really useful when the interesting thing in 
> using it is
> > not
> > > > > about the technology, but about its use.  Put another way, you
> > know
> > > > > that transportation is useful when the interesting thing about
> > using
> > > > > it is arriving at the destination - rather than the 
> trip itself.
> > > > >
> > > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > > To: Eric Gray (LO/EUS)
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > Importance: High
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > >
> > > > > > > Anoop,
> > > > > > >
> > > > > > > 	I tend to view your response below as yet 
> another reason 
> > > > > > > why RBridges MUST use a common path for unicast and 
> > > > > > > multicast (as well as broadcast and flooded) traffic.  In 
> > > > > > > fact, it is a very good reason to limit use of
> > "multipathing"
> > > > > > > in general.
> > > > > >
> > > > > > If we do place those constraints then it would cripple the 
> > > > > > technology and make it very uninteresting (at least to me).
> > > > > >
> > > > > > > 	It is not clear exactly what you mean by your 
> reference to 
> > > > > > > differences between control and data paths.  Control 
> > > > > > > messages are from one RBridge to another and - 
> presumably - 
> > > > > > > follow the same path as data addressed from RBridge to 
> > > > > > > RBridge.  That path may be different from data
> > transitting an
> > > > > > > RBridge campus, but there is no RBridge "control" traffic 
> > > > > > > that transits a campus.
> > > > > > >
> > > > > > > 	Are you suggesting that IGMP should be treated 
> as a control 
> > > > > > > protocol within TRILL?
> > > > > >
> > > > > > In this case, when I said control I meant IGMP 
> (since that is 
> > > > > > what is being used to effect pruning).  If we snoop on the 
> > > > > > information at the edge of the trill cloud and pass this 
> > > > > > information around in IS-IS, then we don't need to 
> worry about 
> > > > > > treating it as a separate control protocol.
> > > > > >
> > > > > > >
> > > > > > > 	Nor is it very clear why this observation is 
> specific to 
> > > > > > > our discussion of multicast optimization.  As a general 
> > > > > > > rule, if there is one reasonably well know 
> application that 
> > > > > > > relies on path congruency for proper operation, there are 
> > > > > > > probably others.
> > > > > > >
> > > > > > > 	Do you think we should provide a logical 
> control-function 
> > > > > > > "bridging" service for all such
> > applications
> > > > > > > as a result of path divergences we introduce?  Should we 
> > > > > > > conduct a research project to determine what 
> other "control 
> > > > > > > protocols" we need to include in TRILL?
> > > > > >
> > > > > > We would need to make a list of everything that 
> bridges snoop 
> > > > > > on and make sure we have ways of sending that 
> around in IS-IS 
> > > > > > (if we care about those functions).
> > > > > > I'm not aware of anything other than IGMP that trill would 
> > > > > > need to worry about, though.
> > > > > >
> > > > > > Anoop
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rbridge mailing list
> > > > > [e-mail]
> > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > >
> > 
> 

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



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5KJNMxw018219 for <[e-mail]>; Wed, 20 Jun 2007 12:23:22 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-153.messagelabs.com!1182367401!2026871!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.9]
Received: (qmail 19871 invoked from network); 20 Jun 2007 19:23:21 -0000
Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-4.tower-153.messagelabs.com with SMTP; 20 Jun 2007 19:23:21 -0000
Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5KJNLFF006953 for <[e-mail]>; Wed, 20 Jun 2007 14:23:21 -0500 (CDT)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5KJNKbr000169 for <[e-mail]>; Wed, 20 Jun 2007 14:23:20 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5KJNI8R000142 for <[e-mail]>; Wed, 20 Jun 2007 14:23:19 -0500 (CDT)
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, 20 Jun 2007 15:22:58 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYAAAOSsw
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJNMxw018219
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:23:58 -0000
Status: RO
Content-Length: 6822

Hi Anoop,

It seems to me that what you are saying is that the strategy in TRILL of
only sending IGMP/MLD to links that appear to have IP multicast routers
on them due to the detection of PIM/MRD messages doesn't work. That, at
least occasionally, IGMP/MLD have to be flooded to every link just in
case there might be an IP multicast router on it that has been silent.

If that's a problem, it has nothing to do with bridges or bridged LANs.
All it takes to demonstrate the problem is a silent IP multicast router
point-to-point connected to an Rbridge somewhere. If that IP multicast
router has never send an PIM or MRD message, then the Rbridge has no way
of knowing to send it IGMPs or MLDs (or multicast data traffic)...

Donald 

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Wednesday, June 20, 2007 3:14 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] per-VLAN instances of IS-IS


And we now go full circle back to...

What if we a bridged LAN between 2 rbridges
and there were no stations on this bridged LAN
(other than the rbridges) that were interested
in receiving that multicast?  You wouldn't
see any of the control packet that you mention.
The only control packets of that type would be
the ones which were going between the rBridges and
those would be trill encap'ed.  So the regular
bridges between these rbridges wouldn't 
understand them (for snooping).

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 12:11 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> From two places. They should see native IGMP/MLD/PIM/MRD from 
> end stations that are directly attached to them. And, to the 
> extent that they let any surrounding Rbridges see any PIM/MRD 
> messages, the Designated Rbridge will send IGMP/MLDs in 
> native form into the bridged LAN. I should think this would 
> give the bridges enough information to figure out how to do 
> an optimized forwarding of IP derived multicast address traffic.
> 
> Donald 
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 2:53 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Donald,
> 
> So then the bridges in the LAN between the
> 2 rbridges need some information to do their
> pruning.   Where do they get it from?
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 7:16 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Hi Anoop,
> > 
> > No, it shouldn't get delivered to every end station unless it is 
> > broadcast or a layer 2 multicast not derived from an IP address.
> > 
> > If it is an layer 2 multicast address derived from an IP 
> address, then 
> > Rbridges should prune the distribution tree and the links they 
> > decapsulate and forward onto to those with listeners for an IP 
> > multicast address that corresponds to that layer 2 
> multicast address 
> > or with an IP multicast router.
> > 
> > Donald
> > 
> > PS: All the above is scoped by VLAN as well.
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 7:32 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]; Caitlin Bestler
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Donald,
> > 
> > What if there are no IP multicast routers or listeners in 
> the bridged 
> > LAN between the rBridges?  Does that mean a copy of the trill frame 
> > gets delivered to every station in that LAN?
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 12:51 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]; Caitlin Bestler
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > In addition to what Caitlin says, I would point out that,
> > if there are
> > > multicast listeners or IP multicast routers in this bridged
> > LAN (which
> > > looks to the Rbridges pretty much like a single 
> multi-access link), 
> > > then the Rbridges should have heard about them and the Designated 
> > > Rbridge for the VLAN in question for that cloud will also 
> > > decapsulate
> > appropriate
> > > data/multicast-control and send it into the cloud as native
> > > (non-TRILL)
> > > frames whose distribution within the cloud the bridges are
> > welcome to
> > > try to optimize as much as they like.
> > > 
> > > Donald
> > > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Caitlin Bestler
> > > Sent: Tuesday, June 19, 2007 3:16 PM
> > > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > [e-mail] wrote:
> > > > Eric,
> > > > 
> > > > It depends on what we mean by compatibility.
> > > > One can always say that if one cares about such and such 
> > > > compatibility then here's a way to solve it.
> > > > 
> > > > Even if trill were to impose the constraint you suggest, many 
> > > > things will break.  For example, if I have a topology with a 
> > > > bridged cloud between 2 trill devices, then the traffic going 
> > > > between the trill devices will not be "snoopable" by 
> the bridges 
> > > > because they won't understand trill encapsulation.
> > > > 
> > > 
> > > Why are these intermediate bridges snooping?
> > > 
> > > The only service being requested of them is to relay 
> Ethernet frames 
> > > from the ingress rbridge to the egress rbridge. Is that 
> not implied 
> > > by their being a cloud *between* 2 trill devices?
> > > 
> > > How is this different from any tunnel? You have traffic that a 
> > > middlebox might have optimized had it been untunelled, 
> but that it 
> > > does not see when tunneled. It cannot provide its 
> service, but it is 
> > > not being asked to do so.
> > > 
> > > A non-rbridge bridge forwards packets without understanding that 
> > > they are rbridge encapsulated frames. I always thought 
> that this was 
> > > a strength of the proposal, not a weakness. You can't be 
> snoopable 
> > > and opaque. Opaque is better.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > 
> 



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KJHba7016776 for <[e-mail]>; Wed, 20 Jun 2007 12:17:37 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 20 Jun 2007 12:17:37 -0700
X-IronPort-AV: i="4.16,444,1175497200";  d="scan'208"; a="11142367:sNHT19213635"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id A110723836C; Wed, 20 Jun 2007 12:15:14 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jun 2007 12:17:37 -0700
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, 20 Jun 2007 12:17:15 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
Thread-Index: AcezbyC9Vi8/omkEQGSpYByszrVhhAAACt9w
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 19:17:37.0584 (UTC) FILETIME=[A9DBBB00:01C7B36F]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJHba7016776
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:18:00 -0000
Status: RO
Content-Length: 4222

Radia,

I don't see what this has to do with security.
If "secure enrolment" is a requirement, then
the edge rBridge won't transmit any frames
from an end node until it has completed secure
enrolment.  It won't learn the address, and 
nor will the egress rbridge.

I still don't get what the per-VLAN IS-IS 
instance would buy us.

Anoop

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 12:14 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> What I am referring to as "per-VLAN instance of IS-IS" consists of 
> announcing attached
> endnodes and includes only attached endnodes in a particular VLAN.
> 
> It's optional to announce, and it's optional to learn from it.
> 
> I think it would be valuable for R1 to use to proactively announce 
> endnodes that have
> explicitly enrolled with R1 through a procedure more secure 
> than simply 
> sending a data
> packet with a (claimed) source address.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> > Radia,
> >
> > Using learning at the edge Rbridges definitely
> > addresses the scaling issue for unicast.
> >
> > From your note below it's not clear if we're
> > still going to have per-VLAN instances of
> > IS-IS.  If we do, I still think we would 
> > have problems with it.
> >
> > One can always make an argument that a 
> > 802.1Q bridge doesn't realistically need
> > to support 2K or 4K or whatever number 
> > of VLANs.  However, they do support it, 
> > and there are customers out there that 
> > configure that many VLANs.
> >
> > If TRILL is even moderately successful,
> > we will likely encounter networks where
> > an rBridge needs to participate in 1000s
> > of VLANs.
> >
> > Anoop
> >
> >   
> >> -----Original Message-----
> >> From: [e-mail] 
> >> [mailto:[e-mail]] On Behalf Of Radia Perlman
> >> Sent: Friday, June 15, 2007 9:12 PM
> >> To: [e-mail]
> >> Subject: [rbridge] I got some answers from the IS-IS mailing list
> >>
> >> 1) They have deployed a variant of IS-IS, and the way they 
> >> distinguish their instances is based on having a new 
> >> multicast address. I wrongly remembered IS-IS, and thought 
> >> that PSNPs got unicast, but even those are multicast (and I 
> >> remember the reasoning at the time this was decided 100 years 
> >> ago, which was to suppress lots of routers sending the same 
> >> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> >> from layer 3 IS-IS by having a different multicast address. 
> >> The bit in the header works too, however.
> >>
> >> 2) I checked to make sure that "0" would be OK to use as an 
> >> area address, and it is.
> >>
> >> 3) The solution I proposed to the scalability issue of having 
> >> a zillion pseudonodes on a LAN (having the DR give the same 
> >> name to all the pseudonodes that get spawned by running the 
> >> Hello protocol on a link according to each VLAN the DR 
> >> supports) works. 
> >> I was worried
> >> about nontransitive connectivity (R1, the DR, names the 
> >> pseudonode R1.1, and issues an LSP on behalf of the 
> >> pseudonode claiming to be attached to all the RBridges on the 
> >> link that can talk to R1 via any of the VLAN tags. But even 
> >> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> >> to R1 (using VLAN Tab B) does not mean that
> >> R2 and R3
> >> can talk to each other.)
> >>
> >> Interestingly, way back when IS-IS was DECnet phase V, and we 
> >> were worried about weird hardware problems creating 
> >> nontransitive connectivity, we put in what R2 should do when 
> >> the link state database implies R2 can talk to R3 through the 
> >> pseudonode, but
> >> R2 can't really talk to R3 -- R2 sends to the DR).
> >>
> >> So we can use this solution. So does that (and learning from 
> >> data packets rather than announcing all endnodes in per-VLAN 
> >> instances of IS-IS) answer everyone's scalability concerns?
> >>
> >> Radia
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>     
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KJEBcH015653 for <[e-mail]>; Wed, 20 Jun 2007 12:14:11 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 20 Jun 2007 12:14:11 -0700
X-IronPort-AV: i="4.16,444,1175497200";  d="scan'208"; a="13933388:sNHT26022311"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 6824D23836C; Wed, 20 Jun 2007 12:11:48 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jun 2007 12:14:11 -0700
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, 20 Jun 2007 12:13:49 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsAAADJuYA==
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 19:14:11.0431 (UTC) FILETIME=[2EFB4770:01C7B36F]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJEBcH015653
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:14:33 -0000
Status: RO
Content-Length: 5866

And we now go full circle back to...

What if we a bridged LAN between 2 rbridges
and there were no stations on this bridged LAN
(other than the rbridges) that were interested
in receiving that multicast?  You wouldn't
see any of the control packet that you mention.
The only control packets of that type would be
the ones which were going between the rBridges and
those would be trill encap'ed.  So the regular
bridges between these rbridges wouldn't 
understand them (for snooping).

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 12:11 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> From two places. They should see native IGMP/MLD/PIM/MRD from 
> end stations that are directly attached to them. And, to the 
> extent that they let any surrounding Rbridges see any PIM/MRD 
> messages, the Designated Rbridge will send IGMP/MLDs in 
> native form into the bridged LAN. I should think this would 
> give the bridges enough information to figure out how to do 
> an optimized forwarding of IP derived multicast address traffic.
> 
> Donald 
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2007 2:53 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Donald,
> 
> So then the bridges in the LAN between the
> 2 rbridges need some information to do their
> pruning.   Where do they get it from?
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> > [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 7:16 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Hi Anoop,
> > 
> > No, it shouldn't get delivered to every end station unless it is 
> > broadcast or a layer 2 multicast not derived from an IP address.
> > 
> > If it is an layer 2 multicast address derived from an IP 
> address, then 
> > Rbridges should prune the distribution tree and the links they 
> > decapsulate and forward onto to those with listeners for an IP 
> > multicast address that corresponds to that layer 2 
> multicast address 
> > or with an IP multicast router.
> > 
> > Donald
> > 
> > PS: All the above is scoped by VLAN as well.
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 7:32 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]; Caitlin Bestler
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Donald,
> > 
> > What if there are no IP multicast routers or listeners in 
> the bridged 
> > LAN between the rBridges?  Does that mean a copy of the trill frame 
> > gets delivered to every station in that LAN?
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 12:51 PM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]; Caitlin Bestler
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > In addition to what Caitlin says, I would point out that,
> > if there are
> > > multicast listeners or IP multicast routers in this bridged
> > LAN (which
> > > looks to the Rbridges pretty much like a single 
> multi-access link), 
> > > then the Rbridges should have heard about them and the Designated 
> > > Rbridge for the VLAN in question for that cloud will also 
> > > decapsulate
> > appropriate
> > > data/multicast-control and send it into the cloud as native
> > > (non-TRILL)
> > > frames whose distribution within the cloud the bridges are
> > welcome to
> > > try to optimize as much as they like.
> > > 
> > > Donald
> > > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Caitlin Bestler
> > > Sent: Tuesday, June 19, 2007 3:16 PM
> > > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > [e-mail] wrote:
> > > > Eric,
> > > > 
> > > > It depends on what we mean by compatibility.
> > > > One can always say that if one cares about such and such 
> > > > compatibility then here's a way to solve it.
> > > > 
> > > > Even if trill were to impose the constraint you suggest, many 
> > > > things will break.  For example, if I have a topology with a 
> > > > bridged cloud between 2 trill devices, then the traffic going 
> > > > between the trill devices will not be "snoopable" by 
> the bridges 
> > > > because they won't understand trill encapsulation.
> > > > 
> > > 
> > > Why are these intermediate bridges snooping?
> > > 
> > > The only service being requested of them is to relay 
> Ethernet frames 
> > > from the ingress rbridge to the egress rbridge. Is that 
> not implied 
> > > by their being a cloud *between* 2 trill devices?
> > > 
> > > How is this different from any tunnel? You have traffic that a 
> > > middlebox might have optimized had it been untunelled, 
> but that it 
> > > does not see when tunneled. It cannot provide its 
> service, but it is 
> > > not being asked to do so.
> > > 
> > > A non-rbridge bridge forwards packets without understanding that 
> > > they are rbridge encapsulated frames. I always thought 
> that this was 
> > > a strength of the proposal, not a weakness. You can't be 
> snoopable 
> > > and opaque. Opaque is better.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > 
> 



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 l5KJE14P015591 for <[e-mail]>; Wed, 20 Jun 2007 12:14:01 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 20 Jun 2007 12:13:46 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.17.136]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 20 Jun 2007 12:13:46 -0700 (PDT)
Date: Wed, 20 Jun 2007 12:14:27 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:14:29 -0000
Status: RO
Content-Length: 3440

What I am referring to as "per-VLAN instance of IS-IS" consists of 
announcing attached
endnodes and includes only attached endnodes in a particular VLAN.

It's optional to announce, and it's optional to learn from it.

I think it would be valuable for R1 to use to proactively announce 
endnodes that have
explicitly enrolled with R1 through a procedure more secure than simply 
sending a data
packet with a (claimed) source address.

Radia




Anoop Ghanwani wrote:
> Radia,
>
> Using learning at the edge Rbridges definitely
> addresses the scaling issue for unicast.
>
> From your note below it's not clear if we're
> still going to have per-VLAN instances of
> IS-IS.  If we do, I still think we would 
> have problems with it.
>
> One can always make an argument that a 
> 802.1Q bridge doesn't realistically need
> to support 2K or 4K or whatever number 
> of VLANs.  However, they do support it, 
> and there are customers out there that 
> configure that many VLANs.
>
> If TRILL is even moderately successful,
> we will likely encounter networks where
> an rBridge needs to participate in 1000s
> of VLANs.
>
> Anoop
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Radia Perlman
>> Sent: Friday, June 15, 2007 9:12 PM
>> To: [e-mail]
>> Subject: [rbridge] I got some answers from the IS-IS mailing list
>>
>> 1) They have deployed a variant of IS-IS, and the way they 
>> distinguish their instances is based on having a new 
>> multicast address. I wrongly remembered IS-IS, and thought 
>> that PSNPs got unicast, but even those are multicast (and I 
>> remember the reasoning at the time this was decided 100 years 
>> ago, which was to suppress lots of routers sending the same 
>> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
>> from layer 3 IS-IS by having a different multicast address. 
>> The bit in the header works too, however.
>>
>> 2) I checked to make sure that "0" would be OK to use as an 
>> area address, and it is.
>>
>> 3) The solution I proposed to the scalability issue of having 
>> a zillion pseudonodes on a LAN (having the DR give the same 
>> name to all the pseudonodes that get spawned by running the 
>> Hello protocol on a link according to each VLAN the DR 
>> supports) works. 
>> I was worried
>> about nontransitive connectivity (R1, the DR, names the 
>> pseudonode R1.1, and issues an LSP on behalf of the 
>> pseudonode claiming to be attached to all the RBridges on the 
>> link that can talk to R1 via any of the VLAN tags. But even 
>> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
>> to R1 (using VLAN Tab B) does not mean that
>> R2 and R3
>> can talk to each other.)
>>
>> Interestingly, way back when IS-IS was DECnet phase V, and we 
>> were worried about weird hardware problems creating 
>> nontransitive connectivity, we put in what R2 should do when 
>> the link state database implies R2 can talk to R3 through the 
>> pseudonode, but
>> R2 can't really talk to R3 -- R2 sends to the DR).
>>
>> So we can use this solution. So does that (and learning from 
>> data packets rather than announcing all endnodes in per-VLAN 
>> instances of IS-IS) answer everyone's scalability concerns?
>>
>> Radia
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5KJBB1V014802 for <[e-mail]>; Wed, 20 Jun 2007 12:11:11 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-153.messagelabs.com!1182366665!1360128!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 29362 invoked from network); 20 Jun 2007 19:11:06 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 20 Jun 2007 19:11:06 -0000
Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5KJB5Mn025493 for <[e-mail]>; Wed, 20 Jun 2007 12:11:05 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5KJB4xj020854 for <[e-mail]>; Wed, 20 Jun 2007 14:11:04 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5KJB2jl020842 for <[e-mail]>; Wed, 20 Jun 2007 14:11:03 -0500 (CDT)
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, 20 Jun 2007 15:11:01 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHwAACAvsA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJBB1V014802
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:11:39 -0000
Status: RO
Content-Length: 4814

Hi Anoop,

>From two places. They should see native IGMP/MLD/PIM/MRD from end
stations that are directly attached to them. And, to the extent that
they let any surrounding Rbridges see any PIM/MRD messages, the
Designated Rbridge will send IGMP/MLDs in native form into the bridged
LAN. I should think this would give the bridges enough information to
figure out how to do an optimized forwarding of IP derived multicast
address traffic.

Donald 

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Wednesday, June 20, 2007 2:53 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

So then the bridges in the LAN between the
2 rbridges need some information to do their
pruning.   Where do they get it from?

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 7:16 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> No, it shouldn't get delivered to every end station unless it is
> broadcast or a layer 2 multicast not derived from an IP address.
> 
> If it is an layer 2 multicast address derived from an IP address, then
> Rbridges should prune the distribution tree and the links they
> decapsulate and forward onto to those with listeners for an 
> IP multicast
> address that corresponds to that layer 2 multicast address or 
> with an IP
> multicast router.
> 
> Donald
> 
> PS: All the above is scoped by VLAN as well.
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 7:32 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]; Caitlin Bestler
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Donald,
> 
> What if there are no IP multicast routers or
> listeners in the bridged LAN between the
> rBridges?  Does that mean a copy of the trill
> frame gets delivered to every station in that
> LAN?
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Tuesday, June 19, 2007 12:51 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Caitlin Bestler
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > In addition to what Caitlin says, I would point out that, 
> if there are
> > multicast listeners or IP multicast routers in this bridged 
> LAN (which
> > looks to the Rbridges pretty much like a single multi-access 
> > link), then
> > the Rbridges should have heard about them and the Designated 
> > Rbridge for
> > the VLAN in question for that cloud will also decapsulate 
> appropriate
> > data/multicast-control and send it into the cloud as native 
> > (non-TRILL)
> > frames whose distribution within the cloud the bridges are 
> welcome to
> > try to optimize as much as they like.
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On
> > Behalf Of Caitlin Bestler
> > Sent: Tuesday, June 19, 2007 3:16 PM
> > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > [e-mail] wrote:
> > > Eric,
> > > 
> > > It depends on what we mean by compatibility.
> > > One can always say that if one cares about such and such
> > > compatibility then here's a way to solve it.
> > > 
> > > Even if trill were to impose the constraint you suggest, many
> > > things will break.  For example, if I have a topology with a
> > > bridged cloud between 2 trill devices, then the traffic going
> > > between the trill devices will not be "snoopable" by the
> > > bridges because they won't understand trill encapsulation.
> > > 
> > 
> > Why are these intermediate bridges snooping?
> > 
> > The only service being requested of them is to relay Ethernet
> > frames from the ingress rbridge to the egress rbridge. Is that
> > not implied by their being a cloud *between* 2 trill devices?
> > 
> > How is this different from any tunnel? You have traffic that
> > a middlebox might have optimized had it been untunelled, but
> > that it does not see when tunneled. It cannot provide its service,
> > but it is not being asked to do so.
> > 
> > A non-rbridge bridge forwards packets without understanding that
> > they are rbridge encapsulated frames. I always thought that this
> > was a strength of the proposal, not a weakness. You can't be
> > snoopable and opaque. Opaque is better.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KJ6X4p013310 for <[e-mail]>; Wed, 20 Jun 2007 12:06:33 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 20 Jun 2007 12:06:33 -0700
X-IronPort-AV: i="4.16,443,1175497200";  d="scan'208"; a="11142209:sNHT19059768"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 2A3D523836C; Wed, 20 Jun 2007 12:04:10 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jun 2007 12:06:33 -0700
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, 20 Jun 2007 12:06:10 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acey7FyzmD/kSY3mQDqNMLI7gXT8kwAgQLbA
From: "Anoop Ghanwani" <[e-mail]>
To: "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 19:06:33.0202 (UTC) FILETIME=[1DDB1520:01C7B36E]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KJ6X4p013310
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:06:59 -0000
Status: RO
Content-Length: 2416

 

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 8:37 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop Ghanwani wrote:
> >  
> > Joe,
> > 
> >> And, as Eric notes later, a common path between the two is 
> >> needed at L2.
> > 
> > Sorry, this thread is starting to get long and 
> > I'm losing context.  A common path between what two?
> > Control and data?  As I pointed out the control
> > packets (e.g. if MMRP were being used) do not
> > even make it into the LAN between the rbridges.
> > The rbridges would have to initiate such messages
> > and I don't know what would cause them to intiate
> > such messages.
> 
> I was presuming a common path for multicast at L3 and unicast at L3,
> e.g., IPv6 neighbor discovery and unicast replies.

Why does this matter?

Somewhat unrelated to this discussion:
>From an L2 network standpoint, IPv6 ND
multicasts have to be treated similar to broadcasts
because there is no information that can tell how
to filter the frame as it propagates on the 
spanning tree (unless you have something like
MMRP enabled and the host does MMRP).

> >> As to the pruning that Anoop later notes, I don't consider 
> pruning an
> >> issue for an L2 system. Although I appreciate pruning as an
> >> optimization, I don't consider it a design requirement. If 
> it were, we
> >> would be talking about scalability beyond existing bridge 
> >> capabilities,
> >> which has been off the table from the start.
> > 
> > Well, existing bridges do actually do
> > pruning today - and they have for years.
> > rBridges without multicast pruning would be
> > step (or perhaps two) back.
> 
> There are bridges built into a variety of devices that are a 
> lot simpler
> than the typical COTS stand-alone device. Further, the extent to which
> rbridges even benefit from pruning is different than regular bridges,
> because there can be multiple paths for different traffic in rbridges.
> I.e., this is still just an optimization, and one that may be less
> important in this environment.

I disagree with respect to the importance of
multicast pruning in these networks.  But for a
moment let's say I agree with you and multicast
pruning becomes a non-goal.  Then there is no
function for which we need a per-VLAN instance
of IS-IS.

Anoop



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KIqvYG009560 for <[e-mail]>; Wed, 20 Jun 2007 11:52:57 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 20 Jun 2007 11:52:57 -0700
X-IronPort-AV: i="4.16,443,1175497200";  d="scan'208"; a="13932186:sNHT17661693"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 7AB0423836C; Wed, 20 Jun 2007 11:50:34 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jun 2007 11:52:57 -0700
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, 20 Jun 2007 11:52:35 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAAAi8UHw
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 18:52:57.0427 (UTC) FILETIME=[379DB230:01C7B36C]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KIqvYG009560
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 18:54:00 -0000
Status: RO
Content-Length: 4145

Donald,

So then the bridges in the LAN between the
2 rbridges need some information to do their
pruning.   Where do they get it from?

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 7:16 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> No, it shouldn't get delivered to every end station unless it is
> broadcast or a layer 2 multicast not derived from an IP address.
> 
> If it is an layer 2 multicast address derived from an IP address, then
> Rbridges should prune the distribution tree and the links they
> decapsulate and forward onto to those with listeners for an 
> IP multicast
> address that corresponds to that layer 2 multicast address or 
> with an IP
> multicast router.
> 
> Donald
> 
> PS: All the above is scoped by VLAN as well.
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 7:32 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]; Caitlin Bestler
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Donald,
> 
> What if there are no IP multicast routers or
> listeners in the bridged LAN between the
> rBridges?  Does that mean a copy of the trill
> frame gets delivered to every station in that
> LAN?
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[e-mail]] 
> > Sent: Tuesday, June 19, 2007 12:51 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Caitlin Bestler
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > In addition to what Caitlin says, I would point out that, 
> if there are
> > multicast listeners or IP multicast routers in this bridged 
> LAN (which
> > looks to the Rbridges pretty much like a single multi-access 
> > link), then
> > the Rbridges should have heard about them and the Designated 
> > Rbridge for
> > the VLAN in question for that cloud will also decapsulate 
> appropriate
> > data/multicast-control and send it into the cloud as native 
> > (non-TRILL)
> > frames whose distribution within the cloud the bridges are 
> welcome to
> > try to optimize as much as they like.
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On
> > Behalf Of Caitlin Bestler
> > Sent: Tuesday, June 19, 2007 3:16 PM
> > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > [e-mail] wrote:
> > > Eric,
> > > 
> > > It depends on what we mean by compatibility.
> > > One can always say that if one cares about such and such
> > > compatibility then here's a way to solve it.
> > > 
> > > Even if trill were to impose the constraint you suggest, many
> > > things will break.  For example, if I have a topology with a
> > > bridged cloud between 2 trill devices, then the traffic going
> > > between the trill devices will not be "snoopable" by the
> > > bridges because they won't understand trill encapsulation.
> > > 
> > 
> > Why are these intermediate bridges snooping?
> > 
> > The only service being requested of them is to relay Ethernet
> > frames from the ingress rbridge to the egress rbridge. Is that
> > not implied by their being a cloud *between* 2 trill devices?
> > 
> > How is this different from any tunnel? You have traffic that
> > a middlebox might have optimized had it been untunelled, but
> > that it does not see when tunneled. It cannot provide its service,
> > but it is not being asked to do so.
> > 
> > A non-rbridge bridge forwards packets without understanding that
> > they are rbridge encapsulated frames. I always thought that this
> > was a strength of the proposal, not a weakness. You can't be
> > snoopable and opaque. Opaque is better.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KIhKlR007228 for <[e-mail]>; Wed, 20 Jun 2007 11:43:20 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 20 Jun 2007 11:43:11 -0700
X-IronPort-AV: i="4.16,443,1175497200";  d="scan'208"; a="13931708:sNHT21472206"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 5C87A23836C; Wed, 20 Jun 2007 11:40:48 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jun 2007 11:43:11 -0700
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, 20 Jun 2007 11:42:49 -0700
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIAAI8kMw
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 18:43:11.0268 (UTC) FILETIME=[DA3CEE40:01C7B36A]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KIhKlR007228
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 18:43:36 -0000
Status: RO
Content-Length: 10088

Personally, I would like the group to get to a
consensus on the ECMP issue fairly quickly.

I too, just like Silvano, thought it was going
to be done.

Anoop 

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Wednesday, June 20, 2007 7:29 AM
> To: Silvano Gai; Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Silvano,
> 
> 	Yes, that was probably discussed earlier in May.
> 
> 	AFAIK, discussion != consensus.
> 
> 	Possibly your customers need to explain to you that the 
> difference between "core" and "not core" is not always as 
> clear cut as you apparently think it is.  Nor is it 
> necessarily going to be simple for a device to determine 
> which of the available equal cost paths only contain core elements.
> 
> 	Also, ECMP - at least in the traditional sense - takes 
> place where equal costs exist in a "routing" domain.  That is 
> at least as likely to occur in locii containing one or more 
> edge components, as it is anywhere else.
> 
> 	There are certainly limited applications - typically 
> requiring careful configuration to restrict ECMP-like 
> activity to very specifically defined equal cost paths - 
> where it will be possible to say "we do ECMP only in the 
> core."  I personally wonder why link-bundling wouldn't be a 
> better solution in those cases, however.
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 11:39 PM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> > 
> > We had this discussion on May 8th, 2007 on this mailing list.
> > 
> > In a nutshell: we do ECMP only in the core, but we don't 
> learn in the 
> > core, so I don't see the problem.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 7:14 AM
> > > To: Silvano Gai; Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Silvano,
> > > 
> > > 	Your response is confusing.  If we are not expected to preserve 
> > > forwarding symmetry, have we given up on presumed 
> compatibility with 
> > > standard bridges?
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[e-mail]]
> > > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > >
> > > >
> > > > Eric,
> > > >
> > > > You say: "we're expected to preserve forwarding symmetry".
> > > >
> > > > WE ARE NOT.
> > > >
> > > > Where does the current draft preserve forwarding symmetry?
> > > >
> > > > In regard to your conclusions, many of us (Anoop , Dinesh
> > and I for
> > > > sure) are participating because we are building real products.
> > > >
> > > > I don't buy your argument that "Very uninteresting
> > > > (technology) is very
> > > > good."
> > > >
> > > > -- Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]]
> > > > On
> > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > Anoop,
> > > > >
> > > > > 	I think we strongly disagree on what it means
> > to incorporate
> > > > > something in the control protocol.  From there, it is
> > likely that
> > > > > we also disagree on how best to avoid doing so.
> > > > >
> > > > > 	Figuring out how to correctly carry
> > IGMP-snooped information
> > > > > in TRILL protocol is effectively the same thing as 
> incorporating 
> > > > > IGMP in the control protocol.
> > > > >
> > > > > 	Making a list of everything that bridges snoop
> > and ensuring
> > > > > we can also include that information in IS-IS is
> > exactly the sort
> > > > > of thing we should be trying to avoid.  The good news 
> is that it 
> > > > > also should be easy to avoid.
> > > > >
> > > > > 	Whatever protocols we might use, TRILL is
> > essentially a layer
> > > > > two forwarding technology.  The messages that layer two
> > forwarding
> > > > > technologies want to snoop are visible to the devices
> > involved in
> > > > > forwarding.  Unless devices actively interfere with
> > "normal" layer
> > > > > two forwarding, "external" control messages should be
> > no different
> > > > > than any other form of data - as far as RBridges are 
> concerned - 
> > > > > and should be forwarded in the same way.
> > > > >
> > > > > 	We know that we're expected to preserve
> > forwarding symmetry
> > > > > - at least for the layer two encapsulation of TRILL
> > frames. In the
> > > > > same way, and for similar reasons, we may need to 
> preserve path 
> > > > > congruency.  This is implicit in the decision to 
> learn from data 
> > > > > in the unicast case.
> > > > >
> > > > > 	What we don't know is the complete list of
> > things that depend
> > > > > on our doing that.  But we can compose a partial list, and it
> > seems
> > > > > to me that "snooping" (in general) is one example, 
> OA&M may well
> > be
> > > > > another and there are bound to be more.
> > > > >
> > > > > 	As for the notion of "crippling the technology
> > and making it
> > > > > very uninteresting" - well, to many people, technology becomes
> > very
> > > > > interesting when it is very complicated to make it
> > work.  For the
> > > > > users of any technology, it is only truly useful when 
> it is not
> > very
> > > > > interesting.
> > > > >
> > > > > 	Paraphrasing something a colleague once told
> > me: a technology
> > > > > is only really useful when the interesting thing in 
> using it is
> > not
> > > > > about the technology, but about its use.  Put another way, you
> > know
> > > > > that transportation is useful when the interesting thing about
> > using
> > > > > it is arriving at the destination - rather than the 
> trip itself.
> > > > >
> > > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > > To: Eric Gray (LO/EUS)
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > Importance: High
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > > >
> > > > > > > Anoop,
> > > > > > >
> > > > > > > 	I tend to view your response below as yet 
> another reason 
> > > > > > > why RBridges MUST use a common path for unicast and 
> > > > > > > multicast (as well as broadcast and flooded) traffic.  In 
> > > > > > > fact, it is a very good reason to limit use of
> > "multipathing"
> > > > > > > in general.
> > > > > >
> > > > > > If we do place those constraints then it would cripple the 
> > > > > > technology and make it very uninteresting (at least to me).
> > > > > >
> > > > > > > 	It is not clear exactly what you mean by your 
> reference to 
> > > > > > > differences between control and data paths.  Control 
> > > > > > > messages are from one RBridge to another and - 
> presumably - 
> > > > > > > follow the same path as data addressed from RBridge to 
> > > > > > > RBridge.  That path may be different from data
> > transitting an
> > > > > > > RBridge campus, but there is no RBridge "control" traffic 
> > > > > > > that transits a campus.
> > > > > > >
> > > > > > > 	Are you suggesting that IGMP should be treated 
> as a control 
> > > > > > > protocol within TRILL?
> > > > > >
> > > > > > In this case, when I said control I meant IGMP 
> (since that is 
> > > > > > what is being used to effect pruning).  If we snoop on the 
> > > > > > information at the edge of the trill cloud and pass this 
> > > > > > information around in IS-IS, then we don't need to 
> worry about 
> > > > > > treating it as a separate control protocol.
> > > > > >
> > > > > > >
> > > > > > > 	Nor is it very clear why this observation is 
> specific to 
> > > > > > > our discussion of multicast optimization.  As a general 
> > > > > > > rule, if there is one reasonably well know 
> application that 
> > > > > > > relies on path congruency for proper operation, there are 
> > > > > > > probably others.
> > > > > > >
> > > > > > > 	Do you think we should provide a logical 
> control-function 
> > > > > > > "bridging" service for all such
> > applications
> > > > > > > as a result of path divergences we introduce?  Should we 
> > > > > > > conduct a research project to determine what 
> other "control 
> > > > > > > protocols" we need to include in TRILL?
> > > > > >
> > > > > > We would need to make a list of everything that 
> bridges snoop 
> > > > > > on and make sure we have ways of sending that 
> around in IS-IS 
> > > > > > (if we care about those functions).
> > > > > > I'm not aware of anything other than IGMP that trill would 
> > > > > > need to worry about, though.
> > > > > >
> > > > > > Anoop
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rbridge mailing list
> > > > > [e-mail]
> > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > >
> > 
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5KETJOG025580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 20 Jun 2007 07:29:19 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5KEUkfo019276; Wed, 20 Jun 2007 09:30:46 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 20 Jun 2007 09:29:12 -0500
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, 20 Jun 2007 09:29:06 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SAAHgYVIA==
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2007 14:29:12.0007 (UTC) FILETIME=[5EEE3D70:01C7B347]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5KETJOG025580
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 14:29:51 -0000
Status: RO
Content-Length: 9090

Silvano,

	Yes, that was probably discussed earlier in May.

	AFAIK, discussion != consensus.

	Possibly your customers need to explain to you that the
difference between "core" and "not core" is not always as clear 
cut as you apparently think it is.  Nor is it necessarily going
to be simple for a device to determine which of the available
equal cost paths only contain core elements.

	Also, ECMP - at least in the traditional sense - takes
place where equal costs exist in a "routing" domain.  That is
at least as likely to occur in locii containing one or more
edge components, as it is anywhere else.

	There are certainly limited applications - typically 
requiring careful configuration to restrict ECMP-like activity
to very specifically defined equal cost paths - where it will
be possible to say "we do ECMP only in the core."  I personally
wonder why link-bundling wouldn't be a better solution in those
cases, however.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 11:39 PM
> To: Eric Gray (LO/EUS); Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> We had this discussion on May 8th, 2007 on this mailing list.
> 
> In a nutshell: we do ECMP only in the core, but we don't learn in the
> core, so I don't see the problem.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 7:14 AM
> > To: Silvano Gai; Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Silvano,
> > 
> > 	Your response is confusing.  If we are not expected to
> > preserve forwarding symmetry, have we given up on presumed
> > compatibility with standard bridges?
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[e-mail]]
> > > Sent: Tuesday, June 19, 2007 9:13 AM
> > > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > >
> > >
> > > Eric,
> > >
> > > You say: "we're expected to preserve forwarding symmetry".
> > >
> > > WE ARE NOT.
> > >
> > > Where does the current draft preserve forwarding symmetry?
> > >
> > > In regard to your conclusions, many of us (Anoop , Dinesh 
> and I for
> > > sure) are participating because we are building real products.
> > >
> > > I don't buy your argument that "Very uninteresting
> > > (technology) is very
> > > good."
> > >
> > > -- Silvano
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> [mailto:[e-mail]]
> > > On
> > > > Behalf Of Eric Gray (LO/EUS)
> > > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > Anoop,
> > > >
> > > > 	I think we strongly disagree on what it means 
> to incorporate
> > > > something in the control protocol.  From there, it is 
> likely that
> > > > we also disagree on how best to avoid doing so.
> > > >
> > > > 	Figuring out how to correctly carry 
> IGMP-snooped information
> > > > in TRILL protocol is effectively the same thing as incorporating
> > > > IGMP in the control protocol.
> > > >
> > > > 	Making a list of everything that bridges snoop 
> and ensuring
> > > > we can also include that information in IS-IS is 
> exactly the sort
> > > > of thing we should be trying to avoid.  The good news is that it
> > > > also should be easy to avoid.
> > > >
> > > > 	Whatever protocols we might use, TRILL is 
> essentially a layer
> > > > two forwarding technology.  The messages that layer two 
> forwarding
> > > > technologies want to snoop are visible to the devices 
> involved in
> > > > forwarding.  Unless devices actively interfere with 
> "normal" layer
> > > > two forwarding, "external" control messages should be 
> no different
> > > > than any other form of data - as far as RBridges are concerned -
> > > > and should be forwarded in the same way.
> > > >
> > > > 	We know that we're expected to preserve 
> forwarding symmetry
> > > > - at least for the layer two encapsulation of TRILL 
> frames. In the
> > > > same way, and for similar reasons, we may need to preserve path
> > > > congruency.  This is implicit in the decision to learn from data
> > > > in the unicast case.
> > > >
> > > > 	What we don't know is the complete list of 
> things that depend
> > > > on our doing that.  But we can compose a partial list, and it
> seems
> > > > to me that "snooping" (in general) is one example, OA&M may well
> be
> > > > another and there are bound to be more.
> > > >
> > > > 	As for the notion of "crippling the technology 
> and making it
> > > > very uninteresting" - well, to many people, technology becomes
> very
> > > > interesting when it is very complicated to make it 
> work.  For the
> > > > users of any technology, it is only truly useful when it is not
> very
> > > > interesting.
> > > >
> > > > 	Paraphrasing something a colleague once told 
> me: a technology
> > > > is only really useful when the interesting thing in using it is
> not
> > > > about the technology, but about its use.  Put another way, you
> know
> > > > that transportation is useful when the interesting thing about
> using
> > > > it is arriving at the destination - rather than the trip itself.
> > > >
> > > > 	Uninteresting is good.  Very uninteresting is very good.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > > To: Eric Gray (LO/EUS)
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > Importance: High
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: [e-mail]; Radia Perlman
> > > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > > >
> > > > > > Anoop,
> > > > > >
> > > > > > 	I tend to view your response below as yet another
> > > > > > reason why RBridges MUST use a common path for unicast and
> > > > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > > > fact, it is a very good reason to limit use of 
> "multipathing"
> > > > > > in general.
> > > > >
> > > > > If we do place those constraints then it would
> > > > > cripple the technology and make it very uninteresting
> > > > > (at least to me).
> > > > >
> > > > > > 	It is not clear exactly what you mean by your reference
> > > > > > to differences between control and data paths.  Control
> > > > > > messages are from one RBridge to another and - presumably -
> > > > > > follow the same path as data addressed from RBridge to
> > > > > > RBridge.  That path may be different from data 
> transitting an
> > > > > > RBridge campus, but there is no RBridge "control" traffic
> > > > > > that transits a campus.
> > > > > >
> > > > > > 	Are you suggesting that IGMP should be treated as a
> > > > > > control protocol within TRILL?
> > > > >
> > > > > In this case, when I said control I meant IGMP (since
> > > > > that is what is being used to effect pruning).  If we
> > > > > snoop on the information at the edge of the trill
> > > > > cloud and pass this information around in IS-IS, then we don't
> > > > > need to worry about treating it as a separate control
> > > > > protocol.
> > > > >
> > > > > >
> > > > > > 	Nor is it very clear why this observation is specific
> > > > > > to our discussion of multicast optimization.  As a general
> > > > > > rule, if there is one reasonably well know application that
> > > > > > relies on path congruency for proper operation, there are
> > > > > > probably others.
> > > > > >
> > > > > > 	Do you think we should provide a logical
> > > > > > control-function "bridging" service for all such 
> applications
> > > > > > as a result of path divergences we introduce?  Should we
> > > > > > conduct a research project to determine what other "control
> > > > > > protocols" we need to include in TRILL?
> > > > >
> > > > > We would need to make a list of everything that bridges
> > > > > snoop on and make sure we have ways of sending that
> > > > > around in IS-IS (if we care about those functions).
> > > > > I'm not aware of anything other than IGMP that trill
> > > > > would need to worry about, though.
> > > > >
> > > > > Anoop
> > > > >
> > > >
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [e-mail]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> 



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5K4KIXM025148 for <[e-mail]>; Tue, 19 Jun 2007 21:20:18 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-128.messagelabs.com!1182313216!598770!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 5413 invoked from network); 20 Jun 2007 04:20:17 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 20 Jun 2007 04:20:17 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5K4KGPD008192 for <[e-mail]>; Tue, 19 Jun 2007 21:20:16 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5K4KGhq015504 for <[e-mail]>; Tue, 19 Jun 2007 23:20:16 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5K4KFMu015493 for <[e-mail]>; Tue, 19 Jun 2007 23:20:15 -0500 (CDT)
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, 20 Jun 2007 00:20:13 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
thread-index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIAAvcbTAAB3PRFAAARhtgAAEXWZwAACFmXAAAZ/mIAA/iTlA
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5K4KIXM025148
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 04:20:41 -0000
Status: RO
Content-Length: 6490

Hi Anoop,

See below at ### 

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Monday, June 18, 2007 5:51 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

Donald,

By "trill core", I meant an rBridge that is connected
only to other rBridges (i.e. a device that has only 
"trill" ports).

### OK. I have the impression that, to at least some extent, people
organize bridges that way because of the nature of spanning tree.
Rbridges are much better at doing good forwarding in a more general
mesh, so their should be at least a little less reason to organize
things into "core" and "non-core". But perhaps this effect will be
small.

I think there's another notion of port state
for rBridges in the trill core - they drop
multicast frames that are received on a port
if that port is not in the tree as indicated
by the egress rBridge address.

### That seems closer to Link State than port state, which I've always
thought of as binary. In spanning tree, a port is either forwarding or
not. In Rbridges, a port is either DRB or not. The test you mention is
useful for any Rbridge that is directly connected to two other Rbridges.
The utility of the test has nothing to do with whether or not there are
end stations connected to the Rbridge, that is to say whether or not it
is "core". Furthermore, since TRILL Ethertype frames get through to an
Rbridge regardless of the "port state" in the sense that I'm using port
state, using my vocabulary, that check has nothing to do with "port
state".

                                However, this
behavior cannot be applied to IS-IS frames.

### The behavior does not make sense for "core instance" (a different
use of "core") TRILL IS-IS frames because they only ever go one hop. But
it makes perfect sense and should be applied to per VLAN instance TRILL
IS-IS frames which are multicast and, in general, multi-hop.

So while edge rBridges have DRB state, 
core rBridges need to have tree state for
all of the trees on all of their trill ports.

### Unless you do some configuration or the link medium is
point-to-point, every Rbridge port has a DRB state. As I say, any
Rbridge that is connected to two or more other Rbridges will usefully do
tree checks. So, unless your "edge Rbridges" are only singly connected
to other Rbridges, they need to do the check also.

Since unicast frames never get filtered, if the

### That's not the case anymore. The WG favored adding a check to
discard any TRILL data frames, including unicast TRILL data frames, that
arrive on a port that has no IS-IS adjacency on it.

core IS-IS instance used a special multicast
address, that would be enough for achieving 
the above function.

### Sorry, you've lost me above.

### Thanks,
### Donald

Ethertype can also be used as you point out.

Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 2:32 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Anoop,
> 
> See below at @@@
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Monday, June 18, 2007 4:51 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Donald,
> 
> I think Silvano mentioned it is better to use a multicast MAC 
> address to identify IS-IS frames.
> I assume this refers to the core IS-IS instance.
> 
> @@ I may be wrong but I thought he wanted to use a different 
> multicast address for all TRILL IS-IS frames because they are 
> control messages and thus should get through when an Rbridge 
> port is "blocked" (not DRB). But TRILL data frames should get 
> through also.
> 
> Then you mentioned that we wouldn't really need to do 
> filtering in the trill core based on port state.
> 
> @@2 What is the "trill core"? If you are not DRB for some 
> port/VLAN, you need to discard incoming native data frames 
> and not emit native data frames no matter where in the campus you are.
> 
> At which point I clarified that in the trill core, when an 
> rBridge receives a frame it is required to filter multicast 
> frames if they are received on a port which is not part of 
> the tree indicated by the egress rBridge address.
> 
> @@@ Sorry, but I find you use of "filter" a little confusing. 
> Yes, that check and others are performed on multicast TRILL 
> frames when they are received by any Rbridge. I still don't 
> know what you mean by "trill core". There are no "trill core 
> Rbridges" as opposed to "peripheral trill Rbridges" or something...
> 
> Thus there is some dependence on port state even in the TRILL 
> core and the kind of frames that the rBridge would be willing 
> to accept and process from a port.
> 
> @@@ To me, "port state" for an Rbridge is whether it is 
> Designated Rbridge for a particular port/VLAN. Sure, this 
> affects whether or not it will accept or emit native data 
> frames. But this "port state" has no effect on whether it 
> will process any TRILL Ethertype frame. Nor does the "port 
> state" have any effect on whether that TRILL frame meets any 
> of the various tests such as, if it is multicast, the tree 
> test you mention.
> 
> We could use the Ethertype or the MAC address for this 
> filtering, but right now, with the MAC address for all 
> multicast frames being set to all-rbridges, it looks like the 
> only option we have is to use the Ethertype.
> That's fine too.
> 
> @@@ All frames sent to the All-Rbridges multicast address are 
> TRILL Ethertype. There are also unicast TRILL data frames. 
> How a frame is affected by port state corresponds to whether 
> or not it is TRILL Ethertype. How a frame is affected by port 
> state does not correspond with whether or not it is sent to 
> the All-Rbridges multicast address.
> The filtering on port state has nothing to do with whether a 
> frame is "TRILL IS-IS" versus "TRILL data".  I do not see how 
> port filtering would be helped by having a different TRILL 
> IS-IS multicast address.
> Whether there are one or two multicast addresses, it is still 
> the case that trying to filter based on a combination of port 
> state and multicast
> address(es) will be incorrect but filtering based on port 
> state and Ethertype will be correct.
> 
> Anoop
> 
> @@@ Donald
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5K3cwX2016006 for <[e-mail]>; Tue, 19 Jun 2007 20:38:58 -0700 (PDT)
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: Tue, 19 Jun 2007 20:38:58 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgABRo0SA=
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5K3cwX2016006
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 03:39:39 -0000
Status: RO
Content-Length: 7375

We had this discussion on May 8th, 2007 on this mailing list.

In a nutshell: we do ECMP only in the core, but we don't learn in the
core, so I don't see the problem.

-- Silvano

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Tuesday, June 19, 2007 7:14 AM
> To: Silvano Gai; Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Silvano,
> 
> 	Your response is confusing.  If we are not expected to
> preserve forwarding symmetry, have we given up on presumed
> compatibility with standard bridges?
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 9:13 AM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> >
> >
> > Eric,
> >
> > You say: "we're expected to preserve forwarding symmetry".
> >
> > WE ARE NOT.
> >
> > Where does the current draft preserve forwarding symmetry?
> >
> > In regard to your conclusions, many of us (Anoop , Dinesh and I for
> > sure) are participating because we are building real products.
> >
> > I don't buy your argument that "Very uninteresting
> > (technology) is very
> > good."
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: [e-mail]
[mailto:[e-mail]]
> > On
> > > Behalf Of Eric Gray (LO/EUS)
> > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > >
> > > Anoop,
> > >
> > > 	I think we strongly disagree on what it means to incorporate
> > > something in the control protocol.  From there, it is likely that
> > > we also disagree on how best to avoid doing so.
> > >
> > > 	Figuring out how to correctly carry IGMP-snooped information
> > > in TRILL protocol is effectively the same thing as incorporating
> > > IGMP in the control protocol.
> > >
> > > 	Making a list of everything that bridges snoop and ensuring
> > > we can also include that information in IS-IS is exactly the sort
> > > of thing we should be trying to avoid.  The good news is that it
> > > also should be easy to avoid.
> > >
> > > 	Whatever protocols we might use, TRILL is essentially a layer
> > > two forwarding technology.  The messages that layer two forwarding
> > > technologies want to snoop are visible to the devices involved in
> > > forwarding.  Unless devices actively interfere with "normal" layer
> > > two forwarding, "external" control messages should be no different
> > > than any other form of data - as far as RBridges are concerned -
> > > and should be forwarded in the same way.
> > >
> > > 	We know that we're expected to preserve forwarding symmetry
> > > - at least for the layer two encapsulation of TRILL frames. In the
> > > same way, and for similar reasons, we may need to preserve path
> > > congruency.  This is implicit in the decision to learn from data
> > > in the unicast case.
> > >
> > > 	What we don't know is the complete list of things that depend
> > > on our doing that.  But we can compose a partial list, and it
seems
> > > to me that "snooping" (in general) is one example, OA&M may well
be
> > > another and there are bound to be more.
> > >
> > > 	As for the notion of "crippling the technology and making it
> > > very uninteresting" - well, to many people, technology becomes
very
> > > interesting when it is very complicated to make it work.  For the
> > > users of any technology, it is only truly useful when it is not
very
> > > interesting.
> > >
> > > 	Paraphrasing something a colleague once told me: a technology
> > > is only really useful when the interesting thing in using it is
not
> > > about the technology, but about its use.  Put another way, you
know
> > > that transportation is useful when the interesting thing about
using
> > > it is arriving at the destination - rather than the trip itself.
> > >
> > > 	Uninteresting is good.  Very uninteresting is very good.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > To: Eric Gray (LO/EUS)
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > Anoop,
> > > > >
> > > > > 	I tend to view your response below as yet another
> > > > > reason why RBridges MUST use a common path for unicast and
> > > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > > fact, it is a very good reason to limit use of "multipathing"
> > > > > in general.
> > > >
> > > > If we do place those constraints then it would
> > > > cripple the technology and make it very uninteresting
> > > > (at least to me).
> > > >
> > > > > 	It is not clear exactly what you mean by your reference
> > > > > to differences between control and data paths.  Control
> > > > > messages are from one RBridge to another and - presumably -
> > > > > follow the same path as data addressed from RBridge to
> > > > > RBridge.  That path may be different from data transitting an
> > > > > RBridge campus, but there is no RBridge "control" traffic
> > > > > that transits a campus.
> > > > >
> > > > > 	Are you suggesting that IGMP should be treated as a
> > > > > control protocol within TRILL?
> > > >
> > > > In this case, when I said control I meant IGMP (since
> > > > that is what is being used to effect pruning).  If we
> > > > snoop on the information at the edge of the trill
> > > > cloud and pass this information around in IS-IS, then we don't
> > > > need to worry about treating it as a separate control
> > > > protocol.
> > > >
> > > > >
> > > > > 	Nor is it very clear why this observation is specific
> > > > > to our discussion of multicast optimization.  As a general
> > > > > rule, if there is one reasonably well know application that
> > > > > relies on path congruency for proper operation, there are
> > > > > probably others.
> > > > >
> > > > > 	Do you think we should provide a logical
> > > > > control-function "bridging" service for all such applications
> > > > > as a result of path divergences we introduce?  Should we
> > > > > conduct a research project to determine what other "control
> > > > > protocols" we need to include in TRILL?
> > > >
> > > > We would need to make a list of everything that bridges
> > > > snoop on and make sure we have ways of sending that
> > > > around in IS-IS (if we care about those functions).
> > > > I'm not aware of anything other than IGMP that trill
> > > > would need to worry about, though.
> > > >
> > > > Anoop
> > > >
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> >



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5K3bZYI015690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 19 Jun 2007 20:37:35 -0700 (PDT)
Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5K3bIru016747; Tue, 19 Jun 2007 20:37:18 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 19 Jun 2007 20:37:08 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5FF19A71A7494599F06547D0"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 03:38:08 -0000
Status: RO
Content-Length: 2326

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5FF19A71A7494599F06547D0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Anoop Ghanwani wrote:
> =20
> Joe,
>=20
>> And, as Eric notes later, a common path between the two is=20
>> needed at L2.
>=20
> Sorry, this thread is starting to get long and=20
> I'm losing context.  A common path between what two?
> Control and data?  As I pointed out the control
> packets (e.g. if MMRP were being used) do not
> even make it into the LAN between the rbridges.
> The rbridges would have to initiate such messages
> and I don't know what would cause them to intiate
> such messages.

I was presuming a common path for multicast at L3 and unicast at L3,
e.g., IPv6 neighbor discovery and unicast replies.

>> As to the pruning that Anoop later notes, I don't consider pruning an
>> issue for an L2 system. Although I appreciate pruning as an
>> optimization, I don't consider it a design requirement. If it were, we=

>> would be talking about scalability beyond existing bridge=20
>> capabilities,
>> which has been off the table from the start.
>=20
> Well, existing bridges do actually do
> pruning today - and they have for years.
> rBridges without multicast pruning would be
> step (or perhaps two) back.

There are bridges built into a variety of devices that are a lot simpler
than the typical COTS stand-alone device. Further, the extent to which
rbridges even benefit from pruning is different than regular bridges,
because there can be multiple paths for different traffic in rbridges.
I.e., this is still just an optimization, and one that may be less
important in this environment.

Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enig5FF19A71A7494599F06547D0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGeKDuE5f5cImnZrsRAnrgAKDlXOXCZEhck0GhTj+GI7W3etLYWgCgqi3R
MuhaPVE7tOX8UJ1WPUKAb5c=
=o2aQ
-----END PGP SIGNATURE-----

--------------enig5FF19A71A7494599F06547D0--


Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5K2G6v1028805 for <[e-mail]>; Tue, 19 Jun 2007 19:16:06 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-153.messagelabs.com!1182305765!1913954!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 16924 invoked from network); 20 Jun 2007 02:16:05 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 20 Jun 2007 02:16:05 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5K2G5QB011504 for <[e-mail]>; Tue, 19 Jun 2007 19:16:05 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5K2G4rT009642 for <[e-mail]>; Tue, 19 Jun 2007 21:16:05 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5K2G3nY009632 for <[e-mail]>; Tue, 19 Jun 2007 21:16:04 -0500 (CDT)
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: Tue, 19 Jun 2007 22:15:52 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvAABYkSAA==
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5K2G6v1028805
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 02:16:33 -0000
Status: RO
Content-Length: 3529

Hi Anoop,

No, it shouldn't get delivered to every end station unless it is
broadcast or a layer 2 multicast not derived from an IP address.

If it is an layer 2 multicast address derived from an IP address, then
Rbridges should prune the distribution tree and the links they
decapsulate and forward onto to those with listeners for an IP multicast
address that corresponds to that layer 2 multicast address or with an IP
multicast router.

Donald

PS: All the above is scoped by VLAN as well.

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Tuesday, June 19, 2007 7:32 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]; Caitlin Bestler
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

What if there are no IP multicast routers or
listeners in the bridged LAN between the
rBridges?  Does that mean a copy of the trill
frame gets delivered to every station in that
LAN?

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 12:51 PM
> To: Anoop Ghanwani
> Cc: [e-mail]; Caitlin Bestler
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> In addition to what Caitlin says, I would point out that, if there are
> multicast listeners or IP multicast routers in this bridged LAN (which
> looks to the Rbridges pretty much like a single multi-access 
> link), then
> the Rbridges should have heard about them and the Designated 
> Rbridge for
> the VLAN in question for that cloud will also decapsulate appropriate
> data/multicast-control and send it into the cloud as native 
> (non-TRILL)
> frames whose distribution within the cloud the bridges are welcome to
> try to optimize as much as they like.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Caitlin Bestler
> Sent: Tuesday, June 19, 2007 3:16 PM
> To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> [e-mail] wrote:
> > Eric,
> > 
> > It depends on what we mean by compatibility.
> > One can always say that if one cares about such and such
> > compatibility then here's a way to solve it.
> > 
> > Even if trill were to impose the constraint you suggest, many
> > things will break.  For example, if I have a topology with a
> > bridged cloud between 2 trill devices, then the traffic going
> > between the trill devices will not be "snoopable" by the
> > bridges because they won't understand trill encapsulation.
> > 
> 
> Why are these intermediate bridges snooping?
> 
> The only service being requested of them is to relay Ethernet
> frames from the ingress rbridge to the egress rbridge. Is that
> not implied by their being a cloud *between* 2 trill devices?
> 
> How is this different from any tunnel? You have traffic that
> a middlebox might have optimized had it been untunelled, but
> that it does not see when tunneled. It cannot provide its service,
> but it is not being asked to do so.
> 
> A non-rbridge bridge forwards packets without understanding that
> they are rbridge encapsulated frames. I always thought that this
> was a strength of the proposal, not a weakness. You can't be
> snoopable and opaque. Opaque is better.
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JNf8uN024065 for <[e-mail]>; Tue, 19 Jun 2007 16:41:08 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 19 Jun 2007 16:41:08 -0700
X-IronPort-AV: i="4.16,440,1175497200";  d="scan'208"; a="13883734:sNHT18228119"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 09BCB23836C; Tue, 19 Jun 2007 16:38:47 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jun 2007 16:41:08 -0700
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: Tue, 19 Jun 2007 16:40:49 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AceywBJJQ8u6AtSdTtu77peBB6QHogACqvfg
From: "Anoop Ghanwani" <[e-mail]>
To: "Joe Touch" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 23:41:08.0786 (UTC) FILETIME=[4FA7F120:01C7B2CB]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JNf8uN024065
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 23:41:25 -0000
Status: RO
Content-Length: 938

 
Joe,

> And, as Eric notes later, a common path between the two is 
> needed at L2.

Sorry, this thread is starting to get long and 
I'm losing context.  A common path between what two?
Control and data?  As I pointed out the control
packets (e.g. if MMRP were being used) do not
even make it into the LAN between the rbridges.
The rbridges would have to initiate such messages
and I don't know what would cause them to intiate
such messages.
 
> As to the pruning that Anoop later notes, I don't consider pruning an
> issue for an L2 system. Although I appreciate pruning as an
> optimization, I don't consider it a design requirement. If it were, we
> would be talking about scalability beyond existing bridge 
> capabilities,
> which has been off the table from the start.

Well, existing bridges do actually do
pruning today - and they have for years.
rBridges without multicast pruning would be
step (or perhaps two) back.

Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JNWmRx022324 for <[e-mail]>; Tue, 19 Jun 2007 16:32:53 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 19 Jun 2007 16:32:48 -0700
X-IronPort-AV: i="4.16,440,1175497200";  d="scan'208"; a="11123805:sNHT20183086"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id C856123836C; Tue, 19 Jun 2007 16:30:26 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jun 2007 16:32:48 -0700
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: Tue, 19 Jun 2007 16:32:29 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkAAAf4HvA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 23:32:48.0551 (UTC) FILETIME=[257E2370:01C7B2CA]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JNWmRx022324
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 23:33:24 -0000
Status: RO
Content-Length: 2798

Donald,

What if there are no IP multicast routers or
listeners in the bridged LAN between the
rBridges?  Does that mean a copy of the trill
frame gets delivered to every station in that
LAN?

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 12:51 PM
> To: Anoop Ghanwani
> Cc: [e-mail]; Caitlin Bestler
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> In addition to what Caitlin says, I would point out that, if there are
> multicast listeners or IP multicast routers in this bridged LAN (which
> looks to the Rbridges pretty much like a single multi-access 
> link), then
> the Rbridges should have heard about them and the Designated 
> Rbridge for
> the VLAN in question for that cloud will also decapsulate appropriate
> data/multicast-control and send it into the cloud as native 
> (non-TRILL)
> frames whose distribution within the cloud the bridges are welcome to
> try to optimize as much as they like.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Caitlin Bestler
> Sent: Tuesday, June 19, 2007 3:16 PM
> To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> [e-mail] wrote:
> > Eric,
> > 
> > It depends on what we mean by compatibility.
> > One can always say that if one cares about such and such
> > compatibility then here's a way to solve it.
> > 
> > Even if trill were to impose the constraint you suggest, many
> > things will break.  For example, if I have a topology with a
> > bridged cloud between 2 trill devices, then the traffic going
> > between the trill devices will not be "snoopable" by the
> > bridges because they won't understand trill encapsulation.
> > 
> 
> Why are these intermediate bridges snooping?
> 
> The only service being requested of them is to relay Ethernet
> frames from the ingress rbridge to the egress rbridge. Is that
> not implied by their being a cloud *between* 2 trill devices?
> 
> How is this different from any tunnel? You have traffic that
> a middlebox might have optimized had it been untunelled, but
> that it does not see when tunneled. It cannot provide its service,
> but it is not being asked to do so.
> 
> A non-rbridge bridge forwards packets without understanding that
> they are rbridge encapsulated frames. I always thought that this
> was a strength of the proposal, not a weakness. You can't be
> snoopable and opaque. Opaque is better.
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JL64OT004159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 19 Jun 2007 14:06:04 -0700 (PDT)
Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5JL5g43006522; Tue, 19 Jun 2007 14:05:42 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 19 Jun 2007 14:05:16 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDAA30FA3CA606D0A59A50451"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 21:06:28 -0000
Status: RO
Content-Length: 1715

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDAA30FA3CA606D0A59A50451
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Anoop Ghanwani wrote:
> =20
>=20
>> -----Original Message-----
>> From: Eric Gray (LO/EUS) [mailto:[e-mail]]=20
=2E..
>> In fact, I believe it is the case that most networks use IP=20
>> multicast almost exclusively for routing protocols (for which=20
>> we have previously concluded IGMP snooping does not work).
>=20
> I'd recommend looking at some of the IP multicast
> applications that enterprises deploy.  It's not just
> routing protocols.

IPv6 uses multicast for neighbor discovery too.

And, as Eric notes later, a common path between the two is needed at L2.

As to the pruning that Anoop later notes, I don't consider pruning an
issue for an L2 system. Although I appreciate pruning as an
optimization, I don't consider it a design requirement. If it were, we
would be talking about scalability beyond existing bridge capabilities,
which has been off the table from the start.

Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enigDAA30FA3CA606D0A59A50451
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGeEUME5f5cImnZrsRAn/jAKDpsBm0KpWdRxEdYCU9tbHURYnzQgCfSAbg
gtlpR5n8QJpCx/gwZXdt+pI=
=YfDQ
-----END PGP SIGNATURE-----

--------------enigDAA30FA3CA606D0A59A50451--


Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5JL56H6003891 for <[e-mail]>; Tue, 19 Jun 2007 14:05:06 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-6.tower-119.messagelabs.com!1182287104!12932927!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.189.100.105]
Received: (qmail 7507 invoked from network); 19 Jun 2007 21:05:05 -0000
Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-119.messagelabs.com with SMTP; 19 Jun 2007 21:05:05 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l5JL54NH026891 for <[e-mail]>; Tue, 19 Jun 2007 14:05:04 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5JL5395005063 for <[e-mail]>; Tue, 19 Jun 2007 16:05:04 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5JL52Me005044 for <[e-mail]>; Tue, 19 Jun 2007 16:05:02 -0500 (CDT)
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: Tue, 19 Jun 2007 17:05:01 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAEG/WAAAFjFMAAMNAKQ
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JL56H6003891
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 21:05:21 -0000
Status: RO
Content-Length: 3562

Hi Eric,

Well, I read some of the earlier messages in this email thread and I'm
not sure if I'm more or less confused than I was.

I now assume that what you are talking about is bridge learning of MAC
addresses inside a bridged LAN that's between two or more Rbridges. If
my guess is right, then I don't see why it makes any difference whether
TRILL data frames do or do not pass through in such a
symmetric/congruent/whatever way that the learning you would want
happens. The periodic TRILL IS-IS Hellos will cause the learning you
need inside the bridged LAN for transit traffic between Rbridges.

If I'm wrong, perhaps you could be more explicit about what you are
saying and what you mean by "forwarding symmetry" and "congruent paths".

Donald

(some of thread below but earliest parts deleted)

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
Sent: Tuesday, June 19, 2007 11:12 AM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

	If you look at the entire statement (from which Silvano
excerpted a partial quote), it says:

"We know that we're expected to preserve forwarding symmetry
 - at least for the layer two encapsulation of TRILL frames."

This is necessary for "compatibility" with intermediate LAN
bridges.  This refers to the L2 encapsulation that "protects"
the TRILL header (which - as you say - protects the SA/DA of
the internal frames).

	I did not suppose that Silvano was being disingenuous 
in his partial quote, but - based on your comment - perhaps 
I should have re-inserted the actual context anyway.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 10:50 AM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> What does "compatibility" mean?
> 
> I believe forwarding symmetry has to do with address learning 
> at transit
> bridges. But, with Rbridges, transit bridges don't learn the actual
> source and destination of the data once it has been protected 
> by a TRILL
> Header. So forwarding symmetry is no longer of any significance.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, June 19, 2007 10:14 AM
> To: Silvano Gai; Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Silvano,
> 
> 	Your response is confusing.  If we are not expected to 
> preserve forwarding symmetry, have we given up on presumed 
> compatibility with standard bridges?
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]] 
> > Sent: Tuesday, June 19, 2007 9:13 AM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> > 
> > 
> > Eric,
> > 
> > You say: "we're expected to preserve forwarding symmetry".
> > 
> > WE ARE NOT.
> > 
> > Where does the current draft preserve forwarding symmetry?
> > 
> > In regard to your conclusions, many of us (Anoop , Dinesh and I for
> > sure) are participating because we are building real products. 
> > 
> > I don't buy your argument that "Very uninteresting 
> > (technology) is very
> > good."
> > 
> > -- Silvano



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JKVWjj023565 for <[e-mail]>; Tue, 19 Jun 2007 13:31:32 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 19 Jun 2007 13:31:32 -0700
X-IronPort-AV: i="4.16,439,1175497200";  d="scan'208"; a="11121104:sNHT21491113"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 0E76E23836C; Tue, 19 Jun 2007 13:29:11 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jun 2007 13:31:32 -0700
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: Tue, 19 Jun 2007 13:31:13 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAACve1w
From: "Anoop Ghanwani" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Eric Gray (LO/EUS)" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 20:31:32.0864 (UTC) FILETIME=[D3140000:01C7B2B0]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JKVWjj023565
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 20:31:58 -0000
Status: RO
Content-Length: 2421

 

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 12:16 PM
> To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> [e-mail] wrote:
> > Eric,
> > 
> > It depends on what we mean by compatibility.
> > One can always say that if one cares about such and such
> > compatibility then here's a way to solve it.
> > 
> > Even if trill were to impose the constraint you suggest, many
> > things will break.  For example, if I have a topology with a
> > bridged cloud between 2 trill devices, then the traffic going
> > between the trill devices will not be "snoopable" by the
> > bridges because they won't understand trill encapsulation.
> > 
> 
> Why are these intermediate bridges snooping?

They're snooping because they too care about
pruning their trees for a given multicast group
and that would be one of the ways to achieve it.
Otherwise, all multicasts would have to be 
broadcast on the spanning tree interconnecting
the bridged network that sits between the two
rBridges.

> The only service being requested of them is to relay Ethernet
> frames from the ingress rbridge to the egress rbridge. Is that
> not implied by their being a cloud *between* 2 trill devices?

If we didn't care about multicast pruning,
we wouldn't need to worry about any of this.

> How is this different from any tunnel? You have traffic that
> a middlebox might have optimized had it been untunelled, but
> that it does not see when tunneled. It cannot provide its service,
> but it is not being asked to do so.

Most tunnels are point to point and that makes
life easy.  It's when you have multicast that
things start to get a bit tricky.

> A non-rbridge bridge forwards packets without understanding that
> they are rbridge encapsulated frames. I always thought that this
> was a strength of the proposal, not a weakness. You can't be
> snoopable and opaque. Opaque is better.

Opaque is best if you're not depending on
the inner stuff to tell you where to go.  The
current rbridge spec looks all over the inner
L2 header to figure out where to send the frame.
I wouldn't exactly call that opaque.

At that point, you have to use what the
same (or similar) controls to those used
by devices that forward using that header
(in this case bridges).

Anoop



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5JJpJMp011803 for <[e-mail]>; Tue, 19 Jun 2007 12:51:19 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-153.messagelabs.com!1182282674!1891058!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.7]
Received: (qmail 2031 invoked from network); 19 Jun 2007 19:51:14 -0000
Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-15.tower-153.messagelabs.com with SMTP; 19 Jun 2007 19:51:14 -0000
Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l5JJpD5A009499 for <[e-mail]>; Tue, 19 Jun 2007 12:51:13 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5JJpB8A029106 for <[e-mail]>; Tue, 19 Jun 2007 14:51:11 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JJpAja029076 for <[e-mail]>; Tue, 19 Jun 2007 14:51:10 -0500 (CDT)
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: Tue, 19 Jun 2007 15:51:08 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEAABWhkA
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JJpJMp011803
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 19:51:58 -0000
Status: RO
Content-Length: 2203

In addition to what Caitlin says, I would point out that, if there are
multicast listeners or IP multicast routers in this bridged LAN (which
looks to the Rbridges pretty much like a single multi-access link), then
the Rbridges should have heard about them and the Designated Rbridge for
the VLAN in question for that cloud will also decapsulate appropriate
data/multicast-control and send it into the cloud as native (non-TRILL)
frames whose distribution within the cloud the bridges are welcome to
try to optimize as much as they like.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Caitlin Bestler
Sent: Tuesday, June 19, 2007 3:16 PM
To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
Cc: [e-mail]; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

[e-mail] wrote:
> Eric,
> 
> It depends on what we mean by compatibility.
> One can always say that if one cares about such and such
> compatibility then here's a way to solve it.
> 
> Even if trill were to impose the constraint you suggest, many
> things will break.  For example, if I have a topology with a
> bridged cloud between 2 trill devices, then the traffic going
> between the trill devices will not be "snoopable" by the
> bridges because they won't understand trill encapsulation.
> 

Why are these intermediate bridges snooping?

The only service being requested of them is to relay Ethernet
frames from the ingress rbridge to the egress rbridge. Is that
not implied by their being a cloud *between* 2 trill devices?

How is this different from any tunnel? You have traffic that
a middlebox might have optimized had it been untunelled, but
that it does not see when tunneled. It cannot provide its service,
but it is not being asked to do so.

A non-rbridge bridge forwards packets without understanding that
they are rbridge encapsulated frames. I always thought that this
was a strength of the proposal, not a weakness. You can't be
snoopable and opaque. Opaque is better.





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



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5JJLtbx003552 for <[e-mail]>; Tue, 19 Jun 2007 12:21:55 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-119.messagelabs.com!1182280912!22685654!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 12616 invoked from network); 19 Jun 2007 19:21:52 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-119.messagelabs.com with SMTP; 19 Jun 2007 19:21:52 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l5JJLplT008564 for <[e-mail]>; Tue, 19 Jun 2007 12:21:51 -0700 (MST)
Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5JJLo8Z023916 for <[e-mail]>; Tue, 19 Jun 2007 14:21:51 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5JJLnaA023900 for <[e-mail]>; Tue, 19 Jun 2007 14:21:50 -0500 (CDT)
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: Tue, 19 Jun 2007 15:21:48 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rbridge/TRILL Related Terminology
thread-index: AceypxUmluU/ldNhSTCELj7rrJq8aQ==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JJLtbx003552
Subject: [rbridge] Rbridge/TRILL Related Terminology
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 19:22:20 -0000
Status: RO
Content-Length: 333

Hi,

The terminology used in the different TRILL working group drafts has
been inconsistent. As a step towards fixing this, the listed authors of
the working group drafts have come up with proposed common terminology.
This is now available at
<http://www.postel.org/rbridge/terminology.html>.

Comments are welcome.

Thanks,
Donald



Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JJGqms002016 for <[e-mail]>; Tue, 19 Jun 2007 12:16:52 -0700 (PDT)
Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 19 Jun 2007 12:16:39 -0700
X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A2FE22B0; Tue, 19 Jun 2007 12:16:39 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 785312AF; Tue, 19 Jun 2007 12:16:39 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FJY89599; Tue, 19 Jun 2007 12:16:35 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id D07B369CA6; Tue, 19 Jun 2007 12:16:34 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 19 Jun 2007 12:16:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoAAAfbvEA==
From: "Caitlin Bestler" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eric Gray (LO/EUS)" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-WSS-ID: 6A66F41D3CG12242526-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JJGqms002016
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 19:17:19 -0000
Status: RO
Content-Length: 1212

[e-mail] wrote:
> Eric,
> 
> It depends on what we mean by compatibility.
> One can always say that if one cares about such and such
> compatibility then here's a way to solve it.
> 
> Even if trill were to impose the constraint you suggest, many
> things will break.  For example, if I have a topology with a
> bridged cloud between 2 trill devices, then the traffic going
> between the trill devices will not be "snoopable" by the
> bridges because they won't understand trill encapsulation.
> 

Why are these intermediate bridges snooping?

The only service being requested of them is to relay Ethernet
frames from the ingress rbridge to the egress rbridge. Is that
not implied by their being a cloud *between* 2 trill devices?

How is this different from any tunnel? You have traffic that
a middlebox might have optimized had it been untunelled, but
that it does not see when tunneled. It cannot provide its service,
but it is not being asked to do so.

A non-rbridge bridge forwards packets without understanding that
they are rbridge encapsulated frames. I always thought that this
was a strength of the proposal, not a weakness. You can't be
snoopable and opaque. Opaque is better.







Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JIggH2022511 for <[e-mail]>; Tue, 19 Jun 2007 11:42:42 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 19 Jun 2007 11:42:31 -0700
X-IronPort-AV: i="4.16,439,1175497200";  d="scan'208"; a="13868926:sNHT24640161"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id D4E1323836C; Tue, 19 Jun 2007 11:40:09 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jun 2007 11:42:31 -0700
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: Tue, 19 Jun 2007 11:42:12 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAADuPywA==
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 18:42:31.0561 (UTC) FILETIME=[98285F90:01C7B2A1]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JIggH2022511
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 18:42:45 -0000
Status: RO
Content-Length: 5577

Eric,

What makes a technology interesting to me is
whether or not it is capable of satisfying the
needs of our customer.  If trill doesn't solve
that problem, it becomes uninteresting to me 
and I will have to find another way to solve it.

Anoop 

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 5:27 AM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> 	I think we strongly disagree on what it means to incorporate
> something in the control protocol.  From there, it is likely that
> we also disagree on how best to avoid doing so.
> 
> 	Figuring out how to correctly carry IGMP-snooped information 
> in TRILL protocol is effectively the same thing as incorporating 
> IGMP in the control protocol.
> 
> 	Making a list of everything that bridges snoop and ensuring
> we can also include that information in IS-IS is exactly the sort 
> of thing we should be trying to avoid.  The good news is that it 
> also should be easy to avoid.
> 
> 	Whatever protocols we might use, TRILL is essentially a layer
> two forwarding technology.  The messages that layer two forwarding
> technologies want to snoop are visible to the devices involved in
> forwarding.  Unless devices actively interfere with "normal" layer 
> two forwarding, "external" control messages should be no different 
> than any other form of data - as far as RBridges are concerned - 
> and should be forwarded in the same way.
> 
> 	We know that we're expected to preserve forwarding symmetry
> - at least for the layer two encapsulation of TRILL frames. In the 
> same way, and for similar reasons, we may need to preserve path 
> congruency.  This is implicit in the decision to learn from data 
> in the unicast case.
> 
> 	What we don't know is the complete list of things that depend
> on our doing that.  But we can compose a partial list, and it seems
> to me that "snooping" (in general) is one example, OA&M may well be 
> another and there are bound to be more.
> 
> 	As for the notion of "crippling the technology and making it 
> very uninteresting" - well, to many people, technology becomes very
> interesting when it is very complicated to make it work.  For the
> users of any technology, it is only truly useful when it is not very
> interesting.  
> 
> 	Paraphrasing something a colleague once told me: a technology
> is only really useful when the interesting thing in using it is not 
> about the technology, but about its use.  Put another way, you know 
> that transportation is useful when the interesting thing about using
> it is arriving at the destination - rather than the trip itself.
> 
> 	Uninteresting is good.  Very uninteresting is very good.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]] 
> > Sent: Monday, June 18, 2007 7:08 PM
> > To: Eric Gray (LO/EUS)
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> > 
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> > > Sent: Monday, June 18, 2007 11:43 AM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Anoop,
> > > 
> > > 	I tend to view your response below as yet another 
> > > reason why RBridges MUST use a common path for unicast and 
> > > multicast (as well as broadcast and flooded) traffic.  In 
> > > fact, it is a very good reason to limit use of "multipathing" 
> > > in general.
> > 
> > If we do place those constraints then it would
> > cripple the technology and make it very uninteresting
> > (at least to me).
> > 
> > > 	It is not clear exactly what you mean by your reference 
> > > to differences between control and data paths.  Control 
> > > messages are from one RBridge to another and - presumably - 
> > > follow the same path as data addressed from RBridge to 
> > > RBridge.  That path may be different from data transitting an 
> > > RBridge campus, but there is no RBridge "control" traffic 
> > > that transits a campus.
> > >
> > > 	Are you suggesting that IGMP should be treated as a 
> > > control protocol within TRILL?
> > 
> > In this case, when I said control I meant IGMP (since
> > that is what is being used to effect pruning).  If we
> > snoop on the information at the edge of the trill
> > cloud and pass this information around in IS-IS, then we don't
> > need to worry about treating it as a separate control
> > protocol.
> > 
> > > 
> > > 	Nor is it very clear why this observation is specific 
> > > to our discussion of multicast optimization.  As a general 
> > > rule, if there is one reasonably well know application that 
> > > relies on path congruency for proper operation, there are 
> > > probably others.  
> > >
> > > 	Do you think we should provide a logical 
> > > control-function "bridging" service for all such applications 
> > > as a result of path divergences we introduce?  Should we 
> > > conduct a research project to determine what other "control 
> > > protocols" we need to include in TRILL?
> > 
> > We would need to make a list of everything that bridges
> > snoop on and make sure we have ways of sending that
> > around in IS-IS (if we care about those functions).
> > I'm not aware of anything other than IGMP that trill
> > would need to worry about, though.
> > 
> > Anoop
> > 
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JIMMQP016422 for <[e-mail]>; Tue, 19 Jun 2007 11:22:22 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 19 Jun 2007 11:22:12 -0700
X-IronPort-AV: i="4.16,439,1175497200";  d="scan'208"; a="13867800:sNHT34562283"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id C97CC23836C; Tue, 19 Jun 2007 11:19:50 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jun 2007 11:22:12 -0700
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: Tue, 19 Jun 2007 11:21:53 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAhIBoA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>, "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 18:22:12.0460 (UTC) FILETIME=[C18452C0:01C7B29E]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JIMMQP016422
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 18:22:55 -0000
Status: RO
Content-Length: 8254

Eric,

It depends on what we mean by compatibility.
One can always say that if one cares about
such and such compatibility then here's a way
to solve it.  

Even if trill were to impose the constraint 
you suggest, many things will break.  For
example, if I have a topology with a bridged
cloud between 2 trill devices, then the 
traffic going between the trill devices will
not be "snoopable" by the bridges because they
won't understand trill encapsulation.
Additionally, in the above scenario something
like MMRP would break because the ingress rBridge
would terminate the MMRP message and the
bridge cloud would never see them (that's only
logical since rBridges terminate spanning trees
and MMRP runs in the context of a spanning tree).

So rBridges aren't as transparent as we'd 
like them to be.

We have to decide what problem we are trying 
to solve and then find creative ways to work
around those issues, possibly constraining
the deployment, but without cripping the 
technology.

Anoop

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 7:14 AM
> To: Silvano Gai; Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Silvano,
> 
> 	Your response is confusing.  If we are not expected to 
> preserve forwarding symmetry, have we given up on presumed 
> compatibility with standard bridges?
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]] 
> > Sent: Tuesday, June 19, 2007 9:13 AM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> > 
> > 
> > Eric,
> > 
> > You say: "we're expected to preserve forwarding symmetry".
> > 
> > WE ARE NOT.
> > 
> > Where does the current draft preserve forwarding symmetry?
> > 
> > In regard to your conclusions, many of us (Anoop , Dinesh and I for
> > sure) are participating because we are building real products. 
> > 
> > I don't buy your argument that "Very uninteresting 
> > (technology) is very
> > good."
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Eric Gray (LO/EUS)
> > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Anoop,
> > > 
> > > 	I think we strongly disagree on what it means to incorporate
> > > something in the control protocol.  From there, it is likely that
> > > we also disagree on how best to avoid doing so.
> > > 
> > > 	Figuring out how to correctly carry IGMP-snooped information
> > > in TRILL protocol is effectively the same thing as incorporating
> > > IGMP in the control protocol.
> > > 
> > > 	Making a list of everything that bridges snoop and ensuring
> > > we can also include that information in IS-IS is exactly the sort
> > > of thing we should be trying to avoid.  The good news is that it
> > > also should be easy to avoid.
> > > 
> > > 	Whatever protocols we might use, TRILL is essentially a layer
> > > two forwarding technology.  The messages that layer two forwarding
> > > technologies want to snoop are visible to the devices involved in
> > > forwarding.  Unless devices actively interfere with "normal" layer
> > > two forwarding, "external" control messages should be no different
> > > than any other form of data - as far as RBridges are concerned -
> > > and should be forwarded in the same way.
> > > 
> > > 	We know that we're expected to preserve forwarding symmetry
> > > - at least for the layer two encapsulation of TRILL frames. In the
> > > same way, and for similar reasons, we may need to preserve path
> > > congruency.  This is implicit in the decision to learn from data
> > > in the unicast case.
> > > 
> > > 	What we don't know is the complete list of things that depend
> > > on our doing that.  But we can compose a partial list, 
> and it seems
> > > to me that "snooping" (in general) is one example, OA&M 
> may well be
> > > another and there are bound to be more.
> > > 
> > > 	As for the notion of "crippling the technology and making it
> > > very uninteresting" - well, to many people, technology 
> becomes very
> > > interesting when it is very complicated to make it work.  For the
> > > users of any technology, it is only truly useful when it 
> is not very
> > > interesting.
> > > 
> > > 	Paraphrasing something a colleague once told me: a technology
> > > is only really useful when the interesting thing in using 
> it is not
> > > about the technology, but about its use.  Put another 
> way, you know
> > > that transportation is useful when the interesting thing 
> about using
> > > it is arriving at the destination - rather than the trip itself.
> > > 
> > > 	Uninteresting is good.  Very uninteresting is very good.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > To: Eric Gray (LO/EUS)
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > Anoop,
> > > > >
> > > > > 	I tend to view your response below as yet another
> > > > > reason why RBridges MUST use a common path for unicast and
> > > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > > fact, it is a very good reason to limit use of "multipathing"
> > > > > in general.
> > > >
> > > > If we do place those constraints then it would
> > > > cripple the technology and make it very uninteresting
> > > > (at least to me).
> > > >
> > > > > 	It is not clear exactly what you mean by your reference
> > > > > to differences between control and data paths.  Control
> > > > > messages are from one RBridge to another and - presumably -
> > > > > follow the same path as data addressed from RBridge to
> > > > > RBridge.  That path may be different from data transitting an
> > > > > RBridge campus, but there is no RBridge "control" traffic
> > > > > that transits a campus.
> > > > >
> > > > > 	Are you suggesting that IGMP should be treated as a
> > > > > control protocol within TRILL?
> > > >
> > > > In this case, when I said control I meant IGMP (since
> > > > that is what is being used to effect pruning).  If we
> > > > snoop on the information at the edge of the trill
> > > > cloud and pass this information around in IS-IS, then we don't
> > > > need to worry about treating it as a separate control
> > > > protocol.
> > > >
> > > > >
> > > > > 	Nor is it very clear why this observation is specific
> > > > > to our discussion of multicast optimization.  As a general
> > > > > rule, if there is one reasonably well know application that
> > > > > relies on path congruency for proper operation, there are
> > > > > probably others.
> > > > >
> > > > > 	Do you think we should provide a logical
> > > > > control-function "bridging" service for all such applications
> > > > > as a result of path divergences we introduce?  Should we
> > > > > conduct a research project to determine what other "control
> > > > > protocols" we need to include in TRILL?
> > > >
> > > > We would need to make a list of everything that bridges
> > > > snoop on and make sure we have ways of sending that
> > > > around in IS-IS (if we care about those functions).
> > > > I'm not aware of anything other than IGMP that trill
> > > > would need to worry about, though.
> > > >
> > > > Anoop
> > > >
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JFCScT021505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 19 Jun 2007 08:12:28 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5JFFPLH015935; Tue, 19 Jun 2007 10:15:25 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 19 Jun 2007 10:12:20 -0500
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: Tue, 19 Jun 2007 10:12:18 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAEG/WAAAFjFMA==
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 15:12:20.0283 (UTC) FILETIME=[3B4010B0:01C7B284]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JFCScT021505
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 15:13:15 -0000
Status: RO
Content-Length: 8717

Donald,

	If you look at the entire statement (from which Silvano
excerpted a partial quote), it says:

"We know that we're expected to preserve forwarding symmetry
 - at least for the layer two encapsulation of TRILL frames."

This is necessary for "compatibility" with intermediate LAN
bridges.  This refers to the L2 encapsulation that "protects"
the TRILL header (which - as you say - protects the SA/DA of
the internal frames).

	I did not suppose that Silvano was being disingenuous 
in his partial quote, but - based on your comment - perhaps 
I should have re-inserted the actual context anyway.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 10:50 AM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> What does "compatibility" mean?
> 
> I believe forwarding symmetry has to do with address learning 
> at transit
> bridges. But, with Rbridges, transit bridges don't learn the actual
> source and destination of the data once it has been protected 
> by a TRILL
> Header. So forwarding symmetry is no longer of any significance.
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, June 19, 2007 10:14 AM
> To: Silvano Gai; Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Silvano,
> 
> 	Your response is confusing.  If we are not expected to 
> preserve forwarding symmetry, have we given up on presumed 
> compatibility with standard bridges?
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]] 
> > Sent: Tuesday, June 19, 2007 9:13 AM
> > To: Eric Gray (LO/EUS); Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> > 
> > 
> > Eric,
> > 
> > You say: "we're expected to preserve forwarding symmetry".
> > 
> > WE ARE NOT.
> > 
> > Where does the current draft preserve forwarding symmetry?
> > 
> > In regard to your conclusions, many of us (Anoop , Dinesh and I for
> > sure) are participating because we are building real products. 
> > 
> > I don't buy your argument that "Very uninteresting 
> > (technology) is very
> > good."
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Eric Gray (LO/EUS)
> > > Sent: Tuesday, June 19, 2007 5:27 AM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > > 
> > > Anoop,
> > > 
> > > 	I think we strongly disagree on what it means to incorporate
> > > something in the control protocol.  From there, it is likely that
> > > we also disagree on how best to avoid doing so.
> > > 
> > > 	Figuring out how to correctly carry IGMP-snooped information
> > > in TRILL protocol is effectively the same thing as incorporating
> > > IGMP in the control protocol.
> > > 
> > > 	Making a list of everything that bridges snoop and ensuring
> > > we can also include that information in IS-IS is exactly the sort
> > > of thing we should be trying to avoid.  The good news is that it
> > > also should be easy to avoid.
> > > 
> > > 	Whatever protocols we might use, TRILL is essentially a layer
> > > two forwarding technology.  The messages that layer two forwarding
> > > technologies want to snoop are visible to the devices involved in
> > > forwarding.  Unless devices actively interfere with "normal" layer
> > > two forwarding, "external" control messages should be no different
> > > than any other form of data - as far as RBridges are concerned -
> > > and should be forwarded in the same way.
> > > 
> > > 	We know that we're expected to preserve forwarding symmetry
> > > - at least for the layer two encapsulation of TRILL frames. In the
> > > same way, and for similar reasons, we may need to preserve path
> > > congruency.  This is implicit in the decision to learn from data
> > > in the unicast case.
> > > 
> > > 	What we don't know is the complete list of things that depend
> > > on our doing that.  But we can compose a partial list, 
> and it seems
> > > to me that "snooping" (in general) is one example, OA&M 
> may well be
> > > another and there are bound to be more.
> > > 
> > > 	As for the notion of "crippling the technology and making it
> > > very uninteresting" - well, to many people, technology 
> becomes very
> > > interesting when it is very complicated to make it work.  For the
> > > users of any technology, it is only truly useful when it 
> is not very
> > > interesting.
> > > 
> > > 	Paraphrasing something a colleague once told me: a technology
> > > is only really useful when the interesting thing in using 
> it is not
> > > about the technology, but about its use.  Put another 
> way, you know
> > > that transportation is useful when the interesting thing 
> about using
> > > it is arriving at the destination - rather than the trip itself.
> > > 
> > > 	Uninteresting is good.  Very uninteresting is very good.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > > Sent: Monday, June 18, 2007 7:08 PM
> > > > To: Eric Gray (LO/EUS)
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > Importance: High
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [e-mail]; Radia Perlman
> > > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > > >
> > > > > Anoop,
> > > > >
> > > > > 	I tend to view your response below as yet another
> > > > > reason why RBridges MUST use a common path for unicast and
> > > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > > fact, it is a very good reason to limit use of "multipathing"
> > > > > in general.
> > > >
> > > > If we do place those constraints then it would
> > > > cripple the technology and make it very uninteresting
> > > > (at least to me).
> > > >
> > > > > 	It is not clear exactly what you mean by your reference
> > > > > to differences between control and data paths.  Control
> > > > > messages are from one RBridge to another and - presumably -
> > > > > follow the same path as data addressed from RBridge to
> > > > > RBridge.  That path may be different from data transitting an
> > > > > RBridge campus, but there is no RBridge "control" traffic
> > > > > that transits a campus.
> > > > >
> > > > > 	Are you suggesting that IGMP should be treated as a
> > > > > control protocol within TRILL?
> > > >
> > > > In this case, when I said control I meant IGMP (since
> > > > that is what is being used to effect pruning).  If we
> > > > snoop on the information at the edge of the trill
> > > > cloud and pass this information around in IS-IS, then we don't
> > > > need to worry about treating it as a separate control
> > > > protocol.
> > > >
> > > > >
> > > > > 	Nor is it very clear why this observation is specific
> > > > > to our discussion of multicast optimization.  As a general
> > > > > rule, if there is one reasonably well know application that
> > > > > relies on path congruency for proper operation, there are
> > > > > probably others.
> > > > >
> > > > > 	Do you think we should provide a logical
> > > > > control-function "bridging" service for all such applications
> > > > > as a result of path divergences we introduce?  Should we
> > > > > conduct a research project to determine what other "control
> > > > > protocols" we need to include in TRILL?
> > > >
> > > > We would need to make a list of everything that bridges
> > > > snoop on and make sure we have ways of sending that
> > > > around in IS-IS (if we care about those functions).
> > > > I'm not aware of anything other than IGMP that trill
> > > > would need to worry about, though.
> > > >
> > > > Anoop
> > > >
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5JEw3dS017525 for <[e-mail]>; Tue, 19 Jun 2007 07:58:04 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-153.messagelabs.com!1182265082!1262434!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 25434 invoked from network); 19 Jun 2007 14:58:02 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 19 Jun 2007 14:58:02 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JEw1ZF010949 for <[e-mail]>; Tue, 19 Jun 2007 07:58:02 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5JEw0Sq027538 for <[e-mail]>; Tue, 19 Jun 2007 09:58:00 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JEnio0023408 for <[e-mail]>; Tue, 19 Jun 2007 09:50:32 -0500 (CDT)
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: Tue, 19 Jun 2007 10:49:40 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfgAAEG/WA=
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JEw3dS017525
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 14:58:22 -0000
Status: RO
Content-Length: 7373

What does "compatibility" mean?

I believe forwarding symmetry has to do with address learning at transit
bridges. But, with Rbridges, transit bridges don't learn the actual
source and destination of the data once it has been protected by a TRILL
Header. So forwarding symmetry is no longer of any significance.

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eric Gray (LO/EUS)
Sent: Tuesday, June 19, 2007 10:14 AM
To: Silvano Gai; Anoop Ghanwani
Cc: [e-mail]; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Silvano,

	Your response is confusing.  If we are not expected to 
preserve forwarding symmetry, have we given up on presumed 
compatibility with standard bridges?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 9:13 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> Eric,
> 
> You say: "we're expected to preserve forwarding symmetry".
> 
> WE ARE NOT.
> 
> Where does the current draft preserve forwarding symmetry?
> 
> In regard to your conclusions, many of us (Anoop , Dinesh and I for
> sure) are participating because we are building real products. 
> 
> I don't buy your argument that "Very uninteresting 
> (technology) is very
> good."
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Tuesday, June 19, 2007 5:27 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	I think we strongly disagree on what it means to incorporate
> > something in the control protocol.  From there, it is likely that
> > we also disagree on how best to avoid doing so.
> > 
> > 	Figuring out how to correctly carry IGMP-snooped information
> > in TRILL protocol is effectively the same thing as incorporating
> > IGMP in the control protocol.
> > 
> > 	Making a list of everything that bridges snoop and ensuring
> > we can also include that information in IS-IS is exactly the sort
> > of thing we should be trying to avoid.  The good news is that it
> > also should be easy to avoid.
> > 
> > 	Whatever protocols we might use, TRILL is essentially a layer
> > two forwarding technology.  The messages that layer two forwarding
> > technologies want to snoop are visible to the devices involved in
> > forwarding.  Unless devices actively interfere with "normal" layer
> > two forwarding, "external" control messages should be no different
> > than any other form of data - as far as RBridges are concerned -
> > and should be forwarded in the same way.
> > 
> > 	We know that we're expected to preserve forwarding symmetry
> > - at least for the layer two encapsulation of TRILL frames. In the
> > same way, and for similar reasons, we may need to preserve path
> > congruency.  This is implicit in the decision to learn from data
> > in the unicast case.
> > 
> > 	What we don't know is the complete list of things that depend
> > on our doing that.  But we can compose a partial list, and it seems
> > to me that "snooping" (in general) is one example, OA&M may well be
> > another and there are bound to be more.
> > 
> > 	As for the notion of "crippling the technology and making it
> > very uninteresting" - well, to many people, technology becomes very
> > interesting when it is very complicated to make it work.  For the
> > users of any technology, it is only truly useful when it is not very
> > interesting.
> > 
> > 	Paraphrasing something a colleague once told me: a technology
> > is only really useful when the interesting thing in using it is not
> > about the technology, but about its use.  Put another way, you know
> > that transportation is useful when the interesting thing about using
> > it is arriving at the destination - rather than the trip itself.
> > 
> > 	Uninteresting is good.  Very uninteresting is very good.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Monday, June 18, 2007 7:08 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > Anoop,
> > > >
> > > > 	I tend to view your response below as yet another
> > > > reason why RBridges MUST use a common path for unicast and
> > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > fact, it is a very good reason to limit use of "multipathing"
> > > > in general.
> > >
> > > If we do place those constraints then it would
> > > cripple the technology and make it very uninteresting
> > > (at least to me).
> > >
> > > > 	It is not clear exactly what you mean by your reference
> > > > to differences between control and data paths.  Control
> > > > messages are from one RBridge to another and - presumably -
> > > > follow the same path as data addressed from RBridge to
> > > > RBridge.  That path may be different from data transitting an
> > > > RBridge campus, but there is no RBridge "control" traffic
> > > > that transits a campus.
> > > >
> > > > 	Are you suggesting that IGMP should be treated as a
> > > > control protocol within TRILL?
> > >
> > > In this case, when I said control I meant IGMP (since
> > > that is what is being used to effect pruning).  If we
> > > snoop on the information at the edge of the trill
> > > cloud and pass this information around in IS-IS, then we don't
> > > need to worry about treating it as a separate control
> > > protocol.
> > >
> > > >
> > > > 	Nor is it very clear why this observation is specific
> > > > to our discussion of multicast optimization.  As a general
> > > > rule, if there is one reasonably well know application that
> > > > relies on path congruency for proper operation, there are
> > > > probably others.
> > > >
> > > > 	Do you think we should provide a logical
> > > > control-function "bridging" service for all such applications
> > > > as a result of path divergences we introduce?  Should we
> > > > conduct a research project to determine what other "control
> > > > protocols" we need to include in TRILL?
> > >
> > > We would need to make a list of everything that bridges
> > > snoop on and make sure we have ways of sending that
> > > around in IS-IS (if we care about those functions).
> > > I'm not aware of anything other than IGMP that trill
> > > would need to worry about, though.
> > >
> > > Anoop
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 

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



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JEPCl4008570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 19 Jun 2007 07:25:13 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5JEQhfc002395; Tue, 19 Jun 2007 09:26:43 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 19 Jun 2007 09:25:11 -0500
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: Tue, 19 Jun 2007 09:25:09 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Simplicity verses Interesting Features (was per-VLAN instances of IS-IS)
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACkeYg
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 14:25:11.0572 (UTC) FILETIME=[A5350540:01C7B27D]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JEPCl4008570
Cc: [e-mail]
Subject: Re: [rbridge] Simplicity verses Interesting Features (was per-VLAN instances of IS-IS)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 14:25:40 -0000
Status: RO
Content-Length: 7097

Silvano,

	Many people are building real products, so you needn't feel
that the fact that you are makes you somehow different from every
one else.

	As another 802 kind of guy said once, any time you deal with
customers, they want (at least) the following in your products:

o	A rich feature set
o	A low price
o	An early delivery date

Realistically, these factors push and pull each other.  In particular,
features work against both low price and early delivery.

	Apparently the customers for who you are building real products
are more interested in the first factor than they are in the others.

	That is not true for all customers.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 9:13 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> Eric,
> 
> You say: "we're expected to preserve forwarding symmetry".
> 
> WE ARE NOT.
> 
> Where does the current draft preserve forwarding symmetry?
> 
> In regard to your conclusions, many of us (Anoop , Dinesh and I for
> sure) are participating because we are building real products. 
> 
> I don't buy your argument that "Very uninteresting 
> (technology) is very
> good."
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Tuesday, June 19, 2007 5:27 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	I think we strongly disagree on what it means to incorporate
> > something in the control protocol.  From there, it is likely that
> > we also disagree on how best to avoid doing so.
> > 
> > 	Figuring out how to correctly carry IGMP-snooped information
> > in TRILL protocol is effectively the same thing as incorporating
> > IGMP in the control protocol.
> > 
> > 	Making a list of everything that bridges snoop and ensuring
> > we can also include that information in IS-IS is exactly the sort
> > of thing we should be trying to avoid.  The good news is that it
> > also should be easy to avoid.
> > 
> > 	Whatever protocols we might use, TRILL is essentially a layer
> > two forwarding technology.  The messages that layer two forwarding
> > technologies want to snoop are visible to the devices involved in
> > forwarding.  Unless devices actively interfere with "normal" layer
> > two forwarding, "external" control messages should be no different
> > than any other form of data - as far as RBridges are concerned -
> > and should be forwarded in the same way.
> > 
> > 	We know that we're expected to preserve forwarding symmetry
> > - at least for the layer two encapsulation of TRILL frames. In the
> > same way, and for similar reasons, we may need to preserve path
> > congruency.  This is implicit in the decision to learn from data
> > in the unicast case.
> > 
> > 	What we don't know is the complete list of things that depend
> > on our doing that.  But we can compose a partial list, and it seems
> > to me that "snooping" (in general) is one example, OA&M may well be
> > another and there are bound to be more.
> > 
> > 	As for the notion of "crippling the technology and making it
> > very uninteresting" - well, to many people, technology becomes very
> > interesting when it is very complicated to make it work.  For the
> > users of any technology, it is only truly useful when it is not very
> > interesting.
> > 
> > 	Paraphrasing something a colleague once told me: a technology
> > is only really useful when the interesting thing in using it is not
> > about the technology, but about its use.  Put another way, you know
> > that transportation is useful when the interesting thing about using
> > it is arriving at the destination - rather than the trip itself.
> > 
> > 	Uninteresting is good.  Very uninteresting is very good.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Monday, June 18, 2007 7:08 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > Anoop,
> > > >
> > > > 	I tend to view your response below as yet another
> > > > reason why RBridges MUST use a common path for unicast and
> > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > fact, it is a very good reason to limit use of "multipathing"
> > > > in general.
> > >
> > > If we do place those constraints then it would
> > > cripple the technology and make it very uninteresting
> > > (at least to me).
> > >
> > > > 	It is not clear exactly what you mean by your reference
> > > > to differences between control and data paths.  Control
> > > > messages are from one RBridge to another and - presumably -
> > > > follow the same path as data addressed from RBridge to
> > > > RBridge.  That path may be different from data transitting an
> > > > RBridge campus, but there is no RBridge "control" traffic
> > > > that transits a campus.
> > > >
> > > > 	Are you suggesting that IGMP should be treated as a
> > > > control protocol within TRILL?
> > >
> > > In this case, when I said control I meant IGMP (since
> > > that is what is being used to effect pruning).  If we
> > > snoop on the information at the edge of the trill
> > > cloud and pass this information around in IS-IS, then we don't
> > > need to worry about treating it as a separate control
> > > protocol.
> > >
> > > >
> > > > 	Nor is it very clear why this observation is specific
> > > > to our discussion of multicast optimization.  As a general
> > > > rule, if there is one reasonably well know application that
> > > > relies on path congruency for proper operation, there are
> > > > probably others.
> > > >
> > > > 	Do you think we should provide a logical
> > > > control-function "bridging" service for all such applications
> > > > as a result of path divergences we introduce?  Should we
> > > > conduct a research project to determine what other "control
> > > > protocols" we need to include in TRILL?
> > >
> > > We would need to make a list of everything that bridges
> > > snoop on and make sure we have ways of sending that
> > > around in IS-IS (if we care about those functions).
> > > I'm not aware of anything other than IGMP that trill
> > > would need to worry about, though.
> > >
> > > Anoop
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JEDibS005770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 19 Jun 2007 07:13:45 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5JEFCbT032720; Tue, 19 Jun 2007 09:15:12 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 19 Jun 2007 09:13:40 -0500
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: Tue, 19 Jun 2007 09:13:34 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IAACarfg
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 14:13:40.0179 (UTC) FILETIME=[091AD230:01C7B27C]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JEDibS005770
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 14:14:50 -0000
Status: RO
Content-Length: 6624

Silvano,

	Your response is confusing.  If we are not expected to 
preserve forwarding symmetry, have we given up on presumed 
compatibility with standard bridges?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Tuesday, June 19, 2007 9:13 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> Eric,
> 
> You say: "we're expected to preserve forwarding symmetry".
> 
> WE ARE NOT.
> 
> Where does the current draft preserve forwarding symmetry?
> 
> In regard to your conclusions, many of us (Anoop , Dinesh and I for
> sure) are participating because we are building real products. 
> 
> I don't buy your argument that "Very uninteresting 
> (technology) is very
> good."
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Tuesday, June 19, 2007 5:27 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	I think we strongly disagree on what it means to incorporate
> > something in the control protocol.  From there, it is likely that
> > we also disagree on how best to avoid doing so.
> > 
> > 	Figuring out how to correctly carry IGMP-snooped information
> > in TRILL protocol is effectively the same thing as incorporating
> > IGMP in the control protocol.
> > 
> > 	Making a list of everything that bridges snoop and ensuring
> > we can also include that information in IS-IS is exactly the sort
> > of thing we should be trying to avoid.  The good news is that it
> > also should be easy to avoid.
> > 
> > 	Whatever protocols we might use, TRILL is essentially a layer
> > two forwarding technology.  The messages that layer two forwarding
> > technologies want to snoop are visible to the devices involved in
> > forwarding.  Unless devices actively interfere with "normal" layer
> > two forwarding, "external" control messages should be no different
> > than any other form of data - as far as RBridges are concerned -
> > and should be forwarded in the same way.
> > 
> > 	We know that we're expected to preserve forwarding symmetry
> > - at least for the layer two encapsulation of TRILL frames. In the
> > same way, and for similar reasons, we may need to preserve path
> > congruency.  This is implicit in the decision to learn from data
> > in the unicast case.
> > 
> > 	What we don't know is the complete list of things that depend
> > on our doing that.  But we can compose a partial list, and it seems
> > to me that "snooping" (in general) is one example, OA&M may well be
> > another and there are bound to be more.
> > 
> > 	As for the notion of "crippling the technology and making it
> > very uninteresting" - well, to many people, technology becomes very
> > interesting when it is very complicated to make it work.  For the
> > users of any technology, it is only truly useful when it is not very
> > interesting.
> > 
> > 	Paraphrasing something a colleague once told me: a technology
> > is only really useful when the interesting thing in using it is not
> > about the technology, but about its use.  Put another way, you know
> > that transportation is useful when the interesting thing about using
> > it is arriving at the destination - rather than the trip itself.
> > 
> > 	Uninteresting is good.  Very uninteresting is very good.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Monday, June 18, 2007 7:08 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > > Sent: Monday, June 18, 2007 11:43 AM
> > > > To: Anoop Ghanwani
> > > > Cc: [e-mail]; Radia Perlman
> > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > >
> > > > Anoop,
> > > >
> > > > 	I tend to view your response below as yet another
> > > > reason why RBridges MUST use a common path for unicast and
> > > > multicast (as well as broadcast and flooded) traffic.  In
> > > > fact, it is a very good reason to limit use of "multipathing"
> > > > in general.
> > >
> > > If we do place those constraints then it would
> > > cripple the technology and make it very uninteresting
> > > (at least to me).
> > >
> > > > 	It is not clear exactly what you mean by your reference
> > > > to differences between control and data paths.  Control
> > > > messages are from one RBridge to another and - presumably -
> > > > follow the same path as data addressed from RBridge to
> > > > RBridge.  That path may be different from data transitting an
> > > > RBridge campus, but there is no RBridge "control" traffic
> > > > that transits a campus.
> > > >
> > > > 	Are you suggesting that IGMP should be treated as a
> > > > control protocol within TRILL?
> > >
> > > In this case, when I said control I meant IGMP (since
> > > that is what is being used to effect pruning).  If we
> > > snoop on the information at the edge of the trill
> > > cloud and pass this information around in IS-IS, then we don't
> > > need to worry about treating it as a separate control
> > > protocol.
> > >
> > > >
> > > > 	Nor is it very clear why this observation is specific
> > > > to our discussion of multicast optimization.  As a general
> > > > rule, if there is one reasonably well know application that
> > > > relies on path congruency for proper operation, there are
> > > > probably others.
> > > >
> > > > 	Do you think we should provide a logical
> > > > control-function "bridging" service for all such applications
> > > > as a result of path divergences we introduce?  Should we
> > > > conduct a research project to determine what other "control
> > > > protocols" we need to include in TRILL?
> > >
> > > We would need to make a list of everything that bridges
> > > snoop on and make sure we have ways of sending that
> > > around in IS-IS (if we care about those functions).
> > > I'm not aware of anything other than IGMP that trill
> > > would need to worry about, though.
> > >
> > > Anoop
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JDCvXc013929 for <[e-mail]>; Tue, 19 Jun 2007 06:12:57 -0700 (PDT)
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: Tue, 19 Jun 2007 06:12:37 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuAAAye6IA==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JDCvXc013929
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 13:13:09 -0000
Status: RO
Content-Length: 5831

Eric,

You say: "we're expected to preserve forwarding symmetry".

WE ARE NOT.

Where does the current draft preserve forwarding symmetry?

In regard to your conclusions, many of us (Anoop , Dinesh and I for
sure) are participating because we are building real products. 

I don't buy your argument that "Very uninteresting (technology) is very
good."

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, June 19, 2007 5:27 AM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> 	I think we strongly disagree on what it means to incorporate
> something in the control protocol.  From there, it is likely that
> we also disagree on how best to avoid doing so.
> 
> 	Figuring out how to correctly carry IGMP-snooped information
> in TRILL protocol is effectively the same thing as incorporating
> IGMP in the control protocol.
> 
> 	Making a list of everything that bridges snoop and ensuring
> we can also include that information in IS-IS is exactly the sort
> of thing we should be trying to avoid.  The good news is that it
> also should be easy to avoid.
> 
> 	Whatever protocols we might use, TRILL is essentially a layer
> two forwarding technology.  The messages that layer two forwarding
> technologies want to snoop are visible to the devices involved in
> forwarding.  Unless devices actively interfere with "normal" layer
> two forwarding, "external" control messages should be no different
> than any other form of data - as far as RBridges are concerned -
> and should be forwarded in the same way.
> 
> 	We know that we're expected to preserve forwarding symmetry
> - at least for the layer two encapsulation of TRILL frames. In the
> same way, and for similar reasons, we may need to preserve path
> congruency.  This is implicit in the decision to learn from data
> in the unicast case.
> 
> 	What we don't know is the complete list of things that depend
> on our doing that.  But we can compose a partial list, and it seems
> to me that "snooping" (in general) is one example, OA&M may well be
> another and there are bound to be more.
> 
> 	As for the notion of "crippling the technology and making it
> very uninteresting" - well, to many people, technology becomes very
> interesting when it is very complicated to make it work.  For the
> users of any technology, it is only truly useful when it is not very
> interesting.
> 
> 	Paraphrasing something a colleague once told me: a technology
> is only really useful when the interesting thing in using it is not
> about the technology, but about its use.  Put another way, you know
> that transportation is useful when the interesting thing about using
> it is arriving at the destination - rather than the trip itself.
> 
> 	Uninteresting is good.  Very uninteresting is very good.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Monday, June 18, 2007 7:08 PM
> > To: Eric Gray (LO/EUS)
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> >
> >
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > Sent: Monday, June 18, 2007 11:43 AM
> > > To: Anoop Ghanwani
> > > Cc: [e-mail]; Radia Perlman
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > >
> > > Anoop,
> > >
> > > 	I tend to view your response below as yet another
> > > reason why RBridges MUST use a common path for unicast and
> > > multicast (as well as broadcast and flooded) traffic.  In
> > > fact, it is a very good reason to limit use of "multipathing"
> > > in general.
> >
> > If we do place those constraints then it would
> > cripple the technology and make it very uninteresting
> > (at least to me).
> >
> > > 	It is not clear exactly what you mean by your reference
> > > to differences between control and data paths.  Control
> > > messages are from one RBridge to another and - presumably -
> > > follow the same path as data addressed from RBridge to
> > > RBridge.  That path may be different from data transitting an
> > > RBridge campus, but there is no RBridge "control" traffic
> > > that transits a campus.
> > >
> > > 	Are you suggesting that IGMP should be treated as a
> > > control protocol within TRILL?
> >
> > In this case, when I said control I meant IGMP (since
> > that is what is being used to effect pruning).  If we
> > snoop on the information at the edge of the trill
> > cloud and pass this information around in IS-IS, then we don't
> > need to worry about treating it as a separate control
> > protocol.
> >
> > >
> > > 	Nor is it very clear why this observation is specific
> > > to our discussion of multicast optimization.  As a general
> > > rule, if there is one reasonably well know application that
> > > relies on path congruency for proper operation, there are
> > > probably others.
> > >
> > > 	Do you think we should provide a logical
> > > control-function "bridging" service for all such applications
> > > as a result of path divergences we introduce?  Should we
> > > conduct a research project to determine what other "control
> > > protocols" we need to include in TRILL?
> >
> > We would need to make a list of everything that bridges
> > snoop on and make sure we have ways of sending that
> > around in IS-IS (if we care about those functions).
> > I'm not aware of anything other than IGMP that trill
> > would need to worry about, though.
> >
> > Anoop
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JD2HRx011266 for <[e-mail]>; Tue, 19 Jun 2007 06:02:17 -0700 (PDT)
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: Tue, 19 Jun 2007 06:01:57 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgAB295SA=
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eric Gray \(LO/EUS\)" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JD2HRx011266
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 13:02:36 -0000
Status: RO
Content-Length: 1025

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Monday, June 18, 2007 4:08 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > Sent: Monday, June 18, 2007 11:43 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> >
> > Anoop,
> >
> > 	I tend to view your response below as yet another
> > reason why RBridges MUST use a common path for unicast and
> > multicast (as well as broadcast and flooded) traffic.  In
> > fact, it is a very good reason to limit use of "multipathing"
> > in general.
> 
> If we do place those constraints then it would
> cripple the technology and make it very uninteresting
> (at least to me).
> 

I AM IN VIOLENT AGREEMENT with Anoop on this point.

-- Silvano



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5JCRVMv001014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 19 Jun 2007 05:27:31 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5JCSvRp015600; Tue, 19 Jun 2007 07:28:58 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 19 Jun 2007 07:27:25 -0500
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: Tue, 19 Jun 2007 07:27:25 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUgABqpJuA=
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 19 Jun 2007 12:27:25.0989 (UTC) FILETIME=[31CA9D50:01C7B26D]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5JCRVMv001014
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2007 12:28:22 -0000
Status: RO
Content-Length: 4838

Anoop,

	I think we strongly disagree on what it means to incorporate
something in the control protocol.  From there, it is likely that
we also disagree on how best to avoid doing so.

	Figuring out how to correctly carry IGMP-snooped information 
in TRILL protocol is effectively the same thing as incorporating 
IGMP in the control protocol.

	Making a list of everything that bridges snoop and ensuring
we can also include that information in IS-IS is exactly the sort 
of thing we should be trying to avoid.  The good news is that it 
also should be easy to avoid.

	Whatever protocols we might use, TRILL is essentially a layer
two forwarding technology.  The messages that layer two forwarding
technologies want to snoop are visible to the devices involved in
forwarding.  Unless devices actively interfere with "normal" layer 
two forwarding, "external" control messages should be no different 
than any other form of data - as far as RBridges are concerned - 
and should be forwarded in the same way.

	We know that we're expected to preserve forwarding symmetry
- at least for the layer two encapsulation of TRILL frames. In the 
same way, and for similar reasons, we may need to preserve path 
congruency.  This is implicit in the decision to learn from data 
in the unicast case.

	What we don't know is the complete list of things that depend
on our doing that.  But we can compose a partial list, and it seems
to me that "snooping" (in general) is one example, OA&M may well be 
another and there are bound to be more.

	As for the notion of "crippling the technology and making it 
very uninteresting" - well, to many people, technology becomes very
interesting when it is very complicated to make it work.  For the
users of any technology, it is only truly useful when it is not very
interesting.  

	Paraphrasing something a colleague once told me: a technology
is only really useful when the interesting thing in using it is not 
about the technology, but about its use.  Put another way, you know 
that transportation is useful when the interesting thing about using
it is arriving at the destination - rather than the trip itself.

	Uninteresting is good.  Very uninteresting is very good.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 7:08 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> > Sent: Monday, June 18, 2007 11:43 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	I tend to view your response below as yet another 
> > reason why RBridges MUST use a common path for unicast and 
> > multicast (as well as broadcast and flooded) traffic.  In 
> > fact, it is a very good reason to limit use of "multipathing" 
> > in general.
> 
> If we do place those constraints then it would
> cripple the technology and make it very uninteresting
> (at least to me).
> 
> > 	It is not clear exactly what you mean by your reference 
> > to differences between control and data paths.  Control 
> > messages are from one RBridge to another and - presumably - 
> > follow the same path as data addressed from RBridge to 
> > RBridge.  That path may be different from data transitting an 
> > RBridge campus, but there is no RBridge "control" traffic 
> > that transits a campus.
> >
> > 	Are you suggesting that IGMP should be treated as a 
> > control protocol within TRILL?
> 
> In this case, when I said control I meant IGMP (since
> that is what is being used to effect pruning).  If we
> snoop on the information at the edge of the trill
> cloud and pass this information around in IS-IS, then we don't
> need to worry about treating it as a separate control
> protocol.
> 
> > 
> > 	Nor is it very clear why this observation is specific 
> > to our discussion of multicast optimization.  As a general 
> > rule, if there is one reasonably well know application that 
> > relies on path congruency for proper operation, there are 
> > probably others.  
> >
> > 	Do you think we should provide a logical 
> > control-function "bridging" service for all such applications 
> > as a result of path divergences we introduce?  Should we 
> > conduct a research project to determine what other "control 
> > protocols" we need to include in TRILL?
> 
> We would need to make a list of everything that bridges
> snoop on and make sure we have ways of sending that
> around in IS-IS (if we care about those functions).
> I'm not aware of anything other than IGMP that trill
> would need to worry about, though.
> 
> Anoop
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5IN80k9019421 for <[e-mail]>; Mon, 18 Jun 2007 16:08:00 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 18 Jun 2007 16:07:59 -0700
X-IronPort-AV: i="4.16,436,1175497200";  d="scan'208"; a="13816578:sNHT19555578"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 8153A23836C; Mon, 18 Jun 2007 16:05:39 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jun 2007 16:08:00 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 16:07:41 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAAAJVYUg
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 23:08:00.0680 (UTC) FILETIME=[843D4A80:01C7B1FD]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IN80k9019421
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 23:08:22 -0000
Status: RO
Content-Length: 2207

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 11:43 AM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> 	I tend to view your response below as yet another 
> reason why RBridges MUST use a common path for unicast and 
> multicast (as well as broadcast and flooded) traffic.  In 
> fact, it is a very good reason to limit use of "multipathing" 
> in general.

If we do place those constraints then it would
cripple the technology and make it very uninteresting
(at least to me).

> 	It is not clear exactly what you mean by your reference 
> to differences between control and data paths.  Control 
> messages are from one RBridge to another and - presumably - 
> follow the same path as data addressed from RBridge to 
> RBridge.  That path may be different from data transitting an 
> RBridge campus, but there is no RBridge "control" traffic 
> that transits a campus.
>
> 	Are you suggesting that IGMP should be treated as a 
> control protocol within TRILL?

In this case, when I said control I meant IGMP (since
that is what is being used to effect pruning).  If we
snoop on the information at the edge of the trill
cloud and pass this information around in IS-IS, then we don't
need to worry about treating it as a separate control
protocol.

> 
> 	Nor is it very clear why this observation is specific 
> to our discussion of multicast optimization.  As a general 
> rule, if there is one reasonably well know application that 
> relies on path congruency for proper operation, there are 
> probably others.  
>
> 	Do you think we should provide a logical 
> control-function "bridging" service for all such applications 
> as a result of path divergences we introduce?  Should we 
> conduct a research project to determine what other "control 
> protocols" we need to include in TRILL?

We would need to make a list of everything that bridges
snoop on and make sure we have ways of sending that
around in IS-IS (if we care about those functions).
I'm not aware of anything other than IGMP that trill
would need to worry about, though.

Anoop



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5ILpkU4029864 for <[e-mail]>; Mon, 18 Jun 2007 14:51:47 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 18 Jun 2007 14:51:46 -0700
X-IronPort-AV: i="4.16,436,1175497200";  d="scan'208"; a="13813447:sNHT22185583"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 6F54E23836C; Mon, 18 Jun 2007 14:49:26 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jun 2007 14:51:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 14:51:28 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
Thread-Index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIAAvcbTAAB3PRFAAARhtgAAEXWZwAACFmXAAAZ/mIA==
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 21:51:46.0980 (UTC) FILETIME=[DE1A0E40:01C7B1F2]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5ILpkU4029864
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 21:53:29 -0000
Status: RO
Content-Length: 4347

Donald,

By "trill core", I meant an rBridge that is connected
only to other rBridges (i.e. a device that has only 
"trill" ports).

I think there's another notion of port state
for rBridges in the trill core - they drop
multicast frames that are received on a port
if that port is not in the tree as indicated
by the egress rBridge address.  However, this
behavior cannot be applied to IS-IS frames.
So while edge rBridges have DRB state, 
core rBridges need to have tree state for
all of the trees on all of their trill ports.

Since unicast frames never get filtered, if the
core IS-IS instance used a special multicast
address, that would be enough for achieving 
the above function.

Ethertype can also be used as you point out.

Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 2:32 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Anoop,
> 
> See below at @@@
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]]
> Sent: Monday, June 18, 2007 4:51 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Donald,
> 
> I think Silvano mentioned it is better to use a multicast MAC 
> address to identify IS-IS frames.
> I assume this refers to the core IS-IS instance.
> 
> @@ I may be wrong but I thought he wanted to use a different 
> multicast address for all TRILL IS-IS frames because they are 
> control messages and thus should get through when an Rbridge 
> port is "blocked" (not DRB). But TRILL data frames should get 
> through also.
> 
> Then you mentioned that we wouldn't really need to do 
> filtering in the trill core based on port state.
> 
> @@2 What is the "trill core"? If you are not DRB for some 
> port/VLAN, you need to discard incoming native data frames 
> and not emit native data frames no matter where in the campus you are.
> 
> At which point I clarified that in the trill core, when an 
> rBridge receives a frame it is required to filter multicast 
> frames if they are received on a port which is not part of 
> the tree indicated by the egress rBridge address.
> 
> @@@ Sorry, but I find you use of "filter" a little confusing. 
> Yes, that check and others are performed on multicast TRILL 
> frames when they are received by any Rbridge. I still don't 
> know what you mean by "trill core". There are no "trill core 
> Rbridges" as opposed to "peripheral trill Rbridges" or something...
> 
> Thus there is some dependence on port state even in the TRILL 
> core and the kind of frames that the rBridge would be willing 
> to accept and process from a port.
> 
> @@@ To me, "port state" for an Rbridge is whether it is 
> Designated Rbridge for a particular port/VLAN. Sure, this 
> affects whether or not it will accept or emit native data 
> frames. But this "port state" has no effect on whether it 
> will process any TRILL Ethertype frame. Nor does the "port 
> state" have any effect on whether that TRILL frame meets any 
> of the various tests such as, if it is multicast, the tree 
> test you mention.
> 
> We could use the Ethertype or the MAC address for this 
> filtering, but right now, with the MAC address for all 
> multicast frames being set to all-rbridges, it looks like the 
> only option we have is to use the Ethertype.
> That's fine too.
> 
> @@@ All frames sent to the All-Rbridges multicast address are 
> TRILL Ethertype. There are also unicast TRILL data frames. 
> How a frame is affected by port state corresponds to whether 
> or not it is TRILL Ethertype. How a frame is affected by port 
> state does not correspond with whether or not it is sent to 
> the All-Rbridges multicast address.
> The filtering on port state has nothing to do with whether a 
> frame is "TRILL IS-IS" versus "TRILL data".  I do not see how 
> port filtering would be helped by having a different TRILL 
> IS-IS multicast address.
> Whether there are one or two multicast addresses, it is still 
> the case that trying to filter based on a combination of port 
> state and multicast
> address(es) will be incorrect but filtering based on port 
> state and Ethertype will be correct.
> 
> Anoop
> 
> @@@ Donald
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5ILf54Z026825 for <[e-mail]>; Mon, 18 Jun 2007 14:41:09 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 18 Jun 2007 14:41:05 -0700
X-IronPort-AV: i="4.16,436,1175497200";  d="scan'208"; a="13812942:sNHT19945296"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 6D25E23836C; Mon, 18 Jun 2007 14:38:45 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jun 2007 14:41:06 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 14:40:47 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
Thread-Index: AcevzWGfSByipQ2XSN+D2aV7n9v0LQCI0c/g
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 21:41:06.0487 (UTC) FILETIME=[60569470:01C7B1F1]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5ILf54Z026825
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 21:41:39 -0000
Status: RO
Content-Length: 2874

Radia,

Using learning at the edge Rbridges definitely
addresses the scaling issue for unicast.

>From your note below it's not clear if we're
still going to have per-VLAN instances of
IS-IS.  If we do, I still think we would 
have problems with it.

One can always make an argument that a 
802.1Q bridge doesn't realistically need
to support 2K or 4K or whatever number 
of VLANs.  However, they do support it, 
and there are customers out there that 
configure that many VLANs.

If TRILL is even moderately successful,
we will likely encounter networks where
an rBridge needs to participate in 1000s
of VLANs.

Anoop

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: [e-mail]
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> 1) They have deployed a variant of IS-IS, and the way they 
> distinguish their instances is based on having a new 
> multicast address. I wrongly remembered IS-IS, and thought 
> that PSNPs got unicast, but even those are multicast (and I 
> remember the reasoning at the time this was decided 100 years 
> ago, which was to suppress lots of routers sending the same 
> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> from layer 3 IS-IS by having a different multicast address. 
> The bit in the header works too, however.
> 
> 2) I checked to make sure that "0" would be OK to use as an 
> area address, and it is.
> 
> 3) The solution I proposed to the scalability issue of having 
> a zillion pseudonodes on a LAN (having the DR give the same 
> name to all the pseudonodes that get spawned by running the 
> Hello protocol on a link according to each VLAN the DR 
> supports) works. 
> I was worried
> about nontransitive connectivity (R1, the DR, names the 
> pseudonode R1.1, and issues an LSP on behalf of the 
> pseudonode claiming to be attached to all the RBridges on the 
> link that can talk to R1 via any of the VLAN tags. But even 
> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> to R1 (using VLAN Tab B) does not mean that
> R2 and R3
> can talk to each other.)
> 
> Interestingly, way back when IS-IS was DECnet phase V, and we 
> were worried about weird hardware problems creating 
> nontransitive connectivity, we put in what R2 should do when 
> the link state database implies R2 can talk to R3 through the 
> pseudonode, but
> R2 can't really talk to R3 -- R2 sends to the DR).
> 
> So we can use this solution. So does that (and learning from 
> data packets rather than announcing all endnodes in per-VLAN 
> instances of IS-IS) answer everyone's scalability concerns?
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5ILVfjc024262 for <[e-mail]>; Mon, 18 Jun 2007 14:31:42 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-153.messagelabs.com!1182202300!1747516!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.7]
Received: (qmail 11070 invoked from network); 18 Jun 2007 21:31:40 -0000
Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-7.tower-153.messagelabs.com with SMTP; 18 Jun 2007 21:31:40 -0000
Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l5ILVeJi023657 for <[e-mail]>; Mon, 18 Jun 2007 14:31:40 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5ILVc9r002059 for <[e-mail]>; Mon, 18 Jun 2007 16:31:39 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5ILVbHV002036 for <[e-mail]>; Mon, 18 Jun 2007 16:31:38 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 17:31:36 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
thread-index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIAAvcbTAAB3PRFAAARhtgAAEXWZwAACFmXA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5ILVfjc024262
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 21:32:18 -0000
Status: RO
Content-Length: 3148

Anoop,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Monday, June 18, 2007 4:51 PM
To: Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

Donald,

I think Silvano mentioned it is better to use
a multicast MAC address to identify IS-IS frames.
I assume this refers to the core IS-IS instance.

@@ I may be wrong but I thought he wanted to use a different multicast
address for all TRILL IS-IS frames because they are control messages and
thus should get through when an Rbridge port is "blocked" (not DRB). But
TRILL data frames should get through also.

Then you mentioned that we wouldn't really need
to do filtering in the trill core based on 
port state.

@@2 What is the "trill core"? If you are not DRB for some port/VLAN, you
need to discard incoming native data frames and not emit native data
frames no matter where in the campus you are.

At which point I clarified that in the trill 
core, when an rBridge receives a frame 
it is required to filter multicast frames 
if they are received on a port which is not
part of the tree indicated by the egress
rBridge address.

@@@ Sorry, but I find you use of "filter" a little confusing. Yes, that
check and others are performed on multicast TRILL frames when they are
received by any Rbridge. I still don't know what you mean by "trill
core". There are no "trill core Rbridges" as opposed to "peripheral
trill Rbridges" or something...

Thus there is some dependence on port state
even in the TRILL core and the kind of frames
that the rBridge would be willing to accept
and process from a port.

@@@ To me, "port state" for an Rbridge is whether it is Designated
Rbridge for a particular port/VLAN. Sure, this affects whether or not it
will accept or emit native data frames. But this "port state" has no
effect on whether it will process any TRILL Ethertype frame. Nor does
the "port state" have any effect on whether that TRILL frame meets any
of the various tests such as, if it is multicast, the tree test you
mention.

We could use the Ethertype or the MAC address
for this filtering, but right now, with the 
MAC address for all multicast frames being 
set to all-rbridges, it looks like the only
option we have is to use the Ethertype.
That's fine too.

@@@ All frames sent to the All-Rbridges multicast address are TRILL
Ethertype. There are also unicast TRILL data frames. How a frame is
affected by port state corresponds to whether or not it is TRILL
Ethertype. How a frame is affected by port state does not correspond
with whether or not it is sent to the All-Rbridges multicast address.
The filtering on port state has nothing to do with whether a frame is
"TRILL IS-IS" versus "TRILL data".  I do not see how port filtering
would be helped by having a different TRILL IS-IS multicast address.
Whether there are one or two multicast addresses, it is still the case
that trying to filter based on a combination of port state and multicast
address(es) will be incorrect but filtering based on port state and
Ethertype will be correct.

Anoop

@@@ Donald



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5IKpTTf012937 for <[e-mail]>; Mon, 18 Jun 2007 13:51:29 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 18 Jun 2007 13:51:29 -0700
X-IronPort-AV: i="4.16,436,1175497200";  d="scan'208"; a="11100225:sNHT24384745"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id DBACB23836C; Mon, 18 Jun 2007 13:49:08 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jun 2007 13:51:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 13:51:10 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
Thread-Index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIAAvcbTAAB3PRFAAARhtgAAEXWZw
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 20:51:29.0317 (UTC) FILETIME=[71CE7D50:01C7B1EA]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IKpTTf012937
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 20:51:38 -0000
Status: RO
Content-Length: 10161

Donald,

I think Silvano mentioned it is better to use
a multicast MAC address to identify IS-IS frames.
I assume this refers to the core IS-IS instance.

Then you mentioned that we wouldn't really need
to do filtering in the trill core based on 
port state.

At which point I clarified that in the trill 
core, when an rBridge receives a frame 
it is required to filter multicast frames 
if they are received on a port which is not
part of the tree indicated by the egress
rBridge address.

Thus there is some dependence on port state
even in the TRILL core and the kind of frames
that the rBridge would be willing to accept
and process from a port.

We could use the Ethertype or the MAC address
for this filtering, but right now, with the 
MAC address for all multicast frames being 
set to all-rbridges, it looks like the only
option we have is to use the Ethertype.
That's fine too.

Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 12:36 PM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Anoop,
> 
> Sure, but I was interpreting "blocking" to be the sort of things that
> 802.1 bridge ports do in any state other than the Forwarding 
> state. That
> is, data doesn't go through and is not processed (except possibly to
> learn addresses). However, when blocked, 802.1 bridges still receive,
> process, and send BPDUs. (I'm ignoring all the various possible
> "port-to-port" things like 802.1AB and 802.1AE etc.)
> 
> The corresponding thing for Rbridges is to not be the 
> Designated Rbridge
> (DRB) on a port/VLAN pair. When you are not the DRB, native 
> data doesn't
> go through and is not processed. However, any TRILL Ethertype frame is
> fine to receive, process, and, if appropriate, send. That 
> processing may
> cause the frame to be discarded, as you point out below, but I just
> don't think of that as the same thing as throwing away a frame as soon
> as you notice that it is a native data frame received from a port/VLAN
> where you are not DRB or not emitting the native data frame inside a
> TRILL data frame you have received onto any port/VLAN pair because you
> are not DRB.
> 
> Maybe we are just arguing about what words to use.
> 
> In any case, my point was that in connection with "blocking" as I mean
> it above, I don't see any difference between TRILL IS-IS frames and
> TRILL data frames. So there is no particular reason to have two
> multicast addresses. In fact, depending just on the multicast 
> address to
> by-pass blocking isn't right, because unicast TRILL data 
> frames need to
> get through and, if there were any unicast TRILL IS-IS frames, they
> would need to get through also. Looking for the TRILL Ethertype seems
> like the best way to determine if a frame gets through "blocking".
> 
> Donald
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 2:10 PM
> To: Eastlake III Donald-LDE008; Silvano Gai; [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Donald,
> 
> Even in the TRILL network, you have to block frames 
> with the all-rbridges address if the come in on a 
> port that is not part of the tree identified by the 
> egress rbridge address in the frame.
> 
> Anoop 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Sunday, June 17, 2007 8:57 PM
> > To: Silvano Gai; [e-mail]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > I've got no problem with using destination address to bypass 
> > blocked port state but the only thing you need to block are 
> > native data frames.
> > Once a frame has been admitted by a DRB and converted into a 
> > TRILL data frame, there is no reason to port block it. So 
> > anything to the All Rbridges multicast address is fine.
> > 
> > Donald 
> > 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Sunday, June 17, 2007 1:22 AM
> > To: Eastlake III Donald-LDE008; [e-mail]
> > Subject: RE: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > I disagree; current bridges distinguish control frames 
> > (BPDUs, CDP, LLDP, GARP, etc) on reserved MAC addresses.
> > 
> > Remember that these control frames need to bypass the blocked 
> > port state (due to ST or DRB election). 
> > 
> > Today we have port logic that checks a set of registers for 
> > MAC addresses of frames that need to bypass the port state. 
> > 
> > It is much more difficult to parse a frame to understand if 
> > applying or not the port state.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Eastlake III Donald-LDE008
> > > Sent: Saturday, June 16, 2007 8:11 PM
> > > To: [e-mail]
> > > Subject: Re: [rbridge] I got some answers from the IS-IS 
> > mailing list
> > > 
> > > While I think that multicast addresses are cheap, so we could
> > certainly
> > > get two, I don't see any advantage to having two: presumably 
> > > "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast 
> addresses.
> > You
> > > definitely want different multicast addresses if you have 
> different 
> > > listeners, but in this case all Rbridges would have to list 
> > for both 
> > > multicast addresses.
> > > 
> > > Both TRILL Data and TRILL IS-IS messages have the same 
> structure of 
> > > TRILL header and it seems easier to figure things out from 
> > that header 
> > > rather than having to keep track of one extra bit from 
> > earlier in the 
> > > frame from the multicast address.
> > > 
> > > The variant of IS-IS that the IS-IS working group deployed 
> > did use a 
> > > different multicast address from the one used for level one IS-IS 
> > > routers, the multicast address "All-Level-1-ISs". We are 
> > already using
> > a
> > > different multicast address from that, just like they 
> did, by using
> > the
> > > multicast address "All-Rbridges".
> > > 
> > > Thanks,
> > > Donald
> > > 
> > > PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
> > which
> > > isn't relevant as the TRILL usage of IS-IS is Level 1.
> > > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Silvano Gai
> > > Sent: Saturday, June 16, 2007 11:24 AM
> > > To: Radia Perlman; [e-mail]
> > > Subject: Re: [rbridge] I got some answers from the IS-IS 
> > mailing list
> > > 
> > > 
> > > If this is the case I will use the multicast address to 
> distinguish 
> > > TRILL ISIS not an extra bit in the header.
> > > 
> > > -- Silvano
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail] 
> > [mailto:[e-mail]]
> > > On
> > > > Behalf Of Radia Perlman
> > > > Sent: Friday, June 15, 2007 9:12 PM
> > > > To: [e-mail]
> > > > Subject: [rbridge] I got some answers from the IS-IS 
> mailing list
> > > >
> > > > 1) They have deployed a variant of IS-IS, and the way they
> > distinguish
> > > > their instances
> > > > is based on having a new multicast address. I wrongly remembered
> > > IS-IS,
> > > > and thought that
> > > > PSNPs got unicast, but even those are multicast (and I 
> > remember the 
> > > > reasoning at the time this was decided 100 years ago, 
> > which was to 
> > > > suppress lots of routers sending the same PSNP). So, 
> for encoding 
> > > > TRILL IS-IS, it can be differentiated
> > > from
> > > > layer 3 IS-IS
> > > > by having a different multicast address. The bit in the 
> > header works 
> > > > too, however.
> > > >
> > > > 2) I checked to make sure that "0" would be OK to use 
> as an area 
> > > > address, and it is.
> > > >
> > > > 3) The solution I proposed to the scalability issue of having a
> > > zillion
> > > > pseudonodes on a LAN
> > > > (having the DR give the same name to all the 
> pseudonodes that get 
> > > > spawned by running the Hello protocol on a link 
> according to each 
> > > > VLAN the DR supports)
> > > works.
> > > > I was worried
> > > > about nontransitive connectivity (R1, the DR, names the 
> pseudonode
> > > R1.1,
> > > > and issues
> > > > an LSP on behalf of the pseudonode claiming to be 
> attached to all
> > the
> > > > RBridges on the
> > > > link that can talk to R1 via any of the VLAN tags. But 
> even though
> > R2
> > > > can talk to R1 (using
> > > > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) 
> does not mean
> > > that
> > > > R2 and R3
> > > > can talk to each other.)
> > > >
> > > > Interestingly, way back when IS-IS was DECnet phase V, 
> > and we were 
> > > > worried about weird hardware problems creating nontransitive 
> > > > connectivity, we put
> > in
> > > > what R2 should
> > > > do when the link state database implies R2 can talk to 
> R3 through
> > the
> > > > pseudonode, but
> > > > R2 can't really talk to R3 -- R2 sends to the DR).
> > > >
> > > > So we can use this solution. So does that (and learning 
> from data 
> > > > packets rather than announcing all endnodes in per-VLAN 
> > instances of 
> > > > IS-IS) answer
> > > everyone's
> > > > scalability concerns?
> > > >
> > > > Radia
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [e-mail]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5IJaTKk021651 for <[e-mail]>; Mon, 18 Jun 2007 12:36:30 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-119.messagelabs.com!1182195388!20375860!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 3390 invoked from network); 18 Jun 2007 19:36:28 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 18 Jun 2007 19:36:28 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5IJaSL3029320 for <[e-mail]>; Mon, 18 Jun 2007 12:36:28 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5IJaREs024622 for <[e-mail]>; Mon, 18 Jun 2007 14:36:28 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5IJaQYJ024613 for <[e-mail]>; Mon, 18 Jun 2007 14:36:27 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 15:36:25 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
thread-index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIAAvcbTAAB3PRFAAARhtgA==
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IJaTKk021651
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 19:36:40 -0000
Status: RO
Content-Length: 8450

Anoop,

Sure, but I was interpreting "blocking" to be the sort of things that
802.1 bridge ports do in any state other than the Forwarding state. That
is, data doesn't go through and is not processed (except possibly to
learn addresses). However, when blocked, 802.1 bridges still receive,
process, and send BPDUs. (I'm ignoring all the various possible
"port-to-port" things like 802.1AB and 802.1AE etc.)

The corresponding thing for Rbridges is to not be the Designated Rbridge
(DRB) on a port/VLAN pair. When you are not the DRB, native data doesn't
go through and is not processed. However, any TRILL Ethertype frame is
fine to receive, process, and, if appropriate, send. That processing may
cause the frame to be discarded, as you point out below, but I just
don't think of that as the same thing as throwing away a frame as soon
as you notice that it is a native data frame received from a port/VLAN
where you are not DRB or not emitting the native data frame inside a
TRILL data frame you have received onto any port/VLAN pair because you
are not DRB.

Maybe we are just arguing about what words to use.

In any case, my point was that in connection with "blocking" as I mean
it above, I don't see any difference between TRILL IS-IS frames and
TRILL data frames. So there is no particular reason to have two
multicast addresses. In fact, depending just on the multicast address to
by-pass blocking isn't right, because unicast TRILL data frames need to
get through and, if there were any unicast TRILL IS-IS frames, they
would need to get through also. Looking for the TRILL Ethertype seems
like the best way to determine if a frame gets through "blocking".

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[e-mail]] 
Sent: Monday, June 18, 2007 2:10 PM
To: Eastlake III Donald-LDE008; Silvano Gai; [e-mail]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

Donald,

Even in the TRILL network, you have to block frames 
with the all-rbridges address if the come in on a 
port that is not part of the tree identified by the 
egress rbridge address in the frame.

Anoop 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Sunday, June 17, 2007 8:57 PM
> To: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> I've got no problem with using destination address to bypass 
> blocked port state but the only thing you need to block are 
> native data frames.
> Once a frame has been admitted by a DRB and converted into a 
> TRILL data frame, there is no reason to port block it. So 
> anything to the All Rbridges multicast address is fine.
> 
> Donald 
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Sunday, June 17, 2007 1:22 AM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> I disagree; current bridges distinguish control frames 
> (BPDUs, CDP, LLDP, GARP, etc) on reserved MAC addresses.
> 
> Remember that these control frames need to bypass the blocked 
> port state (due to ST or DRB election). 
> 
> Today we have port logic that checks a set of registers for 
> MAC addresses of frames that need to bypass the port state. 
> 
> It is much more difficult to parse a frame to understand if 
> applying or not the port state.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Saturday, June 16, 2007 8:11 PM
> > To: [e-mail]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > While I think that multicast addresses are cheap, so we could
> certainly
> > get two, I don't see any advantage to having two: presumably 
> > "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
> You
> > definitely want different multicast addresses if you have different 
> > listeners, but in this case all Rbridges would have to list 
> for both 
> > multicast addresses.
> > 
> > Both TRILL Data and TRILL IS-IS messages have the same structure of 
> > TRILL header and it seems easier to figure things out from 
> that header 
> > rather than having to keep track of one extra bit from 
> earlier in the 
> > frame from the multicast address.
> > 
> > The variant of IS-IS that the IS-IS working group deployed 
> did use a 
> > different multicast address from the one used for level one IS-IS 
> > routers, the multicast address "All-Level-1-ISs". We are 
> already using
> a
> > different multicast address from that, just like they did, by using
> the
> > multicast address "All-Rbridges".
> > 
> > Thanks,
> > Donald
> > 
> > PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
> which
> > isn't relevant as the TRILL usage of IS-IS is Level 1.
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Silvano Gai
> > Sent: Saturday, June 16, 2007 11:24 AM
> > To: Radia Perlman; [e-mail]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > 
> > If this is the case I will use the multicast address to distinguish 
> > TRILL ISIS not an extra bit in the header.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Radia Perlman
> > > Sent: Friday, June 15, 2007 9:12 PM
> > > To: [e-mail]
> > > Subject: [rbridge] I got some answers from the IS-IS mailing list
> > >
> > > 1) They have deployed a variant of IS-IS, and the way they
> distinguish
> > > their instances
> > > is based on having a new multicast address. I wrongly remembered
> > IS-IS,
> > > and thought that
> > > PSNPs got unicast, but even those are multicast (and I 
> remember the 
> > > reasoning at the time this was decided 100 years ago, 
> which was to 
> > > suppress lots of routers sending the same PSNP). So, for encoding 
> > > TRILL IS-IS, it can be differentiated
> > from
> > > layer 3 IS-IS
> > > by having a different multicast address. The bit in the 
> header works 
> > > too, however.
> > >
> > > 2) I checked to make sure that "0" would be OK to use as an area 
> > > address, and it is.
> > >
> > > 3) The solution I proposed to the scalability issue of having a
> > zillion
> > > pseudonodes on a LAN
> > > (having the DR give the same name to all the pseudonodes that get 
> > > spawned by running the Hello protocol on a link according to each 
> > > VLAN the DR supports)
> > works.
> > > I was worried
> > > about nontransitive connectivity (R1, the DR, names the pseudonode
> > R1.1,
> > > and issues
> > > an LSP on behalf of the pseudonode claiming to be attached to all
> the
> > > RBridges on the
> > > link that can talk to R1 via any of the VLAN tags. But even though
> R2
> > > can talk to R1 (using
> > > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> > that
> > > R2 and R3
> > > can talk to each other.)
> > >
> > > Interestingly, way back when IS-IS was DECnet phase V, 
> and we were 
> > > worried about weird hardware problems creating nontransitive 
> > > connectivity, we put
> in
> > > what R2 should
> > > do when the link state database implies R2 can talk to R3 through
> the
> > > pseudonode, but
> > > R2 can't really talk to R3 -- R2 sends to the DR).
> > >
> > > So we can use this solution. So does that (and learning from data 
> > > packets rather than announcing all endnodes in per-VLAN 
> instances of 
> > > IS-IS) answer
> > everyone's
> > > scalability concerns?
> > >
> > > Radia
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5IIgnHN007466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 18 Jun 2007 11:42:50 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5IIiEps002231; Mon, 18 Jun 2007 13:44:14 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 18 Jun 2007 13:42:44 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 13:42:41 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJAAAGQRAA==
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 18:42:44.0177 (UTC) FILETIME=[7543AC10:01C7B1D8]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IIgnHN007466
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 18:43:10 -0000
Status: RO
Content-Length: 4137

Anoop,

	I tend to view your response below as yet another reason
why RBridges MUST use a common path for unicast and multicast
(as well as broadcast and flooded) traffic.  In fact, it is a
very good reason to limit use of "multipathing" in general.

	It is not clear exactly what you mean by your reference to 
differences between control and data paths.  Control messages are 
from one RBridge to another and - presumably - follow the same 
path as data addressed from RBridge to RBridge.  That path may be 
different from data transitting an RBridge campus, but there is 
no RBridge "control" traffic that transits a campus.

	Are you suggesting that IGMP should be treated as a control
protocol within TRILL?

	Nor is it very clear why this observation is specific to 
our discussion of multicast optimization.  As a general rule, if 
there is one reasonably well know application that relies on path 
congruency for proper operation, there are probably others.  

	Do you think we should provide a logical control-function 
"bridging" service for all such applications as a result of path 
divergences we introduce?  Should we conduct a research project
to determine what other "control protocols" we need to include in
TRILL?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 2:18 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
>  
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> > Sent: Monday, June 18, 2007 6:35 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Here is where the problem arises.  With bridges, the ability 
> > to do IGMP snooping can be a local optimization.  Hence it 
> > makes a lot of sense to incorporate the capability (possibly 
> > as an add- on feature) in deployments where it is useful.
> > 
> > But, the weakness in your argument is two pronged, when 
> > dealing with TRILL: one is the argument that IGMP snooping 
> > will not work as a local optimization in TRILL (of which I am 
> > not convinced) and the other is the phrase -
> > 
> > 	"to someone [who] actually uses multicast"
> > 
> > - which would appear not to apply in at least some cases.
> > 
> > In fact, I believe it is the case that most networks use IP 
> > multicast almost exclusively for routing protocols (for which 
> > we have previously concluded IGMP snooping does not work).
> 
> I'd recommend looking at some of the IP multicast
> applications that enterprises deploy.  It's not just
> routing protocols.
>  
> > But, you suppose that this "optimization" is required to be 
> > supported ubiquitously in both senses - i.e. - for all 
> > RBridges in any deployment and for all deployments.  And yet 
> > it is clearly not required in all cases.
> > 
> > Also, note the recent change in consensus to use learning 
> > from the data path would definitely seem to apply to the 
> > multicast case as well as to the unicast case.  
>  
> This is definitely a scalable option for unicast; no argument
> there.  However it doesn't apply to multicast.
> 
> > From the fact 
> > that MAC reachability advertisement is no longer the default 
> > for RBridge routing protocol(s), it should be apparent that 
> > RBridges can implement IGMP snooping as a local optimization 
> > just as existing switces do.
> 
> Absolutely not!  Snooping requires that control and data
> use exactly the same path in the network.  With rBridges
> that is not true (especially when one introduces 
> multipathing).
> 
> > What that means to me is that the protocol specification does 
> > not have to address this - in part because it is an 
> optimization (and
> > - therefore - optional) and in part because it is 
> > implementable as a strictly local optimization in any 
> > specific implementation.
> 
> It depends on whether or not you care for people to
> build and deploy the specification.
> 
> Anoop
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5IIah8f005550 for <[e-mail]>; Mon, 18 Jun 2007 11:36:43 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 18 Jun 2007 11:36:43 -0700
X-IronPort-AV: i="4.16,435,1175497200";  d="scan'208"; a="13803127:sNHT20844089"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 2EFFB23836C; Mon, 18 Jun 2007 11:34:23 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jun 2007 11:36:43 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 11:36:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHz3IgAApe64A=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 18:36:43.0718 (UTC) FILETIME=[9E69FE60:01C7B1D7]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IIah8f005550
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 18:37:04 -0000
Status: RO
Content-Length: 1744

 

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 6:59 AM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>
> > I don't know too many midrange routers that are capable of 
> supporting 
> > 4K adjacencies.  I do know several midrange switches that are 
> > perfectly capable of supporting all 4K VLANs and mapping 
> them to MST 
> > instances.

> I also have made the (somewhat subtle) point that the concept 
> of "adjacencies" in soft-state protocols is not quite the 
> scalability issue that you think it is.

And I just don't get it.

> Thus, my argument is that your concerns are not a problem we 
> need to solve.
> 
> In a rational discussion, it IS NOT necessary for a person to 
> prove that a problem does not need to be solved.  Otherwise, 
> it would be possible to endlessly stall rational discussions 
> with arbitrary "problems" 
> and a supposed "necessity" to establish that none of them 
> need to be solved.
> 
> In any rational discussion, it IS necessary to show that 
> there is a point in pursuing resolution of any specific issue 
> or problem.  Otherwise, it would be likely that any rational 
> discussion would quickly become pointless.
> 
> Hence, it is necessary for you to prove that your specific 
> problem is in fact an issue that we need to address and it is 
> not necessary for me to prove that it is not.
> 
> So far, you have simply asserted that there is an issue with 
> scalability that we need to solve.
> 
> Prove it. 

I don't have much more to offer in terms of argument
other than what I already have.  So we'll just have
to disagree on this matter.

Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5III7Y6000141 for <[e-mail]>; Mon, 18 Jun 2007 11:18:07 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 18 Jun 2007 11:18:07 -0700
X-IronPort-AV: i="4.16,435,1175497200";  d="scan'208"; a="11097649:sNHT21693700"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 61AF823836C; Mon, 18 Jun 2007 11:15:47 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jun 2007 11:18:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 11:17:49 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4gAApeQJA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 18:18:07.0895 (UTC) FILETIME=[0554EA70:01C7B1D5]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5III7Y6000141
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 18:18:36 -0000
Status: RO
Content-Length: 2468

 

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Monday, June 18, 2007 6:35 AM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Here is where the problem arises.  With bridges, the ability 
> to do IGMP snooping can be a local optimization.  Hence it 
> makes a lot of sense to incorporate the capability (possibly 
> as an add- on feature) in deployments where it is useful.
> 
> But, the weakness in your argument is two pronged, when 
> dealing with TRILL: one is the argument that IGMP snooping 
> will not work as a local optimization in TRILL (of which I am 
> not convinced) and the other is the phrase -
> 
> 	"to someone [who] actually uses multicast"
> 
> - which would appear not to apply in at least some cases.
> 
> In fact, I believe it is the case that most networks use IP 
> multicast almost exclusively for routing protocols (for which 
> we have previously concluded IGMP snooping does not work).

I'd recommend looking at some of the IP multicast
applications that enterprises deploy.  It's not just
routing protocols.
 
> But, you suppose that this "optimization" is required to be 
> supported ubiquitously in both senses - i.e. - for all 
> RBridges in any deployment and for all deployments.  And yet 
> it is clearly not required in all cases.
> 
> Also, note the recent change in consensus to use learning 
> from the data path would definitely seem to apply to the 
> multicast case as well as to the unicast case.  
 
This is definitely a scalable option for unicast; no argument
there.  However it doesn't apply to multicast.

> From the fact 
> that MAC reachability advertisement is no longer the default 
> for RBridge routing protocol(s), it should be apparent that 
> RBridges can implement IGMP snooping as a local optimization 
> just as existing switces do.

Absolutely not!  Snooping requires that control and data
use exactly the same path in the network.  With rBridges
that is not true (especially when one introduces 
multipathing).

> What that means to me is that the protocol specification does 
> not have to address this - in part because it is an optimization (and
> - therefore - optional) and in part because it is 
> implementable as a strictly local optimization in any 
> specific implementation.

It depends on whether or not you care for people to
build and deploy the specification.

Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5IIA9Ba027643 for <[e-mail]>; Mon, 18 Jun 2007 11:10:17 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 18 Jun 2007 11:10:05 -0700
X-IronPort-AV: i="4.16,435,1175497200";  d="scan'208"; a="11097523:sNHT22703611"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 5620D23836C; Mon, 18 Jun 2007 11:07:45 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jun 2007 11:10:06 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 11:09:47 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
Thread-Index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIAAvcbTAAB3PRFA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Silvano Gai" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 18:10:06.0080 (UTC) FILETIME=[E625C800:01C7B1D3]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IIA9Ba027643
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 18:10:33 -0000
Status: RO
Content-Length: 6528

Donald,

Even in the TRILL network, you have to block frames 
with the all-rbridges address if the come in on a 
port that is not part of the tree identified by the 
egress rbridge address in the frame.

Anoop 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Sunday, June 17, 2007 8:57 PM
> To: Silvano Gai; [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> I've got not problem with using destination address to bypass 
> blocked port state but the only thing you need to block are 
> native data frames.
> Once a frame has been admitted by a DRB and converted into a 
> TRILL data frame, there is no reason to port block it. So 
> anything to the All Rbridges multicast address is fine.
> 
> Donald 
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Sunday, June 17, 2007 1:22 AM
> To: Eastlake III Donald-LDE008; [e-mail]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> I disagree; current bridges distinguish control frames 
> (BPDUs, CDP, LLDP, GARP, etc) on reserved MAC addresses.
> 
> Remember that these control frames need to bypass the blocked 
> port state (due to ST or DRB election). 
> 
> Today we have port logic that checks a set of registers for 
> MAC addresses of frames that need to bypass the port state. 
> 
> It is much more difficult to parse a frame to understand if 
> applying or not the port state.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Saturday, June 16, 2007 8:11 PM
> > To: [e-mail]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > While I think that multicast addresses are cheap, so we could
> certainly
> > get two, I don't see any advantage to having two: presumably 
> > "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
> You
> > definitely want different multicast addresses if you have different 
> > listeners, but in this case all Rbridges would have to list 
> for both 
> > multicast addresses.
> > 
> > Both TRILL Data and TRILL IS-IS messages have the same structure of 
> > TRILL header and it seems easier to figure things out from 
> that header 
> > rather than having to keep track of one extra bit from 
> earlier in the 
> > frame from the multicast address.
> > 
> > The variant of IS-IS that the IS-IS working group deployed 
> did use a 
> > different multicast address from the one used for level one IS-IS 
> > routers, the multicast address "All-Level-1-ISs". We are 
> already using
> a
> > different multicast address from that, just like they did, by using
> the
> > multicast address "All-Rbridges".
> > 
> > Thanks,
> > Donald
> > 
> > PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
> which
> > isn't relevant as the TRILL usage of IS-IS is Level 1.
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Silvano Gai
> > Sent: Saturday, June 16, 2007 11:24 AM
> > To: Radia Perlman; [e-mail]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > 
> > If this is the case I will use the multicast address to distinguish 
> > TRILL ISIS not an extra bit in the header.
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > On
> > > Behalf Of Radia Perlman
> > > Sent: Friday, June 15, 2007 9:12 PM
> > > To: [e-mail]
> > > Subject: [rbridge] I got some answers from the IS-IS mailing list
> > >
> > > 1) They have deployed a variant of IS-IS, and the way they
> distinguish
> > > their instances
> > > is based on having a new multicast address. I wrongly remembered
> > IS-IS,
> > > and thought that
> > > PSNPs got unicast, but even those are multicast (and I 
> remember the 
> > > reasoning at the time this was decided 100 years ago, 
> which was to 
> > > suppress lots of routers sending the same PSNP). So, for encoding 
> > > TRILL IS-IS, it can be differentiated
> > from
> > > layer 3 IS-IS
> > > by having a different multicast address. The bit in the 
> header works 
> > > too, however.
> > >
> > > 2) I checked to make sure that "0" would be OK to use as an area 
> > > address, and it is.
> > >
> > > 3) The solution I proposed to the scalability issue of having a
> > zillion
> > > pseudonodes on a LAN
> > > (having the DR give the same name to all the pseudonodes that get 
> > > spawned by running the Hello protocol on a link according to each 
> > > VLAN the DR supports)
> > works.
> > > I was worried
> > > about nontransitive connectivity (R1, the DR, names the pseudonode
> > R1.1,
> > > and issues
> > > an LSP on behalf of the pseudonode claiming to be attached to all
> the
> > > RBridges on the
> > > link that can talk to R1 via any of the VLAN tags. But even though
> R2
> > > can talk to R1 (using
> > > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> > that
> > > R2 and R3
> > > can talk to each other.)
> > >
> > > Interestingly, way back when IS-IS was DECnet phase V, 
> and we were 
> > > worried about weird hardware problems creating nontransitive 
> > > connectivity, we put
> in
> > > what R2 should
> > > do when the link state database implies R2 can talk to R3 through
> the
> > > pseudonode, but
> > > R2 can't really talk to R3 -- R2 sends to the DR).
> > >
> > > So we can use this solution. So does that (and learning from data 
> > > packets rather than announcing all endnodes in per-VLAN 
> instances of 
> > > IS-IS) answer
> > everyone's
> > > scalability concerns?
> > >
> > > Radia
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5IGqNqG006018 for <[e-mail]>; Mon, 18 Jun 2007 09:52:24 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-119.messagelabs.com!1182185542!23035598!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.189.100.103]
Received: (qmail 15163 invoked from network); 18 Jun 2007 16:52:22 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-14.tower-119.messagelabs.com with SMTP; 18 Jun 2007 16:52:22 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l5IGqH5n004692 for <[e-mail]>; Mon, 18 Jun 2007 09:52:22 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5IGqHGS004149 for <[e-mail]>; Mon, 18 Jun 2007 11:52:17 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5IGqFTH004111 for <[e-mail]>; Mon, 18 Jun 2007 11:52:16 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 12:52:14 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IS-IS Consensus Call, Routing Requirements Document
thread-index: AcexyQW7vMDVoDvsS1aefWusSLdgWg==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IGqNqG006018
Subject: [rbridge] IS-IS Consensus Call, Routing Requirements Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 16:52:30 -0000
Status: RO
Content-Length: 1242

It appears that there has been some change in the IESG position on the
selection of a link state routing protocol for TRILL. Since we have been
working on the TRILL protocol specification for some time and no
reasonable alternative has appeared, if there is a TRILL working group
consensus for IS-IS, we expect that this will satisfy the IESG. As a
consequence, the Routing Requirements document, which was originally
requested by the IESG as a basis for deciding on the routing protocol,
would no longer be necessary after a selection of IS-IS. This document,
in fact, ran into a lot of opposition in the IESG, not because of what
it says about routing requirements, but mostly because it was somehow
misinterpreted as a TRILL requirements document. We would expect that,
after selection of IS-IS, the key points of the Routing Requirements
document would be merged into the Architecture document and no longer be
a separate deliverable.

The discussion in the working group has given the impression that there
is a consensus for IS-IS. In fact, it may come as a surprise to some
people that it has not yet been officially selected. Unless significant
opposition appears, we will judge that IS-IS is the consensus.

Thanks,
Erik and Donald



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5IDx4pb013714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 18 Jun 2007 06:59:04 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5IE24vu011483; Mon, 18 Jun 2007 09:02:05 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 18 Jun 2007 08:59:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 08:59:01 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHz3Ig
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 13:59:03.0004 (UTC) FILETIME=[D3DAC9C0:01C7B1B0]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IDx4pb013714
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 13:59:24 -0000
Status: RO
Content-Length: 2264

Anoop,

	See additional response(s) below...

--
Eric Gray
Principal Engineer
Ericsson  

> 
> > 	On the issue of link-state protocol scalability, do you 
> > have any evidence to support your claims for non-scalability? 
> >  Does it (your evidence) include a comparison of scalability 
> > of multiple instances to scalability of similar single 
> > instance solution? 
> > Throwing the number of adjacencies around does not - in and 
> > of itself - prove much of anything.
> 
> I don't know too many midrange routers that are
> capable of supporting 4K adjacencies.  I do know
> several midrange switches that are perfectly 
> capable of supporting all 4K VLANs and mapping
> them to MST instances.
> 
> Why don't you prove that it scales, instead of
> having me prove otherwise?  :-)
> 
> Anoop
> 

You are the one who asserted that scale is an issue.

I have made the point that significant increases in
scalability is not a goal of the TRILL work.

I have made the point that - once you suppose that a
single physical LAN might have as many as 4K VLANs 
within it - this same scaling issue exists today for
any routing protocol.  Apparently, you did not quite
understand this point - but I made it none-the-less.

I also have made the (somewhat subtle) point that the
concept of "adjacencies" in soft-state protocols is
not quite the scalability issue that you think it is.

Thus, my argument is that your concerns are not a 
problem we need to solve.

In a rational discussion, it IS NOT necessary for a
person to prove that a problem does not need to be 
solved.  Otherwise, it would be possible to endlessly 
stall rational discussions with arbitrary "problems" 
and a supposed "necessity" to establish that none of 
them need to be solved.

In any rational discussion, it IS necessary to show
that there is a point in pursuing resolution of any
specific issue or problem.  Otherwise, it would be 
likely that any rational discussion would quickly 
become pointless.

Hence, it is necessary for you to prove that your
specific problem is in fact an issue that we need 
to address and it is not necessary for me to prove 
that it is not.

So far, you have simply asserted that there is an 
issue with scalability that we need to solve.

Prove it. 

--
E



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5IDZcvZ007029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 18 Jun 2007 06:35:38 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5IDb1TD012270; Mon, 18 Jun 2007 08:37:01 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 18 Jun 2007 08:35:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jun 2007 08:35:27 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YACHCu4g
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2007 13:35:32.0442 (UTC) FILETIME=[8B181BA0:01C7B1AD]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5IDZcvZ007029
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 13:36:32 -0000
Status: RO
Content-Length: 3207

Anoop,

	Please see below...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Friday, June 15, 2007 4:52 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
>  
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> > Sent: Friday, June 15, 2007 1:05 PM
> > To: Anoop Ghanwani
> > Cc: [e-mail]; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	There are two issues you're attempting to address in 
> > this mail.  One is the issue with advertising, and you have 
> > further broken that into unicast and multicast.  The other is 
> > with how the RBridge link state protocols scale.
> > 
> > 	On the first issue, you agree that having the default 
> > mode for acquiring unicast MAC reachability be via learning, 
> > addresses that portion of the scalability issue.  For 
> > multicast, you seem to assume that multicast optimization is 
> > required - because the only reason why acquiring multicast 
> > address reachability would be needed is if you absolutely 
> > require multicast optimization (instead of treating multicast 
> > as broadcast - as is still allowed for a standard bridge).
> 
> All I can say is - try selling a bridge that doesn't do 
> IGMP snooping to someone that actually uses multicast.
> That will address your concern on why the optimization
> is absolutely essential.
> 

Here is where the problem arises.  With bridges, the ability to
do IGMP snooping can be a local optimization.  Hence it makes a
lot of sense to incorporate the capability (possibly as an add-
on feature) in deployments where it is useful.

But, the weakness in your argument is two pronged, when dealing
with TRILL: one is the argument that IGMP snooping will not work 
as a local optimization in TRILL (of which I am not convinced)
and the other is the phrase -

	"to someone [who] actually uses multicast"

- which would appear not to apply in at least some cases.

In fact, I believe it is the case that most networks use IP
multicast almost exclusively for routing protocols (for which
we have previously concluded IGMP snooping does not work).

But, you suppose that this "optimization" is required to be
supported ubiquitously in both senses - i.e. - for all RBridges 
in any deployment and for all deployments.  And yet it is clearly
not required in all cases.

Also, note the recent change in consensus to use learning from
the data path would definitely seem to apply to the multicast
case as well as to the unicast case.  From the fact that MAC
reachability advertisement is no longer the default for RBridge
routing protocol(s), it should be apparent that RBridges can 
implement IGMP snooping as a local optimization just as existing 
switces do.

What that means to me is that the protocol specification does not 
have to address this - in part because it is an optimization (and
- therefore - optional) and in part because it is implementable 
as a strictly local optimization in any specific implementation.

--
E



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5I3vJoL007180 for <[e-mail]>; Sun, 17 Jun 2007 20:57:19 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-153.messagelabs.com!1182139038!1516951!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12634 invoked from network); 18 Jun 2007 03:57:18 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 18 Jun 2007 03:57:18 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5I3vI8C022631 for <[e-mail]>; Sun, 17 Jun 2007 20:57:18 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5I3vHUR021999 for <[e-mail]>; Sun, 17 Jun 2007 22:57:17 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5I3vG4E021989 for <[e-mail]>; Sun, 17 Jun 2007 22:57:17 -0500 (CDT)
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: Sun, 17 Jun 2007 23:57:13 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
thread-index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIAAvcbTA
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5I3vJoL007180
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 03:57:40 -0000
Status: RO
Content-Length: 5486

I've got not problem with using destination address to bypass blocked
port state but the only thing you need to block are native data frames.
Once a frame has been admitted by a DRB and converted into a TRILL data
frame, there is no reason to port block it. So anything to the All
Rbridges multicast address is fine.

Donald 

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Sunday, June 17, 2007 1:22 AM
To: Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

I disagree; current bridges distinguish control frames (BPDUs, CDP,
LLDP, GARP, etc) on reserved MAC addresses.

Remember that these control frames need to bypass the blocked port state
(due to ST or DRB election). 

Today we have port logic that checks a set of registers for MAC
addresses of frames that need to bypass the port state. 

It is much more difficult to parse a frame to understand if applying or
not the port state.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Saturday, June 16, 2007 8:11 PM
> To: [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> While I think that multicast addresses are cheap, so we could
certainly
> get two, I don't see any advantage to having two: presumably
> "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
You
> definitely want different multicast addresses if you have different
> listeners, but in this case all Rbridges would have to list for both
> multicast addresses.
> 
> Both TRILL Data and TRILL IS-IS messages have the same structure of
> TRILL header and it seems easier to figure things out from that header
> rather than having to keep track of one extra bit from earlier in the
> frame from the multicast address.
> 
> The variant of IS-IS that the IS-IS working group deployed did use a
> different multicast address from the one used for level one IS-IS
> routers, the multicast address "All-Level-1-ISs". We are already using
a
> different multicast address from that, just like they did, by using
the
> multicast address "All-Rbridges".
> 
> Thanks,
> Donald
> 
> PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
which
> isn't relevant as the TRILL usage of IS-IS is Level 1.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Silvano Gai
> Sent: Saturday, June 16, 2007 11:24 AM
> To: Radia Perlman; [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> 
> If this is the case I will use the multicast address to distinguish
> TRILL ISIS not an extra bit in the header.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Radia Perlman
> > Sent: Friday, June 15, 2007 9:12 PM
> > To: [e-mail]
> > Subject: [rbridge] I got some answers from the IS-IS mailing list
> >
> > 1) They have deployed a variant of IS-IS, and the way they
distinguish
> > their instances
> > is based on having a new multicast address. I wrongly remembered
> IS-IS,
> > and thought that
> > PSNPs got unicast, but even those are multicast (and I remember the
> > reasoning at the
> > time this was decided 100 years ago, which was to suppress lots of
> > routers sending the
> > same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
> from
> > layer 3 IS-IS
> > by having a different multicast address. The bit in the header works
> > too, however.
> >
> > 2) I checked to make sure that "0" would be OK to use as an area
> > address, and it is.
> >
> > 3) The solution I proposed to the scalability issue of having a
> zillion
> > pseudonodes on a LAN
> > (having the DR give the same name to all the pseudonodes that get
> > spawned by running the
> > Hello protocol on a link according to each VLAN the DR supports)
> works.
> > I was worried
> > about nontransitive connectivity (R1, the DR, names the pseudonode
> R1.1,
> > and issues
> > an LSP on behalf of the pseudonode claiming to be attached to all
the
> > RBridges on the
> > link that can talk to R1 via any of the VLAN tags. But even though
R2
> > can talk to R1 (using
> > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> that
> > R2 and R3
> > can talk to each other.)
> >
> > Interestingly, way back when IS-IS was DECnet phase V, and we were
> > worried about
> > weird hardware problems creating nontransitive connectivity, we put
in
> > what R2 should
> > do when the link state database implies R2 can talk to R3 through
the
> > pseudonode, but
> > R2 can't really talk to R3 -- R2 sends to the DR).
> >
> > So we can use this solution. So does that (and learning from data
> > packets rather than
> > announcing all endnodes in per-VLAN instances of IS-IS) answer
> everyone's
> > scalability concerns?
> >
> > Radia
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5H5MAJw023967 for <[e-mail]>; Sat, 16 Jun 2007 22:22:10 -0700 (PDT)
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: Sat, 16 Jun 2007 22:21:47 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
Thread-Index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mAABM3dIA==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5H5MAJw023967
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 17 Jun 2007 05:22:38 -0000
Status: RO
Content-Length: 4925

I disagree; current bridges distinguish control frames (BPDUs, CDP,
LLDP, GARP, etc) on reserved MAC addresses.

Remember that these control frames need to bypass the blocked port state
(due to ST or DRB election). 

Today we have port logic that checks a set of registers for MAC
addresses of frames that need to bypass the port state. 

It is much more difficult to parse a frame to understand if applying or
not the port state.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Saturday, June 16, 2007 8:11 PM
> To: [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> While I think that multicast addresses are cheap, so we could
certainly
> get two, I don't see any advantage to having two: presumably
> "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
You
> definitely want different multicast addresses if you have different
> listeners, but in this case all Rbridges would have to list for both
> multicast addresses.
> 
> Both TRILL Data and TRILL IS-IS messages have the same structure of
> TRILL header and it seems easier to figure things out from that header
> rather than having to keep track of one extra bit from earlier in the
> frame from the multicast address.
> 
> The variant of IS-IS that the IS-IS working group deployed did use a
> different multicast address from the one used for level one IS-IS
> routers, the multicast address "All-Level-1-ISs". We are already using
a
> different multicast address from that, just like they did, by using
the
> multicast address "All-Rbridges".
> 
> Thanks,
> Donald
> 
> PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
which
> isn't relevant as the TRILL usage of IS-IS is Level 1.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Silvano Gai
> Sent: Saturday, June 16, 2007 11:24 AM
> To: Radia Perlman; [e-mail]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> 
> If this is the case I will use the multicast address to distinguish
> TRILL ISIS not an extra bit in the header.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Radia Perlman
> > Sent: Friday, June 15, 2007 9:12 PM
> > To: [e-mail]
> > Subject: [rbridge] I got some answers from the IS-IS mailing list
> >
> > 1) They have deployed a variant of IS-IS, and the way they
distinguish
> > their instances
> > is based on having a new multicast address. I wrongly remembered
> IS-IS,
> > and thought that
> > PSNPs got unicast, but even those are multicast (and I remember the
> > reasoning at the
> > time this was decided 100 years ago, which was to suppress lots of
> > routers sending the
> > same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
> from
> > layer 3 IS-IS
> > by having a different multicast address. The bit in the header works
> > too, however.
> >
> > 2) I checked to make sure that "0" would be OK to use as an area
> > address, and it is.
> >
> > 3) The solution I proposed to the scalability issue of having a
> zillion
> > pseudonodes on a LAN
> > (having the DR give the same name to all the pseudonodes that get
> > spawned by running the
> > Hello protocol on a link according to each VLAN the DR supports)
> works.
> > I was worried
> > about nontransitive connectivity (R1, the DR, names the pseudonode
> R1.1,
> > and issues
> > an LSP on behalf of the pseudonode claiming to be attached to all
the
> > RBridges on the
> > link that can talk to R1 via any of the VLAN tags. But even though
R2
> > can talk to R1 (using
> > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> that
> > R2 and R3
> > can talk to each other.)
> >
> > Interestingly, way back when IS-IS was DECnet phase V, and we were
> > worried about
> > weird hardware problems creating nontransitive connectivity, we put
in
> > what R2 should
> > do when the link state database implies R2 can talk to R3 through
the
> > pseudonode, but
> > R2 can't really talk to R3 -- R2 sends to the DR).
> >
> > So we can use this solution. So does that (and learning from data
> > packets rather than
> > announcing all endnodes in per-VLAN instances of IS-IS) answer
> everyone's
> > scalability concerns?
> >
> > Radia
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5H3B8OH000305 for <[e-mail]>; Sat, 16 Jun 2007 20:11:08 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-128.messagelabs.com!1182049867!20657176!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.10]
Received: (qmail 7155 invoked from network); 17 Jun 2007 03:11:07 -0000
Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-4.tower-128.messagelabs.com with SMTP; 17 Jun 2007 03:11:07 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l5H3B6X6007825 for <[e-mail]>; Sat, 16 Jun 2007 20:11:07 -0700 (MST)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5H3B5fS019276 for <[e-mail]>; Sat, 16 Jun 2007 22:11:06 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5H3B4lI019268 for <[e-mail]>; Sat, 16 Jun 2007 22:11:05 -0500 (CDT)
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: Sat, 16 Jun 2007 23:11:02 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
thread-index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQgABg/7mA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5H3B8OH000305
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 17 Jun 2007 03:11:36 -0000
Status: RO
Content-Length: 3840

While I think that multicast addresses are cheap, so we could certainly
get two, I don't see any advantage to having two: presumably
"All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses. You
definitely want different multicast addresses if you have different
listeners, but in this case all Rbridges would have to list for both
multicast addresses.

Both TRILL Data and TRILL IS-IS messages have the same structure of
TRILL header and it seems easier to figure things out from that header
rather than having to keep track of one extra bit from earlier in the
frame from the multicast address.

The variant of IS-IS that the IS-IS working group deployed did use a
different multicast address from the one used for level one IS-IS
routers, the multicast address "All-Level-1-ISs". We are already using a
different multicast address from that, just like they did, by using the
multicast address "All-Rbridges".

Thanks,
Donald

PS: There is also an "All-Level-2-ISs" multicast address in IS-IS which
isn't relevant as the TRILL usage of IS-IS is Level 1.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Saturday, June 16, 2007 11:24 AM
To: Radia Perlman; [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list


If this is the case I will use the multicast address to distinguish
TRILL ISIS not an extra bit in the header.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: [e-mail]
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> 1) They have deployed a variant of IS-IS, and the way they distinguish
> their instances
> is based on having a new multicast address. I wrongly remembered
IS-IS,
> and thought that
> PSNPs got unicast, but even those are multicast (and I remember the
> reasoning at the
> time this was decided 100 years ago, which was to suppress lots of
> routers sending the
> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
from
> layer 3 IS-IS
> by having a different multicast address. The bit in the header works
> too, however.
> 
> 2) I checked to make sure that "0" would be OK to use as an area
> address, and it is.
> 
> 3) The solution I proposed to the scalability issue of having a
zillion
> pseudonodes on a LAN
> (having the DR give the same name to all the pseudonodes that get
> spawned by running the
> Hello protocol on a link according to each VLAN the DR supports)
works.
> I was worried
> about nontransitive connectivity (R1, the DR, names the pseudonode
R1.1,
> and issues
> an LSP on behalf of the pseudonode claiming to be attached to all the
> RBridges on the
> link that can talk to R1 via any of the VLAN tags. But even though R2
> can talk to R1 (using
> VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
that
> R2 and R3
> can talk to each other.)
> 
> Interestingly, way back when IS-IS was DECnet phase V, and we were
> worried about
> weird hardware problems creating nontransitive connectivity, we put in
> what R2 should
> do when the link state database implies R2 can talk to R3 through the
> pseudonode, but
> R2 can't really talk to R3 -- R2 sends to the DR).
> 
> So we can use this solution. So does that (and learning from data
> packets rather than
> announcing all endnodes in per-VLAN instances of IS-IS) answer
everyone's
> scalability concerns?
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5H2YT0q023152 for <[e-mail]>; Sat, 16 Jun 2007 19:34:30 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 16 Jun 2007 19:34:27 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.18.48]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Sat, 16 Jun 2007 19:34:26 -0700 (PDT)
Date: Sat, 16 Jun 2007 19:35:07 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Dinesh G Dutt <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 17 Jun 2007 02:35:39 -0000
Status: RO
Content-Length: 1164

Oh definitely. We need both (putting 0 into the area address, and either 
a multicast
address or a bit in the header).

Radia


Dinesh G Dutt wrote:
> Hi Radia,
>
> Radia Perlman wrote:
>> 1) They have deployed a variant of IS-IS, and the way they 
>> distinguish their instances
>> is based on having a new multicast address. I wrongly remembered 
>> IS-IS, and thought that
>> PSNPs got unicast, but even those are multicast (and I remember the 
>> reasoning at the
>> time this was decided 100 years ago, which was to suppress lots of 
>> routers sending the
>> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
>> from layer 3 IS-IS
>> by having a different multicast address. The bit in the header works 
>> too, however.
>>
>> 2) I checked to make sure that "0" would be OK to use as an area 
>> address, and it is.
>>   
> My reading of what they recommended is that we use a different 
> multicast address since it was not guaranteed that all implementations 
> would support a 0 in the area address.
>
> Here is a pointer to the email from Mike Shand: 
> http://www1.ietf.org/mail-archive/web/isis-wg/current/msg01746.html
>
> Dinesh
>



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5GHAKDD017259 for <[e-mail]>; Sat, 16 Jun 2007 10:10:21 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2007 10:10:21 -0700
X-IronPort-AV: i="4.16,430,1175497200";  d="scan'208"; a="379988824:sNHT44599438"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5GHAKgH004009;  Sat, 16 Jun 2007 10:10:20 -0700
Received: from [10.21.66.10] (sjc-vpn3-522.cisco.com [10.21.66.10]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5GHAKtV016254; Sat, 16 Jun 2007 17:10:20 GMT
Message-ID: <[e-mail]>
Date: Sat, 16 Jun 2007 10:10:22 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1152; t=1182013820; x=1182877820; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20I=20got=20some=20answers=20from=20the=20I S-IS=20mailing=20list |Sender:=20; bh=Iqes9ZN+lCNJm6VkCyep4+k37JvlO4YFKUpBX4ClN1g=; b=mtJdFZGQ9FqFjEI9H9rdNpUEArHntUwbwwnh4sPeKi0dKyBgXNyRPtJYJ3geSeb/qVkVBzu6 S8V8tbZKevSWcy8K97meZCzovLthsDZux+yDko5tkV3vOcLjO0Togp8/;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Jun 2007 17:10:45 -0000
Status: RO
Content-Length: 1121

Hi Radia,

Radia Perlman wrote:
> 1) They have deployed a variant of IS-IS, and the way they distinguish 
> their instances
> is based on having a new multicast address. I wrongly remembered IS-IS, 
> and thought that
> PSNPs got unicast, but even those are multicast (and I remember the 
> reasoning at the
> time this was decided 100 years ago, which was to suppress lots of 
> routers sending the
> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated from 
> layer 3 IS-IS
> by having a different multicast address. The bit in the header works 
> too, however.
>
> 2) I checked to make sure that "0" would be OK to use as an area 
> address, and it is.
>   
My reading of what they recommended is that we use a different multicast 
address since it was not guaranteed that all implementations would 
support a 0 in the area address.

Here is a pointer to the email from Mike Shand: 
http://www1.ietf.org/mail-archive/web/isis-wg/current/msg01746.html

Dinesh

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


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5GFOVqe020842 for <[e-mail]>; Sat, 16 Jun 2007 08:24:32 -0700 (PDT)
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: Sat, 16 Jun 2007 08:24:12 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] I got some answers from the IS-IS mailing list
Thread-Index: AcevzYg9AvQMJ43ARK2ibHdPxK97NgAXLHQg
References: <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5GFOVqe020842
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Jun 2007 15:24:43 -0000
Status: RO
Content-Length: 2364

If this is the case I will use the multicast address to distinguish
TRILL ISIS not an extra bit in the header.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: [e-mail]
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> 1) They have deployed a variant of IS-IS, and the way they distinguish
> their instances
> is based on having a new multicast address. I wrongly remembered
IS-IS,
> and thought that
> PSNPs got unicast, but even those are multicast (and I remember the
> reasoning at the
> time this was decided 100 years ago, which was to suppress lots of
> routers sending the
> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
from
> layer 3 IS-IS
> by having a different multicast address. The bit in the header works
> too, however.
> 
> 2) I checked to make sure that "0" would be OK to use as an area
> address, and it is.
> 
> 3) The solution I proposed to the scalability issue of having a
zillion
> pseudonodes on a LAN
> (having the DR give the same name to all the pseudonodes that get
> spawned by running the
> Hello protocol on a link according to each VLAN the DR supports)
works.
> I was worried
> about nontransitive connectivity (R1, the DR, names the pseudonode
R1.1,
> and issues
> an LSP on behalf of the pseudonode claiming to be attached to all the
> RBridges on the
> link that can talk to R1 via any of the VLAN tags. But even though R2
> can talk to R1 (using
> VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
that
> R2 and R3
> can talk to each other.)
> 
> Interestingly, way back when IS-IS was DECnet phase V, and we were
> worried about
> weird hardware problems creating nontransitive connectivity, we put in
> what R2 should
> do when the link state database implies R2 can talk to R3 through the
> pseudonode, but
> R2 can't really talk to R3 -- R2 sends to the DR).
> 
> So we can use this solution. So does that (and learning from data
> packets rather than
> announcing all endnodes in per-VLAN instances of IS-IS) answer
everyone's
> scalability concerns?
> 
> Radia
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



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 l5G4As54021939 for <[e-mail]>; Fri, 15 Jun 2007 21:10:54 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 15 Jun 2007 21:10:50 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.18.48]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 15 Jun 2007 21:10:49 -0700 (PDT)
Date: Fri, 15 Jun 2007 21:11:31 -0700
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] I got some answers from the IS-IS mailing list
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Jun 2007 04:11:25 -0000
Status: RO
Content-Length: 1754

1) They have deployed a variant of IS-IS, and the way they distinguish 
their instances
is based on having a new multicast address. I wrongly remembered IS-IS, 
and thought that
PSNPs got unicast, but even those are multicast (and I remember the 
reasoning at the
time this was decided 100 years ago, which was to suppress lots of 
routers sending the
same PSNP). So, for encoding TRILL IS-IS, it can be differentiated from 
layer 3 IS-IS
by having a different multicast address. The bit in the header works 
too, however.

2) I checked to make sure that "0" would be OK to use as an area 
address, and it is.

3) The solution I proposed to the scalability issue of having a zillion 
pseudonodes on a LAN
(having the DR give the same name to all the pseudonodes that get 
spawned by running the
Hello protocol on a link according to each VLAN the DR supports) works. 
I was worried
about nontransitive connectivity (R1, the DR, names the pseudonode R1.1, 
and issues
an LSP on behalf of the pseudonode claiming to be attached to all the 
RBridges on the
link that can talk to R1 via any of the VLAN tags. But even though R2 
can talk to R1 (using
VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean that 
R2 and R3
can talk to each other.)

Interestingly, way back when IS-IS was DECnet phase V, and we were 
worried about
weird hardware problems creating nontransitive connectivity, we put in 
what R2 should
do when the link state database implies R2 can talk to R3 through the 
pseudonode, but
R2 can't really talk to R3 -- R2 sends to the DR).

So we can use this solution. So does that (and learning from data 
packets rather than
announcing all endnodes in per-VLAN instances of IS-IS) answer everyone's
scalability concerns?

Radia


Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5FKq7vL013647 for <[e-mail]>; Fri, 15 Jun 2007 13:52:07 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 15 Jun 2007 13:52:07 -0700
X-IronPort-AV: i="4.16,426,1175497200";  d="scan'208"; a="11053076:sNHT18628057"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 5C640238381; Fri, 15 Jun 2007 13:49:51 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jun 2007 13:52:07 -0700
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: Fri, 15 Jun 2007 13:51:48 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZAAAk//YA==
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-OriginalArrivalTime: 15 Jun 2007 20:52:07.0971 (UTC) FILETIME=[099B5F30:01C7AF8F]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5FKq7vL013647
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 20:52:16 -0000
Status: RO
Content-Length: 1856

 

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Friday, June 15, 2007 1:05 PM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> 	There are two issues you're attempting to address in 
> this mail.  One is the issue with advertising, and you have 
> further broken that into unicast and multicast.  The other is 
> with how the RBridge link state protocols scale.
> 
> 	On the first issue, you agree that having the default 
> mode for acquiring unicast MAC reachability be via learning, 
> addresses that portion of the scalability issue.  For 
> multicast, you seem to assume that multicast optimization is 
> required - because the only reason why acquiring multicast 
> address reachability would be needed is if you absolutely 
> require multicast optimization (instead of treating multicast 
> as broadcast - as is still allowed for a standard bridge).

All I can say is - try selling a bridge that doesn't do 
IGMP snooping to someone that actually uses multicast.
That will address your concern on why the optimization
is absolutely essential.

> 	On the issue of link-state protocol scalability, do you 
> have any evidence to support your claims for non-scalability? 
>  Does it (your evidence) include a comparison of scalability 
> of multiple instances to scalability of similar single 
> instance solution? 
> Throwing the number of adjacencies around does not - in and 
> of itself - prove much of anything.

I don't know too many midrange routers that are
capable of supporting 4K adjacencies.  I do know
several midrange switches that are perfectly 
capable of supporting all 4K VLANs and mapping
them to MST instances.

Why don't you prove that it scales, instead of
having me prove otherwise?  :-)

Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5FKktMT012433 for <[e-mail]>; Fri, 15 Jun 2007 13:46:56 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 15 Jun 2007 13:46:55 -0700
X-IronPort-AV: i="4.16,426,1175497200";  d="scan'208"; a="11052968:sNHT17787560"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 34C45238381; Fri, 15 Jun 2007 13:44:39 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jun 2007 13:46:55 -0700
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: Fri, 15 Jun 2007 13:46:36 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAAMvlTAAAl1RsA==
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 15 Jun 2007 20:46:55.0716 (UTC) FILETIME=[4F7D0A40:01C7AF8E]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5FKktMT012433
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 20:47:13 -0000
Status: RO
Content-Length: 762

 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[e-mail]] 
> Sent: Friday, June 15, 2007 12:41 PM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> You only have an instance of IS-IS for VLAN x in Rbridge y is 
> Rbridge y
> is advertising that it has directly connected end stations in 
> VLAN x. Is
> it plausible that an Rbridge would be reporting that it has directly
> connected end stations in all of 4K VLANs?

I understand that.  But it's not completely
out of the world to have 4K VLANs configured
in a "core" switch.  If you had RBridge 
network attached to one of these, you'd have
to be able to deal with the 4K instances.

Anoop



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5FKAFGo002732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 15 Jun 2007 13:10:15 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5FKBVhu010992; Fri, 15 Jun 2007 15:11:31 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 15 Jun 2007 15:10:09 -0500
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: Fri, 15 Jun 2007 15:10:09 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAAMvlTAAAPrhwA==
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 15 Jun 2007 20:10:09.0972 (UTC) FILETIME=[2CC33740:01C7AF89]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5FKAFGo002732
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 20:10:51 -0000
Status: RO
Content-Length: 1857

Donald,

	This is the essence of why I asked the questions I asked Anoop.
In the real world, if you have a significant overlap in VLAN membership
at the edges, then you achieve similarly significant scaling advantages
by grouping VLANs and using Q-in-Q.  It is therefore very difficult to
imagine a realistic scenario in which you would actually have N-squared
order of adjacencies for even a large part of 4K VLANs.

	It is for this very reason that I would like to hear about real
world scenarios where the above reasoning does not apply...

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, June 15, 2007 3:41 PM
> To: Anoop Ghanwani
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> You only have an instance of IS-IS for VLAN x in Rbridge y is 
> Rbridge y
> is advertising that it has directly connected end stations in 
> VLAN x. Is
> it plausible that an Rbridge would be reporting that it has directly
> connected end stations in all of 4K VLANs?
> 
> Donald
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Anoop Ghanwani
> Sent: Friday, June 15, 2007 2:15 PM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> ...
> 
> If you absolutely had to have multiple IS-IS
> instances, it might make sense to have some
> number 'n' and then define a mapping of VLANs
> to each instance.  Having 4K instances of IS-IS
> running in an RBridge won't scale.
> 
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5FK4rbm001383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 15 Jun 2007 13:04:53 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5FK7f0C003012; Fri, 15 Jun 2007 15:07:42 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 15 Jun 2007 15:04:47 -0500
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: Fri, 15 Jun 2007 15:04:46 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAANQJZA=
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 15 Jun 2007 20:04:47.0962 (UTC) FILETIME=[6CD463A0:01C7AF88]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5FK4rbm001383
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 20:05:22 -0000
Status: RO
Content-Length: 4496

Anoop,

	There are two issues you're attempting to address in this 
mail.  One is the issue with advertising, and you have further 
broken that into unicast and multicast.  The other is with how
the RBridge link state protocols scale.

	On the first issue, you agree that having the default mode
for acquiring unicast MAC reachability be via learning, addresses
that portion of the scalability issue.  For multicast, you seem
to assume that multicast optimization is required - because the
only reason why acquiring multicast address reachability would
be needed is if you absolutely require multicast optimization 
(instead of treating multicast as broadcast - as is still allowed 
for a standard bridge).

	On the issue of link-state protocol scalability, do you have
any evidence to support your claims for non-scalability?  Does it
(your evidence) include a comparison of scalability of multiple
instances to scalability of similar single instance solution? 
Throwing the number of adjacencies around does not - in and of 
itself - prove much of anything.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Friday, June 15, 2007 2:15 PM
> To: Radia Perlman
> Cc: Eric Gray (LO/EUS); [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
>  
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[e-mail]] 
> > Sent: Thursday, June 14, 2007 9:54 PM
> > To: Anoop Ghanwani
> > Cc: Eric Gray (LO/EUS); [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > I'm catching up after travelling, so if someone else answered this, 
> > sorry about that.
> > 
> > Anoop Ghanwani wrote:
> > >
> > > What I'm getting at is that all RBridges in the 
> > > network need to know about all VLANs so that they
> > > can prune their trees for each VLAN correctly.
> > 
> > Yes--all the intermediate RBridges need to know which edge 
> > RBridges (where
> > an "edge RBridge is one that is acting as a Designated 
> > RBridge on a link)
> > are attached to which VLANs.
> > 
> > But an RBridge that is not an edge RBridge does *not* need to 
> > know about
> > any endnodes. And an RBridge that is not the DR for a link in 
> > VLAN A does
> > *not* need to know about endnodes in VLAN A.
> 
> That is correct.  However, even in that scenario, I
> don't think it makes sense to have a per-VLAN 
> IS-IS instance - maintaining the adjacencies
> for a given instance won't scale to large
> numbers of VLANs.  I would probably be better
> to just use the single instance and encode
> the information in such a way that the receiver
> can quickly determine what it needs to care
> about.  
> 
> However, as you point out below, I think
> it makes more sense to solve this problem using
> learning at the edge RBridges.  But that doesn't
> solve the problem for multicasts so those will
> have to be advertised anyway, and they will
> have to be sent to all Rbridges in the
> network.
> 
> > So...mostly I'm confused (and I think others are) about what 
> > is meant by
> > "a per-VLAN instance of IS-IS". When I was using the phrase I meant
> > the piece of IS-IS that announced VLAN A endnodes, and that 
> > information
> > only would have to go to RBridges that are Designated RBridge 
> > for a link 
> > in VLAN A.
> > 
> > But, as Donald said, we are switching to having the default 
> > case being 
> > that the
> > mapping between (ingress RBridge, source endnode) is learned 
> > by the egress
> > RBridge that decapsulates a data packet onto its link. That 
> way only 
> > Designated
> > RBridges learn endnode locations, and only learn endnode 
> > locations that are
> > talking to endnodes on that RBridge's link.
> > 
> > We are also allowing optional advertisement of attached 
> > endnodes in VLAN A,
> > and optional learning from these, in a "per-VLAN IS-IS 
> > instance", which does
> > nothing but advertise the location of endnodes, and is 
> > broadcast only to
> > Designated RBridges attached to that VLAN. The intention is 
> > that endnodes
> > announced in this way would be endnodes that are 
> definitively learned 
> > through
> > some sort of layer 2 enrollment protocol.
> 
> If you absolutely had to have multiple IS-IS
> instances, it might make sense to have some
> number 'n' and then define a mapping of VLANs
> to each instance.  Having 4K instances of IS-IS
> running in an RBridge won't scale.
> 
> Anoop
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5FJfA08024076 for <[e-mail]>; Fri, 15 Jun 2007 12:41:10 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-119.messagelabs.com!1181936469!17966383!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 13722 invoked from network); 15 Jun 2007 19:41:09 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 15 Jun 2007 19:41:09 -0000
Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5FJf3D1016176 for <[e-mail]>; Fri, 15 Jun 2007 12:41:07 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5FJf2wh000715 for <[e-mail]>; Fri, 15 Jun 2007 14:41:02 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5FJf0Jn000703 for <[e-mail]>; Fri, 15 Jun 2007 14:41:01 -0500 (CDT)
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: Fri, 15 Jun 2007 15:40:36 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQAAMvlTA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5FJfA08024076
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 19:41:42 -0000
Status: RO
Content-Length: 750

You only have an instance of IS-IS for VLAN x in Rbridge y is Rbridge y
is advertising that it has directly connected end stations in VLAN x. Is
it plausible that an Rbridge would be reporting that it has directly
connected end stations in all of 4K VLANs?

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 15, 2007 2:15 PM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS

...

If you absolutely had to have multiple IS-IS
instances, it might make sense to have some
number 'n' and then define a mapping of VLANs
to each instance.  Having 4K instances of IS-IS
running in an RBridge won't scale.

Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5FIF2Fw001004 for <[e-mail]>; Fri, 15 Jun 2007 11:15:02 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 15 Jun 2007 11:15:02 -0700
X-IronPort-AV: i="4.16,425,1175497200";  d="scan'208"; a="11050581:sNHT21480970"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 067F2238381; Fri, 15 Jun 2007 11:12:46 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jun 2007 11:15:02 -0700
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: Fri, 15 Jun 2007 11:14:43 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: AcevCRapXqAp+8vRQlycJzDH2JH2mAAbr6qQ
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 15 Jun 2007 18:15:02.0285 (UTC) FILETIME=[1775D3D0:01C7AF79]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5FIF2Fw001004
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 18:15:23 -0000
Status: RO
Content-Length: 2961

 

> -----Original Message-----
> From: Radia Perlman [mailto:[e-mail]] 
> Sent: Thursday, June 14, 2007 9:54 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> I'm catching up after travelling, so if someone else answered this, 
> sorry about that.
> 
> Anoop Ghanwani wrote:
> >
> > What I'm getting at is that all RBridges in the 
> > network need to know about all VLANs so that they
> > can prune their trees for each VLAN correctly.
> 
> Yes--all the intermediate RBridges need to know which edge 
> RBridges (where
> an "edge RBridge is one that is acting as a Designated 
> RBridge on a link)
> are attached to which VLANs.
> 
> But an RBridge that is not an edge RBridge does *not* need to 
> know about
> any endnodes. And an RBridge that is not the DR for a link in 
> VLAN A does
> *not* need to know about endnodes in VLAN A.

That is correct.  However, even in that scenario, I
don't think it makes sense to have a per-VLAN 
IS-IS instance - maintaining the adjacencies
for a given instance won't scale to large
numbers of VLANs.  I would probably be better
to just use the single instance and encode
the information in such a way that the receiver
can quickly determine what it needs to care
about.  

However, as you point out below, I think
it makes more sense to solve this problem using
learning at the edge RBridges.  But that doesn't
solve the problem for multicasts so those will
have to be advertised anyway, and they will
have to be sent to all Rbridges in the
network.

> So...mostly I'm confused (and I think others are) about what 
> is meant by
> "a per-VLAN instance of IS-IS". When I was using the phrase I meant
> the piece of IS-IS that announced VLAN A endnodes, and that 
> information
> only would have to go to RBridges that are Designated RBridge 
> for a link 
> in VLAN A.
> 
> But, as Donald said, we are switching to having the default 
> case being 
> that the
> mapping between (ingress RBridge, source endnode) is learned 
> by the egress
> RBridge that decapsulates a data packet onto its link. That way only 
> Designated
> RBridges learn endnode locations, and only learn endnode 
> locations that are
> talking to endnodes on that RBridge's link.
> 
> We are also allowing optional advertisement of attached 
> endnodes in VLAN A,
> and optional learning from these, in a "per-VLAN IS-IS 
> instance", which does
> nothing but advertise the location of endnodes, and is 
> broadcast only to
> Designated RBridges attached to that VLAN. The intention is 
> that endnodes
> announced in this way would be endnodes that are definitively learned 
> through
> some sort of layer 2 enrollment protocol.

If you absolutely had to have multiple IS-IS
instances, it might make sense to have some
number 'n' and then define a mapping of VLANs
to each instance.  Having 4K instances of IS-IS
running in an RBridge won't scale.

Anoop



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5FBieLn014615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 15 Jun 2007 04:44:40 -0700 (PDT)
Received: from [70.194.55.114] (114.sub-70-194-55.myvzw.com [70.194.55.114]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5FBiNa6018058; Fri, 15 Jun 2007 04:44:24 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 15 Jun 2007 04:43:57 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig310861EA015486A0B1180507"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] TRILL header format, understanding the pros and cons (was "multicastpruning")
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 11:45:29 -0000
Status: RO
Content-Length: 4093

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig310861EA015486A0B1180507
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'll add some info in the spirit of summarizing the reasons for a
decision already made.

Radia Perlman wrote:
=2E..
> Moving the VLAN tag into the TRILL header (as a fixed field
> rather than an option) makes the packet 2 bytes longer when there is no=
=20
> inner VLAN,
> but makes the packet 2 bytes shorter when there was an inner VLAN=20
> (because the
> VLAN can be deleted from the inner frame).

I disagree that TRILL operations should ever modify their payload. Even
when done only at the ingress/egress, and only as an optimization, this
means that separate code is needed to parse headers inside vs. outside,
rather than just adding code to parse TRILL headers. Such code would be
used by trace debuggers, as well as by TRILL devices supporting other
fields that "should have been copied" into the TRILL header had we known
about them.

Any existing ethernet header that can be parsed now (or in the future)
in its original place can be parsed by TRILL using a fixed offset.
There's zero utility in copying or moving data - it presents
opportunities for more bugs and complexity.

> Signalling that the packet is an IGMP reply (so should be pruned to onl=
y=20
> send to
> links with IP multicast routers) can be done with a single bit in the=20
> TRILL header.

The same issue applies here.

=2E..
> So the cost of moving these into the TRILL header are 2 bytes +1 bit, a=
nd
> actually the 2 byte cost is only a cost when there was no VLAN tag in=20
> the inner header.
>=20
> I'd think the advantages of doing so would be

I disagree that the following are agreed...

> a) easier for transit RBridges to make a forwarding decision

It is irrelevant where a header value is so long as it is in a fixed
location. There could be minor efficiencies in grabbing data in large
chunks, but such chunks are just as likely to grab both TRILL and the
inner ethernet headers in their entirety.

> b) in a sense more "architecturally pure" since the transit RBridges=20
> would not
> need to look at anything more than the TRILL header

This is a fallacy. It is not architecturally "pure" to move a header;
it's still a field of the inner header, and moving it - if anything -
adds pollutes the architecture because it gives the misimpression that
TRILL is making decisions on only _its_ information.

> c) if 802 invented a new kind of tag, since tags are not TLV encoded,=20
> transit RBridges
> would not need to be upgraded to understand the new tag in order to fin=
d the
> fields in the inner packet.

If 802 invented a new kind of tag, it's possible it wouldn't fit in the
current TRILL header, which means everything in TRILL would need to be
updated anyway.

Also, I don't believe there will be devices that support only transit or
only ingress/egress; ethernet plug-and-play compatibility means that
every device ought to support both functions (albeit with different
efficiency or scale in different devices).

> I'm not saying we have to change the TRILL format...I just want to=20
> carefully understand
> the pros and cons. What arguments have I missed? (either more arguments=
=20
> for moving
> everything necessary for forwarding into the TRILL header, or against i=
t).

I think you missed the pros, and omitted the cons (most of which you
posed as pros anyway).

Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enig310861EA015486A0B1180507
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcnt+E5f5cImnZrsRAlUyAKCbluPJ5tO75xSbzhr84bUfPpPcrACgwoXh
/0lyieUmUMUZxblqTm5Wf8c=
=AElZ
-----END PGP SIGNATURE-----

--------------enig310861EA015486A0B1180507--


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 l5F5U3e1019139 for <[e-mail]>; Thu, 14 Jun 2007 22:30:03 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 14 Jun 2007 22:30:03 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.18.48]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 14 Jun 2007 22:30:01 -0700 (PDT)
Date: Thu, 14 Jun 2007 22:30:42 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Silvano Gai <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] TRILL header format, understanding the pros and cons (was "multicastpruning")
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 05:30:23 -0000
Status: RO
Content-Length: 6737

Sorry, Silvano,

I do believe it is worthwhile to calmly list all points for and against 
something even if the
issue has been decided. I understand the problem of a committee being 
like the
proverbial donkey starving because it is equidistant between two bales 
of hay and
can't decide which one to go to. And I understand also how at some 
point, unless
something is really broken, it's better to just go off in the original 
direction rather than
never converging.

However, I believe it is also always a useful exercise to summarize all 
the arguments
in one place. And sometimes when doing so, it might make sense to change 
the decision.

So...the way the TRILL header is now, intermediate RBridges have to find the
inner frame and look for:
a) VLAN tag (to do VLAN pruning)
b) the original destination address (in case it's an IP multicast, in 
order to do
IP multicast pruning)
c) the IP protocol type (for IGMP), and parsing enough of the IGMP 
message to
know that this is an IGMP reply (in order for it to get sent only to 
links with IP multicast
routers)

Moving the VLAN tag into the TRILL header (as a fixed field
rather than an option) makes the packet 2 bytes longer when there is no 
inner VLAN,
but makes the packet 2 bytes shorter when there was an inner VLAN 
(because the
VLAN can be deleted from the inner frame).

Signalling that the packet is an IGMP reply (so should be pruned to only 
send to
links with IP multicast routers) can be done with a single bit in the 
TRILL header.

Moving the original destination address into the TRILL header could 
theoretically
be done without adding to the length of the packet, by merely 
considering the
first 6 bytes of the packet to be the final 6 bytes of the TRILL header.

So the cost of moving these into the TRILL header are 2 bytes +1 bit, and
actually the 2 byte cost is only a cost when there was no VLAN tag in 
the inner header.

I'd think the advantages of doing so would be
a) easier for transit RBridges to make a forwarding decision
b) in a sense more "architecturally pure" since the transit RBridges 
would not
need to look at anything more than the TRILL header
c) if 802 invented a new kind of tag, since tags are not TLV encoded, 
transit RBridges
would not need to be upgraded to understand the new tag in order to find the
fields in the inner packet.

I'm not saying we have to change the TRILL format...I just want to 
carefully understand
the pros and cons. What arguments have I missed? (either more arguments 
for moving
everything necessary for forwarding into the TRILL header, or against it).

Thanks,

Radia



Silvano Gai wrote:
> Folks,
>
> We had a detailed discussion on the header format which included all the
> points that Radia list below. We had a strong consensus on one solution.
> The WG chairs confirmed this consensus on the mailing list.
>
> There is no new piece of information. We have not discovered anything
> that was not known at the time of the consensus. I propose we stick with
> the current header format.
>
> If we continue to change things we will never converge and the frame
> format needs to be stable ASAP.
>
> If we reopen the frame format discussion, then I want to reopen nickname
> vs address ;-) :-) :-) ;-)
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> Sent: Thursday, June 07, 2007 1:29 PM
>> To: Eastlake III Donald-LDE008
>> Cc: [e-mail]
>> Subject: Re: [rbridge] multicast pruning in TRILL
>>
>> (revisiting the issue of moving whatever is necessary for transit
>> bridges to look at
>> for pruning of multicasts (VLAN tag and destination multicast address)
>> to the portion of the frame outside the tunnel, i.e., either the TRILL
>> header or
>> the outer header)
>>
>> The mailing list archives are daunting, even though I've been trying
>>     
> to
>   
>> follow it all along.
>> I'd like to see the arguments both sides of this issue summarized
>>     
> rather
>   
>> than
>> pointing people at the mailing list -- just now I tried to review the
>> mailing list
>> on this issue and got discouraged. It never hurts to summarize the
>> issues again.
>>
>> I'll start by writing down concisely what I do remember, and perhaps
>> people can
>> concisely add other arguments:
>>
>> a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer
>> bits total (since you
>> don't need the Ethertype) to include it as a tag in the inner header),
>> it's easier to find since
>> transit RBridges don't need to find the inner header,
>> the TRILL header is still fixed length.  Minuses: It takes up room
>>     
> even
>   
>> when there is
>> no VLAN tag in the inner header
>>
>> b) moving VLAN tag to TRILL header as an option: Pluses: it only takes
>> up room
>> when there is a VLAN tag in the inner frame. Minus: it makes the TRILL
>> header
>> variable length
>>
>> c) moving the inner multicast address (for IP multicast pruning) into
>> the TRILL header: I don't think this was discussed. But it would
>>     
> clearly
>   
>> have to be done as an option in the TRILL
>> header since we wouldn't want to make space for it in the TRILL header
>> on unicast
>> packets, so it would make the TRILL header variable length
>>
>> d) copying the inner multicast address (for IP multicast pruning) into
>> the *outer* Ethernet
>> header. I don't think this was discussed at all on the mailing list. I
>> assume that it wouldn't
>> confuse non-RBridge devices listening to that multicast address that
>> might hear the
>> packet because the Ethertype would be TRILL, so they'd (hopefully)
>>     
> drop
>   
>> it without
>> getting confused.
>>
>> Whatever I've missed, can someone add to this?
>>
>> Thanks,
>>
>> Radia
>>
>>
>> Eastlake III Donald-LDE008 wrote:
>>     
>>> @@@ Indeed, for precisely the reason you give, it was and remains my
>>> strong personal opinion that the VLAN-tag information should be part
>>>       
> of
>   
>>> the TRILL Header where it would be at least 14 bytes earlier and you
>>> would also save the 2 bytes of tag Ethertype. It contains priority
>>>       
> as
>   
>>> well as the VLAN ID info.
>>>
>>> @@@ However, the working group appears to be of the opinion that the
>>> VLAN-tag should be inserted inside the inner frame with an
>>>       
> Ethertype.
>   
>>> See the May mail here which includes arguments on the other side of
>>>       
> the
>   
>>> issue:
>>> http://www.postel.org/pipermail/rbridge/2007-May/thread.html.
>>>
>>>
>>>       
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     



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 l5F4rR50010919 for <[e-mail]>; Thu, 14 Jun 2007 21:53:28 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 14 Jun 2007 21:53:14 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.18.48]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 14 Jun 2007 21:53:11 -0700 (PDT)
Date: Thu, 14 Jun 2007 21:53:53 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2007 04:53:49 -0000
Status: RO
Content-Length: 1721

I'm catching up after travelling, so if someone else answered this, 
sorry about that.

Anoop Ghanwani wrote:
>
> What I'm getting at is that all RBridges in the 
> network need to know about all VLANs so that they
> can prune their trees for each VLAN correctly.
Yes--all the intermediate RBridges need to know which edge RBridges (where
an "edge RBridge is one that is acting as a Designated RBridge on a link)
are attached to which VLANs.

But an RBridge that is not an edge RBridge does *not* need to know about
any endnodes. And an RBridge that is not the DR for a link in VLAN A does
*not* need to know about endnodes in VLAN A.

So...mostly I'm confused (and I think others are) about what is meant by
"a per-VLAN instance of IS-IS". When I was using the phrase I meant
the piece of IS-IS that announced VLAN A endnodes, and that information
only would have to go to RBridges that are Designated RBridge for a link 
in VLAN A.

But, as Donald said, we are switching to having the default case being 
that the
mapping between (ingress RBridge, source endnode) is learned by the egress
RBridge that decapsulates a data packet onto its link. That way only 
Designated
RBridges learn endnode locations, and only learn endnode locations that are
talking to endnodes on that RBridge's link.

We are also allowing optional advertisement of attached endnodes in VLAN A,
and optional learning from these, in a "per-VLAN IS-IS instance", which does
nothing but advertise the location of endnodes, and is broadcast only to
Designated RBridges attached to that VLAN. The intention is that endnodes
announced in this way would be endnodes that are definitively learned 
through
some sort of layer 2 enrollment protocol.

Radia


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5BHO9DO010289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 11 Jun 2007 10:24:10 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5BHQngk025312; Mon, 11 Jun 2007 12:26:49 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 11 Jun 2007 12:24:06 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 11 Jun 2007 12:24:04 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAhLOAAA+asGAAgp8JIAAEBYtgAACzY3A=
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 11 Jun 2007 17:24:06.0121 (UTC) FILETIME=[50313590:01C7AC4D]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5BHO9DO010289
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2007 17:24:23 -0000
Status: RO
Content-Length: 15062

Anoop,

	Two things:

1) From Radia's response, I think this is (again) a case of my
   getting confused by the strange use of "per-VLAN" in this 
   context.  On that score, I agree that there is little point
   in continuing that part of this discussion.  Part of the 
   reason for my confusion on this score is that I was under 
   the impression that the specific scalability concern you
   raised doesn't exist any more.

2) On the issue of scalability - in general - the responses I've
   seen are not sufficient to justify your observation for the
   general issue of scalability.  What I've seen is agreement on
   the specific issues associated with "per-VLAN" announcements
   - which, as Radia indicates, is going away.

	I believe we all need to get on that page (the one where
that particular misnomer doesn't exist).  Otherwise, we're going
to continue to create confusion over the use of IS-IS instances
(in general) and the impact that this has on scalability.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Monday, June 11, 2007 12:58 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> Eric,
> 
> I don't think it's worth continuing this discussion
> since it looks like there is agreement from several
> others that understand the scaling issues and it
> looks like there is consensus that it needs to be
> addressed.  That's all that I was hoping to achieve.
> 
> Thanks,
> Anoop 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> > Sent: Monday, June 11, 2007 8:55 AM
> > To: Anoop Ghanwani
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	Thanks for the well thought out reply.  Please see 
> > continuing discussion below...
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:[e-mail]]
> > > Sent: Friday, June 08, 2007 9:15 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > > >
> > > > 	Having per-VLAN instances of IS-IS helps to simplify 
> > interactions - 
> > > > thus increasing the likelihood of correct specification 
> > leading to 
> > > > interoperable implementations.
> > > > 
> > > > 	This is accomplished at some cost in extremely complex 
> > deployment 
> > > > scenarios - such as the one you cite as an example
> > > > - but the cost is not nearly as high as you make it sound.
> > > > 
> > > > 	Please see in-line comments below for further details.
> > > ...
> > > > 
> > > > I am not convinced that you do.  Having a per-VLAN 
> IS-IS instance 
> > > > greatly simplifies interactions, and allows us to 
> > effectively define 
> > > > RBridges in a single VLAN context
> > > > - leaving implementers free to implement inter-VLAN as already 
> > > > implemented in 802.1Q (and related) implementation.
> > > > 
> > > > This is more than just "useful."  See below for further 
> > > > clarification.
> > > 
> > > I'm not quite sure I get it, but I'll look below.
> > > 
> > > > > If an end rBridge
> > > > > participates in 1000 VLANs, it will have to maintain 1000 
> > > > > adjacencies.
> > > > 
> > > > This is effectively true if we postulate only a single IS-IS 
> > > > instance for all VLANs, because you have to scope routing 
> > > > activities, link-state, etc. - on a per-VLAN basis even 
> > if that is 
> > > > the case.
> > > > 
> > > > What you accomplish by using a single instance is to 
> make it far 
> > > > more difficult to describe, understand and correctly implement 
> > > > RBridge routing protocol behaviors.
> > > 
> > > I understand there will be some complexity in describing 
> > all the VLANs 
> > > and multicast addresses in a single instance, but I think 
> it scales 
> > > better than multiple instances.  Why?  Consider the 
> > following picture:
> > > 
> > >            D
> > >            |
> > > v1 -- A -- B -- C -- v1
> > >            | 
> > >            E
> > > 
> > > A-E are RBridges.
> > > 
> > > In this picture VLAN v1 is configured only on A and C.  B 
> > doesn't have 
> > > v1 configured on it.  Yet B needs to know about VLAN v1's 
> > location in 
> > > order to correctly prune its trees.
> > 
> > Note that this configuration - if A-E were Q-bridges - would 
> > be pathological, resulting in segmenting v1.
> > 
> > I believe you've over-simplified interactions to make a 
> > point, and the result is an example that does not make that point.
> > 
> > In the above scenario, two simple approaches might have been 
> > used that would not share the pathology of the given
> > example:
> > 
> > 1) B might be configured to support v1 (flat model).
> > 2) A and C might be configured to tunnel (e.g. - Q-in-Q)
> >    v1 via B, using a VID for which B is configured
> >    (hierarchical model).
> > 
> > It may be difficult to imagine why the second choice may be 
> > useful, given the over-simplified example, but it is actually 
> > quite likely to be useful in complex secnarios
> > - particularly involving edge bridges with very large numbers 
> > of subscriber-facing ports with large overlap in VLAN 
> > membership among edge bridges.
> > 
> > These same approaches are also useful with RBridges.
> > 
> > > 
> > > What I'm getting at is that all RBridges in the network 
> > need to know 
> > > about all VLANs so that they can prune their trees for each VLAN 
> > > correctly.
> > 
> > Yes, in a flat model, this would be true.  With the 
> > alternative approach, only edge RBridges really have to know 
> > about VLANs at the edge.  Pruding in core RBridges occurs as 
> > a consequence of Q-in-Q (or like
> > approach) configuration.
> > 
> > > 
> > > If you have an instance per VLAN we are talking about 
> > maintain up to 
> > > 4K instances in each Rbridge.
> > > And it's not unheard of to configure a 1000 VLANs in 
> regular 802.1Q 
> > > device.
> > > 
> > 
> > Yes.  I believe this essentially makes my point.  It is done 
> > today, with today's bridges, hence scalability is apparently 
> > not a real concern (yet).
> > 
> > > 
> > > > > Plus, it looks like for the per-VLAN IS-IS instance, 
> > the RBridge 
> > > > > network operates as single LAN segment.  That would 
> > mean having to 
> > > > > go through DR/BDR election for each instance.
> > > > 
> > > > And this would be correct behavior.  An RBridge should only be 
> > > > eligible for ingress and egress to a local VLAN is it is 
> > configured 
> > > > to participate in that local VLAN.  Hence, it may only 
> > participate 
> > > > in DR election for VLANs on a local bridged LAN if it 
> > participates 
> > > > in those VLANs.
> > > 
> > > See above for why this is not true.  Or tell me how I can 
> > do pruning 
> > > without interior RBridges knowing about all VLANs.
> > 
> > Use a hierarchical model model with VID-based tunneling.
> > 
> > This is not a trivially easy configuration for some 
> > real-world deployment scenarios we can all probably imagine.  
> > But it is also not as trivially easy to break, once correctly 
> > configured.
> > 
> > > 
> > > > This is central to one of the issues with specifying - 
> > and correctly 
> > > > implementing - RBridge functionality.
> > > > 
> > > > There are optimizations we may consider at a later date 
> that will 
> > > > reduce - for example - messaging overhead, and there 
> are already 
> > > > existing optimizations to reduce the actual state maintenance 
> > > > overhead to roughly the same as would be the case with a single 
> > > > IS-IS instance.
> > > >  
> > > > > 
> > > > > Operating 100's of routers on a single LAN segment 
> > would poses its 
> > > > > own set of scaling issues.  Having per VLAN instances 
> > exacerbates 
> > > > > the problem.
> > > > 
> > > > Are there deployment scenarios in today's bridging 
> > community where 
> > > > we support this kind of network as a bidged network?
> > > 
> > > Not in a bridged network.  But if I recall correctly, and I 
> > may be off 
> > > since the charter may have changed since the beginning, 
> one of the 
> > > goals of rBridges was to be able to build large campuses without 
> > > routers and routing-related configuration.  Has that gone away?
> > > It is not atypical to find a campus with 20K users on 100's 
> > of VLANs 
> > > with ~100 nodes.
> > 
> > That never was a goal.  There are people who might like to 
> > make it one, but that's (IMO) a malignant nightmare.
> > 
> > There is no conceivable way to build devices that do 
> > everything a router does without incorporating all of the 
> > complexity (read
> > "cost") of a router into that device.  If that's what 
> > somebody really wants to do, then I'd like to hear how they 
> > propose to design routing complexity - using a routing 
> > protocol, and putting everything else a router does into it - 
> > without the end product actually being MORE complex (read 
> > "expensive") than anybody's current routing implementation.
> > 
> > > 
> > > > If there are not, then please recall that sclability of 
> > the current 
> > > > solution is targetted only for routghly the same size 
> networks as 
> > > > can be established with bridging today.
> > > 
> > > Even with a network of today's bridges there would be 
> > scaling issues 
> > > if you had say 20-30 rBridges all trying to establish adjacencies 
> > > between groups of themselves for a few 100 VLANs.  It is 
> > not atypical 
> > > to have ~1000 VLANs configured in core switches.
> > 
> > So, for IS-IS (or OSPF), issues with "adjacencies" are not 
> > subject to the same sorts of concerns as (for example) BGP.
> > 
> > What maintaining adjacencies really means is keeping up to 
> > date on link state for a peer-set.  What you're pointing out 
> > is that - for many VLANs - the numer of peer-sets for which 
> > link state has to be maintained may be large.
> > 
> > Short of using hierarchical VLANs, this is competely and 
> > absolutely unavoidable - unless we're going to accept the 
> > consequences of specifying incorrect VLAN interactions as a 
> > mechanism for effectively doing the same thing (i.e. - 
> > effectively specifying hierarchy using some other means, or 
> > simply hoping that people can somehow get it right).
> > 
> > If you assume - as I do - that VLAN traffic is only supposed 
> > to traverse links for which that VLAN is configured (either 
> > explicitly or implicity), than not including a VLAN (again, 
> > either explicitly or implicitly) in the configuration for a 
> > specific link means that that VLAN's traffic is not supposed 
> > to traverse that link.  Period.
> > 
> > > 
> > > > You make it sound as if we're expected to solve problems with 
> > > > RBridges for which solutions have never been specified 
> > for routing.
> > > >
> > > > As for complicating the problem with VLAN instances, 
> > think about how 
> > > > complicated this scenario would be already with 802.1Q 
> > VLANs running 
> > > > any of today's spanning tree protocols.
> > > 
> > > They scale just fine because they limit the maximum 
> number of trees 
> > > and have some VLANs share a tree.  They don't try to run one STP 
> > > instance per VLAN.
> > 
> > Right.  Assuming you've gotten your head around the notion of 
> > hierarchical VLANs, how is this different?
> > 
> > >  
> > > > Also, note that in this same situation with routers in place of 
> > > > RBridges, each router would most likely be required to have a 
> > > > logical interface in each VLAN on every link to which it is 
> > > > connected.
> > > 
> > > This cannot be compared with routers.  We're talking 
> about bridging 
> > > here.  If we routed, we'd just terminate the MAC domain 
> at the edge 
> > > router and we wouldn't run into any of these issues.  No sense in 
> > > having a VLAN interface on every router in the campus.
> > > (One could design the network that way, but it would be a 
> > really bad 
> > > way to do it.)
> > 
> > The point is that - if you had 1000 (or 4000) VLANs, in a 
> > subnet, you would terminate a large percentage of those on 
> > connected routers.
> > 
> > If you imagine that there are many sch subnets (as seems to 
> > be implied in your earlier comments), then this would also be 
> > true for other physical interfaces on each router.
> > 
> > Also, if you believe that RBridges may be used to replace 
> > routers, then you compound this issue.
> > 
> > >  
> > > > In other words, this situation is just plain complicated - 
> > > > irrespective of what you're trying to do to deal with it.
> > > > 
> > > > > 
> > > > > Have the scaling issues been considered at all?  It 
> > might actually 
> > > > > be better to just use the core IS-IS instance.
> > > > 
> > > > Scaling has been considered.  Large increases in 
> > scalability are not 
> > > > a primary goal - relative to existing bridging, for example.
> > > > 
> > > > RTFC!  Increased scalability over existing bridging was 
> > explicitly 
> > > > NOT included in the charter as a goal.
> > > 
> > > I thought I knew what the charter was but I went back and read it 
> > > again anyway.  I didn't find much there to work with with 
> > respect to 
> > > scalability requirements.
> > > It talks about a "problem statement and applicability"
> > > document.  I'm not sure which of the published documents that is.
> > 
> > It is the one that has that name.  Joe Touch is the main 
> > author/editor (with Radia Perlman).  It apparently has been 
> > allowed to expire.
> > 
> > See: 
> > 
> > https://datatracker.ietf.org/public/idindex.cgi?command=id_det
> ail&id=147
> > 71
> > 
> > for more information.
> > 
> > By the way, it actually did not expire very long ago, so it 
> > is likely that there is a new version in the works.
> > 
> > However, the way that IETF charters typically work is that 
> > they are exclusive, rather than inclusive, by default.  In 
> > other words, the fact that the charter does not explicitly 
> > include increased scalability as a goal CANNOT be read to 
> > mean that it may be a goal because it is not explicitly excluded.
> > 
> > Per the charter, the design goals for the TRILL solution are:
> > 
> > - Minimal or no configuration required
> > - Load-splitting among multiple paths
> > - Routing loop mitigation (possibly through a TTL field)
> > - Support of multiple points of attachment
> > - Support for broadcast and multicast
> > - No significant service delay after attachment
> > - No less secure than existing bridged solutions
> > 
> > There is nothing in these explicitly listed goals that can be 
> > stretched to include the notion of hugely increased scale, or 
> > replacement of routers.
> > 
> > > 
> > > Anoop
> > > 
> > 
> 



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5BGwKW9002890 for <[e-mail]>; Mon, 11 Jun 2007 09:58:20 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 11 Jun 2007 09:58:20 -0700
X-IronPort-AV: i="4.16,408,1175497200";  d="scan'208"; a="13414346:sNHT25927496"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 1BFEE23836C; Mon, 11 Jun 2007 09:56:09 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 11 Jun 2007 09:58:19 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 11 Jun 2007 09:58:12 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAhLOAAA+asGAAgp8JIAAEBYtg
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-OriginalArrivalTime: 11 Jun 2007 16:58:19.0806 (UTC) FILETIME=[B68443E0:01C7AC49]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5BGwKW9002890
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2007 16:58:49 -0000
Status: RO
Content-Length: 13037

Eric,

I don't think it's worth continuing this discussion
since it looks like there is agreement from several
others that understand the scaling issues and it
looks like there is consensus that it needs to be
addressed.  That's all that I was hoping to achieve.

Thanks,
Anoop 

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Monday, June 11, 2007 8:55 AM
> To: Anoop Ghanwani
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Anoop,
> 
> 	Thanks for the well thought out reply.  Please see 
> continuing discussion below...
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:[e-mail]]
> > Sent: Friday, June 08, 2007 9:15 PM
> > To: Eric Gray (LO/EUS)
> > Cc: [e-mail]
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Importance: High
> > 
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> > >
> > > 	Having per-VLAN instances of IS-IS helps to simplify 
> interactions - 
> > > thus increasing the likelihood of correct specification 
> leading to 
> > > interoperable implementations.
> > > 
> > > 	This is accomplished at some cost in extremely complex 
> deployment 
> > > scenarios - such as the one you cite as an example
> > > - but the cost is not nearly as high as you make it sound.
> > > 
> > > 	Please see in-line comments below for further details.
> > ...
> > > 
> > > I am not convinced that you do.  Having a per-VLAN IS-IS instance 
> > > greatly simplifies interactions, and allows us to 
> effectively define 
> > > RBridges in a single VLAN context
> > > - leaving implementers free to implement inter-VLAN as already 
> > > implemented in 802.1Q (and related) implementation.
> > > 
> > > This is more than just "useful."  See below for further 
> > > clarification.
> > 
> > I'm not quite sure I get it, but I'll look below.
> > 
> > > > If an end rBridge
> > > > participates in 1000 VLANs, it will have to maintain 1000 
> > > > adjacencies.
> > > 
> > > This is effectively true if we postulate only a single IS-IS 
> > > instance for all VLANs, because you have to scope routing 
> > > activities, link-state, etc. - on a per-VLAN basis even 
> if that is 
> > > the case.
> > > 
> > > What you accomplish by using a single instance is to make it far 
> > > more difficult to describe, understand and correctly implement 
> > > RBridge routing protocol behaviors.
> > 
> > I understand there will be some complexity in describing 
> all the VLANs 
> > and multicast addresses in a single instance, but I think it scales 
> > better than multiple instances.  Why?  Consider the 
> following picture:
> > 
> >            D
> >            |
> > v1 -- A -- B -- C -- v1
> >            | 
> >            E
> > 
> > A-E are RBridges.
> > 
> > In this picture VLAN v1 is configured only on A and C.  B 
> doesn't have 
> > v1 configured on it.  Yet B needs to know about VLAN v1's 
> location in 
> > order to correctly prune its trees.
> 
> Note that this configuration - if A-E were Q-bridges - would 
> be pathological, resulting in segmenting v1.
> 
> I believe you've over-simplified interactions to make a 
> point, and the result is an example that does not make that point.
> 
> In the above scenario, two simple approaches might have been 
> used that would not share the pathology of the given
> example:
> 
> 1) B might be configured to support v1 (flat model).
> 2) A and C might be configured to tunnel (e.g. - Q-in-Q)
>    v1 via B, using a VID for which B is configured
>    (hierarchical model).
> 
> It may be difficult to imagine why the second choice may be 
> useful, given the over-simplified example, but it is actually 
> quite likely to be useful in complex secnarios
> - particularly involving edge bridges with very large numbers 
> of subscriber-facing ports with large overlap in VLAN 
> membership among edge bridges.
> 
> These same approaches are also useful with RBridges.
> 
> > 
> > What I'm getting at is that all RBridges in the network 
> need to know 
> > about all VLANs so that they can prune their trees for each VLAN 
> > correctly.
> 
> Yes, in a flat model, this would be true.  With the 
> alternative approach, only edge RBridges really have to know 
> about VLANs at the edge.  Pruding in core RBridges occurs as 
> a consequence of Q-in-Q (or like
> approach) configuration.
> 
> > 
> > If you have an instance per VLAN we are talking about 
> maintain up to 
> > 4K instances in each Rbridge.
> > And it's not unheard of to configure a 1000 VLANs in regular 802.1Q 
> > device.
> > 
> 
> Yes.  I believe this essentially makes my point.  It is done 
> today, with today's bridges, hence scalability is apparently 
> not a real concern (yet).
> 
> > 
> > > > Plus, it looks like for the per-VLAN IS-IS instance, 
> the RBridge 
> > > > network operates as single LAN segment.  That would 
> mean having to 
> > > > go through DR/BDR election for each instance.
> > > 
> > > And this would be correct behavior.  An RBridge should only be 
> > > eligible for ingress and egress to a local VLAN is it is 
> configured 
> > > to participate in that local VLAN.  Hence, it may only 
> participate 
> > > in DR election for VLANs on a local bridged LAN if it 
> participates 
> > > in those VLANs.
> > 
> > See above for why this is not true.  Or tell me how I can 
> do pruning 
> > without interior RBridges knowing about all VLANs.
> 
> Use a hierarchical model model with VID-based tunneling.
> 
> This is not a trivially easy configuration for some 
> real-world deployment scenarios we can all probably imagine.  
> But it is also not as trivially easy to break, once correctly 
> configured.
> 
> > 
> > > This is central to one of the issues with specifying - 
> and correctly 
> > > implementing - RBridge functionality.
> > > 
> > > There are optimizations we may consider at a later date that will 
> > > reduce - for example - messaging overhead, and there are already 
> > > existing optimizations to reduce the actual state maintenance 
> > > overhead to roughly the same as would be the case with a single 
> > > IS-IS instance.
> > >  
> > > > 
> > > > Operating 100's of routers on a single LAN segment 
> would poses its 
> > > > own set of scaling issues.  Having per VLAN instances 
> exacerbates 
> > > > the problem.
> > > 
> > > Are there deployment scenarios in today's bridging 
> community where 
> > > we support this kind of network as a bidged network?
> > 
> > Not in a bridged network.  But if I recall correctly, and I 
> may be off 
> > since the charter may have changed since the beginning, one of the 
> > goals of rBridges was to be able to build large campuses without 
> > routers and routing-related configuration.  Has that gone away?
> > It is not atypical to find a campus with 20K users on 100's 
> of VLANs 
> > with ~100 nodes.
> 
> That never was a goal.  There are people who might like to 
> make it one, but that's (IMO) a malignant nightmare.
> 
> There is no conceivable way to build devices that do 
> everything a router does without incorporating all of the 
> complexity (read
> "cost") of a router into that device.  If that's what 
> somebody really wants to do, then I'd like to hear how they 
> propose to design routing complexity - using a routing 
> protocol, and putting everything else a router does into it - 
> without the end product actually being MORE complex (read 
> "expensive") than anybody's current routing implementation.
> 
> > 
> > > If there are not, then please recall that sclability of 
> the current 
> > > solution is targetted only for routghly the same size networks as 
> > > can be established with bridging today.
> > 
> > Even with a network of today's bridges there would be 
> scaling issues 
> > if you had say 20-30 rBridges all trying to establish adjacencies 
> > between groups of themselves for a few 100 VLANs.  It is 
> not atypical 
> > to have ~1000 VLANs configured in core switches.
> 
> So, for IS-IS (or OSPF), issues with "adjacencies" are not 
> subject to the same sorts of concerns as (for example) BGP.
> 
> What maintaining adjacencies really means is keeping up to 
> date on link state for a peer-set.  What you're pointing out 
> is that - for many VLANs - the numer of peer-sets for which 
> link state has to be maintained may be large.
> 
> Short of using hierarchical VLANs, this is competely and 
> absolutely unavoidable - unless we're going to accept the 
> consequences of specifying incorrect VLAN interactions as a 
> mechanism for effectively doing the same thing (i.e. - 
> effectively specifying hierarchy using some other means, or 
> simply hoping that people can somehow get it right).
> 
> If you assume - as I do - that VLAN traffic is only supposed 
> to traverse links for which that VLAN is configured (either 
> explicitly or implicity), than not including a VLAN (again, 
> either explicitly or implicitly) in the configuration for a 
> specific link means that that VLAN's traffic is not supposed 
> to traverse that link.  Period.
> 
> > 
> > > You make it sound as if we're expected to solve problems with 
> > > RBridges for which solutions have never been specified 
> for routing.
> > >
> > > As for complicating the problem with VLAN instances, 
> think about how 
> > > complicated this scenario would be already with 802.1Q 
> VLANs running 
> > > any of today's spanning tree protocols.
> > 
> > They scale just fine because they limit the maximum number of trees 
> > and have some VLANs share a tree.  They don't try to run one STP 
> > instance per VLAN.
> 
> Right.  Assuming you've gotten your head around the notion of 
> hierarchical VLANs, how is this different?
> 
> >  
> > > Also, note that in this same situation with routers in place of 
> > > RBridges, each router would most likely be required to have a 
> > > logical interface in each VLAN on every link to which it is 
> > > connected.
> > 
> > This cannot be compared with routers.  We're talking about bridging 
> > here.  If we routed, we'd just terminate the MAC domain at the edge 
> > router and we wouldn't run into any of these issues.  No sense in 
> > having a VLAN interface on every router in the campus.
> > (One could design the network that way, but it would be a 
> really bad 
> > way to do it.)
> 
> The point is that - if you had 1000 (or 4000) VLANs, in a 
> subnet, you would terminate a large percentage of those on 
> connected routers.
> 
> If you imagine that there are many sch subnets (as seems to 
> be implied in your earlier comments), then this would also be 
> true for other physical interfaces on each router.
> 
> Also, if you believe that RBridges may be used to replace 
> routers, then you compound this issue.
> 
> >  
> > > In other words, this situation is just plain complicated - 
> > > irrespective of what you're trying to do to deal with it.
> > > 
> > > > 
> > > > Have the scaling issues been considered at all?  It 
> might actually 
> > > > be better to just use the core IS-IS instance.
> > > 
> > > Scaling has been considered.  Large increases in 
> scalability are not 
> > > a primary goal - relative to existing bridging, for example.
> > > 
> > > RTFC!  Increased scalability over existing bridging was 
> explicitly 
> > > NOT included in the charter as a goal.
> > 
> > I thought I knew what the charter was but I went back and read it 
> > again anyway.  I didn't find much there to work with with 
> respect to 
> > scalability requirements.
> > It talks about a "problem statement and applicability"
> > document.  I'm not sure which of the published documents that is.
> 
> It is the one that has that name.  Joe Touch is the main 
> author/editor (with Radia Perlman).  It apparently has been 
> allowed to expire.
> 
> See: 
> 
> https://datatracker.ietf.org/public/idindex.cgi?command=id_det
ail&id=147
> 71
> 
> for more information.
> 
> By the way, it actually did not expire very long ago, so it 
> is likely that there is a new version in the works.
> 
> However, the way that IETF charters typically work is that 
> they are exclusive, rather than inclusive, by default.  In 
> other words, the fact that the charter does not explicitly 
> include increased scalability as a goal CANNOT be read to 
> mean that it may be a goal because it is not explicitly excluded.
> 
> Per the charter, the design goals for the TRILL solution are:
> 
> - Minimal or no configuration required
> - Load-splitting among multiple paths
> - Routing loop mitigation (possibly through a TTL field)
> - Support of multiple points of attachment
> - Support for broadcast and multicast
> - No significant service delay after attachment
> - No less secure than existing bridged solutions
> 
> There is nothing in these explicitly listed goals that can be 
> stretched to include the notion of hugely increased scale, or 
> replacement of routers.
> 
> > 
> > Anoop
> > 
> 



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5BGp2RD001330 for <[e-mail]>; Mon, 11 Jun 2007 09:51:03 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 11 Jun 2007 09:50:56 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2406D2B0; Mon, 11 Jun 2007 09:50:56 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0D92D2AE; Mon, 11 Jun 2007 09:50:56 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FJH27600; Mon, 11 Jun 2007 09:50:50 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id B742769CA3; Mon, 11 Jun 2007 09:50:50 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 11 Jun 2007 09:50:49 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAuSRGgAGf5ZCA=
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>, [e-mail]
X-WSS-ID: 6A73A2FA37042451684-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5BGp2RD001330
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2007 16:51:50 -0000
Status: RO
Content-Length: 1494

Silvano Gai wrote:
> Anoop,
> 
> You are right; there is a tremendous scalability issue.
> 
> My proposal is to completely drop the per-VLAN ISIS instance
> and learn from data frames. Proven, scalable, it works.
> 

An RFC does not tell any implementation how to store the
bits and bytes used to retain configuration data. It merely
specifies what information is retained, not how.

I do not see how the method of learning the information is
relevant to efficiently encoding it.

If your presumption is that information learned form data
frames is droppable then the efficiency in storage comes
from giving an implementation the option to forget information
that it does not find useful. But given that all implementations
have finite limits on their storage it would seem to be an 
implicit part of any protocol that did not demand that the
a node drop out of the network when it hit is memory limit.

The only other possible optimization on information retention
is if you allow assumptions about the data. Examples that come
to mind, but which are probably not acceptable, include:

a) assuming that a MAC address is unique.
b) assuming that the topology is the same for all VLANs.
   That is the topology for any VLAN is a subset of "the" topology.

Were you thinking of these or other encoding optimizations? Or is
the scalability strictly a matter of gaining the option to forget?
If so, why wouldn't the option to forget be valuable/necessary no
matter what other decisions are made?




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5BGWPco025697 for <[e-mail]>; Mon, 11 Jun 2007 09:32:25 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 11 Jun 2007 09:32:10 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] multicast pruning in TRILL
Thread-Index: AcesQXyLU9yLZMnnTiWz+rVN8mCBhAABHPWA
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Joe Touch" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5BGWPco025697
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2007 16:32:48 -0000
Status: RO
Content-Length: 958

I agree with Joe.
In general we should use only MAY or MUST, not SHOULD

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Joe Touch
> Sent: Monday, June 11, 2007 8:48 AM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] multicast pruning in TRILL
> 
> 
> 
> Radia Perlman wrote:
> > Re: Is multicast pruning a MAY or MUST:
> >
> > I'm not sure there's been enough opinion voiced to have a consensus
on
> this.
> > I'd be happy with MAY or SHOULD, since it really it just an
> optimization.
> 
> IMO, optimizations should be expressed as MAY.
> 
> To say "SHOULD" is to say that implementations that do not implement
the
> optimization should have a good reason for not doing so. I don't think
> the presumption should be tilted that way.
> 
> Joe
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment




Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5BFtdoB016554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 11 Jun 2007 08:55:39 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5BFuh6d018015; Mon, 11 Jun 2007 10:56:43 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 11 Jun 2007 10:55:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 11 Jun 2007 10:55:29 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAhLOAAA+asGAAgp8JIA==
References: <[e-mail]> <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 11 Jun 2007 15:55:33.0327 (UTC) FILETIME=[F1852DF0:01C7AC40]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5BFtdoB016554
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2007 15:55:49 -0000
Status: RO
Content-Length: 11775

Anoop,

	Thanks for the well thought out reply.  Please see continuing 
discussion below...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[e-mail]] 
> Sent: Friday, June 08, 2007 9:15 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> >
> > 	Having per-VLAN instances of IS-IS helps to simplify 
> > interactions - thus increasing the likelihood of correct 
> > specification leading to interoperable implementations.
> > 
> > 	This is accomplished at some cost in extremely complex
> > deployment scenarios - such as the one you cite as an example
> > - but the cost is not nearly as high as you make it sound.
> > 
> > 	Please see in-line comments below for further details.
> ...
> > 
> > I am not convinced that you do.  Having a per-VLAN IS-IS
> > instance greatly simplifies interactions, and allows us 
> > to effectively define RBridges in a single VLAN context
> > - leaving implementers free to implement inter-VLAN as 
> > already implemented in 802.1Q (and related) implementation.
> > 
> > This is more than just "useful."  See below for further
> > clarification.
> 
> I'm not quite sure I get it, but I'll look below.
> 
> > > If an end rBridge 
> > > participates in 1000 VLANs, it will have
> > > to maintain 1000 adjacencies. 
> > 
> > This is effectively true if we postulate only a single IS-IS
> > instance for all VLANs, because you have to scope routing
> > activities, link-state, etc. - on a per-VLAN basis even if
> > that is the case.
> > 
> > What you accomplish by using a single instance is to make it
> > far more difficult to describe, understand and correctly
> > implement RBridge routing protocol behaviors.
> 
> I understand there will be some complexity in
> describing all the VLANs and multicast addresses
> in a single instance, but I think it scales better
> than multiple instances.  Why?  Consider the
> following picture:
> 
>            D
>            |
> v1 -- A -- B -- C -- v1
>            | 
>            E
> 
> A-E are RBridges.
> 
> In this picture VLAN v1 is configured only on A
> and C.  B doesn't have v1 configured on it.  Yet
> B needs to know about VLAN v1's location in order
> to correctly prune its trees.

Note that this configuration - if A-E were Q-bridges - 
would be pathological, resulting in segmenting v1.

I believe you've over-simplified interactions to make
a point, and the result is an example that does not 
make that point.

In the above scenario, two simple approaches might have
been used that would not share the pathology of the given
example:

1) B might be configured to support v1 (flat model).
2) A and C might be configured to tunnel (e.g. - Q-in-Q)
   v1 via B, using a VID for which B is configured
   (hierarchical model).

It may be difficult to imagine why the second choice may
be useful, given the over-simplified example, but it is
actually quite likely to be useful in complex secnarios
- particularly involving edge bridges with very large 
numbers of subscriber-facing ports with large overlap
in VLAN membership among edge bridges.

These same approaches are also useful with RBridges.

> 
> What I'm getting at is that all RBridges in the 
> network need to know about all VLANs so that they
> can prune their trees for each VLAN correctly.

Yes, in a flat model, this would be true.  With the
alternative approach, only edge RBridges really have
to know about VLANs at the edge.  Pruding in core 
RBridges occurs as a consequence of Q-in-Q (or like
approach) configuration.

> 
> If you have an instance per VLAN we are talking
> about maintain up to 4K instances in each Rbridge.
> And it's not unheard of to configure a 1000
> VLANs in regular 802.1Q device.
> 

Yes.  I believe this essentially makes my point.  It
is done today, with today's bridges, hence scalability
is apparently not a real concern (yet).

> 
> > > Plus, it looks like for the per-VLAN IS-IS
> > > instance, the RBridge network operates
> > > as single LAN segment.  That would mean
> > > having to go through DR/BDR election for
> > > each instance. 
> > 
> > And this would be correct behavior.  An RBridge should only
> > be eligible for ingress and egress to a local VLAN is it is
> > configured to participate in that local VLAN.  Hence, it may
> > only participate in DR election for VLANs on a local bridged
> > LAN if it participates in those VLANs.
> 
> See above for why this is not true.  Or
> tell me how I can do pruning without interior
> RBridges knowing about all VLANs.

Use a hierarchical model model with VID-based tunneling.

This is not a trivially easy configuration for some real-world
deployment scenarios we can all probably imagine.  But it is
also not as trivially easy to break, once correctly configured.

> 
> > This is central to one of the issues with specifying - and
> > correctly implementing - RBridge functionality.
> > 
> > There are optimizations we may consider at a later date that
> > will reduce - for example - messaging overhead, and there are
> > already existing optimizations to reduce the actual state
> > maintenance overhead to roughly the same as would be the case
> > with a single IS-IS instance.
> >  
> > > 
> > > Operating 100's of routers on a single 
> > > LAN segment would poses its own set of 
> > > scaling issues.  Having per VLAN instances
> > > exacerbates the problem.
> > 
> > Are there deployment scenarios in today's bridging community
> > where we support this kind of network as a bidged network?
> 
> Not in a bridged network.  But if I recall correctly,
> and I may be off since the charter may have changed
> since the beginning, one of the goals of rBridges was
> to be able to build large campuses without routers
> and routing-related configuration.  Has that gone away?
> It is not atypical to find a campus with 20K users
> on 100's of VLANs with ~100 nodes.

That never was a goal.  There are people who might like to make
it one, but that's (IMO) a malignant nightmare.

There is no conceivable way to build devices that do everything
a router does without incorporating all of the complexity (read
"cost") of a router into that device.  If that's what somebody
really wants to do, then I'd like to hear how they propose to
design routing complexity - using a routing protocol, and putting
everything else a router does into it - without the end product 
actually being MORE complex (read "expensive") than anybody's 
current routing implementation.

> 
> > If there are not, then please recall that sclability of the
> > current solution is targetted only for routghly the same
> > size networks as can be established with bridging today.
> 
> Even with a network of today's bridges there would
> be scaling issues if you had say 20-30 rBridges
> all trying to establish adjacencies between groups
> of themselves for a few 100 VLANs.  It is not 
> atypical to have ~1000 VLANs configured in core
> switches.

So, for IS-IS (or OSPF), issues with "adjacencies" are not
subject to the same sorts of concerns as (for example) BGP.

What maintaining adjacencies really means is keeping up to
date on link state for a peer-set.  What you're pointing 
out is that - for many VLANs - the numer of peer-sets for
which link state has to be maintained may be large.

Short of using hierarchical VLANs, this is competely and
absolutely unavoidable - unless we're going to accept the
consequences of specifying incorrect VLAN interactions as
a mechanism for effectively doing the same thing (i.e. -
effectively specifying hierarchy using some other means,
or simply hoping that people can somehow get it right).

If you assume - as I do - that VLAN traffic is only supposed
to traverse links for which that VLAN is configured (either
explicitly or implicity), than not including a VLAN (again,
either explicitly or implicitly) in the configuration for a
specific link means that that VLAN's traffic is not supposed
to traverse that link.  Period.

> 
> > You make it sound as if we're expected to solve problems 
> > with RBridges for which solutions have never been specified
> > for routing.
> >
> > As for complicating the problem with VLAN instances, think
> > about how complicated this scenario would be already with 
> > 802.1Q VLANs running any of today's spanning tree protocols.
> 
> They scale just fine because they limit the 
> maximum number of trees and have some VLANs share
> a tree.  They don't try to run one STP instance
> per VLAN.

Right.  Assuming you've gotten your head around the notion of
hierarchical VLANs, how is this different?

>  
> > Also, note that in this same situation with routers in place
> > of RBridges, each router would most likely be required to 
> > have a logical interface in each VLAN on every link to which
> > it is connected.
> 
> This cannot be compared with routers.  We're talking
> about bridging here.  If we routed, we'd just terminate
> the MAC domain at the edge router and we wouldn't
> run into any of these issues.  No sense in having a
> VLAN interface on every router in the campus.
> (One could design the network that way, but it would
> be a really bad way to do it.)

The point is that - if you had 1000 (or 4000) VLANs, in a
subnet, you would terminate a large percentage of those on
connected routers.

If you imagine that there are many sch subnets (as seems to
be implied in your earlier comments), then this would also
be true for other physical interfaces on each router.

Also, if you believe that RBridges may be used to replace
routers, then you compound this issue.

>  
> > In other words, this situation is just plain complicated -
> > irrespective of what you're trying to do to deal with it.
> > 
> > > 
> > > Have the scaling issues been considered
> > > at all?  It might actually be better to
> > > just use the core IS-IS instance.
> > 
> > Scaling has been considered.  Large increases in scalability 
> > are not a primary goal - relative to existing bridging, for
> > example.
> > 
> > RTFC!  Increased scalability over existing bridging was 
> > explicitly NOT included in the charter as a goal.
> 
> I thought I knew what the charter was but I went back
> and read it again anyway.  I didn't find much there
> to work with with respect to scalability requirements.
> It talks about a "problem statement and applicability"
> document.  I'm not sure which of the published documents
> that is. 

It is the one that has that name.  Joe Touch is the main
author/editor (with Radia Perlman).  It apparently has been 
allowed to expire.

See: 

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=147
71

for more information.

By the way, it actually did not expire very long ago, so it
is likely that there is a new version in the works.

However, the way that IETF charters typically work is that
they are exclusive, rather than inclusive, by default.  In
other words, the fact that the charter does not explicitly
include increased scalability as a goal CANNOT be read to
mean that it may be a goal because it is not explicitly 
excluded.

Per the charter, the design goals for the TRILL solution are:

- Minimal or no configuration required
- Load-splitting among multiple paths
- Routing loop mitigation (possibly through a TTL field)
- Support of multiple points of attachment
- Support for broadcast and multicast
- No significant service delay after attachment
- No less secure than existing bridged solutions

There is nothing in these explicitly listed goals that can
be stretched to include the notion of hugely increased scale,
or replacement of routers.

> 
> Anoop
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5BFnOp6014655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 11 Jun 2007 08:49:24 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-105-94-14.lsanca.dsl-w.verizon.net [71.105.94.14]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5BFmmjj018346; Mon, 11 Jun 2007 08:48:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 11 Jun 2007 08:48:23 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig379256FFDAB9F816DF083044"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2007 15:49:49 -0000
Status: RO
Content-Length: 1276

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig379256FFDAB9F816DF083044
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Radia Perlman wrote:
> Re: Is multicast pruning a MAY or MUST:
>=20
> I'm not sure there's been enough opinion voiced to have a consensus on =
this.
> I'd be happy with MAY or SHOULD, since it really it just an optimizatio=
n.

IMO, optimizations should be expressed as MAY.

To say "SHOULD" is to say that implementations that do not implement the
optimization should have a good reason for not doing so. I don't think
the presumption should be tilted that way.

Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enig379256FFDAB9F816DF083044
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbW7HE5f5cImnZrsRAlb4AKCSI744iAbAy6grjPitYUXkLpRLCQCfQMAW
NcXt98ggTLGGl1xID5TwjnM=
=M3sf
-----END PGP SIGNATURE-----

--------------enig379256FFDAB9F816DF083044--



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 l5A42RrH009148 for <[e-mail]>; Sat, 9 Jun 2007 21:02:27 -0700 (PDT)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 09 Jun 2007 21:02:12 -0700 (PDT)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 09 Jun 2007 21:02:11 -0700 (PDT)
Received: from [152.70.2.164] (Forwarded-For: [71.231.195.148]) by mail-srv.sfvic.sunlabs.com (mshttpd); Sat, 09 Jun 2007 21:02:11 -0700
Date: Sat, 09 Jun 2007 21:02:11 -0700
From: [e-mail]
To: Silvano Gai <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Jun 2007 04:02:52 -0000
Status: RO
Content-Length: 5128

Expanding on what Silvano said, and agreeing with what I think Anoop was pointing out.

It was an error in the previous version of the spec to say that the IP multicast group membership
information would be announced in the per-VLAN instance, since the core guys would need
to look at membership in VLAN A, even if they are not in VLAN A, in order to prune multicasts
in VLAN A inside the core. So IP group membership is moving to the core instance.

And for now the per-VLAN instance (which would have announced endnode membership) is
going away, though I'd like it to be optional in the future, for letting an RBridge announce
endnodes that have actually enrolled at layer 2, since it's a more secure binding than
just having an endnode transmit a data packet with the source address. But it will be a MUST
to learn from data packets, and, if we define a per-VLAN instance of IS-IS for announcing endnode
memberships, it would be a SHOULD to announce endnodes that have actually enrolled, with
perhaps a metric for how securely they've enrolled (whether it was cryptographic authentication, e.g.).
And it would be a SHOULD to learn from such reports, and a SHOULD to have the IS-IS announcement
be believed when there is a conflict between what is learned from decapsulating a data packet vs
what is announced in IS-IS.

Radia
----- Original Message -----
From: Silvano Gai <[e-mail]>
Date: Saturday, June 9, 2007 10:01 am
Subject: Re: [rbridge] per-VLAN instances of IS-IS

> Anoop,
> 
> The proposal for multicast is to move this information in the core
> inbstance of ISIS.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: [e-mail] [[e-mail]]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Friday, June 08, 2007 6:25 PM
> > To: Eastlake III Donald-LDE008
> > Cc: [e-mail]
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > >
> > > See below at @@@
> > >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [[e-mail]] On
> > > Behalf Of Anoop Ghanwani
> > > Sent: Friday, June 08, 2007 12:59 PM
> > > To: [e-mail]
> > > Subject: [rbridge] per-VLAN instances of IS-IS
> > ..
> > >
> > > Have the scaling issues been considered
> > > at all?  It might actually be better to
> > > just use the core IS-IS instance.
> > >
> > > @@@ These issues have been raised, although the possibility
> > > of using the
> > > core IS-IS instances hasn't been discussed much.  If you do have
> 1,000
> > > VLANs, using the core instance means that every Rbridge in the
> campus
> > > would have to know all end stations, even if that Rbridge is
> > > in an area
> > > of the campus that only uses one or a few VLANs.
> > >
> > > @@@ The WG appears to favor a change so that all Rbridges MUST be
> able
> > > to learn entirely from data, the way IEEE 802.1 bridges do, 
> based on
> > > frames that they encapsulate and decapsulate. There are, however,
> > > advantages to using the per VLAN IS-IS instances, such as improved
> > > security in learning remote end node addresses if those end states
> > > register with their local Rbridge using some layer 2 protocol such
> as
> > > 802.1X and IS-IS security is in use for the IS-IS messages.
> > > So it seems
> > > appropriate at this time to say in the draft that Rbridges
> > > MAY implement
> > > and use the per VLAN IS-IS technique. Of course, it should also be
> > > possible to use a management protocol to configure end station
> > > addresses, configure so as to turn off learning from data, etc.
> > >
> > > @@@ I expect the next version of the protocol specification to
> reflect
> > > this change so that learning only from data is the zero
> configuration
> > > method.
> > 
> > 
> > The learning approach will work for unicast addresses.
> > It will not work for pruning the trees for multicast
> > addresses and flooding to VLANs.  Those addresses
> > and VLAN membership information needs to be sent
> > around to all RBridges in the network.
> > 
> > >
> > > The following statement in Section 3.3.3.2
> > > of the draft appears to be incorrect/incomplete:
> > >
> > > "RBridges with endnodes in VLAN A also
> > > receive and process the frame in their
> > > VLAN-A IS-IS instance."
> > >
> > > The frame also has to be processed by all
> > > RBridges that might be along the path for
> > > reaching the VLANs, otherwise we wouldn't
> > > be able to prune the distribution trees
> > > correctly.
> > >
> > > @@@ Right. It actually says "... all RBridges forward it as
> > > an ordinary
> > > frame in VLAN A ..." in the previous paragraph.
> > 
> > This doesn't work.  See my response to Eric
> > for why it doesn't.
> > 
> > Thanks,
> > Anoop
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5A0XX91005328 for <[e-mail]>; Sat, 9 Jun 2007 17:33:33 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-128.messagelabs.com!1181435612!12589909!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.10]
Received: (qmail 12422 invoked from network); 10 Jun 2007 00:33:32 -0000
Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-8.tower-128.messagelabs.com with SMTP; 10 Jun 2007 00:33:32 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l5A0XVFW014298 for <[e-mail]>; Sat, 9 Jun 2007 17:33:31 -0700 (MST)
Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5A0XUha027008 for <[e-mail]>; Sat, 9 Jun 2007 19:33:31 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5A0XTae027005 for <[e-mail]>; Sat, 9 Jun 2007 19:33:30 -0500 (CDT)
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: Sat, 9 Jun 2007 20:33:26 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAxz/wABDBIsAAINE5UAAPe96w
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5A0XX91005328
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Jun 2007 00:33:48 -0000
Status: RO
Content-Length: 3858

See below at ###

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Saturday, June 09, 2007 1:02 PM
To: Anoop Ghanwani; Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Anoop,

The proposal for multicast is to move this information in the core
inbstance of ISIS.

### If you referring to the various multicast listener and IP multicast
router information, it has to be in the core instance so pruning can
happen in transit Rbridges.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Friday, June 08, 2007 6:25 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> >
> > See below at @@@
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On
> > Behalf Of Anoop Ghanwani
> > Sent: Friday, June 08, 2007 12:59 PM
> > To: [e-mail]
> > Subject: [rbridge] per-VLAN instances of IS-IS
> ..
> >
> > Have the scaling issues been considered
> > at all?  It might actually be better to
> > just use the core IS-IS instance.
> >
> > @@@ These issues have been raised, although the possibility
> > of using the
> > core IS-IS instances hasn't been discussed much.  If you do have
1,000
> > VLANs, using the core instance means that every Rbridge in the
campus
> > would have to know all end stations, even if that Rbridge is
> > in an area
> > of the campus that only uses one or a few VLANs.
> >
> > @@@ The WG appears to favor a change so that all Rbridges MUST be
able
> > to learn entirely from data, the way IEEE 802.1 bridges do, based on
> > frames that they encapsulate and decapsulate. There are, however,
> > advantages to using the per VLAN IS-IS instances, such as improved
> > security in learning remote end node addresses if those end states
> > register with their local Rbridge using some layer 2 protocol such
as
> > 802.1X and IS-IS security is in use for the IS-IS messages.
> > So it seems
> > appropriate at this time to say in the draft that Rbridges
> > MAY implement
> > and use the per VLAN IS-IS technique. Of course, it should also be
> > possible to use a management protocol to configure end station
> > addresses, configure so as to turn off learning from data, etc.
> >
> > @@@ I expect the next version of the protocol specification to
reflect
> > this change so that learning only from data is the zero
configuration
> > method.
> 
> The learning approach will work for unicast addresses.
> It will not work for pruning the trees for multicast
> addresses and flooding to VLANs.  Those addresses
> and VLAN membership information needs to be sent
> around to all RBridges in the network.

### Correct, that information has to be in the core instance and is
incorrectly shown in the current draft as being in the per VLAN
instance.

### Donald

> > The following statement in Section 3.3.3.2
> > of the draft appears to be incorrect/incomplete:
> >
> > "RBridges with endnodes in VLAN A also
> > receive and process the frame in their
> > VLAN-A IS-IS instance."
> >
> > The frame also has to be processed by all
> > RBridges that might be along the path for
> > reaching the VLANs, otherwise we wouldn't
> > be able to prune the distribution trees
> > correctly.
> >
> > @@@ Right. It actually says "... all RBridges forward it as
> > an ordinary
> > frame in VLAN A ..." in the previous paragraph.
> 
> This doesn't work.  See my response to Eric
> for why it doesn't.
> 
> Thanks,
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l5A0M6Kt003467 for <[e-mail]>; Sat, 9 Jun 2007 17:22:06 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-153.messagelabs.com!1181434925!1172699!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.9]
Received: (qmail 10767 invoked from network); 10 Jun 2007 00:22:05 -0000
Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-8.tower-153.messagelabs.com with SMTP; 10 Jun 2007 00:22:05 -0000
Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5A0M4M8002418 for <[e-mail]>; Sat, 9 Jun 2007 19:22:04 -0500 (CDT)
Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5A0M3JR014862 for <[e-mail]>; Sat, 9 Jun 2007 19:22:04 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5A0M20j014854 for <[e-mail]>; Sat, 9 Jun 2007 19:22:02 -0500 (CDT)
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: Sat, 9 Jun 2007 20:21:58 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] multicast pruning in TRILL
thread-index: AcepQ0nCzZjQ6NfSS4eIRiupXc50owBY1c3QABNirrA=
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l5A0M6Kt003467
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Jun 2007 00:22:19 -0000
Status: RO
Content-Length: 1052

The consensus determination referred to is here:
http://www.postel.org/pipermail/rbridge/2007-May/002226.html
which refers to the option 1 here:
http://www.postel.org/pipermail/rbridge/2007-May/002078.html

Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Saturday, June 09, 2007 11:04 AM
To: Radia Perlman; Eastlake III Donald-LDE008
Cc: [e-mail]
Subject: RE: [rbridge] multicast pruning in TRILL

Folks,

We had a detailed discussion on the header format which included all the
points that Radia list below. We had a strong consensus on one solution.
The WG chairs confirmed this consensus on the mailing list.

There is no new piece of information. We have not discovered anything
that was not known at the time of the consensus. I propose we stick with
the current header format.

If we continue to change things we will never converge and the frame
format needs to be stable ASAP.

If we reopen the frame format discussion, then I want to reopen nickname
vs address ;-) :-) :-) ;-)

-- Silvano



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l59H1q7p011267 for <[e-mail]>; Sat, 9 Jun 2007 10:01:52 -0700 (PDT)
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: Sat, 9 Jun 2007 10:01:35 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAxz/wABDBIsAAINE5UA==
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l59H1q7p011267
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Jun 2007 17:02:44 -0000
Status: RO
Content-Length: 3290

Anoop,

The proposal for multicast is to move this information in the core
inbstance of ISIS.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Friday, June 08, 2007 6:25 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008
> >
> > See below at @@@
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On
> > Behalf Of Anoop Ghanwani
> > Sent: Friday, June 08, 2007 12:59 PM
> > To: [e-mail]
> > Subject: [rbridge] per-VLAN instances of IS-IS
> ..
> >
> > Have the scaling issues been considered
> > at all?  It might actually be better to
> > just use the core IS-IS instance.
> >
> > @@@ These issues have been raised, although the possibility
> > of using the
> > core IS-IS instances hasn't been discussed much.  If you do have
1,000
> > VLANs, using the core instance means that every Rbridge in the
campus
> > would have to know all end stations, even if that Rbridge is
> > in an area
> > of the campus that only uses one or a few VLANs.
> >
> > @@@ The WG appears to favor a change so that all Rbridges MUST be
able
> > to learn entirely from data, the way IEEE 802.1 bridges do, based on
> > frames that they encapsulate and decapsulate. There are, however,
> > advantages to using the per VLAN IS-IS instances, such as improved
> > security in learning remote end node addresses if those end states
> > register with their local Rbridge using some layer 2 protocol such
as
> > 802.1X and IS-IS security is in use for the IS-IS messages.
> > So it seems
> > appropriate at this time to say in the draft that Rbridges
> > MAY implement
> > and use the per VLAN IS-IS technique. Of course, it should also be
> > possible to use a management protocol to configure end station
> > addresses, configure so as to turn off learning from data, etc.
> >
> > @@@ I expect the next version of the protocol specification to
reflect
> > this change so that learning only from data is the zero
configuration
> > method.
> 
> 
> The learning approach will work for unicast addresses.
> It will not work for pruning the trees for multicast
> addresses and flooding to VLANs.  Those addresses
> and VLAN membership information needs to be sent
> around to all RBridges in the network.
> 
> >
> > The following statement in Section 3.3.3.2
> > of the draft appears to be incorrect/incomplete:
> >
> > "RBridges with endnodes in VLAN A also
> > receive and process the frame in their
> > VLAN-A IS-IS instance."
> >
> > The frame also has to be processed by all
> > RBridges that might be along the path for
> > reaching the VLANs, otherwise we wouldn't
> > be able to prune the distribution trees
> > correctly.
> >
> > @@@ Right. It actually says "... all RBridges forward it as
> > an ordinary
> > frame in VLAN A ..." in the previous paragraph.
> 
> This doesn't work.  See my response to Eric
> for why it doesn't.
> 
> Thanks,
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l59F6ihE018369 for <[e-mail]>; Sat, 9 Jun 2007 08:06:44 -0700 (PDT)
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: Sat, 9 Jun 2007 08:06:31 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAuSRGg
References: <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l59F6ihE018369
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Jun 2007 15:07:02 -0000
Status: RO
Content-Length: 1760

Anoop,

You are right; there is a tremendous scalability issue.

My proposal is to completely drop the per-VLAN ISIS instance and learn
from data frames. Proven, scalable, it works.

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anoop Ghanwani
> Sent: Friday, June 08, 2007 9:59 AM
> To: [e-mail]
> Subject: [rbridge] per-VLAN instances of IS-IS
> 
> 
> Section 3.3.3.2 of the rBridge base spec
> talks about the per VLAN instance of IS-IS.
> 
> I can see why that would be useful.
> However, if looks like there could be
> problems scaling.  If an end rBridge
> participates in 1000 VLANs, it will have
> to maintain 1000 adjacencies.
> 
> Plus, it looks like for the per-VLAN IS-IS
> instance, the RBridge network operates
> as single LAN segment.  That would mean
> having to go through DR/BDR election for
> each instance.
> 
> Operating 100's of routers on a single
> LAN segment would poses its own set of
> scaling issues.  Having per VLAN instances
> exacerbates the problem.
> 
> Have the scaling issues been considered
> at all?  It might actually be better to
> just use the core IS-IS instance.
> 
> The following statement in Section 3.3.3.2
> of the draft appears to be incorrect/incomplete:
> 
> "RBridges with endnodes in VLAN A also
> receive and process the frame in their
> VLAN-A IS-IS instance."
> 
> The frame also has to be processed by all
> RBridges that might be along the path for
> reaching the VLANs, otherwise we wouldn't
> be able to prune the distribution trees
> correctly.
> 
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l59F3rFo017710 for <[e-mail]>; Sat, 9 Jun 2007 08:03:53 -0700 (PDT)
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: Sat, 9 Jun 2007 08:03:38 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] multicast pruning in TRILL
Thread-Index: AcepQ0nCzZjQ6NfSS4eIRiupXc50owBY1c3Q
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Eastlake III Donald-LDE008" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l59F3rFo017710
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Jun 2007 15:04:08 -0000
Status: RO
Content-Length: 3834

Folks,

We had a detailed discussion on the header format which included all the
points that Radia list below. We had a strong consensus on one solution.
The WG chairs confirmed this consensus on the mailing list.

There is no new piece of information. We have not discovered anything
that was not known at the time of the consensus. I propose we stick with
the current header format.

If we continue to change things we will never converge and the frame
format needs to be stable ASAP.

If we reopen the frame format discussion, then I want to reopen nickname
vs address ;-) :-) :-) ;-)

-- Silvano

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Thursday, June 07, 2007 1:29 PM
> To: Eastlake III Donald-LDE008
> Cc: [e-mail]
> Subject: Re: [rbridge] multicast pruning in TRILL
> 
> (revisiting the issue of moving whatever is necessary for transit
> bridges to look at
> for pruning of multicasts (VLAN tag and destination multicast address)
> to the portion of the frame outside the tunnel, i.e., either the TRILL
> header or
> the outer header)
> 
> The mailing list archives are daunting, even though I've been trying
to
> follow it all along.
> I'd like to see the arguments both sides of this issue summarized
rather
> than
> pointing people at the mailing list -- just now I tried to review the
> mailing list
> on this issue and got discouraged. It never hurts to summarize the
> issues again.
> 
> I'll start by writing down concisely what I do remember, and perhaps
> people can
> concisely add other arguments:
> 
> a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer
> bits total (since you
> don't need the Ethertype) to include it as a tag in the inner header),
> it's easier to find since
> transit RBridges don't need to find the inner header,
> the TRILL header is still fixed length.  Minuses: It takes up room
even
> when there is
> no VLAN tag in the inner header
> 
> b) moving VLAN tag to TRILL header as an option: Pluses: it only takes
> up room
> when there is a VLAN tag in the inner frame. Minus: it makes the TRILL
> header
> variable length
> 
> c) moving the inner multicast address (for IP multicast pruning) into
> the TRILL header: I don't think this was discussed. But it would
clearly
> have to be done as an option in the TRILL
> header since we wouldn't want to make space for it in the TRILL header
> on unicast
> packets, so it would make the TRILL header variable length
> 
> d) copying the inner multicast address (for IP multicast pruning) into
> the *outer* Ethernet
> header. I don't think this was discussed at all on the mailing list. I
> assume that it wouldn't
> confuse non-RBridge devices listening to that multicast address that
> might hear the
> packet because the Ethertype would be TRILL, so they'd (hopefully)
drop
> it without
> getting confused.
> 
> Whatever I've missed, can someone add to this?
> 
> Thanks,
> 
> Radia
> 
> 
> Eastlake III Donald-LDE008 wrote:
> >
> > @@@ Indeed, for precisely the reason you give, it was and remains my
> > strong personal opinion that the VLAN-tag information should be part
of
> > the TRILL Header where it would be at least 14 bytes earlier and you
> > would also save the 2 bytes of tag Ethertype. It contains priority
as
> > well as the VLAN ID info.
> >
> > @@@ However, the working group appears to be of the opinion that the
> > VLAN-tag should be inserted inside the inner frame with an
Ethertype.
> > See the May mail here which includes arguments on the other side of
the
> > issue:
> > http://www.postel.org/pipermail/rbridge/2007-May/thread.html.
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l591PJYm008444 for <[e-mail]>; Fri, 8 Jun 2007 18:25:19 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 08 Jun 2007 18:25:19 -0700
X-IronPort-AV: i="4.16,401,1175497200";  d="scan'208"; a="10919201:sNHT25255776"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id C4D20238377; Fri,  8 Jun 2007 18:23:11 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 8 Jun 2007 18:25:19 -0700
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: Fri, 8 Jun 2007 18:25:08 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAxz/wABDBIsA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>
X-OriginalArrivalTime: 09 Jun 2007 01:25:19.0367 (UTC) FILETIME=[0ABFA970:01C7AA35]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l591PJYm008444
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Jun 2007 01:26:16 -0000
Status: RO
Content-Length: 2619

 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> 
> See below at @@@
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Anoop Ghanwani
> Sent: Friday, June 08, 2007 12:59 PM
> To: [e-mail]
> Subject: [rbridge] per-VLAN instances of IS-IS
..
> 
> Have the scaling issues been considered
> at all?  It might actually be better to
> just use the core IS-IS instance.
> 
> @@@ These issues have been raised, although the possibility 
> of using the
> core IS-IS instances hasn't been discussed much.  If you do have 1,000
> VLANs, using the core instance means that every Rbridge in the campus
> would have to know all end stations, even if that Rbridge is 
> in an area
> of the campus that only uses one or a few VLANs.
> 
> @@@ The WG appears to favor a change so that all Rbridges MUST be able
> to learn entirely from data, the way IEEE 802.1 bridges do, based on
> frames that they encapsulate and decapsulate. There are, however,
> advantages to using the per VLAN IS-IS instances, such as improved
> security in learning remote end node addresses if those end states
> register with their local Rbridge using some layer 2 protocol such as
> 802.1X and IS-IS security is in use for the IS-IS messages. 
> So it seems
> appropriate at this time to say in the draft that Rbridges 
> MAY implement
> and use the per VLAN IS-IS technique. Of course, it should also be
> possible to use a management protocol to configure end station
> addresses, configure so as to turn off learning from data, etc.
>
> @@@ I expect the next version of the protocol specification to reflect
> this change so that learning only from data is the zero configuration
> method.


The learning approach will work for unicast addresses.
It will not work for pruning the trees for multicast
addresses and flooding to VLANs.  Those addresses
and VLAN membership information needs to be sent
around to all RBridges in the network.

> 
> The following statement in Section 3.3.3.2
> of the draft appears to be incorrect/incomplete:
> 
> "RBridges with endnodes in VLAN A also 
> receive and process the frame in their 
> VLAN-A IS-IS instance."
> 
> The frame also has to be processed by all
> RBridges that might be along the path for
> reaching the VLANs, otherwise we wouldn't
> be able to prune the distribution trees
> correctly.
> 
> @@@ Right. It actually says "... all RBridges forward it as 
> an ordinary
> frame in VLAN A ..." in the previous paragraph.

This doesn't work.  See my response to Eric 
for why it doesn't.

Thanks,
Anoop



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l591FFnR006695 for <[e-mail]>; Fri, 8 Jun 2007 18:15:15 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 08 Jun 2007 18:15:15 -0700
X-IronPort-AV: i="4.16,401,1175497200";  d="scan'208"; a="10919106:sNHT20088761"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 98B63238377; Fri,  8 Jun 2007 18:13:07 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 8 Jun 2007 18:15:15 -0700
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: Fri, 8 Jun 2007 18:15:04 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAhLOAAA+asGA=
From: "Anoop Ghanwani" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-OriginalArrivalTime: 09 Jun 2007 01:15:15.0164 (UTC) FILETIME=[A29D99C0:01C7AA33]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l591FFnR006695
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Jun 2007 01:15:44 -0000
Status: RO
Content-Length: 6176

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
>
> 	Having per-VLAN instances of IS-IS helps to simplify 
> interactions - thus increasing the likelihood of correct 
> specification leading to interoperable implementations.
> 
> 	This is accomplished at some cost in extremely complex
> deployment scenarios - such as the one you cite as an example
> - but the cost is not nearly as high as you make it sound.
> 
> 	Please see in-line comments below for further details.
...
> 
> I am not convinced that you do.  Having a per-VLAN IS-IS
> instance greatly simplifies interactions, and allows us 
> to effectively define RBridges in a single VLAN context
> - leaving implementers free to implement inter-VLAN as 
> already implemented in 802.1Q (and related) implementation.
> 
> This is more than just "useful."  See below for further
> clarification.

I'm not quite sure I get it, but I'll look below.

> > If an end rBridge 
> > participates in 1000 VLANs, it will have
> > to maintain 1000 adjacencies. 
> 
> This is effectively true if we postulate only a single IS-IS
> instance for all VLANs, because you have to scope routing
> activities, link-state, etc. - on a per-VLAN basis even if
> that is the case.
> 
> What you accomplish by using a single instance is to make it
> far more difficult to describe, understand and correctly
> implement RBridge routing protocol behaviors.

I understand there will be some complexity in
describing all the VLANs and multicast addresses
in a single instance, but I think it scales better
than multiple instances.  Why?  Consider the
following picture:

           D
           |
v1 -- A -- B -- C -- v1
           | 
           E

A-E are RBridges.

In this picture VLAN v1 is configured only on A
and C.  B doesn't have v1 configured on it.  Yet
B needs to know about VLAN v1's location in order
to correctly prune its trees.

What I'm getting at is that all RBridges in the 
network need to know about all VLANs so that they
can prune their trees for each VLAN correctly.

If you have an instance per VLAN we are talking
about maintain up to 4K instances in each Rbridge.
And it's not unheard of to configure a 1000
VLANs in regular 802.1Q device.


> > Plus, it looks like for the per-VLAN IS-IS
> > instance, the RBridge network operates
> > as single LAN segment.  That would mean
> > having to go through DR/BDR election for
> > each instance. 
> 
> And this would be correct behavior.  An RBridge should only
> be eligible for ingress and egress to a local VLAN is it is
> configured to participate in that local VLAN.  Hence, it may
> only participate in DR election for VLANs on a local bridged
> LAN if it participates in those VLANs.

See above for why this is not true.  Or
tell me how I can do pruning without interior
RBridges knowing about all VLANs.

> This is central to one of the issues with specifying - and
> correctly implementing - RBridge functionality.
> 
> There are optimizations we may consider at a later date that
> will reduce - for example - messaging overhead, and there are
> already existing optimizations to reduce the actual state
> maintenance overhead to roughly the same as would be the case
> with a single IS-IS instance.
>  
> > 
> > Operating 100's of routers on a single 
> > LAN segment would poses its own set of 
> > scaling issues.  Having per VLAN instances
> > exacerbates the problem.
> 
> Are there deployment scenarios in today's bridging community
> where we support this kind of network as a bidged network?

Not in a bridged network.  But if I recall correctly,
and I may be off since the charter may have changed
since the beginning, one of the goals of rBridges was
to be able to build large campuses without routers
and routing-related configuration.  Has that gone away?
It is not atypical to find a campus with 20K users
on 100's of VLANs with ~100 nodes.

> If there are not, then please recall that sclability of the
> current solution is targetted only for routghly the same
> size networks as can be established with bridging today.

Even with a network of today's bridges there would
be scaling issues if you had say 20-30 rBridges
all trying to establish adjacencies between groups
of themselves for a few 100 VLANs.  It is not 
atypical to have ~1000 VLANs configured in core
switches.

> You make it sound as if we're expected to solve problems 
> with RBridges for which solutions have never been specified
> for routing.
>
> As for complicating the problem with VLAN instances, think
> about how complicated this scenario would be already with 
> 802.1Q VLANs running any of today's spanning tree protocols.

They scale just fine because they limit the 
maximum number of trees and have some VLANs share
a tree.  They don't try to run one STP instance
per VLAN.
 
> Also, note that in this same situation with routers in place
> of RBridges, each router would most likely be required to 
> have a logical interface in each VLAN on every link to which
> it is connected.

This cannot be compared with routers.  We're talking
about bridging here.  If we routed, we'd just terminate
the MAC domain at the edge router and we wouldn't
run into any of these issues.  No sense in having a
VLAN interface on every router in the campus.
(One could design the network that way, but it would
be a really bad way to do it.)
 
> In other words, this situation is just plain complicated -
> irrespective of what you're trying to do to deal with it.
> 
> > 
> > Have the scaling issues been considered
> > at all?  It might actually be better to
> > just use the core IS-IS instance.
> 
> Scaling has been considered.  Large increases in scalability 
> are not a primary goal - relative to existing bridging, for
> example.
> 
> RTFC!  Increased scalability over existing bridging was 
> explicitly NOT included in the charter as a goal.

I thought I knew what the charter was but I went back
and read it again anyway.  I didn't find much there
to work with with respect to scalability requirements.
It talks about a "problem statement and applicability"
document.  I'm not sure which of the published documents
that is. 

Anoop



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l58Hm16r022426 for <[e-mail]>; Fri, 8 Jun 2007 10:48:02 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-128.messagelabs.com!1181324880!15087416!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 31944 invoked from network); 8 Jun 2007 17:48:00 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 8 Jun 2007 17:48:00 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l58HltqO023571 for <[e-mail]>; Fri, 8 Jun 2007 10:47:59 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l58Hlt18015465 for <[e-mail]>; Fri, 8 Jun 2007 12:47:55 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l58HlsEV015450 for <[e-mail]>; Fri, 8 Jun 2007 12:47:54 -0500 (CDT)
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: Fri, 8 Jun 2007 13:47:53 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
thread-index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAxz/w
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l58Hm16r022426
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2007 17:49:12 -0000
Status: RO
Content-Length: 2744

Hi Anoop,

See below at @@@

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 08, 2007 12:59 PM
To: [e-mail]
Subject: [rbridge] per-VLAN instances of IS-IS

Section 3.3.3.2 of the rBridge base spec 
talks about the per VLAN instance of IS-IS.

I can see why that would be useful.
However, if looks like there could be
problems scaling.  If an end rBridge 
participates in 1000 VLANs, it will have
to maintain 1000 adjacencies.  

Plus, it looks like for the per-VLAN IS-IS
instance, the RBridge network operates
as single LAN segment.  That would mean
having to go through DR/BDR election for
each instance.  

Operating 100's of routers on a single 
LAN segment would poses its own set of 
scaling issues.  Having per VLAN instances
exacerbates the problem.

Have the scaling issues been considered
at all?  It might actually be better to
just use the core IS-IS instance.

@@@ These issues have been raised, although the possibility of using the
core IS-IS instances hasn't been discussed much.  If you do have 1,000
VLANs, using the core instance means that every Rbridge in the campus
would have to know all end stations, even if that Rbridge is in an area
of the campus that only uses one or a few VLANs.

@@@ The WG appears to favor a change so that all Rbridges MUST be able
to learn entirely from data, the way IEEE 802.1 bridges do, based on
frames that they encapsulate and decapsulate. There are, however,
advantages to using the per VLAN IS-IS instances, such as improved
security in learning remote end node addresses if those end states
register with their local Rbridge using some layer 2 protocol such as
802.1X and IS-IS security is in use for the IS-IS messages. So it seems
appropriate at this time to say in the draft that Rbridges MAY implement
and use the per VLAN IS-IS technique. Of course, it should also be
possible to use a management protocol to configure end station
addresses, configure so as to turn off learning from data, etc.

@@@ I expect the next version of the protocol specification to reflect
this change so that learning only from data is the zero configuration
method.

The following statement in Section 3.3.3.2
of the draft appears to be incorrect/incomplete:

"RBridges with endnodes in VLAN A also 
receive and process the frame in their 
VLAN-A IS-IS instance."

The frame also has to be processed by all
RBridges that might be along the path for
reaching the VLANs, otherwise we wouldn't
be able to prune the distribution trees
correctly.

@@@ Right. It actually says "... all RBridges forward it as an ordinary
frame in VLAN A ..." in the previous paragraph.

Anoop

@@@ Thanks,
@@@ Donald




Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l58HfVQO020901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 8 Jun 2007 10:41:31 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l58HgRi1028081; Fri, 8 Jun 2007 12:42:27 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 8 Jun 2007 12:41:24 -0500
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: Fri, 8 Jun 2007 12:41:22 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebwAAhLOA
References: <[e-mail]>
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-OriginalArrivalTime: 08 Jun 2007 17:41:24.0946 (UTC) FILETIME=[3C241320:01C7A9F4]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l58HfVQO020901
Cc: [e-mail]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2007 17:42:00 -0000
Status: RO
Content-Length: 4603

Anoop,

	Having per-VLAN instances of IS-IS helps to simplify 
interactions - thus increasing the likelihood of correct 
specification leading to interoperable implementations.

	This is accomplished at some cost in extremely complex
deployment scenarios - such as the one you cite as an example
- but the cost is not nearly as high as you make it sound.

	Please see in-line comments below for further details.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
> Sent: Friday, June 08, 2007 12:59 PM
> To: [e-mail]
> Subject: [rbridge] per-VLAN instances of IS-IS
> 
> 
> Section 3.3.3.2 of the rBridge base spec 
> talks about the per VLAN instance of IS-IS.
> 
> I can see why that would be useful.
> However, if looks like there could be
> problems scaling.  

I am not convinced that you do.  Having a per-VLAN IS-IS
instance greatly simplifies interactions, and allows us 
to effectively define RBridges in a single VLAN context
- leaving implementers free to implement inter-VLAN as 
already implemented in 802.1Q (and related) implementation.

This is more than just "useful."  See below for further
clarification.

> If an end rBridge 
> participates in 1000 VLANs, it will have
> to maintain 1000 adjacencies. 

This is effectively true if we postulate only a single IS-IS
instance for all VLANs, because you have to scope routing
activities, link-state, etc. - on a per-VLAN basis even if
that is the case.

What you accomplish by using a single instance is to make it
far more difficult to describe, understand and correctly
implement RBridge routing protocol behaviors.
 
> 
> Plus, it looks like for the per-VLAN IS-IS
> instance, the RBridge network operates
> as single LAN segment.  That would mean
> having to go through DR/BDR election for
> each instance. 

And this would be correct behavior.  An RBridge should only
be eligible for ingress and egress to a local VLAN is it is
configured to participate in that local VLAN.  Hence, it may
only participate in DR election for VLANs on a local bridged
LAN if it participates in those VLANs.

This is central to one of the issues with specifying - and
correctly implementing - RBridge functionality.

There are optimizations we may consider at a later date that
will reduce - for example - messaging overhead, and there are
already existing optimizations to reduce the actual state
maintenance overhead to roughly the same as would be the case
with a single IS-IS instance.
 
> 
> Operating 100's of routers on a single 
> LAN segment would poses its own set of 
> scaling issues.  Having per VLAN instances
> exacerbates the problem.

Are there deployment scenarios in today's bridging community
where we support this kind of network as a bidged network?

If there are not, then please recall that sclability of the
current solution is targetted only for routghly the same
size networks as can be established with bridging today.

You make it sound as if we're expected to solve problems 
with RBridges for which solutions have never been specified
for routing.

As for complicating the problem with VLAN instances, think
about how complicated this scenario would be already with 
802.1Q VLANs running any of today's spanning tree protocols.

Also, note that in this same situation with routers in place
of RBridges, each router would most likely be required to 
have a logical interface in each VLAN on every link to which
it is connected.

In other words, this situation is just plain complicated -
irrespective of what you're trying to do to deal with it.

> 
> Have the scaling issues been considered
> at all?  It might actually be better to
> just use the core IS-IS instance.

Scaling has been considered.  Large increases in scalability 
are not a primary goal - relative to existing bridging, for
example.

RTFC!  Increased scalability over existing bridging was 
explicitly NOT included in the charter as a goal.

> 
> The following statement in Section 3.3.3.2
> of the draft appears to be incorrect/incomplete:
> 
> "RBridges with endnodes in VLAN A also 
> receive and process the frame in their 
> VLAN-A IS-IS instance."
> 
> The frame also has to be processed by all
> RBridges that might be along the path for
> reaching the VLANs, otherwise we wouldn't
> be able to prune the distribution trees
> correctly.
> 
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l58GxbX0009960 for <[e-mail]>; Fri, 8 Jun 2007 09:59:37 -0700 (PDT)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 08 Jun 2007 09:59:31 -0700
X-IronPort-AV: i="4.16,400,1175497200";  d="scan'208"; a="10912420:sNHT16335788"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id A8ECB238377 for <[e-mail]>; Fri,  8 Jun 2007 09:57:24 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 8 Jun 2007 09:59:31 -0700
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: Fri, 8 Jun 2007 09:59:21 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: per-VLAN instances of IS-IS
Thread-Index: Acep7lwdZzYyx0pSQEyF7VcL+3/ebw==
From: "Anoop Ghanwani" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 08 Jun 2007 16:59:31.0860 (UTC) FILETIME=[62399540:01C7A9EE]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l58GxbX0009960
Subject: [rbridge] per-VLAN instances of IS-IS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2007 16:59:59 -0000
Status: RO
Content-Length: 1102

Section 3.3.3.2 of the rBridge base spec 
talks about the per VLAN instance of IS-IS.

I can see why that would be useful.
However, if looks like there could be
problems scaling.  If an end rBridge 
participates in 1000 VLANs, it will have
to maintain 1000 adjacencies.  

Plus, it looks like for the per-VLAN IS-IS
instance, the RBridge network operates
as single LAN segment.  That would mean
having to go through DR/BDR election for
each instance.  

Operating 100's of routers on a single 
LAN segment would poses its own set of 
scaling issues.  Having per VLAN instances
exacerbates the problem.

Have the scaling issues been considered
at all?  It might actually be better to
just use the core IS-IS instance.

The following statement in Section 3.3.3.2
of the draft appears to be incorrect/incomplete:

"RBridges with endnodes in VLAN A also 
receive and process the frame in their 
VLAN-A IS-IS instance."

The frame also has to be processed by all
RBridges that might be along the path for
reaching the VLANs, otherwise we wouldn't
be able to prune the distribution trees
correctly.

Anoop



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l57KT6c1016061 for <[e-mail]>; Thu, 7 Jun 2007 13:29:06 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-153.messagelabs.com!1181248145!486275!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 20411 invoked from network); 7 Jun 2007 20:29:05 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 7 Jun 2007 20:29:05 -0000
Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57KT43n028313 for <[e-mail]>; Thu, 7 Jun 2007 13:29:04 -0700 (MST)
Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l57KT3Eq006864 for <[e-mail]>; Thu, 7 Jun 2007 15:29:03 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l57KT2Vq006852 for <[e-mail]>; Thu, 7 Jun 2007 15:29:02 -0500 (CDT)
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: Thu, 7 Jun 2007 16:28:58 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] multicast pruning in TRILL
thread-index: AcepKeMFrjxIX+hQR5OED6oJoChkLgAA0IZwAAQ+1SA=
References: <[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Radia Perlman" <[e-mail]>, "Caitlin Bestler" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l57KT6c1016061
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 20:30:10 -0000
Status: RO
Content-Length: 4162

Hi,

See below at @@@ 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Caitlin Bestler
Sent: Thursday, June 07, 2007 2:00 PM
To: Radia Perlman; Anoop Ghanwani
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL

Caitlin Bestler <[e-mail]> wrote:

I can see some value in moving RBridge-relevant fields earlier
in the overall packet, but I would want to avoid any and all
risks of doing so in a way where the semantics of those fields
did not remain fully under the IEEE and/or that would require
product to implement the same logic twice. Leaving them where
they are totally avoids such risks.

@@@ The proposal would be to put a two byte field into the TRILL Header
that would be specified by reference to the IEEE standard. The 16 bits
would be used to control distribution tree pruning, priority queuing,
etc., inside an Rbridge in exactly the same way, regardless of whether
those 2 bytes are a field in the TRILL Header or are inserted inside the
encapsulated frame after an Ethertype. 

@@@ more below

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Thursday, June 07, 2007 2:15 PM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL

Radia,

> Re: Is multicast pruning a MAY or MUST:
> 
> I'm not sure there's been enough opinion voiced to have a 
> consensus on this.
> I'd be happy with MAY or SHOULD, since it really it just an 
> optimization.

Actually, I think I agree with Donald's response.  Even
if it were a MAY/SHOULD, no one would ever want to build
a system that didn't do pruning.  It would be way too
inefficient.

> On the other part of what you said -- namely that you have to 
> dig deeper 
> into
> the frame for multicast and VLAN pruning --- it was suggested, but
> not extensively discussed, to move the inner VLAN into the 
> TRILL header
> so that VLAN pruning would not need to be done by finding the 
> inner frame.
> 
> This would still require an RBridge in the core to look 
> inside to find the
> inner frame in order to look at the multicast address.
> 
> There are two ways I can think of to avoid this:
> a) move the multicast address into the inner frame, perhaps 
> as an option in
> the TRILL header
> b) use the multicast address in the inner frame as the destination 
> address in the outer
> header.

Moving the multicast address to the outer
header doesn't really help in terms of 
implementation since the look ups required
stay the same.  It might help from an 
architecture standpoint, but even that
I don't really see.

@@@ Seems to me that moving an inner multicast or broadcast MAC address
to the outer Ethernet header could, on shared links, cause additional
interrupts to end stations from frames they would ultimately have to
discard (and probably shouldn't be handling anyway) because they don't
understand the TRILL Ethertype... 

Essentially, we need both the inner VLAN and the
MAC DA to make their way into the TRILL header
so that they can be consulted for forwarding.
But doing so would unnecessarily add to the 
frame overhead.

@@@ As far as I can see, moving the VLAN tag info to the TRILL Header
reduces frame overhead. There would no longer be a need to insert an
Ethertype and the VLAN tag info into the encapsulated frame. Thus you
would save two bytes.

@@@ On the other hand, since the inner MAC DA is right after the TRILL
Header, whether it is part of the TRILL Header or not just depends on
where you draw the boundaries of that header :-)

@@@ Thanks,
@@@ Donald

Perhaps what is defined is as good as it
gets.  :-)

Somewhat off topic -
I now recall why the statement about "problems 
with learning when doing multipathing" was put
into the TRILL routing requirements document.
In the early days of TRILL, IIRC RBridges 
were going to just forward unicast frames without
an encapsulation header.  In that case, if
one had RBridges and regular bridges intermixed
in a network and had ECMP running in the RBridges,
we'd run into problems with address learning.

Anoop



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 l57KSMX5015953 for <[e-mail]>; Thu, 7 Jun 2007 13:28:22 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 07 Jun 2007 13:28:22 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.19.144]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 07 Jun 2007 13:28:22 -0700 (PDT)
Date: Thu, 07 Jun 2007 13:28:59 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 20:28:28 -0000
Status: RO
Content-Length: 2675

(revisiting the issue of moving whatever is necessary for transit 
bridges to look at
for pruning of multicasts (VLAN tag and destination multicast address)
to the portion of the frame outside the tunnel, i.e., either the TRILL 
header or
the outer header)

The mailing list archives are daunting, even though I've been trying to 
follow it all along.
I'd like to see the arguments both sides of this issue summarized rather 
than
pointing people at the mailing list -- just now I tried to review the 
mailing list
on this issue and got discouraged. It never hurts to summarize the 
issues again.

I'll start by writing down concisely what I do remember, and perhaps 
people can
concisely add other arguments:

a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer 
bits total (since you
don't need the Ethertype) to include it as a tag in the inner header), 
it's easier to find since
transit RBridges don't need to find the inner header,
the TRILL header is still fixed length.  Minuses: It takes up room even 
when there is
no VLAN tag in the inner header

b) moving VLAN tag to TRILL header as an option: Pluses: it only takes 
up room
when there is a VLAN tag in the inner frame. Minus: it makes the TRILL 
header
variable length

c) moving the inner multicast address (for IP multicast pruning) into 
the TRILL header: I don't think this was discussed. But it would clearly 
have to be done as an option in the TRILL
header since we wouldn't want to make space for it in the TRILL header 
on unicast
packets, so it would make the TRILL header variable length

d) copying the inner multicast address (for IP multicast pruning) into 
the *outer* Ethernet
header. I don't think this was discussed at all on the mailing list. I 
assume that it wouldn't
confuse non-RBridge devices listening to that multicast address that 
might hear the
packet because the Ethertype would be TRILL, so they'd (hopefully) drop 
it without
getting confused.

Whatever I've missed, can someone add to this?

Thanks,

Radia


Eastlake III Donald-LDE008 wrote:
>
> @@@ Indeed, for precisely the reason you give, it was and remains my
> strong personal opinion that the VLAN-tag information should be part of
> the TRILL Header where it would be at least 14 bytes earlier and you
> would also save the 2 bytes of tag Ethertype. It contains priority as
> well as the VLAN ID info.
>
> @@@ However, the working group appears to be of the opinion that the
> VLAN-tag should be inserted inside the inner frame with an Ethertype.
> See the May mail here which includes arguments on the other side of the
> issue:
> http://www.postel.org/pipermail/rbridge/2007-May/thread.html.
>
>   



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l57IYqdi017128 for <[e-mail]>; Thu, 7 Jun 2007 11:34:53 -0700 (PDT)
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: Thu, 7 Jun 2007 11:34:40 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TRILL at the next IETF
Thread-Index: AcepMoJxHaC8LUlcTeeqpqM5qTvzAw==
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, "Erik Nordmark" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l57IYqdi017128
Cc: [e-mail]
Subject: [rbridge] TRILL at the next IETF
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 18:35:21 -0000
Status: RO
Content-Length: 252

Chairs,

The preliminary agenda shows the TRILL meeting split over two days.

https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=
69

This is really inconvenient.
Can we have the two slots in the same day?

Thank You

-- Silvano



Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l57IFaFB011487 for <[e-mail]>; Thu, 7 Jun 2007 11:15:36 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 07 Jun 2007 11:15:36 -0700
X-IronPort-AV: i="4.16,395,1175497200";  d="scan'208"; a="13237277:sNHT17500014"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 3E0CD238377; Thu,  7 Jun 2007 11:13:30 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 7 Jun 2007 11:15:36 -0700
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: Thu, 7 Jun 2007 11:15:28 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] multicast pruning in TRILL
Thread-Index: AcepKeMFrjxIX+hQR5OED6oJoChkLgAA0IZw
From: "Anoop Ghanwani" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 07 Jun 2007 18:15:36.0006 (UTC) FILETIME=[D8413E60:01C7A92F]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l57IFaFB011487
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 18:15:51 -0000
Status: RO
Content-Length: 2039

Radia,

> Re: Is multicast pruning a MAY or MUST:
> 
> I'm not sure there's been enough opinion voiced to have a 
> consensus on this.
> I'd be happy with MAY or SHOULD, since it really it just an 
> optimization.

Actually, I think I agree with Donald's response.  Even
if it were a MAY/SHOULD, no one would ever want to build
a system that didn't do pruning.  It would be way too
inefficient.

> On the other part of what you said -- namely that you have to 
> dig deeper 
> into
> the frame for multicast and VLAN pruning --- it was suggested, but
> not extensively discussed, to move the inner VLAN into the 
> TRILL header
> so that VLAN pruning would not need to be done by finding the 
> inner frame.
> 
> This would still require an RBridge in the core to look 
> inside to find the
> inner frame in order to look at the multicast address.
> 
> There are two ways I can think of to avoid this:
> a) move the multicast address into the inner frame, perhaps 
> as an option in
> the TRILL header
> b) use the multicast address in the inner frame as the destination 
> address in the outer
> header.

Moving the multicast address to the outer
header doesn't really help in terms of 
implementation since the look ups required
stay the same.  It might help from an 
architecture standpoint, but even that
I don't really see.

Essentially, we need both the inner VLAN and the
MAC DA to make their way into the TRILL header
so that they can be consulted for forwarding.
But doing so would unnecessarily add to the 
frame overhead.

Perhaps what is defined is as good as it
gets.  :-)

Somewhat off topic -
I now recall why the statement about "problems 
with learning when doing multipathing" was put
into the TRILL routing requirements document.
In the early days of TRILL, IIRC RBridges 
were going to just forward unicast frames without
an encapsulation header.  In that case, if
one had RBridges and regular bridges intermixed
in a network and had ECMP running in the RBridges,
we'd run into problems with address learning.

Anoop



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l57I0jte007514 for <[e-mail]>; Thu, 7 Jun 2007 11:00:45 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 07 Jun 2007 11:00:36 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EBBD52AF; Thu, 7 Jun 2007 11:00:35 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D2A332AE; Thu, 7 Jun 2007 11:00:35 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FIZ57442; Thu, 7 Jun 2007 11:00:29 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id F034469CA7; Thu, 7 Jun 2007 11:00:28 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 7 Jun 2007 11:00:27 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] multicast pruning in TRILL
Thread-Index: AcepLAlVROrKhPahSz+Jf/sm5JbudQAAQqdQ
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Anoop Ghanwani" <[e-mail]>
X-WSS-ID: 6A76984E37040859473-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l57I0jte007514
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 18:00:52 -0000
Status: RO
Content-Length: 1477

[e-mail] wrote:
> Re: Is multicast pruning a MAY or MUST:
> 
> I'm not sure there's been enough opinion voiced to have a consensus
> on this. I'd be happy with MAY or SHOULD, since it really it just an
> optimization. 
> 
> On the other part of what you said -- namely that you have to
> dig deeper into the frame for multicast and VLAN pruning ---
> it was suggested, but not extensively discussed, to move the
> inner VLAN into the TRILL header so that VLAN pruning would
> not need to be done by finding the inner frame.
> 
> This would still require an RBridge in the core to look
> inside to find the inner frame in order to look at the multicast
> address. 
> 
> There are two ways I can think of to avoid this:
> a) move the multicast address into the inner frame, perhaps
> as an option in the TRILL header
> b) use the multicast address in the inner frame as the
> destination address in the outer header.
> 
> I rather like the notion of moving stuff that RBridges need
> to look at into the outer header or TRILL header.
> 
> But this would need to be discussed, and hopefully soon.
> 
> Radia
> 

I can see some value in moving RBridge-relevant fields earlier
in the overall packet, but I would want to avoid any and all
risks of doing so in a way where the semantics of those fields
did not remain fully under the IEEE and/or that would require
product to implement the same logic twice. Leaving them where
they are totally avoids such risks.





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 l57HX9Po000271 for <[e-mail]>; Thu, 7 Jun 2007 10:33:09 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 07 Jun 2007 10:32:52 -0700 (PDT)
Received: from [127.0.0.1] ([129.150.19.144]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 07 Jun 2007 10:32:52 -0700 (PDT)
Date: Thu, 07 Jun 2007 10:33:29 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Anoop Ghanwani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 17:33:25 -0000
Status: RO
Content-Length: 2162

Re: Is multicast pruning a MAY or MUST:

I'm not sure there's been enough opinion voiced to have a consensus on this.
I'd be happy with MAY or SHOULD, since it really it just an optimization.

On the other part of what you said -- namely that you have to dig deeper 
into
the frame for multicast and VLAN pruning --- it was suggested, but
not extensively discussed, to move the inner VLAN into the TRILL header
so that VLAN pruning would not need to be done by finding the inner frame.

This would still require an RBridge in the core to look inside to find the
inner frame in order to look at the multicast address.

There are two ways I can think of to avoid this:
a) move the multicast address into the inner frame, perhaps as an option in
the TRILL header
b) use the multicast address in the inner frame as the destination 
address in the outer
header.

I rather like the notion of moving stuff that RBridges need to look at 
into the
outer header or TRILL header.

But this would need to be discussed, and hopefully soon.

Radia



Anoop Ghanwani wrote:
> Per Section 3.5 of the Rbridge Base Protocol
> Specification, it looks like the trees computed
> by the ISIS base instance need to be pruned 
> based on VLAN/IGMP membership information.
>
> Also, in order to actually make use of the 
> pruning information when forwarding frames 
> in a TRILL device, it looks like one would 
> have to consult the inner L2 header of the 
> frame to extract the inner VLAN and inner
> MAC DA (the latter is needed for multicast).
>
> In some sense TRILL is creating a tunnel,
> and yet we need to dig deeper than the tunnel
> headers in order to accomplish forwarding.
> It also lacks consistency in that unicasts
> are forwarded based on the RBridge destination
> address and multicasts are forwarded based
> on the inner MAC DA and VLAN.
>
> If pruning was not a requirement we would
> not have this issue.
>
> Is the pruning functionality a requirement
> (MUST) or a recommendation (MAY)?
>
> Thanks,
> Anoop
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l573wUPg015400 for <[e-mail]>; Wed, 6 Jun 2007 20:58:31 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-153.messagelabs.com!1181188709!1090357!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 15350 invoked from network); 7 Jun 2007 03:58:29 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 7 Jun 2007 03:58:29 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l573wPBI005776 for <[e-mail]>; Wed, 6 Jun 2007 20:58:29 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l573wPWh004918 for <[e-mail]>; Wed, 6 Jun 2007 22:58:25 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l573wO08004903 for <[e-mail]>; Wed, 6 Jun 2007 22:58:24 -0500 (CDT)
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, 6 Jun 2007 23:58:22 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] multicast pruning in TRILL
thread-index: AceognxFTBROZCdOSf6LyzvXWQIWSgALBKxQ
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l573wUPg015400
Cc: [e-mail]
Subject: Re: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 03:59:10 -0000
Status: RO
Content-Length: 3459

Hi Anoop,

See below at @@@

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 06, 2007 5:35 PM
To: [e-mail]
Subject: [rbridge] multicast pruning in TRILL

Per Section 3.5 of the Rbridge Base Protocol
Specification, it looks like the trees computed
by the ISIS base instance need to be pruned 
based on VLAN/IGMP membership information.

Also, in order to actually make use of the 
pruning information when forwarding frames 
in a TRILL device, it looks like one would 
have to consult the inner L2 header of the 
frame to extract the inner VLAN and inner
MAC DA (the latter is needed for multicast).

In some sense TRILL is creating a tunnel,
and yet we need to dig deeper than the tunnel
headers in order to accomplish forwarding.

@@@ Certainly, the encapsulated ingress to egress Rbridge transport is a
tunnel.

@@@ Indeed, for precisely the reason you give, it was and remains my
strong personal opinion that the VLAN-tag information should be part of
the TRILL Header where it would be at least 14 bytes earlier and you
would also save the 2 bytes of tag Ethertype. It contains priority as
well as the VLAN ID info.

@@@ However, the working group appears to be of the opinion that the
VLAN-tag should be inserted inside the inner frame with an Ethertype.
See the May mail here which includes arguments on the other side of the
issue:
http://www.postel.org/pipermail/rbridge/2007-May/thread.html.

It also lacks consistency in that unicasts
are forwarded based on the RBridge destination
address and multicasts are forwarded based
on the inner MAC DA and VLAN.

@@@ There really isn't any inconsistency. The egress Rbridge for a
known-unicast frame is determined by using the destination MAC address
and the VLAN ID. It is just that for unicast, this can all be factored
into the selection of one relevant egress Rbridge and no in transit
pruning is needed. On the other hand, for multicast/broadcast, you could
theoretically have the ingress Rbridge determine and unicast to all the
relevant egress Rbridges, but that doesn't scale very well :-) So you
flood the frame but need to consult the destination address and VLAN for
pruning along the way so it only gets to relevant egress RBridges. For
both known-unicast and multi-destination frames, the frame passes
through transit Rbridges based on IS-IS adjacency and optimization
regardless of VLAN.

If pruning was not a requirement we would
not have this issue.

Is the pruning functionality a requirement
(MUST) or a recommendation (MAY)?

@@@ On the question of VLAN pruning and IP multicast pruning
implementation requirements, they can be considered separate questions
and there has been substantial discussion of them. I believe that VLAN
pruning should have an equal or higher level of implementation
requirement as IP multicast pruning and it is my impression that
"SHOULD" would be a reasonable implementation requirement for both of
these. 

@@@ Rbridges would, in some sense, operate "correctly" if there were no
pruning of multi-destination frames but you could be talking about
several orders of magnitude of inefficiency. If you were going to do
that, maybe you should consider being ultra consistent and just flooding
all frames, including unicast; after all, destination Rbridges that
don't need the frames can always throw them away. :-)

Thanks,
Anoop

@@@ Thanks,
@@@ Donald



Received: from mx20.brocade.com (66-243-153-19.focaldata.net [66.243.153.19] (may be forged)) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l56LYipL013764 for <[e-mail]>; Wed, 6 Jun 2007 14:34:44 -0700 (PDT)
Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 06 Jun 2007 14:34:43 -0700
X-IronPort-AV: i="4.16,390,1175497200";  d="scan'208"; a="10880874:sNHT16049677"
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 493FB238370 for <[e-mail]>; Wed,  6 Jun 2007 14:32:38 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 6 Jun 2007 14:34:43 -0700
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, 6 Jun 2007 14:34:38 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: multicast pruning in TRILL
Thread-Index: AceognxFTBROZCdOSf6LyzvXWQIWSg==
From: "Anoop Ghanwani" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 06 Jun 2007 21:34:43.0113 (UTC) FILETIME=[7EDF5990:01C7A882]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l56LYipL013764
Subject: [rbridge] multicast pruning in TRILL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2007 21:35:16 -0000
Status: RO
Content-Length: 899

Per Section 3.5 of the Rbridge Base Protocol
Specification, it looks like the trees computed
by the ISIS base instance need to be pruned 
based on VLAN/IGMP membership information.

Also, in order to actually make use of the 
pruning information when forwarding frames 
in a TRILL device, it looks like one would 
have to consult the inner L2 header of the 
frame to extract the inner VLAN and inner
MAC DA (the latter is needed for multicast).

In some sense TRILL is creating a tunnel,
and yet we need to dig deeper than the tunnel
headers in order to accomplish forwarding.
It also lacks consistency in that unicasts
are forwarded based on the RBridge destination
address and multicasts are forwarded based
on the inner MAC DA and VLAN.

If pruning was not a requirement we would
not have this issue.

Is the pruning functionality a requirement
(MUST) or a recommendation (MAY)?

Thanks,
Anoop



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l52GRcHY002916 for <[e-mail]>; Sat, 2 Jun 2007 09:27:38 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-119.messagelabs.com!1180801657!15018266!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 13126 invoked from network); 2 Jun 2007 16:27:37 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 2 Jun 2007 16:27:37 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l52GRWiO022062 for <[e-mail]>; Sat, 2 Jun 2007 09:27:36 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l52GRWSk013525 for <[e-mail]>; Sat, 2 Jun 2007 11:27:32 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l52GRV5S013517 for <[e-mail]>; Sat, 2 Jun 2007 11:27:32 -0500 (CDT)
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: Sat, 2 Jun 2007 12:27:29 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How is an IS-IS packet differentiated from layer 3IS-IS, and TRILL-encapsulated data packets?
thread-index: Acei5NFuSBAvz1zmSiiKz+cpdkJSRwAAs+vQAAscLiAAhy8e4A==
References: <[e-mail]> <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Vontu: Pass
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l52GRcHY002916
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3IS-IS, and TRILL-encapsulated data packets?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 02 Jun 2007 16:27:44 -0000
Status: RO
Content-Length: 5032

Commenting on my own message, see below at @@@

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Wednesday, May 30, 2007 10:26 PM
To: [e-mail]
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer
3IS-IS, and TRILL-encapsulated data packets?

OK.

Well, based on the email with this subject, the working group seems
pretty happy with the solution where both TRILL encapsulated data and
TRILL IS-IS frames are indicated by the TRILL Ethertype and header with
one of the current two reserved bits used to distinguish these cases.

But, to allow for the possibility of learning end nodes via IS-IS, I
think we need to provide for a per VLAN TRILL IS-IS message. The
proposal seems to be that, if a Q-tag is present, then it is per VLAN,
otherwise it is a core TRILL IS-IS message.

So a per VLAN multicast TRILL IS-IS message would look like

Outer.DA - 6 bytes (All-Rbridges)
Outer.SA - 6 bytes (this hop SA)
TRILL-Ethertype - 2 bytes (tbd)
TRILL Header - 6 bytes (with "control message" and multi-destination
bits on)
Inner.DA - 6 bytes (All-Rbridges)
Inner.SA - 6 bytes (original SA)
Q-Ethertype - 2 bytes
Q-tag value - 2 bytes
Length - 2 bytes
IS-IS DSAP - 1 byte (0xFE)
IS-IS SSAP - 1 byte (0xFE)
CTL - 1 byte (0x03)
IS-IS payload - variable

A core TRILL IS-IS message would be the same but without the inner
Q-tag. (Also, for a core IS-IS message, the inner and outer SA would
always be the same.)

If the IS-IS message was unicast core, the outer and inner DA addresses
would be the unicast destination, there would be no inner Q-tag, and the
multi-destination bit would be off.

If the IS-IS message was unicast per VLAN, the outer DA would the "this
hop" DA, the inner DA would be the original DA, the Q-tab would be
present, and the multi-destination bit would be off.

In the TRILL header, for the per VLAN case, the Hop Count seems
meaningful. But the ingress and egress RBridge nicknames are not used
and, in fact, you need to send IS-IS Hellos before nicknames may have
been established. Basically, the TRILL data frame needs six addresses,
one pair each for the end stations, the ingress/egress Rbridges, and the
per hop Rbridges. But IS-IS control messages are only ever from one
Rbridge to another, so they only need four addresses in the per VLAN
case (and really only two addresses in the core case since they go only
one hop).

@@@ The above is incorrect with reference to per VLAN  multicast IS-IS
messages. In particular, you need to specify the distribution tree. For
consistency, it seems best to do this via the "egress Rbridge" field.
This means you really can't do per VLAN IS-IS until the nicknames are
settled, which is probably OK.

So it seems to me that the alternatives are to either
	(1) Leave the nickname fields unset or set to zero on
transmission and ignored on receipt or
	(2) Maybe add one of the reserved bits to the Version field and
re-name it "Variation" or something and have the 6 byte "Data" variation
as currently specified and the "IS-IS" variation which is just 2 bytes
because it does not have the nickname fields.

@@@ Making the Version field into a Variation field is really orthogonal
and may be a reasonable idea regardless.

@@@ Because the "egress Rbridge" field is needed to specify the
distribution tree for per VLAN multicast IS-IS messages, it seems
simpler to stick with the existing TRILL Header format for both data and
TRILL IS-IS messages.

@@@ Thanks,
@@@ Donald

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]] 
Sent: Wednesday, May 30, 2007 2:25 PM
To: Erik Nordmark
Cc: Radia Perlman; Eastlake III Donald-LDE008; [e-mail]
Subject: RE: [rbridge] How is an IS-IS packet differentiated from layer
3 IS-IS, and TRILL-encapsulated data packets?

Erik,

You are correct, I oversimplified the explanation, but the conclusion
still holds

-- Silvano

> -----Original Message-----
> From: Erik Nordmark [mailto:[e-mail]]
> Sent: Wednesday, May 30, 2007 11:02 AM
> To: Silvano Gai
> Cc: Radia Perlman; Eastlake III Donald-LDE008; [e-mail]
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from
layer 3
> IS-IS, and TRILL-encapsulated data packets?
> 
> Silvano Gai wrote:
> 
> > The advantage of using a reserved bit is that the frame with
Ethertype =
> TRILL already go through DR blocked ports. The non-TRILL IS-IS frames
will
> have Ethertype = ISIS and will be dropped by DR blocked ports.
> 
> I don't know if this matters, but AFAIK (and after checking RFC 1142),
> there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header
(i.e.
> a length field instead of an Ethertype field) followed by 3 bytes of
LLC
> header with the SAP 0xFE. Thus the 3 bytes after the length field is
03
> FE FE.
> 
>     Erik
> 


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