From anoop at brocade.com Sun Jul 1 13:27:14 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Sun, 1 Jul 2007 13:27:14 -0700 Subject: [rbridge] a clarification about the core IS-IS instance In-Reply-To: <3870C46029D1F945B1472F170D2D979002BCA205@de01exm64.ds.mot.com> References: <4C94DE2070B172459E4F1EE14BD2364E1CBA26@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D979002B8E79A@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364E1CBA6D@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D979002BC9A3E@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364E1CBA75@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D979002BC9B02@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA201AE5FBE@nuova-ex1.hq.nuovaimpresa.com><4C94DE2070B172459E4F1EE14BD2364E25FCE1@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D979002BCA205@de01exm64.ds.mot.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E25FE29@HQ-EXCH-5.corp.brocade.com> Donald, This does assume that the IS-IS instance used by TRILL uses an address (all-rbridges) that is different than that used today by IS-IS. Why can't we just get a separate address for this? That way, an all-rbridges address must never appear in the inner mac da field. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Friday, June 29, 2007 12:56 PM > To: rbridge at postel.org > Subject: Re: [rbridge] a clarification about the core IS-IS instance > > 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:anoop at brocade.com] > Sent: Friday, June 29, 2007 3:10 PM > To: Silvano Gai; Eastlake III Donald-LDE008 > Cc: rbridge at postel.org > 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:sgai at nuovasystems.com] > > Sent: Thursday, June 28, 2007 1:54 PM > > To: Eastlake III Donald-LDE008; Anoop Ghanwani > > Cc: rbridge at postel.org > > 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: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] > > On > > > Behalf Of Eastlake III Donald-LDE008 > > > Sent: Thursday, June 28, 2007 8:46 AM > > > To: Anoop Ghanwani > > > Cc: rbridge at postel.org > > > 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:anoop at brocade.com] > > > Sent: Thursday, June 28, 2007 10:34 AM > > > To: Eastlake III Donald-LDE008 > > > Cc: rbridge at postel.org > > > 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:Donald.Eastlake at motorola.com] > > > > Sent: Thursday, June 28, 2007 7:30 AM > > > > To: Anoop Ghanwani > > > > Cc: rbridge at postel.org > > > > 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:anoop at brocade.com] > > > > Sent: Thursday, June 28, 2007 10:00 AM > > > > To: Eastlake III Donald-LDE008 > > > > Cc: rbridge at postel.org > > > > 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:Donald.Eastlake at motorola.com] > > > > > Sent: Wednesday, June 27, 2007 9:09 PM > > > > > To: Anoop Ghanwani > > > > > Cc: rbridge at postel.org > > > > > 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: rbridge-bounces at postel.org > > > > > [mailto:rbridge-bounces at postel.org] On Behalf Of > Anoop Ghanwani > > > > > Sent: Wednesday, June 27, 2007 9:42 PM > > > > > To: rbridge at postel.org > > > > > 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 > > > rbridge at postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Sun Jul 1 13:29:35 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Sun, 1 Jul 2007 13:29:35 -0700 Subject: [rbridge] a clarification about the core IS-IS instance In-Reply-To: <4685E994.5040404@sun.com> References: <4C94DE2070B172459E4F1EE14BD2364E1CBA26@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D979002B8E79A@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E1CBA6D@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D979002BC9A3E@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E1CBA75@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D979002BC9B02@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201AE5FBE@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E25FCE1@HQ-EXCH-5.corp.brocade.com> <4685E994.5040404@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E25FE2A@HQ-EXCH-5.corp.brocade.com> Radia, I would prefer a separate multicast address. I think Silvano also said he would prefer it that way. It makes things a lot simple from a parsing/frame validation standpoint. Anoop > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Friday, June 29, 2007 10:27 PM > To: Anoop Ghanwani > Cc: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org > Subject: Re: [rbridge] a clarification about the core IS-IS instance > > 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:sgai at nuovasystems.com] > >> Sent: Thursday, June 28, 2007 1:54 PM > >> To: Eastlake III Donald-LDE008; Anoop Ghanwani > >> Cc: rbridge at postel.org > >> 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: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] > >>> > >> On > >> > >>> Behalf Of Eastlake III Donald-LDE008 > >>> Sent: Thursday, June 28, 2007 8:46 AM > >>> To: Anoop Ghanwani > >>> Cc: rbridge at postel.org > >>> 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:anoop at brocade.com] > >>> Sent: Thursday, June 28, 2007 10:34 AM > >>> To: Eastlake III Donald-LDE008 > >>> Cc: rbridge at postel.org > >>> 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:Donald.Eastlake at motorola.com] > >>>> Sent: Thursday, June 28, 2007 7:30 AM > >>>> To: Anoop Ghanwani > >>>> Cc: rbridge at postel.org > >>>> 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:anoop at brocade.com] > >>>> Sent: Thursday, June 28, 2007 10:00 AM > >>>> To: Eastlake III Donald-LDE008 > >>>> Cc: rbridge at postel.org > >>>> 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:Donald.Eastlake at motorola.com] > >>>>> Sent: Wednesday, June 27, 2007 9:09 PM > >>>>> To: Anoop Ghanwani > >>>>> Cc: rbridge at postel.org > >>>>> 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: rbridge-bounces at postel.org > >>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani > >>>>> Sent: Wednesday, June 27, 2007 9:42 PM > >>>>> To: rbridge at postel.org > >>>>> 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 > >>> rbridge at postel.org > >>> http://mailman.postel.org/mailman/listinfo/rbridge > >>> > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > From Donald.Eastlake at motorola.com Mon Jul 2 11:33:29 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 2 Jul 2007 14:33:29 -0400 Subject: [rbridge] a clarification about the core IS-IS instance In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E25FE29@HQ-EXCH-5.corp.brocade.com> References: <4C94DE2070B172459E4F1EE14BD2364E1CBA26@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D979002B8E79A@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364E1CBA6D@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D979002BC9A3E@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364E1CBA75@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D979002BC9B02@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA201AE5FBE@nuova-ex1.hq.nuovaimpresa.com><4C94DE2070B172459E4F1EE14BD2364E25FCE1@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D979002BCA205@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E25FE29@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D979002BCA650@de01exm64.ds.mot.com> Hi Anoop, See below at @@@ -----Original Message----- From: Anoop Ghanwani [mailto:anoop at brocade.com] Sent: Sunday, July 01, 2007 4:27 PM To: Eastlake III Donald-LDE008; rbridge at postel.org Subject: RE: [rbridge] a clarification about the core IS-IS instance Donald, This does assume that the IS-IS instance used by TRILL uses an address (all-rbridges) that is different than that used today by IS-IS. @@@ Right. That's what the current and all previous version of the Rbridge/TRILL protocol have assumed. You certainly wouldn't want to use the same multicast address as Layer-3 IS-IS because it would increase the chances for confusion between Layer 3 IS-IS messages and TRILL IS-IS messages. Why can't we just get a separate address for this? That way, an all-rbridges address must never appear in the inner mac da field. @@@ I don't understand what problem you are trying to solve. In the current protocol draft (-04), the inner MAC DA field is All-Rbridges if and only if it is a TRILL IS-IS frame. We could get a "separate" multicast address for this, say "All-TBD". Then the inner MAC DA field would be "All-TBD" if and only if it is a TRILL IS-IS frame. Why is it easier to check for one 48 bit value than another 48 bit value? @@@ I understood your previous statement to have mean that you would prefer a different multicast address to a TRILL Header bit. That's fine, assuming we have to make that choice. In fact, if the multicast addresses were consecutive, as seems likely, you are really just saying you would prefer a flag bit in the bottom bit of the multicast address to a flag bit in the TRILL Header. But it turns out we don't need a flag bit at all, in either place. So I just don't understand what the purpose of a second multicast address would be. @@@ I would have thought you would like the decision tree described below since (1) it uses the current TRILL Header fields as specified in the current draft and you have said you don't want to move any fields around, (2) it has no dependency on a TRILL Header "IS-IS" Flag or V field value, as you requested, (3) it uses only the fields that you listed as reasonable inputs to forwarding/processing decisions, and (4) it clearly works. @@@ Thanks, @@@ Donald Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Friday, June 29, 2007 12:56 PM > To: rbridge at postel.org > Subject: Re: [rbridge] a clarification about the core IS-IS instance > > 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:anoop at brocade.com] > Sent: Friday, June 29, 2007 3:10 PM > To: Silvano Gai; Eastlake III Donald-LDE008 > Cc: rbridge at postel.org > 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:sgai at nuovasystems.com] > > Sent: Thursday, June 28, 2007 1:54 PM > > To: Eastlake III Donald-LDE008; Anoop Ghanwani > > Cc: rbridge at postel.org > > 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: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] > > On > > > Behalf Of Eastlake III Donald-LDE008 > > > Sent: Thursday, June 28, 2007 8:46 AM > > > To: Anoop Ghanwani > > > Cc: rbridge at postel.org > > > 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:anoop at brocade.com] > > > Sent: Thursday, June 28, 2007 10:34 AM > > > To: Eastlake III Donald-LDE008 > > > Cc: rbridge at postel.org > > > 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:Donald.Eastlake at motorola.com] > > > > Sent: Thursday, June 28, 2007 7:30 AM > > > > To: Anoop Ghanwani > > > > Cc: rbridge at postel.org > > > > 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:anoop at brocade.com] > > > > Sent: Thursday, June 28, 2007 10:00 AM > > > > To: Eastlake III Donald-LDE008 > > > > Cc: rbridge at postel.org > > > > 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:Donald.Eastlake at motorola.com] > > > > > Sent: Wednesday, June 27, 2007 9:09 PM > > > > > To: Anoop Ghanwani > > > > > Cc: rbridge at postel.org > > > > > 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: rbridge-bounces at postel.org > > > > > [mailto:rbridge-bounces at postel.org] On Behalf Of > Anoop Ghanwani > > > > > Sent: Wednesday, June 27, 2007 9:42 PM > > > > > To: rbridge at postel.org > > > > > 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 > > > rbridge at postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Donald.Eastlake at motorola.com Tue Jul 3 07:51:19 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 3 Jul 2007 10:51:19 -0400 Subject: [rbridge] Inner/Outer versus Data/Transport Message-ID: <3870C46029D1F945B1472F170D2D979002BCA9BC@de01exm64.ds.mot.com> Hi, A terminology question has come up concerning the current use of Inner and Outer in the protocol specification. Currently these words are used in a way pretty close to their usual English meaning. When a frame is being transported inside a TRILL Header, the Ethernet header on the outside of the frame is called the Outer header and the one inside the envelope is called the Inner header. But, when talking about a native frame, what will become the Inner header when encapsulated is also called an Outer header, because it is on the outside of the native frame. This doesn't bother me and I suspect is fine for native English speakers because the inside/outside connotation of Inner and Outer override any problem with the same header fields being called Outer when they are at the start of a native frame and Inner when they are inside a TRILL envelope. However, some find this very confusing. For example, consider someone implementing an Rbridge where the VLAN associated with an incoming frame is considered meta data stored in a register/variable separate from but associated with the frame payload. (The VLAN might come from an Outer VLAN Tag or be assigned based on the port, etc.) What are you going to call this register/variable? If the incoming frame is a native frame then, if it is encapsulated, this VLAN tag information will appear in the "Inner VLAN" position. But if the frame is forwarded in native form to another local link, it will appear in the "Outer VLAN" position. So neither Inner nor Outer seems to be an appropriate name for this hypothetical register/variable. It has been suggested that "Inner" be changed to "Data" and "Outer" be changed to "Transport" for TRILL frames and to "Data" from native frames, or some similar change. I think that such naming would be reasonably clear and would have the effect that, for example, the Data VLAN Tag could be called that whether it appeared on the outside of a native frame or inside a TRILL envelope. I don't really care one way or the other and am soliciting working group opinion on this question. Thanks, Donald From touch at ISI.EDU Tue Jul 3 19:18:57 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 03 Jul 2007 19:18:57 -0700 Subject: [rbridge] Inner/Outer versus Data/Transport In-Reply-To: <3870C46029D1F945B1472F170D2D979002BCA9BC@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002BCA9BC@de01exm64.ds.mot.com> Message-ID: <468B0391.4020205@isi.edu> Eastlake III Donald-LDE008 wrote: > Hi, > > A terminology question has come up concerning the current use of Inner > and Outer in the protocol specification. > > Currently these words are used in a way pretty close to their usual > English meaning. When a frame is being transported inside a TRILL > Header, the Ethernet header on the outside of the frame is called the > Outer header and the one inside the envelope is called the Inner header. > But, when talking about a native frame, what will become the Inner > header when encapsulated is also called an Outer header, because it is > on the outside of the native frame. > > This doesn't bother me and I suspect is fine for native English speakers > because the inside/outside connotation of Inner and Outer override any > problem with the same header fields being called Outer when they are at > the start of a native frame and Inner when they are inside a TRILL > envelope. > > However, some find this very confusing. For example, consider someone > implementing an Rbridge where the VLAN associated with an incoming frame > is considered meta data stored in a register/variable separate from but > associated with the frame payload. (The VLAN might come from an Outer > VLAN Tag or be assigned based on the port, etc.) What are you going to > call this register/variable? If the incoming frame is a native frame > then, if it is encapsulated, this VLAN tag information will appear in > the "Inner VLAN" position. But if the frame is forwarded in native form > to another local link, it will appear in the "Outer VLAN" position. So > neither Inner nor Outer seems to be an appropriate name for this > hypothetical register/variable. > > It has been suggested that "Inner" be changed to "Data" and "Outer" be > changed to "Transport" for TRILL frames and to "Data" from native > frames, or some similar change. Transport has a meaning in the IETF, and this isn't it - even when encapsulated, the inner header isn't the transport header. > I think that such naming would be > reasonably clear and would have the effect that, for example, the Data > VLAN Tag could be called that whether it appeared on the outside of a > native frame or inside a TRILL envelope. > > I don't really care one way or the other and am soliciting working group > opinion on this question. I think the terms we have are fine, and that diagrams that clarify what they mean are sufficient. Introducing new terms is as likely to cause confusion with the currently non-confused as it would be to resolve confusion in the confused. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070703/22a67160/signature.bin From erik.nordmark at sun.com Thu Jul 5 09:05:35 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Thu, 05 Jul 2007 09:05:35 -0700 Subject: [rbridge] IS-IS Consensus Call, Routing Requirements Document Message-ID: <468D16CF.9020105@sun.com> There hasn't been any objection to this, thus we declare WG consensus for - Selecting IS-IS is the routing protocol to be used by TRILL - Moving the key points from the Routing Requirements into the Architecture document, and removing the Routing Requirements document from our set of milestones. Erik & Donald -------- Original Message -------- Subject: [rbridge] IS-IS Consensus Call, Routing Requirements Document Date: Mon, 18 Jun 2007 12:52:14 -0400 From: Eastlake III Donald-LDE008 To: Rbridge at postel.org 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 _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Internet-Drafts at ietf.org Tue Jul 10 13:15:01 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue, 10 Jul 2007 16:15:01 -0400 Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-05.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-05.txt -------------- next part -------------- From Donald.Eastlake at motorola.com Wed Jul 11 20:32:43 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 11 Jul 2007 23:32:43 -0400 Subject: [rbridge] Preliminary Agenda for Chicago Message-ID: <3870C46029D1F945B1472F170D2D979002C5B936@de01exm64.ds.mot.com> Hi, We're getting this up a bit later than usual but there is a preliminary draft agenda for the TRILL meeting at the 69th IETF meeting in Chicago linked from the meeting materials page at https://datatracker.ietf.org/meeting/69/materials.html. Anyone wishing to make a presentation or with an idea or request for the agenda, please post to this list or send to . We can update the posted agenda for a few more days. You might find the various pointers at http://tools.ietf.org/wg/trill/ useful. Thanks, Donald From Internet-Drafts at ietf.org Thu Jul 12 11:15:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Thu, 12 Jul 2007 14:15:02 -0400 Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-03.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-trill-rbridge-arch-03.txt -------------- next part -------------- From eric.gray at ericsson.com Wed Jul 18 10:21:25 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Wed, 18 Jul 2007 12:21:25 -0500 Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-03.txt In-Reply-To: References: Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0140BABB@eusrcmw721.eamcs.ericsson.se> Folks, This version of the Architecture draft reflects efforts since the last meeting to align terminology among the various WG drafts. A later version is yet to be written in which this draft will be revised to: 1) reduce discussions relating to protocol - or implementation - specific details and continue the alignment efforts (with the protocol specification in particular); 2) incorporate one or two concepts, discussion points and figures that it is felt should be moved from the protocol specification to the architecture document; 3) incorporate one or two of the ideas previously included in the routing requirements draft, and remove the current reference to that (now defunct) draft. Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of > Internet-Drafts at ietf.org > Sent: Thursday, July 12, 2007 2:15 PM > To: i-d-announce at ietf.org > Cc: rbridge at postel.org > Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-03.txt > > 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 : The Architecture of an RBridge > Solution to TRILL > Author(s) : E. Gray > Filename : draft-ietf-trill-rbridge-arch-03.txt > Pages : 35 > Date : 2007-7-12 > > RBridges are link layer (L2) devices that use routing protocols > as a control plane. They combine several of the > benefits of the > link layer with network layer routing benefits. RBridges use > existing link state routing (without requiring > configuration) to > improve RBridge to RBridge aggregate throughput. > RBridges also > > provide support for IP multicast and IP address resolution > optimizations. They are intended to be applicable to > similar L2 > network sizes as conventional bridges and are intended to be > backward compatible with those bridges as both ingress/egress > and transit. They also support VLANs (although this generally > requires configuration) and otherwise attempt to > retain as much > 'plug and play' as is already available in existing bridges. > This document proposes an RBridge system as a solution to the > TRILL problem. It also defines the RBridge > architecture, defines > its terminology, and describes basic components and desired > behavior. One or more separate documents specify the > protocols > and mechanisms that satisfy the architecture presented herein. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-a > rch-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org 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-arch-03.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: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-trill-rbridge-arch-03.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. > From townsley at cisco.com Thu Jul 26 08:55:52 2007 From: townsley at cisco.com (Mark Townsley) Date: Thu, 26 Jul 2007 10:55:52 -0500 Subject: [rbridge] [Fwd: IETF Streaming] Message-ID: <46A8C408.8090003@cisco.com> FYI about audio recordings... And the archive is here: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ ftp://limestone.uoregon.edu/pub/videolab/media/ietf69/ -------- Original Message -------- Subject: IETF Streaming Date: Fri, 20 Jul 2007 16:59:41 -0700 From: Joel Jaeggli To: IETF Discussion The webpage for the streaming has been updated to reflect the schedule for monday and tuesday. http://videolab.uoregon.edu/events/ietf/ One addition is that we intend to record and broadcast the Sunday IEPG meeting located in the crystal ballroom from 1000-1200 CDT. Regards Joel Jaeggli _______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf From Donald.Eastlake at motorola.com Thu Jul 26 14:12:37 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 26 Jul 2007 17:12:37 -0400 Subject: [rbridge] TRILL Meeting Materials for IETF-69 up to date Message-ID: <3870C46029D1F945B1472F170D2D979002D5D2C3@de01exm64.ds.mot.com> Hi, I've updated the TRILL meeting materials on the IETF-69th meeting materials page: https://datatracker.ietf.org/meeting/69/materials.html so that it shows what was actually presented in the order it was shown. Thanks, Donald From touch at ISI.EDU Fri Jul 27 13:31:43 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 27 Jul 2007 13:31:43 -0700 Subject: [rbridge] separating out the header spec Message-ID: <46AA562F.3010900@isi.edu> Hi, all, I spoke with Eric today, and came to an observation that might be useful to make explicit in the separation of the header spec from other parts of our protocols. In a sense, this ought to be a split that reflects the functional separation of the data plane from the control plane. Data plane - encapsulation headers, semantics of the fields, and forwarding operations based on the encapsulation headers Control plane - protocols used to setup state used by the data plane If that's the split, then I understand the utility and agree this is a useful way to get the data plane spec out more quickly. Can anyone who was strongly in favor of the split let me know if this makes sense, or if they're thinking of something else? PS - there are other planes, as well, e.g., the management plane (MIBs), and the one I hope we can avoid in these discussions (the customer plane ;-) Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070727/a787cef2/signature.bin From Donald.Eastlake at motorola.com Sat Jul 28 12:51:03 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 28 Jul 2007 15:51:03 -0400 Subject: [rbridge] Results from the Chicago TRILL Meeting Message-ID: <3870C46029D1F945B1472F170D2D979002D97B5D@de01exm64.ds.mot.com> Hi everyone, I believe we had some very productive TRILL meetings at the Chicago IETF last week. There were some tentative consensuses arrived at which Erik Nordmark and I will be confirming by posting them to the list and some issues discussed which did not appear to be resolved at the meeting and which probably need further discussion on the list. As we get the minutes together from the meeting, Erik or I will be posting these issues/decisions to the list with some effort to make different threads / subject lines for the different issues. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) 111 Locke Drive +1-508-333-2270 (cell) Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Donald.Eastlake at motorola.com Sat Jul 28 20:43:17 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 28 Jul 2007 23:43:17 -0400 Subject: [rbridge] Addition of "Other Multicast" bit to the Multicast Router Attached Bits Message-ID: <3870C46029D1F945B1472F170D2D979002D97B79@de01exm64.ds.mot.com> In the base protocol draft -05 there are two multicast router attachment bits. The tentative consensus at the TRILL meeting last week was to add a third bit so the situation would be as follows: o There are 3 bits in TRILL IS-IS LSPs that appear per VLAN per Rbridge. They are named "Other Multicast (OM)", "IPv4 attached multicast router (MR4)", and "IPv6 attached multicast router (MR6)". o When these bits are set, they cause all multicast frames for the appropriate VLAN to be sent to the Rbridge with the bit on for IPv4 derived multicast (MR4), IPv6 derived multicast (MR6), or all other multicast (OM). (Even if the MR4 or MR6 bit is off, multicast data frames are still sent to the Rbridge if multicast listeners for that data are reported by the Rbridge.) o MR4 is set by an RBridge when it, as Designated Rbridge (DRB), receives a native IGMP Query or IPv4 MRD Report on a port. (As per the relevant RFCs, the bit times out and is cleared unless repeatedly set.) This is an IGMP-snooping action. If an RBridge doesn't support this IGMP-snooping action, it always sets this bit to 1. o MR6 is set by an RBridge when it, as DRB, receives a native MLD Query or IPv6 MRD Report on port. This is an MLD-snooping action. (As per the relevant RFCs, the bit times out and is cleared unless repeatedly set.) If an RBridge doesn't support this MLD-snooping action, it always sets this bit to 1. o OM can't be set by dynamic signaling since non-IPv4/IPv6 derived multicast frames have no widely deployed signaling mechanism. It's value is set by either configuration or deciding on a default setting. o The recommendation is to default the 3 bits to {1,0,0} for {OM,MR4,MR6} respectively for Rbridges that implement IP derived multicast snooping. This causes all non-IPv4/IPv6 (other) multicast frames to be flooded to such RBridges and snooping protocols can set the MR4 and MR6 bits conditionally. For Rbridges that do not implement IP derived multicast snooping, the bits should default to (1,1,1). Thanks, Donald From james.d.carlson at sun.com Mon Jul 30 04:33:23 2007 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 30 Jul 2007 07:33:23 -0400 Subject: [rbridge] Addition of "Other Multicast" bit to the Multicast Router Attached Bits In-Reply-To: <3870C46029D1F945B1472F170D2D979002D97B79@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002D97B79@de01exm64.ds.mot.com> Message-ID: <18093.52355.105717.99252@gargle.gargle.HOWL> Eastlake III Donald-LDE008 writes: > In the base protocol draft -05 there are two multicast router attachment > bits. The tentative consensus at the TRILL meeting last week was to add > a third bit so the situation would be as follows: [...] This result sounds good to me. Thanks for the update. -- James Carlson, Solaris Networking 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 From Radia.Perlman at sun.com Mon Jul 30 19:14:37 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 30 Jul 2007 19:14:37 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags Message-ID: <46AE9B0D.4080606@sun.com> I had a conversation with Anoop, and he is (quite understandably) uneasy about sending IS-IS Hellos tagged with every VLAN. So he made the following suggestion, which I think makes sense. a) declare that bridges must be configured so that VLAN 1 (default VLAN) must not be partitioned on a layer 2 cloud. We will detect the misconfiguration if it occurs (see d)) so that we at least do not have loops, but TRILL will not stand on its head to support what will be declared a gross misconfiguration. b) Run the IS-IS election tagged with VLAN 1. Each RBridge has the following information in its IS-IS Hello: . I am R1 . I hear Hellos from {R2, R3, R7, R11} . If I am DRB, the pseudonode name will be R1.59 . My priority for the set of VLANs {A, D, W} is 7 . My priority for the set of VLANs {B, C, F, G, H} is 3 c) If R1 becomes DRB for at least one of the VLANs on the cloud, then R1 announces, in R1's LSP on behalf of pseudonode R1.59, the ID of the root bridge on the primary spanning tree instance for that layer 2 cloud, along with the set of VLANs for which R1 is DRB on that cloud. Note: The current draft spec isn't clear what information R1 reports in the pseudonode LSP and what it reports in its own LSP. I'm suggesting reporting the bridge ID and set of VLANs in the pseudonode LSP. d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A listed as one of the VLANs, this indicates that VLAN 1 on that layer 2 cloud is partitioned. So one of R1 or R2 should stop forwarding data to/from that cloud for VLAN A. Use ID as a tie breaker, so if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN A traffic to and from the port that has root bridge r11. This is the behavior that will occur if VLAN 1 on that port is actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would have seen each other's Hellos and not both think they are DRB for VLAN A (or any other VLAN). e) This proposal supports multiple DRBs on a cloud for load splitting based on VLANs, since the RBridges can have different priorities for different VLANs. It still requires only sending one Hello, tagged with VLAN 1. R2 should not panic if R2 notices that R1.59 has the same root bridge as on a port on which R2 is DRB, if R1.59's listed set of VLANs does not include any VLANs for which R2 is DRB on the link with that root bridge. If there is only partial overlap of VLAN IDs, say the overlap is VLANs {D, F, and H}, then (the loser based on ID tie-breaker) will stop forwarding traffic to/from that link that is tagged with VLANs D, F, or H. f) If some VLAN, say VLAN C, is actually partitioned, then the result of this is that some VLAN C endnodes on that layer 2 cloud will be orphaned. We will choose NOT to solve that. The result of this proposal is that RBridges will only need to send IS-IS Hellos tagged with VLAN 1, and the only thing it does NOT solve (over the current proposal of sending Hellos with every possible VLAN tag on each port) is that sometimes endnodes might get orphaned if you have a partitioned VLAN. We *could* in that case, if someone *actually wanted* to have VLAN A partitioned on that cloud, configure the RBridges on that layer 2 cloud to explicitly run a different election for VLAN A (and note in the pseudonode LSP that VLAN A had an explicit election tagged with VLAN A so that if there were two DRBs they wouldn't panic). But I'd prefer not solving this case and keeping it simpler (and safer). Radia From sgai at nuovasystems.com Tue Jul 31 08:38:43 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Tue, 31 Jul 2007 08:38:43 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <46AE9B0D.4080606@sun.com> References: <46AE9B0D.4080606@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> Radia, The fact that VLAN 1 (or any other VLANs) is partitioned is NOT a misconfiguration. It is a reality in today networks. TRILL cannot change this. I disagree with this proposal. I think we should stick with the current design that works in any configuration. When we will gain implementation and deployment experience we will optimize. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Monday, July 30, 2007 7:15 PM > To: rbridge at postel.org > Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with > allthe VLAN tags > > I had a conversation with Anoop, and he is (quite understandably) > uneasy about sending IS-IS Hellos tagged with every VLAN. So he > made the following suggestion, which I think makes sense. > > a) declare that bridges must be configured > so that VLAN 1 (default VLAN) must not be > partitioned on a layer 2 cloud. We will detect the misconfiguration > if it occurs (see d)) so that we at least do not have loops, but TRILL > will not > stand on its head to support what will be declared a gross > misconfiguration. > > b) Run the IS-IS election tagged with VLAN 1. Each RBridge has > the following information in its IS-IS Hello: > > . I am R1 > . I hear Hellos from {R2, R3, R7, R11} > . If I am DRB, the pseudonode name will be R1.59 > . My priority for the set of VLANs {A, D, W} is 7 > . My priority for the set of VLANs {B, C, F, G, H} is 3 > > c) If R1 becomes DRB for at least one of the VLANs on the cloud, > then R1 announces, in R1's LSP on behalf of pseudonode R1.59, > the ID of the root bridge on the primary spanning tree > instance for that layer 2 cloud, along with the set of VLANs for which > R1 is DRB on that cloud. > > Note: The current draft spec isn't clear what information R1 reports in > the pseudonode > LSP and what it reports in its own LSP. > I'm suggesting reporting the bridge ID and > set of VLANs in the pseudonode LSP. > > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, > and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A > listed as one of the VLANs, this indicates that VLAN 1 on that layer > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding > data to/from that cloud for VLAN A. Use ID as a tie breaker, so > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN > A > traffic to and from the port that has root bridge r11. > This is the behavior that will occur if VLAN 1 on that port is > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would > have seen each other's Hellos and not both think they are DRB for VLAN A > (or > any other VLAN). > > e) This proposal supports multiple DRBs on a cloud for load splitting > based on VLANs, since the RBridges can have different priorities > for different VLANs. It still requires only sending one Hello, tagged > with VLAN 1. R2 should > not panic if R2 notices that R1.59 has the same root bridge as on > a port on which R2 is DRB, if R1.59's listed set of VLANs does not > include any VLANs for which R2 is DRB on the link with > that root bridge. If there is only partial overlap > of VLAN IDs, say the overlap is VLANs {D, F, and H}, > then (the loser based on ID tie-breaker) will stop forwarding traffic > to/from that link that is tagged with VLANs D, F, or H. > > f) If some VLAN, say VLAN C, is actually partitioned, then the > result of this is that some VLAN C endnodes on that layer 2 cloud > will be orphaned. We will choose NOT to solve that. > > > The result of this proposal is that > RBridges will only need to send IS-IS Hellos tagged > with VLAN 1, and the only thing it does NOT solve (over > the current proposal of sending Hellos with every possible VLAN tag on > each port) is that sometimes endnodes might get orphaned if you have > a partitioned VLAN. > > > We *could* in that case, if someone *actually wanted* to have VLAN A > partitioned on that cloud, configure the RBridges on that layer 2 > cloud to explicitly run a different election > for VLAN A (and note in the pseudonode LSP that VLAN A had > an explicit election tagged with VLAN A so that if there were > two DRBs they wouldn't panic). But I'd prefer not solving this case and > keeping it simpler (and safer). > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Tue Jul 31 09:37:43 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 31 Jul 2007 09:37:43 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <46AF6557.2080109@sun.com> I'd like to understand what problem customers are attempting to solve with partitioned VLANs, and what hardship it would present to require at least one of the VLANs to *not* be partitioned. With TRILL, if a customer eventually replaces all bridges, the customer will not be able to partition VLANs anymore. Also, from what Anoop was explaining to me, the GVRP protocol would automatically configure the switch-to-switch links to join all the islands of VLANs. So it would seem as though it can't be that fatal to solving customer problems to require *one* VLAN on a layer 2 cloud to not be partitioned. I'd guess that most of the time partitioned VLANs would be a result of misconfiguration, or intentional configuration in one topology that becomes partitioning when the spanning tree reconfigures. The only thing I can imagine solve with intentionally partitioned VLANs is that the VLAN space is too small, so they have to reuse the same number in different parts of their cloud. In that case, I'd think a much cleaner solution would be expanding the size of the VLAN, which would be easy with TRILL. At any rate, everything involves tradeoffs. The plus side of the one-Hello-on-VLAN-1 proposal is simplicity and efficiency, since there only needs to be a single hello. So anyway---what problem are customers solving with intentionally partitioned VLANs on a layer 2 cloud? Radia Silvano Gai wrote: > Radia, > > The fact that VLAN 1 (or any other VLANs) is partitioned is NOT a > misconfiguration. It is a reality in today networks. TRILL cannot change > this. > > I disagree with this proposal. > > I think we should stick with the current design that works in any > configuration. When we will gain implementation and deployment > experience we will optimize. > > -- Silvano > > >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] >> > On > >> Behalf Of Radia Perlman >> Sent: Monday, July 30, 2007 7:15 PM >> To: rbridge at postel.org >> Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with >> allthe VLAN tags >> >> I had a conversation with Anoop, and he is (quite understandably) >> uneasy about sending IS-IS Hellos tagged with every VLAN. So he >> made the following suggestion, which I think makes sense. >> >> a) declare that bridges must be configured >> so that VLAN 1 (default VLAN) must not be >> partitioned on a layer 2 cloud. We will detect the misconfiguration >> if it occurs (see d)) so that we at least do not have loops, but TRILL >> will not >> stand on its head to support what will be declared a gross >> misconfiguration. >> >> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has >> the following information in its IS-IS Hello: >> >> . I am R1 >> . I hear Hellos from {R2, R3, R7, R11} >> . If I am DRB, the pseudonode name will be R1.59 >> . My priority for the set of VLANs {A, D, W} is 7 >> . My priority for the set of VLANs {B, C, F, G, H} is 3 >> >> c) If R1 becomes DRB for at least one of the VLANs on the cloud, >> then R1 announces, in R1's LSP on behalf of pseudonode R1.59, >> the ID of the root bridge on the primary spanning tree >> instance for that layer 2 cloud, along with the set of VLANs for which >> R1 is DRB on that cloud. >> >> Note: The current draft spec isn't clear what information R1 reports >> > in > >> the pseudonode >> LSP and what it reports in its own LSP. >> I'm suggesting reporting the bridge ID and >> set of VLANs in the pseudonode LSP. >> >> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge >> > r11, > >> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A >> listed as one of the VLANs, this indicates that VLAN 1 on that layer >> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding >> data to/from that cloud for VLAN A. Use ID as a tie breaker, so >> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding >> > VLAN > >> A >> traffic to and from the port that has root bridge r11. >> This is the behavior that will occur if VLAN 1 on that port is >> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 >> > would > >> have seen each other's Hellos and not both think they are DRB for VLAN >> > A > >> (or >> any other VLAN). >> >> e) This proposal supports multiple DRBs on a cloud for load splitting >> based on VLANs, since the RBridges can have different priorities >> for different VLANs. It still requires only sending one Hello, tagged >> with VLAN 1. R2 should >> not panic if R2 notices that R1.59 has the same root bridge as on >> a port on which R2 is DRB, if R1.59's listed set of VLANs does not >> include any VLANs for which R2 is DRB on the link with >> that root bridge. If there is only partial overlap >> of VLAN IDs, say the overlap is VLANs {D, F, and H}, >> then (the loser based on ID tie-breaker) will stop forwarding traffic >> to/from that link that is tagged with VLANs D, F, or H. >> >> f) If some VLAN, say VLAN C, is actually partitioned, then the >> result of this is that some VLAN C endnodes on that layer 2 cloud >> will be orphaned. We will choose NOT to solve that. >> >> >> The result of this proposal is that >> RBridges will only need to send IS-IS Hellos tagged >> with VLAN 1, and the only thing it does NOT solve (over >> the current proposal of sending Hellos with every possible VLAN tag on >> each port) is that sometimes endnodes might get orphaned if you have >> a partitioned VLAN. >> >> >> We *could* in that case, if someone *actually wanted* to have VLAN A >> partitioned on that cloud, configure the RBridges on that layer 2 >> cloud to explicitly run a different election >> for VLAN A (and note in the pseudonode LSP that VLAN A had >> an explicit election tagged with VLAN A so that if there were >> two DRBs they wouldn't panic). But I'd prefer not solving this case >> > and > >> keeping it simpler (and safer). >> >> Radia >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> From anoop at brocade.com Tue Jul 31 09:40:09 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 31 Jul 2007 09:40:09 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E3CAA75@HQ-EXCH-5.corp.brocade.com> Silvano, Dealing with partitioned VLANs will create all kinds of complexity. Even 802.1Q bridges don't really deal with that (assumming one is using something like GVRP/MVRP as required by the standard). It only works in 802.1Q devices if doing static configuration. We can always allow for that mode of operation as an option but the default should always be to treat the partitioned case as a mis- configuration. However, in the general case, I have to hunt for a VLAN in order to make sure my core IS-IS packets get through. And if there's a reconfiguration in the L2 topology, I might have to hunt for yet another VLAN (one that was previously partitioned but is now connected). Current design works in any configuration but it does not scale and it could take very long for the network to converge. I don't like having to send per-VLAN IS-IS hellos. It would require too much CPU power on the switch. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > Sent: Tuesday, July 31, 2007 8:39 AM > To: Radia Perlman; rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged withallthe VLAN tags > > Radia, > > The fact that VLAN 1 (or any other VLANs) is partitioned is NOT a > misconfiguration. It is a reality in today networks. TRILL > cannot change > this. > > I disagree with this proposal. > > I think we should stick with the current design that works in any > configuration. When we will gain implementation and deployment > experience we will optimize. > > -- Silvano > > > -----Original Message----- > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > On > > Behalf Of Radia Perlman > > Sent: Monday, July 30, 2007 7:15 PM > > To: rbridge at postel.org > > Subject: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged with > > allthe VLAN tags > > > > I had a conversation with Anoop, and he is (quite understandably) > > uneasy about sending IS-IS Hellos tagged with every VLAN. So he > > made the following suggestion, which I think makes sense. > > > > a) declare that bridges must be configured > > so that VLAN 1 (default VLAN) must not be > > partitioned on a layer 2 cloud. We will detect the misconfiguration > > if it occurs (see d)) so that we at least do not have > loops, but TRILL > > will not > > stand on its head to support what will be declared a gross > > misconfiguration. > > > > b) Run the IS-IS election tagged with VLAN 1. Each RBridge has > > the following information in its IS-IS Hello: > > > > . I am R1 > > . I hear Hellos from {R2, R3, R7, R11} > > . If I am DRB, the pseudonode name will be R1.59 > > . My priority for the set of VLANs {A, D, W} is 7 > > . My priority for the set of VLANs {B, C, F, G, H} is 3 > > > > c) If R1 becomes DRB for at least one of the VLANs on the cloud, > > then R1 announces, in R1's LSP on behalf of pseudonode R1.59, > > the ID of the root bridge on the primary spanning tree > > instance for that layer 2 cloud, along with the set of > VLANs for which > > R1 is DRB on that cloud. > > > > Note: The current draft spec isn't clear what information R1 reports > in > > the pseudonode > > LSP and what it reports in its own LSP. > > I'm suggesting reporting the bridge ID and > > set of VLANs in the pseudonode LSP. > > > > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge > r11, > > and R2 sees an LSP for R1.59 that has the same root bridge > and VLAN A > > listed as one of the VLANs, this indicates that VLAN 1 on that layer > > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding > > data to/from that cloud for VLAN A. Use ID as a tie breaker, so > > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding > VLAN > > A > > traffic to and from the port that has root bridge r11. > > This is the behavior that will occur if VLAN 1 on that port is > > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 > would > > have seen each other's Hellos and not both think they are > DRB for VLAN > A > > (or > > any other VLAN). > > > > e) This proposal supports multiple DRBs on a cloud for load > splitting > > based on VLANs, since the RBridges can have different priorities > > for different VLANs. It still requires only sending one > Hello, tagged > > with VLAN 1. R2 should > > not panic if R2 notices that R1.59 has the same root bridge as on > > a port on which R2 is DRB, if R1.59's listed set of VLANs does not > > include any VLANs for which R2 is DRB on the link with > > that root bridge. If there is only partial overlap > > of VLAN IDs, say the overlap is VLANs {D, F, and H}, > > then (the loser based on ID tie-breaker) will stop > forwarding traffic > > to/from that link that is tagged with VLANs D, F, or H. > > > > f) If some VLAN, say VLAN C, is actually partitioned, then the > > result of this is that some VLAN C endnodes on that layer 2 cloud > > will be orphaned. We will choose NOT to solve that. > > > > > > The result of this proposal is that > > RBridges will only need to send IS-IS Hellos tagged > > with VLAN 1, and the only thing it does NOT solve (over > > the current proposal of sending Hellos with every possible > VLAN tag on > > each port) is that sometimes endnodes might get orphaned if you have > > a partitioned VLAN. > > > > > > We *could* in that case, if someone *actually wanted* to have VLAN A > > partitioned on that cloud, configure the RBridges on that layer 2 > > cloud to explicitly run a different election > > for VLAN A (and note in the pseudonode LSP that VLAN A had > > an explicit election tagged with VLAN A so that if there were > > two DRBs they wouldn't panic). But I'd prefer not solving this case > and > > keeping it simpler (and safer). > > > > Radia > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From ddutt at cisco.com Tue Jul 31 10:16:50 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 31 Jul 2007 10:16:50 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags In-Reply-To: <46AE9B0D.4080606@sun.com> References: <46AE9B0D.4080606@sun.com> Message-ID: <46AF6E82.4000603@cisco.com> Hi Radia, Radia Perlman wrote: > I had a conversation with Anoop, and he is (quite understandably) > uneasy about sending IS-IS Hellos tagged with every VLAN. So he > made the following suggestion, which I think makes sense. > > a) declare that bridges must be configured > so that VLAN 1 (default VLAN) must not be > partitioned on a layer 2 cloud. We will detect the misconfiguration > if it occurs (see d)) so that we at least do not have loops, but TRILL > will not > stand on its head to support what will be declared a gross misconfiguration. > This will not fly. We originally had such a scheme a long time ago in our switches. We got so much flak from customers that we eventually had to back away from it. A single VLAN across the entire L2 cloud is unacceptable. Also the number of deployments using GVRP/MVRP/VTP is quite insignificant. A significant (if not most) number of customers have deliberately turned off running these protocols to manage VLANs. However, I'm sympathetic to Anoop's point and do think it is acceptable to partition the network in case of misconfiguration, but we MUST avoid loops at all costs. Let me think a little more, Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From ddutt at cisco.com Tue Jul 31 10:23:42 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 31 Jul 2007 10:23:42 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <46AF6557.2080109@sun.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> Message-ID: <46AF701E.1060609@cisco.com> Radia Perlman wrote: > I'd like to understand what problem customers are attempting to solve with > partitioned VLANs, and what hardship it would present to require at > least one of the > The primary problem with having a VLAN everywhere is that the root of the spanning tree moves around leading to non-optimal forwarding in enterprise networks. Enterprise networks are carefully engineered networks and in the event of failure, they want to localize the effects as much as possible. So, they want each VLAN to be localized and roots where they want it to be. Having a common VLAN messes up that arrangement. Also, VLAN 1 is the default VLAN when a switch comes up and there is typically lots of customer data on it. > VLANs to *not* be partitioned. With TRILL, if a customer eventually replaces > all bridges, the customer will not be able to partition VLANs anymore. > As I raised it in the meeting, this is a side-effect that has not been considered before and needs to be carefully thought through. I don't think many people are aware of this issue with TRILL that doesn't exist with 802.1Q bridges today. > Also, from > what Anoop was explaining to me, the GVRP protocol would automatically > configure the switch-to-switch links to join all the islands of VLANs. > So it would > seem as though it can't be that fatal to solving customer problems to > require > *one* VLAN on a layer 2 cloud to not be partitioned. > GVRP is not deployed by a significant majority of customers. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From ddutt at cisco.com Tue Jul 31 11:05:14 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 31 Jul 2007 11:05:14 -0700 Subject: [rbridge] Aging timer For MAC Entries Message-ID: <46AF79DA.5040102@cisco.com> Since the proposal to learn from data frames is the default mode in RBridges now, we must also mention how to age the MAC addresses learnt in the RBridge forwarding table; this includes MAC addresses learnt on directly attached local ports (local MACs) and those learnt about remote entities (remote MACs), containing the mapping of remote MAC address to RBridge nickname. The basic guideline is to follow the IEEE 802.1Q bridge standards. The 2005 version of the 802.1Q draft has the following to say (section 8.8.3) about entries learnt from data frames (called Dynamic Filtering entries in IEEE lingo): "The Ageing Time may be set by management (Clause 12). A range of applicable values and a recommended default is specified in Table 8-3; this is suggested to remove the need for explicit configuration in most cases. If the value of Ageing Time can be set by management, the Bridge shall have the capability to use values in the range specified, with a granularity of 1 s." Table 8-3 specifies that the recommended default value is 300s and that the range of allowed values is 10-1,000,000 secs. I recommend that we adopt the similar text and recommend the same range and default value. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From james.d.carlson at Sun.COM Tue Jul 31 10:57:17 2007 From: james.d.carlson at Sun.COM (James Carlson) Date: Tue, 31 Jul 2007 13:57:17 -0400 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <46AF701E.1060609@cisco.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> Message-ID: <18095.30717.327947.372266@gargle.gargle.HOWL> Dinesh G Dutt writes: > Radia Perlman wrote: > > I'd like to understand what problem customers are attempting to solve with > > partitioned VLANs, and what hardship it would present to require at > > least one of the > > > The primary problem with having a VLAN everywhere is that the root of > the spanning tree moves around leading to non-optimal forwarding in > enterprise networks. That shouldn't matter anymore with RBridges, right? One of the points of getting rid of STP is to get rid of the single root and the disappointing paths created when STP shuts down useful links. I understand the transition argument, but the idea of VLAN ID reuse seems hard enough to manage over time that it's harmful. Should we carry all of STP's baggage? -- James Carlson, Solaris Networking 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 From Radia.Perlman at sun.com Tue Jul 31 11:18:30 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 31 Jul 2007 11:18:30 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <46AF701E.1060609@cisco.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> Message-ID: <46AF7CF6.8090105@sun.com> I don't understand that problem. What you're describing might argue for bridges using a unique spanning tree per VLAN in order to optimize traffic flow for that VLAN, but I don't see what it has to do with wanting to partition VLANs. Radia Dinesh G Dutt wrote: > Radia Perlman wrote: >> I'd like to understand what problem customers are attempting to solve >> with >> partitioned VLANs, and what hardship it would present to require at >> least one of the >> > The primary problem with having a VLAN everywhere is that the root of > the spanning tree moves around leading to non-optimal forwarding in > enterprise networks. Enterprise networks are carefully engineered > networks and in the event of failure, they want to localize the > effects as much as possible. So, they want each VLAN to be localized > and roots where they want it to be. Having a common VLAN messes up > that arrangement. Also, VLAN 1 is the default VLAN when a switch comes > up and there is typically lots of customer data on it. >> VLANs to *not* be partitioned. With TRILL, if a customer eventually >> replaces >> all bridges, the customer will not be able to partition VLANs anymore. > As I raised it in the meeting, this is a side-effect that has not been > considered before and needs to be carefully thought through. I don't > think many people are aware of this issue with TRILL that doesn't > exist with 802.1Q bridges today. >> Also, from >> what Anoop was explaining to me, the GVRP protocol would automatically >> configure the switch-to-switch links to join all the islands of >> VLANs. So it would >> seem as though it can't be that fatal to solving customer problems to >> require >> *one* VLAN on a layer 2 cloud to not be partitioned. >> > GVRP is not deployed by a significant majority of customers. > > Dinesh > From sgai at nuovasystems.com Tue Jul 31 14:40:02 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Tue, 31 Jul 2007 14:40:02 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <46AF7CF6.8090105@sun.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> Radia, We are describing to you how VLANs are deployed today in Enterprise networks. You may say that "you don't like it", we may agree with you, but this does not change how they are deployed. For RBridges to be successful they need to be able to replace core bridges without messing up the existing network configurations. Today most customers do not deploy VLANs end-to-end and they do reuse VLANs number in different part of the enterprise. If RBridges are not capable of supporting this, they are not attractive. Remember that the #1 customer requirement we have for TRILL is: "replace core bridges with RBridges to enable Equal Cost Multi Path, all the rest MUST remain the same". GVRP is not deployed; I am not sure which customers Anoop is referring to. -- Silvano > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Tuesday, July 31, 2007 11:19 AM > To: Dinesh G Dutt > Cc: Silvano Gai; rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with > allthe VLAN tags > > I don't understand that problem. What you're describing might argue for > bridges using a unique > spanning tree per VLAN in order to optimize traffic flow for that VLAN, > but I don't > see what it has to do with wanting to partition VLANs. > > Radia > > > Dinesh G Dutt wrote: > > Radia Perlman wrote: > >> I'd like to understand what problem customers are attempting to solve > >> with > >> partitioned VLANs, and what hardship it would present to require at > >> least one of the > >> > > The primary problem with having a VLAN everywhere is that the root of > > the spanning tree moves around leading to non-optimal forwarding in > > enterprise networks. Enterprise networks are carefully engineered > > networks and in the event of failure, they want to localize the > > effects as much as possible. So, they want each VLAN to be localized > > and roots where they want it to be. Having a common VLAN messes up > > that arrangement. Also, VLAN 1 is the default VLAN when a switch comes > > up and there is typically lots of customer data on it. > >> VLANs to *not* be partitioned. With TRILL, if a customer eventually > >> replaces > >> all bridges, the customer will not be able to partition VLANs anymore. > > As I raised it in the meeting, this is a side-effect that has not been > > considered before and needs to be carefully thought through. I don't > > think many people are aware of this issue with TRILL that doesn't > > exist with 802.1Q bridges today. > >> Also, from > >> what Anoop was explaining to me, the GVRP protocol would automatically > >> configure the switch-to-switch links to join all the islands of > >> VLANs. So it would > >> seem as though it can't be that fatal to solving customer problems to > >> require > >> *one* VLAN on a layer 2 cloud to not be partitioned. > >> > > GVRP is not deployed by a significant majority of customers. > > > > Dinesh > > From anoop at brocade.com Tue Jul 31 16:06:03 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 31 Jul 2007 16:06:03 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com><46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com><46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E3CABAE@HQ-EXCH-5.corp.brocade.com> Hi Silvano, Believe it or not there are customers out there that use GVRP. They might not be a majority, but they do exist. As far as I'm aware, it is _not_ very common for customers to be reusing VLAN IDs within the enterprise. If they do reuse them, they are in physically separate portions of the network that are interconnected by routers. That's the normal tiered architecture that one tends to see in enterprises. I have never come across a customer that uses partitioned VLANs the way you mention, so I find it hard to believe they are common. There's always the oddball, strange architecture out there. Do we really need to force everyone to send per-VLAN hellos to deal with that? We can always design to make that type of configuration work, but we should optimize for the common case. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > Sent: Tuesday, July 31, 2007 2:40 PM > To: Radia Perlman; Dinesh G Dutt > Cc: rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged withallthe VLAN tags > > > Radia, > > We are describing to you how VLANs are deployed today in > Enterprise networks. You may say that "you don't like it", we > may agree with you, but this does not change how they are deployed. > > For RBridges to be successful they need to be able to replace > core bridges without messing up the existing network configurations. > > Today most customers do not deploy VLANs end-to-end and they > do reuse VLANs number in different part of the enterprise. If > RBridges are not capable of supporting this, they are not attractive. > > Remember that the #1 customer requirement we have for TRILL > is: "replace core bridges with RBridges to enable Equal Cost > Multi Path, all the rest MUST remain the same". > > GVRP is not deployed; I am not sure which customers Anoop is > referring to. > > -- Silvano > > > -----Original Message----- > > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > > Sent: Tuesday, July 31, 2007 11:19 AM > > To: Dinesh G Dutt > > Cc: Silvano Gai; rbridge at postel.org > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > with > > allthe VLAN tags > > > > I don't understand that problem. What you're describing might argue > for > > bridges using a unique > > spanning tree per VLAN in order to optimize traffic flow for that > VLAN, > > but I don't > > see what it has to do with wanting to partition VLANs. > > > > Radia > > > > > > Dinesh G Dutt wrote: > > > Radia Perlman wrote: > > >> I'd like to understand what problem customers are attempting to > solve > > >> with > > >> partitioned VLANs, and what hardship it would present to > require at > > >> least one of the > > >> > > > The primary problem with having a VLAN everywhere is that the root > of > > > the spanning tree moves around leading to non-optimal > forwarding in > > > enterprise networks. Enterprise networks are carefully engineered > > > networks and in the event of failure, they want to localize the > > > effects as much as possible. So, they want each VLAN to > be localized > > > and roots where they want it to be. Having a common VLAN > messes up > > > that arrangement. Also, VLAN 1 is the default VLAN when a switch > comes > > > up and there is typically lots of customer data on it. > > >> VLANs to *not* be partitioned. With TRILL, if a customer > eventually > > >> replaces all bridges, the customer will not be able to partition > > >> VLANs > anymore. > > > As I raised it in the meeting, this is a side-effect that has not > been > > > considered before and needs to be carefully thought > through. I don't > > > think many people are aware of this issue with TRILL that doesn't > > > exist with 802.1Q bridges today. > > >> Also, from > > >> what Anoop was explaining to me, the GVRP protocol would > automatically > > >> configure the switch-to-switch links to join all the islands of > > >> VLANs. So it would seem as though it can't be that fatal > to solving > > >> customer problems > to > > >> require > > >> *one* VLAN on a layer 2 cloud to not be partitioned. > > >> > > > GVRP is not deployed by a significant majority of customers. > > > > > > Dinesh > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Tue Jul 31 18:31:34 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 31 Jul 2007 18:31:34 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <46AFE276.1050601@sun.com> Silvano....I still don't know what problem customers are trying to solve with partitioned VLANs. If it's that they want more than 4000 VLANs, then the design we had (before Anoop's suggestion) also won't help them with that. If it is an important problem to use more than 4000 VLANs, we could (by extending the size of the VLAN tag within a TRILL campus) solve that problem in a much more robust, easily understandable way than configuring interswitch ports to block some VLANs. And I absolutely do not understand any other problems that might be solved with intentionally partitioning VLANs, and it's impossible to design something without understand the problem that needs to be solved. We do have to carefully consider what "breaks" (in the proposal we are currently considering) if a customer does actually configure bridges in some layer 2 cloud so that VLAN 1 is partitioned. I believe the only consequence of a customer configuring bridges so that VLAN 1 is partitioned in some layer 2 cloud is that core RBridges that might have connectivity to each other through some VLAN other than VLAN 1 will not realize they are adjacent, and will therefore not form IS-IS adjacencies, which means fewer RBridge-RBridge links in the core than there might actually be. This might actually cause the campus to get partitioned (since the only connectivity between RBridges will be using VLAN 1, and if all the links in the cut set require an outer tag of other than 1 in order for RBridges to talk, these links won't be found or used). It might cause less good paths. However, it will *not* cause loops, because if there is no connectivity for flooding of LSPs, data also won't flow in the core. The advantage of this proposal is simplicity and scalability -- only one Hello per port. As I said, I cannot understand what functionality is lost if all switch ports within a layer 2 cloud must be configured to pass VLAN 1, and until we do understand some important hardship that this rule imposes, I'd say this (Anoop's proposal) is obviously the right thing to do. Radia Silvano Gai wrote: > Radia, > > We are describing to you how VLANs are deployed today in Enterprise > networks. You may say that "you don't like it", we may agree with you, > but this does not change how they are deployed. > > For RBridges to be successful they need to be able to replace core > bridges without messing up the existing network configurations. > > Today most customers do not deploy VLANs end-to-end and they do reuse > VLANs number in different part of the enterprise. If RBridges are not > capable of supporting this, they are not attractive. > > Remember that the #1 customer requirement we have for TRILL is: "replace > core bridges with RBridges to enable Equal Cost Multi Path, all the rest > MUST remain the same". > > GVRP is not deployed; I am not sure which customers Anoop is referring > to. > > -- Silvano > > >> -----Original Message----- >> From: Radia Perlman [mailto:Radia.Perlman at sun.com] >> Sent: Tuesday, July 31, 2007 11:19 AM >> To: Dinesh G Dutt >> Cc: Silvano Gai; rbridge at postel.org >> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged >> > with > >> allthe VLAN tags >> >> I don't understand that problem. What you're describing might argue >> > for > >> bridges using a unique >> spanning tree per VLAN in order to optimize traffic flow for that >> > VLAN, > >> but I don't >> see what it has to do with wanting to partition VLANs. >> >> Radia >> >> >> Dinesh G Dutt wrote: >> >>> Radia Perlman wrote: >>> >>>> I'd like to understand what problem customers are attempting to >>>> > solve > >>>> with >>>> partitioned VLANs, and what hardship it would present to require at >>>> least one of the >>>> >>>> >>> The primary problem with having a VLAN everywhere is that the root >>> > of > >>> the spanning tree moves around leading to non-optimal forwarding in >>> enterprise networks. Enterprise networks are carefully engineered >>> networks and in the event of failure, they want to localize the >>> effects as much as possible. So, they want each VLAN to be localized >>> and roots where they want it to be. Having a common VLAN messes up >>> that arrangement. Also, VLAN 1 is the default VLAN when a switch >>> > comes > >>> up and there is typically lots of customer data on it. >>> >>>> VLANs to *not* be partitioned. With TRILL, if a customer eventually >>>> replaces >>>> all bridges, the customer will not be able to partition VLANs >>>> > anymore. > >>> As I raised it in the meeting, this is a side-effect that has not >>> > been > >>> considered before and needs to be carefully thought through. I don't >>> think many people are aware of this issue with TRILL that doesn't >>> exist with 802.1Q bridges today. >>> >>>> Also, from >>>> what Anoop was explaining to me, the GVRP protocol would >>>> > automatically > >>>> configure the switch-to-switch links to join all the islands of >>>> VLANs. So it would >>>> seem as though it can't be that fatal to solving customer problems >>>> > to > >>>> require >>>> *one* VLAN on a layer 2 cloud to not be partitioned. >>>> >>>> >>> GVRP is not deployed by a significant majority of customers. >>> >>> Dinesh >>> >>> > > From arien.vijn at ams-ix.net Tue Jul 31 23:37:51 2007 From: arien.vijn at ams-ix.net (Arien Vijn) Date: Wed, 1 Aug 2007 08:37:51 +0200 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <46AFE276.1050601@sun.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> Message-ID: <7DB09C27-376C-4DEC-9305-494CE6294B2C@ams-ix.net> On Aug 1, 2007, at 3:31 AM, Radia Perlman wrote: > Silvano....I still don't know what problem customers are trying to > solve > with partitioned VLANs. We have to chop vlans to overcome limits with regards to link aggregation. We need more interswitch capacity than we can aggregate. Hence we have to use multiple vlans with multiple untagged links which are connected on a central core switch. All these vlans form one broadcast domain. Since vlan information gets lost it is possible to reuse the same vlan id on different switches. Reusing ids has even some operation benefits in the current situation. Nonetheless, TRILL might change this practice and the next generation of switches can aggregate more links. One other thing. The default vlan is often solely used to park unused ports. It is often not interconnected in many networks. I guess many operators would appreciate a configurable vlan for IS-IS election. The default vlan for this should be the default vlan. I believe it is not uncommon to run a dedicated vlan for these kind of purposes and I think it's way cleaner than IS-IS hellos tagged with every VLAN. Hope this makes sense. Arien