From Donald.Eastlake at motorola.com Sat Jun 2 09:27:29 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 2 Jun 2007 12:27:29 -0400 Subject: [rbridge] How is an IS-IS packet differentiated from layer 3IS-IS, and TRILL-encapsulated data packets? In-Reply-To: <3870C46029D1F945B1472F170D2D97900297A494@de01exm64.ds.mot.com> References: <464E7806.7070703@sun.com> <464E7B89.5080908@sun.com><3870C46029D1F945B1472F170D2D9790028BDF50@de01exm64.ds.mot.com><464FE67B.7070809@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201799F2B@nuova-ex1.hq.nuovaimpresa.com><465DBC0F.1080601@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2018AF8FC@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D97900297A494@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D9790029B794E@de01exm64.ds.mot.com> Commenting on my own message, see below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Wednesday, May 30, 2007 10:26 PM To: Rbridge at postel.org Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3IS-IS, and TRILL-encapsulated data packets? OK. Well, based on the email with this subject, the working group seems pretty happy with the solution where both TRILL encapsulated data and TRILL IS-IS frames are indicated by the TRILL Ethertype and header with one of the current two reserved bits used to distinguish these cases. But, to allow for the possibility of learning end nodes via IS-IS, I think we need to provide for a per VLAN TRILL IS-IS message. The proposal seems to be that, if a Q-tag is present, then it is per VLAN, otherwise it is a core TRILL IS-IS message. So a per VLAN multicast TRILL IS-IS message would look like Outer.DA - 6 bytes (All-Rbridges) Outer.SA - 6 bytes (this hop SA) TRILL-Ethertype - 2 bytes (tbd) TRILL Header - 6 bytes (with "control message" and multi-destination bits on) Inner.DA - 6 bytes (All-Rbridges) Inner.SA - 6 bytes (original SA) Q-Ethertype - 2 bytes Q-tag value - 2 bytes Length - 2 bytes IS-IS DSAP - 1 byte (0xFE) IS-IS SSAP - 1 byte (0xFE) CTL - 1 byte (0x03) IS-IS payload - variable A core TRILL IS-IS message would be the same but without the inner Q-tag. (Also, for a core IS-IS message, the inner and outer SA would always be the same.) If the IS-IS message was unicast core, the outer and inner DA addresses would be the unicast destination, there would be no inner Q-tag, and the multi-destination bit would be off. If the IS-IS message was unicast per VLAN, the outer DA would the "this hop" DA, the inner DA would be the original DA, the Q-tab would be present, and the multi-destination bit would be off. In the TRILL header, for the per VLAN case, the Hop Count seems meaningful. But the ingress and egress RBridge nicknames are not used and, in fact, you need to send IS-IS Hellos before nicknames may have been established. Basically, the TRILL data frame needs six addresses, one pair each for the end stations, the ingress/egress Rbridges, and the per hop Rbridges. But IS-IS control messages are only ever from one Rbridge to another, so they only need four addresses in the per VLAN case (and really only two addresses in the core case since they go only one hop). @@@ The above is incorrect with reference to per VLAN multicast IS-IS messages. In particular, you need to specify the distribution tree. For consistency, it seems best to do this via the "egress Rbridge" field. This means you really can't do per VLAN IS-IS until the nicknames are settled, which is probably OK. So it seems to me that the alternatives are to either (1) Leave the nickname fields unset or set to zero on transmission and ignored on receipt or (2) Maybe add one of the reserved bits to the Version field and re-name it "Variation" or something and have the 6 byte "Data" variation as currently specified and the "IS-IS" variation which is just 2 bytes because it does not have the nickname fields. @@@ Making the Version field into a Variation field is really orthogonal and may be a reasonable idea regardless. @@@ Because the "egress Rbridge" field is needed to specify the distribution tree for per VLAN multicast IS-IS messages, it seems simpler to stick with the existing TRILL Header format for both data and TRILL IS-IS messages. @@@ Thanks, @@@ Donald Thanks, Donald -----Original Message----- From: Silvano Gai [mailto:sgai at nuovasystems.com] Sent: Wednesday, May 30, 2007 2:25 PM To: Erik Nordmark Cc: Radia Perlman; Eastlake III Donald-LDE008; Rbridge at postel.org Subject: RE: [rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets? Erik, You are correct, I oversimplified the explanation, but the conclusion still holds -- Silvano > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark at sun.com] > Sent: Wednesday, May 30, 2007 11:02 AM > To: Silvano Gai > Cc: Radia Perlman; Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3 > IS-IS, and TRILL-encapsulated data packets? > > Silvano Gai wrote: > > > The advantage of using a reserved bit is that the frame with Ethertype = > TRILL already go through DR blocked ports. The non-TRILL IS-IS frames will > have Ethertype = ISIS and will be dropped by DR blocked ports. > > I don't know if this matters, but AFAIK (and after checking RFC 1142), > there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header (i.e. > a length field instead of an Ethertype field) followed by 3 bytes of LLC > header with the SAP 0xFE. Thus the 3 bytes after the length field is 03 > FE FE. > > Erik > _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From anoop at brocade.com Wed Jun 6 14:34:38 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 6 Jun 2007 14:34:38 -0700 Subject: [rbridge] multicast pruning in TRILL Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> Per Section 3.5 of the Rbridge Base Protocol Specification, it looks like the trees computed by the ISIS base instance need to be pruned based on VLAN/IGMP membership information. Also, in order to actually make use of the pruning information when forwarding frames in a TRILL device, it looks like one would have to consult the inner L2 header of the frame to extract the inner VLAN and inner MAC DA (the latter is needed for multicast). In some sense TRILL is creating a tunnel, and yet we need to dig deeper than the tunnel headers in order to accomplish forwarding. It also lacks consistency in that unicasts are forwarded based on the RBridge destination address and multicasts are forwarded based on the inner MAC DA and VLAN. If pruning was not a requirement we would not have this issue. Is the pruning functionality a requirement (MUST) or a recommendation (MAY)? Thanks, Anoop From Donald.Eastlake at motorola.com Wed Jun 6 20:58:22 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 6 Jun 2007 23:58:22 -0400 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D9790029FB149@de01exm64.ds.mot.com> Hi Anoop, See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani Sent: Wednesday, June 06, 2007 5:35 PM To: rbridge at postel.org Subject: [rbridge] multicast pruning in TRILL Per Section 3.5 of the Rbridge Base Protocol Specification, it looks like the trees computed by the ISIS base instance need to be pruned based on VLAN/IGMP membership information. Also, in order to actually make use of the pruning information when forwarding frames in a TRILL device, it looks like one would have to consult the inner L2 header of the frame to extract the inner VLAN and inner MAC DA (the latter is needed for multicast). In some sense TRILL is creating a tunnel, and yet we need to dig deeper than the tunnel headers in order to accomplish forwarding. @@@ Certainly, the encapsulated ingress to egress Rbridge transport is a tunnel. @@@ Indeed, for precisely the reason you give, it was and remains my strong personal opinion that the VLAN-tag information should be part of the TRILL Header where it would be at least 14 bytes earlier and you would also save the 2 bytes of tag Ethertype. It contains priority as well as the VLAN ID info. @@@ However, the working group appears to be of the opinion that the VLAN-tag should be inserted inside the inner frame with an Ethertype. See the May mail here which includes arguments on the other side of the issue: http://www.postel.org/pipermail/rbridge/2007-May/thread.html. It also lacks consistency in that unicasts are forwarded based on the RBridge destination address and multicasts are forwarded based on the inner MAC DA and VLAN. @@@ There really isn't any inconsistency. The egress Rbridge for a known-unicast frame is determined by using the destination MAC address and the VLAN ID. It is just that for unicast, this can all be factored into the selection of one relevant egress Rbridge and no in transit pruning is needed. On the other hand, for multicast/broadcast, you could theoretically have the ingress Rbridge determine and unicast to all the relevant egress Rbridges, but that doesn't scale very well :-) So you flood the frame but need to consult the destination address and VLAN for pruning along the way so it only gets to relevant egress RBridges. For both known-unicast and multi-destination frames, the frame passes through transit Rbridges based on IS-IS adjacency and optimization regardless of VLAN. If pruning was not a requirement we would not have this issue. Is the pruning functionality a requirement (MUST) or a recommendation (MAY)? @@@ On the question of VLAN pruning and IP multicast pruning implementation requirements, they can be considered separate questions and there has been substantial discussion of them. I believe that VLAN pruning should have an equal or higher level of implementation requirement as IP multicast pruning and it is my impression that "SHOULD" would be a reasonable implementation requirement for both of these. @@@ Rbridges would, in some sense, operate "correctly" if there were no pruning of multi-destination frames but you could be talking about several orders of magnitude of inefficiency. If you were going to do that, maybe you should consider being ultra consistent and just flooding all frames, including unicast; after all, destination Rbridges that don't need the frames can always throw them away. :-) Thanks, Anoop @@@ Thanks, @@@ Donald From Radia.Perlman at sun.com Thu Jun 7 10:33:29 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 07 Jun 2007 10:33:29 -0700 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> Message-ID: <46684169.8050502@sun.com> Re: Is multicast pruning a MAY or MUST: I'm not sure there's been enough opinion voiced to have a consensus on this. I'd be happy with MAY or SHOULD, since it really it just an optimization. On the other part of what you said -- namely that you have to dig deeper into the frame for multicast and VLAN pruning --- it was suggested, but not extensively discussed, to move the inner VLAN into the TRILL header so that VLAN pruning would not need to be done by finding the inner frame. This would still require an RBridge in the core to look inside to find the inner frame in order to look at the multicast address. There are two ways I can think of to avoid this: a) move the multicast address into the inner frame, perhaps as an option in the TRILL header b) use the multicast address in the inner frame as the destination address in the outer header. I rather like the notion of moving stuff that RBridges need to look at into the outer header or TRILL header. But this would need to be discussed, and hopefully soon. Radia Anoop Ghanwani wrote: > Per Section 3.5 of the Rbridge Base Protocol > Specification, it looks like the trees computed > by the ISIS base instance need to be pruned > based on VLAN/IGMP membership information. > > Also, in order to actually make use of the > pruning information when forwarding frames > in a TRILL device, it looks like one would > have to consult the inner L2 header of the > frame to extract the inner VLAN and inner > MAC DA (the latter is needed for multicast). > > In some sense TRILL is creating a tunnel, > and yet we need to dig deeper than the tunnel > headers in order to accomplish forwarding. > It also lacks consistency in that unicasts > are forwarded based on the RBridge destination > address and multicasts are forwarded based > on the inner MAC DA and VLAN. > > If pruning was not a requirement we would > not have this issue. > > Is the pruning functionality a requirement > (MUST) or a recommendation (MAY)? > > Thanks, > Anoop > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From caitlinb at broadcom.com Thu Jun 7 11:00:27 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Thu, 7 Jun 2007 11:00:27 -0700 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <46684169.8050502@sun.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D041164F4@NT-IRVA-0750.brcm.ad.broadcom.com> rbridge-bounces at postel.org wrote: > Re: Is multicast pruning a MAY or MUST: > > I'm not sure there's been enough opinion voiced to have a consensus > on this. I'd be happy with MAY or SHOULD, since it really it just an > optimization. > > On the other part of what you said -- namely that you have to > dig deeper into the frame for multicast and VLAN pruning --- > it was suggested, but not extensively discussed, to move the > inner VLAN into the TRILL header so that VLAN pruning would > not need to be done by finding the inner frame. > > This would still require an RBridge in the core to look > inside to find the inner frame in order to look at the multicast > address. > > There are two ways I can think of to avoid this: > a) move the multicast address into the inner frame, perhaps > as an option in the TRILL header > b) use the multicast address in the inner frame as the > destination address in the outer header. > > I rather like the notion of moving stuff that RBridges need > to look at into the outer header or TRILL header. > > But this would need to be discussed, and hopefully soon. > > Radia > I can see some value in moving RBridge-relevant fields earlier in the overall packet, but I would want to avoid any and all risks of doing so in a way where the semantics of those fields did not remain fully under the IEEE and/or that would require product to implement the same logic twice. Leaving them where they are totally avoids such risks. From anoop at brocade.com Thu Jun 7 11:15:28 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Thu, 7 Jun 2007 11:15:28 -0700 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <46684169.8050502@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0E1217@HQ-EXCH-5.corp.brocade.com> Radia, > Re: Is multicast pruning a MAY or MUST: > > I'm not sure there's been enough opinion voiced to have a > consensus on this. > I'd be happy with MAY or SHOULD, since it really it just an > optimization. Actually, I think I agree with Donald's response. Even if it were a MAY/SHOULD, no one would ever want to build a system that didn't do pruning. It would be way too inefficient. > On the other part of what you said -- namely that you have to > dig deeper > into > the frame for multicast and VLAN pruning --- it was suggested, but > not extensively discussed, to move the inner VLAN into the > TRILL header > so that VLAN pruning would not need to be done by finding the > inner frame. > > This would still require an RBridge in the core to look > inside to find the > inner frame in order to look at the multicast address. > > There are two ways I can think of to avoid this: > a) move the multicast address into the inner frame, perhaps > as an option in > the TRILL header > b) use the multicast address in the inner frame as the destination > address in the outer > header. Moving the multicast address to the outer header doesn't really help in terms of implementation since the look ups required stay the same. It might help from an architecture standpoint, but even that I don't really see. Essentially, we need both the inner VLAN and the MAC DA to make their way into the TRILL header so that they can be consulted for forwarding. But doing so would unnecessarily add to the frame overhead. Perhaps what is defined is as good as it gets. :-) Somewhat off topic - I now recall why the statement about "problems with learning when doing multipathing" was put into the TRILL routing requirements document. In the early days of TRILL, IIRC RBridges were going to just forward unicast frames without an encapsulation header. In that case, if one had RBridges and regular bridges intermixed in a network and had ECMP running in the RBridges, we'd run into problems with address learning. Anoop From sgai at nuovasystems.com Thu Jun 7 11:34:40 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 7 Jun 2007 11:34:40 -0700 Subject: [rbridge] TRILL at the next IETF Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20192928E@nuova-ex1.hq.nuovaimpresa.com> Chairs, The preliminary agenda shows the TRILL meeting split over two days. https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num= 69 This is really inconvenient. Can we have the two slots in the same day? Thank You -- Silvano From Radia.Perlman at sun.com Thu Jun 7 13:28:59 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 07 Jun 2007 13:28:59 -0700 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <3870C46029D1F945B1472F170D2D9790029FB149@de01exm64.ds.mot.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790029FB149@de01exm64.ds.mot.com> Message-ID: <46686A8B.7020807@sun.com> (revisiting the issue of moving whatever is necessary for transit bridges to look at for pruning of multicasts (VLAN tag and destination multicast address) to the portion of the frame outside the tunnel, i.e., either the TRILL header or the outer header) The mailing list archives are daunting, even though I've been trying to follow it all along. I'd like to see the arguments both sides of this issue summarized rather than pointing people at the mailing list -- just now I tried to review the mailing list on this issue and got discouraged. It never hurts to summarize the issues again. I'll start by writing down concisely what I do remember, and perhaps people can concisely add other arguments: a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer bits total (since you don't need the Ethertype) to include it as a tag in the inner header), it's easier to find since transit RBridges don't need to find the inner header, the TRILL header is still fixed length. Minuses: It takes up room even when there is no VLAN tag in the inner header b) moving VLAN tag to TRILL header as an option: Pluses: it only takes up room when there is a VLAN tag in the inner frame. Minus: it makes the TRILL header variable length c) moving the inner multicast address (for IP multicast pruning) into the TRILL header: I don't think this was discussed. But it would clearly have to be done as an option in the TRILL header since we wouldn't want to make space for it in the TRILL header on unicast packets, so it would make the TRILL header variable length d) copying the inner multicast address (for IP multicast pruning) into the *outer* Ethernet header. I don't think this was discussed at all on the mailing list. I assume that it wouldn't confuse non-RBridge devices listening to that multicast address that might hear the packet because the Ethertype would be TRILL, so they'd (hopefully) drop it without getting confused. Whatever I've missed, can someone add to this? Thanks, Radia Eastlake III Donald-LDE008 wrote: > > @@@ Indeed, for precisely the reason you give, it was and remains my > strong personal opinion that the VLAN-tag information should be part of > the TRILL Header where it would be at least 14 bytes earlier and you > would also save the 2 bytes of tag Ethertype. It contains priority as > well as the VLAN ID info. > > @@@ However, the working group appears to be of the opinion that the > VLAN-tag should be inserted inside the inner frame with an Ethertype. > See the May mail here which includes arguments on the other side of the > issue: > http://www.postel.org/pipermail/rbridge/2007-May/thread.html. > > From Donald.Eastlake at motorola.com Thu Jun 7 13:28:58 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 7 Jun 2007 16:28:58 -0400 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E1217@HQ-EXCH-5.corp.brocade.com> References: <46684169.8050502@sun.com> <4C94DE2070B172459E4F1EE14BD2364E0E1217@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D979002A4267C@de01exm64.ds.mot.com> Hi, See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler Sent: Thursday, June 07, 2007 2:00 PM To: Radia Perlman; Anoop Ghanwani Cc: rbridge at postel.org Subject: Re: [rbridge] multicast pruning in TRILL Caitlin Bestler wrote: I can see some value in moving RBridge-relevant fields earlier in the overall packet, but I would want to avoid any and all risks of doing so in a way where the semantics of those fields did not remain fully under the IEEE and/or that would require product to implement the same logic twice. Leaving them where they are totally avoids such risks. @@@ The proposal would be to put a two byte field into the TRILL Header that would be specified by reference to the IEEE standard. The 16 bits would be used to control distribution tree pruning, priority queuing, etc., inside an Rbridge in exactly the same way, regardless of whether those 2 bytes are a field in the TRILL Header or are inserted inside the encapsulated frame after an Ethertype. @@@ more below -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani Sent: Thursday, June 07, 2007 2:15 PM To: Radia Perlman Cc: rbridge at postel.org Subject: Re: [rbridge] multicast pruning in TRILL Radia, > Re: Is multicast pruning a MAY or MUST: > > I'm not sure there's been enough opinion voiced to have a > consensus on this. > I'd be happy with MAY or SHOULD, since it really it just an > optimization. Actually, I think I agree with Donald's response. Even if it were a MAY/SHOULD, no one would ever want to build a system that didn't do pruning. It would be way too inefficient. > On the other part of what you said -- namely that you have to > dig deeper > into > the frame for multicast and VLAN pruning --- it was suggested, but > not extensively discussed, to move the inner VLAN into the > TRILL header > so that VLAN pruning would not need to be done by finding the > inner frame. > > This would still require an RBridge in the core to look > inside to find the > inner frame in order to look at the multicast address. > > There are two ways I can think of to avoid this: > a) move the multicast address into the inner frame, perhaps > as an option in > the TRILL header > b) use the multicast address in the inner frame as the destination > address in the outer > header. Moving the multicast address to the outer header doesn't really help in terms of implementation since the look ups required stay the same. It might help from an architecture standpoint, but even that I don't really see. @@@ Seems to me that moving an inner multicast or broadcast MAC address to the outer Ethernet header could, on shared links, cause additional interrupts to end stations from frames they would ultimately have to discard (and probably shouldn't be handling anyway) because they don't understand the TRILL Ethertype... Essentially, we need both the inner VLAN and the MAC DA to make their way into the TRILL header so that they can be consulted for forwarding. But doing so would unnecessarily add to the frame overhead. @@@ As far as I can see, moving the VLAN tag info to the TRILL Header reduces frame overhead. There would no longer be a need to insert an Ethertype and the VLAN tag info into the encapsulated frame. Thus you would save two bytes. @@@ On the other hand, since the inner MAC DA is right after the TRILL Header, whether it is part of the TRILL Header or not just depends on where you draw the boundaries of that header :-) @@@ Thanks, @@@ Donald Perhaps what is defined is as good as it gets. :-) Somewhat off topic - I now recall why the statement about "problems with learning when doing multipathing" was put into the TRILL routing requirements document. In the early days of TRILL, IIRC RBridges were going to just forward unicast frames without an encapsulation header. In that case, if one had RBridges and regular bridges intermixed in a network and had ECMP running in the RBridges, we'd run into problems with address learning. Anoop From anoop at brocade.com Fri Jun 8 09:59:21 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 8 Jun 2007 09:59:21 -0700 Subject: [rbridge] per-VLAN instances of IS-IS Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0E13CC@HQ-EXCH-5.corp.brocade.com> Section 3.3.3.2 of the rBridge base spec talks about the per VLAN instance of IS-IS. I can see why that would be useful. However, if looks like there could be problems scaling. If an end rBridge participates in 1000 VLANs, it will have to maintain 1000 adjacencies. Plus, it looks like for the per-VLAN IS-IS instance, the RBridge network operates as single LAN segment. That would mean having to go through DR/BDR election for each instance. Operating 100's of routers on a single LAN segment would poses its own set of scaling issues. Having per VLAN instances exacerbates the problem. Have the scaling issues been considered at all? It might actually be better to just use the core IS-IS instance. The following statement in Section 3.3.3.2 of the draft appears to be incorrect/incomplete: "RBridges with endnodes in VLAN A also receive and process the frame in their VLAN-A IS-IS instance." The frame also has to be processed by all RBridges that might be along the path for reaching the VLANs, otherwise we wouldn't be able to prune the distribution trees correctly. Anoop From eric.gray at ericsson.com Fri Jun 8 10:41:22 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Fri, 8 Jun 2007 12:41:22 -0500 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E13CC@HQ-EXCH-5.corp.brocade.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E13CC@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0104ABD4@eusrcmw721.eamcs.ericsson.se> Anoop, Having per-VLAN instances of IS-IS helps to simplify interactions - thus increasing the likelihood of correct specification leading to interoperable implementations. This is accomplished at some cost in extremely complex deployment scenarios - such as the one you cite as an example - but the cost is not nearly as high as you make it sound. Please see in-line comments below for further details. Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani > Sent: Friday, June 08, 2007 12:59 PM > To: rbridge at postel.org > Subject: [rbridge] per-VLAN instances of IS-IS > > > Section 3.3.3.2 of the rBridge base spec > talks about the per VLAN instance of IS-IS. > > I can see why that would be useful. > However, if looks like there could be > problems scaling. I am not convinced that you do. Having a per-VLAN IS-IS instance greatly simplifies interactions, and allows us to effectively define RBridges in a single VLAN context - leaving implementers free to implement inter-VLAN as already implemented in 802.1Q (and related) implementation. This is more than just "useful." See below for further clarification. > If an end rBridge > participates in 1000 VLANs, it will have > to maintain 1000 adjacencies. This is effectively true if we postulate only a single IS-IS instance for all VLANs, because you have to scope routing activities, link-state, etc. - on a per-VLAN basis even if that is the case. What you accomplish by using a single instance is to make it far more difficult to describe, understand and correctly implement RBridge routing protocol behaviors. > > Plus, it looks like for the per-VLAN IS-IS > instance, the RBridge network operates > as single LAN segment. That would mean > having to go through DR/BDR election for > each instance. And this would be correct behavior. An RBridge should only be eligible for ingress and egress to a local VLAN is it is configured to participate in that local VLAN. Hence, it may only participate in DR election for VLANs on a local bridged LAN if it participates in those VLANs. This is central to one of the issues with specifying - and correctly implementing - RBridge functionality. There are optimizations we may consider at a later date that will reduce - for example - messaging overhead, and there are already existing optimizations to reduce the actual state maintenance overhead to roughly the same as would be the case with a single IS-IS instance. > > Operating 100's of routers on a single > LAN segment would poses its own set of > scaling issues. Having per VLAN instances > exacerbates the problem. Are there deployment scenarios in today's bridging community where we support this kind of network as a bidged network? If there are not, then please recall that sclability of the current solution is targetted only for routghly the same size networks as can be established with bridging today. You make it sound as if we're expected to solve problems with RBridges for which solutions have never been specified for routing. As for complicating the problem with VLAN instances, think about how complicated this scenario would be already with 802.1Q VLANs running any of today's spanning tree protocols. Also, note that in this same situation with routers in place of RBridges, each router would most likely be required to have a logical interface in each VLAN on every link to which it is connected. In other words, this situation is just plain complicated - irrespective of what you're trying to do to deal with it. > > Have the scaling issues been considered > at all? It might actually be better to > just use the core IS-IS instance. Scaling has been considered. Large increases in scalability are not a primary goal - relative to existing bridging, for example. RTFC! Increased scalability over existing bridging was explicitly NOT included in the charter as a goal. > > The following statement in Section 3.3.3.2 > of the draft appears to be incorrect/incomplete: > > "RBridges with endnodes in VLAN A also > receive and process the frame in their > VLAN-A IS-IS instance." > > The frame also has to be processed by all > RBridges that might be along the path for > reaching the VLANs, otherwise we wouldn't > be able to prune the distribution trees > correctly. > > Anoop > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Donald.Eastlake at motorola.com Fri Jun 8 10:47:53 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 8 Jun 2007 13:47:53 -0400 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E13CC@HQ-EXCH-5.corp.brocade.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E13CC@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D979002A42B1B@de01exm64.ds.mot.com> Hi Anoop, See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani Sent: Friday, June 08, 2007 12:59 PM To: rbridge at postel.org Subject: [rbridge] per-VLAN instances of IS-IS Section 3.3.3.2 of the rBridge base spec talks about the per VLAN instance of IS-IS. I can see why that would be useful. However, if looks like there could be problems scaling. If an end rBridge participates in 1000 VLANs, it will have to maintain 1000 adjacencies. Plus, it looks like for the per-VLAN IS-IS instance, the RBridge network operates as single LAN segment. That would mean having to go through DR/BDR election for each instance. Operating 100's of routers on a single LAN segment would poses its own set of scaling issues. Having per VLAN instances exacerbates the problem. Have the scaling issues been considered at all? It might actually be better to just use the core IS-IS instance. @@@ These issues have been raised, although the possibility of using the core IS-IS instances hasn't been discussed much. If you do have 1,000 VLANs, using the core instance means that every Rbridge in the campus would have to know all end stations, even if that Rbridge is in an area of the campus that only uses one or a few VLANs. @@@ The WG appears to favor a change so that all Rbridges MUST be able to learn entirely from data, the way IEEE 802.1 bridges do, based on frames that they encapsulate and decapsulate. There are, however, advantages to using the per VLAN IS-IS instances, such as improved security in learning remote end node addresses if those end states register with their local Rbridge using some layer 2 protocol such as 802.1X and IS-IS security is in use for the IS-IS messages. So it seems appropriate at this time to say in the draft that Rbridges MAY implement and use the per VLAN IS-IS technique. Of course, it should also be possible to use a management protocol to configure end station addresses, configure so as to turn off learning from data, etc. @@@ I expect the next version of the protocol specification to reflect this change so that learning only from data is the zero configuration method. The following statement in Section 3.3.3.2 of the draft appears to be incorrect/incomplete: "RBridges with endnodes in VLAN A also receive and process the frame in their VLAN-A IS-IS instance." The frame also has to be processed by all RBridges that might be along the path for reaching the VLANs, otherwise we wouldn't be able to prune the distribution trees correctly. @@@ Right. It actually says "... all RBridges forward it as an ordinary frame in VLAN A ..." in the previous paragraph. Anoop @@@ Thanks, @@@ Donald From anoop at brocade.com Fri Jun 8 18:15:04 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 8 Jun 2007 18:15:04 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF0104ABD4@eusrcmw721.eamcs.ericsson.se> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0E1572@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] > > Having per-VLAN instances of IS-IS helps to simplify > interactions - thus increasing the likelihood of correct > specification leading to interoperable implementations. > > This is accomplished at some cost in extremely complex > deployment scenarios - such as the one you cite as an example > - but the cost is not nearly as high as you make it sound. > > Please see in-line comments below for further details. ... > > I am not convinced that you do. Having a per-VLAN IS-IS > instance greatly simplifies interactions, and allows us > to effectively define RBridges in a single VLAN context > - leaving implementers free to implement inter-VLAN as > already implemented in 802.1Q (and related) implementation. > > This is more than just "useful." See below for further > clarification. I'm not quite sure I get it, but I'll look below. > > If an end rBridge > > participates in 1000 VLANs, it will have > > to maintain 1000 adjacencies. > > This is effectively true if we postulate only a single IS-IS > instance for all VLANs, because you have to scope routing > activities, link-state, etc. - on a per-VLAN basis even if > that is the case. > > What you accomplish by using a single instance is to make it > far more difficult to describe, understand and correctly > implement RBridge routing protocol behaviors. I understand there will be some complexity in describing all the VLANs and multicast addresses in a single instance, but I think it scales better than multiple instances. Why? Consider the following picture: D | v1 -- A -- B -- C -- v1 | E A-E are RBridges. In this picture VLAN v1 is configured only on A and C. B doesn't have v1 configured on it. Yet B needs to know about VLAN v1's location in order to correctly prune its trees. What I'm getting at is that all RBridges in the network need to know about all VLANs so that they can prune their trees for each VLAN correctly. If you have an instance per VLAN we are talking about maintain up to 4K instances in each Rbridge. And it's not unheard of to configure a 1000 VLANs in regular 802.1Q device. > > Plus, it looks like for the per-VLAN IS-IS > > instance, the RBridge network operates > > as single LAN segment. That would mean > > having to go through DR/BDR election for > > each instance. > > And this would be correct behavior. An RBridge should only > be eligible for ingress and egress to a local VLAN is it is > configured to participate in that local VLAN. Hence, it may > only participate in DR election for VLANs on a local bridged > LAN if it participates in those VLANs. See above for why this is not true. Or tell me how I can do pruning without interior RBridges knowing about all VLANs. > This is central to one of the issues with specifying - and > correctly implementing - RBridge functionality. > > There are optimizations we may consider at a later date that > will reduce - for example - messaging overhead, and there are > already existing optimizations to reduce the actual state > maintenance overhead to roughly the same as would be the case > with a single IS-IS instance. > > > > > Operating 100's of routers on a single > > LAN segment would poses its own set of > > scaling issues. Having per VLAN instances > > exacerbates the problem. > > Are there deployment scenarios in today's bridging community > where we support this kind of network as a bidged network? Not in a bridged network. But if I recall correctly, and I may be off since the charter may have changed since the beginning, one of the goals of rBridges was to be able to build large campuses without routers and routing-related configuration. Has that gone away? It is not atypical to find a campus with 20K users on 100's of VLANs with ~100 nodes. > If there are not, then please recall that sclability of the > current solution is targetted only for routghly the same > size networks as can be established with bridging today. Even with a network of today's bridges there would be scaling issues if you had say 20-30 rBridges all trying to establish adjacencies between groups of themselves for a few 100 VLANs. It is not atypical to have ~1000 VLANs configured in core switches. > You make it sound as if we're expected to solve problems > with RBridges for which solutions have never been specified > for routing. > > As for complicating the problem with VLAN instances, think > about how complicated this scenario would be already with > 802.1Q VLANs running any of today's spanning tree protocols. They scale just fine because they limit the maximum number of trees and have some VLANs share a tree. They don't try to run one STP instance per VLAN. > Also, note that in this same situation with routers in place > of RBridges, each router would most likely be required to > have a logical interface in each VLAN on every link to which > it is connected. This cannot be compared with routers. We're talking about bridging here. If we routed, we'd just terminate the MAC domain at the edge router and we wouldn't run into any of these issues. No sense in having a VLAN interface on every router in the campus. (One could design the network that way, but it would be a really bad way to do it.) > In other words, this situation is just plain complicated - > irrespective of what you're trying to do to deal with it. > > > > > Have the scaling issues been considered > > at all? It might actually be better to > > just use the core IS-IS instance. > > Scaling has been considered. Large increases in scalability > are not a primary goal - relative to existing bridging, for > example. > > RTFC! Increased scalability over existing bridging was > explicitly NOT included in the charter as a goal. I thought I knew what the charter was but I went back and read it again anyway. I didn't find much there to work with with respect to scalability requirements. It talks about a "problem statement and applicability" document. I'm not sure which of the published documents that is. Anoop From anoop at brocade.com Fri Jun 8 18:25:08 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 8 Jun 2007 18:25:08 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <3870C46029D1F945B1472F170D2D979002A42B1B@de01exm64.ds.mot.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0E1579@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: Eastlake III Donald-LDE008 > > See below at @@@ > > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On > Behalf Of Anoop Ghanwani > Sent: Friday, June 08, 2007 12:59 PM > To: rbridge at postel.org > Subject: [rbridge] per-VLAN instances of IS-IS .. > > Have the scaling issues been considered > at all? It might actually be better to > just use the core IS-IS instance. > > @@@ These issues have been raised, although the possibility > of using the > core IS-IS instances hasn't been discussed much. If you do have 1,000 > VLANs, using the core instance means that every Rbridge in the campus > would have to know all end stations, even if that Rbridge is > in an area > of the campus that only uses one or a few VLANs. > > @@@ The WG appears to favor a change so that all Rbridges MUST be able > to learn entirely from data, the way IEEE 802.1 bridges do, based on > frames that they encapsulate and decapsulate. There are, however, > advantages to using the per VLAN IS-IS instances, such as improved > security in learning remote end node addresses if those end states > register with their local Rbridge using some layer 2 protocol such as > 802.1X and IS-IS security is in use for the IS-IS messages. > So it seems > appropriate at this time to say in the draft that Rbridges > MAY implement > and use the per VLAN IS-IS technique. Of course, it should also be > possible to use a management protocol to configure end station > addresses, configure so as to turn off learning from data, etc. > > @@@ I expect the next version of the protocol specification to reflect > this change so that learning only from data is the zero configuration > method. The learning approach will work for unicast addresses. It will not work for pruning the trees for multicast addresses and flooding to VLANs. Those addresses and VLAN membership information needs to be sent around to all RBridges in the network. > > The following statement in Section 3.3.3.2 > of the draft appears to be incorrect/incomplete: > > "RBridges with endnodes in VLAN A also > receive and process the frame in their > VLAN-A IS-IS instance." > > The frame also has to be processed by all > RBridges that might be along the path for > reaching the VLANs, otherwise we wouldn't > be able to prune the distribution trees > correctly. > > @@@ Right. It actually says "... all RBridges forward it as > an ordinary > frame in VLAN A ..." in the previous paragraph. This doesn't work. See my response to Eric for why it doesn't. Thanks, Anoop From sgai at nuovasystems.com Sat Jun 9 08:03:38 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sat, 9 Jun 2007 08:03:38 -0700 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <46686A8B.7020807@sun.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D9790029FB149@de01exm64.ds.mot.com> <46686A8B.7020807@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20199851C@nuova-ex1.hq.nuovaimpresa.com> Folks, We had a detailed discussion on the header format which included all the points that Radia list below. We had a strong consensus on one solution. The WG chairs confirmed this consensus on the mailing list. There is no new piece of information. We have not discovered anything that was not known at the time of the consensus. I propose we stick with the current header format. If we continue to change things we will never converge and the frame format needs to be stable ASAP. If we reopen the frame format discussion, then I want to reopen nickname vs address ;-) :-) :-) ;-) -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Thursday, June 07, 2007 1:29 PM > To: Eastlake III Donald-LDE008 > Cc: rbridge at postel.org > Subject: Re: [rbridge] multicast pruning in TRILL > > (revisiting the issue of moving whatever is necessary for transit > bridges to look at > for pruning of multicasts (VLAN tag and destination multicast address) > to the portion of the frame outside the tunnel, i.e., either the TRILL > header or > the outer header) > > The mailing list archives are daunting, even though I've been trying to > follow it all along. > I'd like to see the arguments both sides of this issue summarized rather > than > pointing people at the mailing list -- just now I tried to review the > mailing list > on this issue and got discouraged. It never hurts to summarize the > issues again. > > I'll start by writing down concisely what I do remember, and perhaps > people can > concisely add other arguments: > > a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer > bits total (since you > don't need the Ethertype) to include it as a tag in the inner header), > it's easier to find since > transit RBridges don't need to find the inner header, > the TRILL header is still fixed length. Minuses: It takes up room even > when there is > no VLAN tag in the inner header > > b) moving VLAN tag to TRILL header as an option: Pluses: it only takes > up room > when there is a VLAN tag in the inner frame. Minus: it makes the TRILL > header > variable length > > c) moving the inner multicast address (for IP multicast pruning) into > the TRILL header: I don't think this was discussed. But it would clearly > have to be done as an option in the TRILL > header since we wouldn't want to make space for it in the TRILL header > on unicast > packets, so it would make the TRILL header variable length > > d) copying the inner multicast address (for IP multicast pruning) into > the *outer* Ethernet > header. I don't think this was discussed at all on the mailing list. I > assume that it wouldn't > confuse non-RBridge devices listening to that multicast address that > might hear the > packet because the Ethertype would be TRILL, so they'd (hopefully) drop > it without > getting confused. > > Whatever I've missed, can someone add to this? > > Thanks, > > Radia > > > Eastlake III Donald-LDE008 wrote: > > > > @@@ Indeed, for precisely the reason you give, it was and remains my > > strong personal opinion that the VLAN-tag information should be part of > > the TRILL Header where it would be at least 14 bytes earlier and you > > would also save the 2 bytes of tag Ethertype. It contains priority as > > well as the VLAN ID info. > > > > @@@ However, the working group appears to be of the opinion that the > > VLAN-tag should be inserted inside the inner frame with an Ethertype. > > See the May mail here which includes arguments on the other side of the > > issue: > > http://www.postel.org/pipermail/rbridge/2007-May/thread.html. > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From sgai at nuovasystems.com Sat Jun 9 08:06:31 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sat, 9 Jun 2007 08:06:31 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E13CC@HQ-EXCH-5.corp.brocade.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E13CC@HQ-EXCH-5.corp.brocade.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20199851D@nuova-ex1.hq.nuovaimpresa.com> Anoop, You are right; there is a tremendous scalability issue. My proposal is to completely drop the per-VLAN ISIS instance and learn from data frames. Proven, scalable, it works. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Anoop Ghanwani > Sent: Friday, June 08, 2007 9:59 AM > To: rbridge at postel.org > Subject: [rbridge] per-VLAN instances of IS-IS > > > Section 3.3.3.2 of the rBridge base spec > talks about the per VLAN instance of IS-IS. > > I can see why that would be useful. > However, if looks like there could be > problems scaling. If an end rBridge > participates in 1000 VLANs, it will have > to maintain 1000 adjacencies. > > Plus, it looks like for the per-VLAN IS-IS > instance, the RBridge network operates > as single LAN segment. That would mean > having to go through DR/BDR election for > each instance. > > Operating 100's of routers on a single > LAN segment would poses its own set of > scaling issues. Having per VLAN instances > exacerbates the problem. > > Have the scaling issues been considered > at all? It might actually be better to > just use the core IS-IS instance. > > The following statement in Section 3.3.3.2 > of the draft appears to be incorrect/incomplete: > > "RBridges with endnodes in VLAN A also > receive and process the frame in their > VLAN-A IS-IS instance." > > The frame also has to be processed by all > RBridges that might be along the path for > reaching the VLANs, otherwise we wouldn't > be able to prune the distribution trees > correctly. > > Anoop > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From sgai at nuovasystems.com Sat Jun 9 10:01:35 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sat, 9 Jun 2007 10:01:35 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E1579@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002A42B1B@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E0E1579@HQ-EXCH-5.corp.brocade.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201998522@nuova-ex1.hq.nuovaimpresa.com> Anoop, The proposal for multicast is to move this information in the core inbstance of ISIS. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Anoop Ghanwani > Sent: Friday, June 08, 2007 6:25 PM > To: Eastlake III Donald-LDE008 > Cc: rbridge at postel.org > Subject: Re: [rbridge] per-VLAN instances of IS-IS > > > > > -----Original Message----- > > From: Eastlake III Donald-LDE008 > > > > See below at @@@ > > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On > > Behalf Of Anoop Ghanwani > > Sent: Friday, June 08, 2007 12:59 PM > > To: rbridge at postel.org > > Subject: [rbridge] per-VLAN instances of IS-IS > .. > > > > Have the scaling issues been considered > > at all? It might actually be better to > > just use the core IS-IS instance. > > > > @@@ These issues have been raised, although the possibility > > of using the > > core IS-IS instances hasn't been discussed much. If you do have 1,000 > > VLANs, using the core instance means that every Rbridge in the campus > > would have to know all end stations, even if that Rbridge is > > in an area > > of the campus that only uses one or a few VLANs. > > > > @@@ The WG appears to favor a change so that all Rbridges MUST be able > > to learn entirely from data, the way IEEE 802.1 bridges do, based on > > frames that they encapsulate and decapsulate. There are, however, > > advantages to using the per VLAN IS-IS instances, such as improved > > security in learning remote end node addresses if those end states > > register with their local Rbridge using some layer 2 protocol such as > > 802.1X and IS-IS security is in use for the IS-IS messages. > > So it seems > > appropriate at this time to say in the draft that Rbridges > > MAY implement > > and use the per VLAN IS-IS technique. Of course, it should also be > > possible to use a management protocol to configure end station > > addresses, configure so as to turn off learning from data, etc. > > > > @@@ I expect the next version of the protocol specification to reflect > > this change so that learning only from data is the zero configuration > > method. > > > The learning approach will work for unicast addresses. > It will not work for pruning the trees for multicast > addresses and flooding to VLANs. Those addresses > and VLAN membership information needs to be sent > around to all RBridges in the network. > > > > > The following statement in Section 3.3.3.2 > > of the draft appears to be incorrect/incomplete: > > > > "RBridges with endnodes in VLAN A also > > receive and process the frame in their > > VLAN-A IS-IS instance." > > > > The frame also has to be processed by all > > RBridges that might be along the path for > > reaching the VLANs, otherwise we wouldn't > > be able to prune the distribution trees > > correctly. > > > > @@@ Right. It actually says "... all RBridges forward it as > > an ordinary > > frame in VLAN A ..." in the previous paragraph. > > This doesn't work. See my response to Eric > for why it doesn't. > > Thanks, > Anoop > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Sat Jun 9 17:21:58 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 9 Jun 2007 20:21:58 -0400 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA20199851C@nuova-ex1.hq.nuovaimpresa.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com><3870C46029D1F945B1472F170D2D9790029FB149@de01exm64.ds.mot.com> <46686A8B.7020807@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA20199851C@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <3870C46029D1F945B1472F170D2D979002A42DB1@de01exm64.ds.mot.com> The consensus determination referred to is here: http://www.postel.org/pipermail/rbridge/2007-May/002226.html which refers to the option 1 here: http://www.postel.org/pipermail/rbridge/2007-May/002078.html Donald -----Original Message----- From: Silvano Gai [mailto:sgai at nuovasystems.com] Sent: Saturday, June 09, 2007 11:04 AM To: Radia Perlman; Eastlake III Donald-LDE008 Cc: rbridge at postel.org Subject: RE: [rbridge] multicast pruning in TRILL Folks, We had a detailed discussion on the header format which included all the points that Radia list below. We had a strong consensus on one solution. The WG chairs confirmed this consensus on the mailing list. There is no new piece of information. We have not discovered anything that was not known at the time of the consensus. I propose we stick with the current header format. If we continue to change things we will never converge and the frame format needs to be stable ASAP. If we reopen the frame format discussion, then I want to reopen nickname vs address ;-) :-) :-) ;-) -- Silvano From Donald.Eastlake at motorola.com Sat Jun 9 17:33:26 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 9 Jun 2007 20:33:26 -0400 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201998522@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D979002A42B1B@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E0E1579@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA201998522@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <3870C46029D1F945B1472F170D2D979002A42DB3@de01exm64.ds.mot.com> See below at ### -----Original Message----- From: Silvano Gai [mailto:sgai at nuovasystems.com] Sent: Saturday, June 09, 2007 1:02 PM To: Anoop Ghanwani; Eastlake III Donald-LDE008 Cc: rbridge at postel.org Subject: RE: [rbridge] per-VLAN instances of IS-IS Anoop, The proposal for multicast is to move this information in the core inbstance of ISIS. ### If you referring to the various multicast listener and IP multicast router information, it has to be in the core instance so pruning can happen in transit Rbridges. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Anoop Ghanwani > Sent: Friday, June 08, 2007 6:25 PM > To: Eastlake III Donald-LDE008 > Cc: rbridge at postel.org > Subject: Re: [rbridge] per-VLAN instances of IS-IS > > > > -----Original Message----- > > From: Eastlake III Donald-LDE008 > > > > See below at @@@ > > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On > > Behalf Of Anoop Ghanwani > > Sent: Friday, June 08, 2007 12:59 PM > > To: rbridge at postel.org > > Subject: [rbridge] per-VLAN instances of IS-IS > .. > > > > Have the scaling issues been considered > > at all? It might actually be better to > > just use the core IS-IS instance. > > > > @@@ These issues have been raised, although the possibility > > of using the > > core IS-IS instances hasn't been discussed much. If you do have 1,000 > > VLANs, using the core instance means that every Rbridge in the campus > > would have to know all end stations, even if that Rbridge is > > in an area > > of the campus that only uses one or a few VLANs. > > > > @@@ The WG appears to favor a change so that all Rbridges MUST be able > > to learn entirely from data, the way IEEE 802.1 bridges do, based on > > frames that they encapsulate and decapsulate. There are, however, > > advantages to using the per VLAN IS-IS instances, such as improved > > security in learning remote end node addresses if those end states > > register with their local Rbridge using some layer 2 protocol such as > > 802.1X and IS-IS security is in use for the IS-IS messages. > > So it seems > > appropriate at this time to say in the draft that Rbridges > > MAY implement > > and use the per VLAN IS-IS technique. Of course, it should also be > > possible to use a management protocol to configure end station > > addresses, configure so as to turn off learning from data, etc. > > > > @@@ I expect the next version of the protocol specification to reflect > > this change so that learning only from data is the zero configuration > > method. > > The learning approach will work for unicast addresses. > It will not work for pruning the trees for multicast > addresses and flooding to VLANs. Those addresses > and VLAN membership information needs to be sent > around to all RBridges in the network. ### Correct, that information has to be in the core instance and is incorrectly shown in the current draft as being in the per VLAN instance. ### Donald > > The following statement in Section 3.3.3.2 > > of the draft appears to be incorrect/incomplete: > > > > "RBridges with endnodes in VLAN A also > > receive and process the frame in their > > VLAN-A IS-IS instance." > > > > The frame also has to be processed by all > > RBridges that might be along the path for > > reaching the VLANs, otherwise we wouldn't > > be able to prune the distribution trees > > correctly. > > > > @@@ Right. It actually says "... all RBridges forward it as > > an ordinary > > frame in VLAN A ..." in the previous paragraph. > > This doesn't work. See my response to Eric > for why it doesn't. > > Thanks, > Anoop > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Sat Jun 9 21:02:11 2007 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Sat, 09 Jun 2007 21:02:11 -0700 Subject: [rbridge] per-VLAN instances of IS-IS Message-ID: <496fc590703b.466b1553@sunlabs.com> Expanding on what Silvano said, and agreeing with what I think Anoop was pointing out. It was an error in the previous version of the spec to say that the IP multicast group membership information would be announced in the per-VLAN instance, since the core guys would need to look at membership in VLAN A, even if they are not in VLAN A, in order to prune multicasts in VLAN A inside the core. So IP group membership is moving to the core instance. And for now the per-VLAN instance (which would have announced endnode membership) is going away, though I'd like it to be optional in the future, for letting an RBridge announce endnodes that have actually enrolled at layer 2, since it's a more secure binding than just having an endnode transmit a data packet with the source address. But it will be a MUST to learn from data packets, and, if we define a per-VLAN instance of IS-IS for announcing endnode memberships, it would be a SHOULD to announce endnodes that have actually enrolled, with perhaps a metric for how securely they've enrolled (whether it was cryptographic authentication, e.g.). And it would be a SHOULD to learn from such reports, and a SHOULD to have the IS-IS announcement be believed when there is a conflict between what is learned from decapsulating a data packet vs what is announced in IS-IS. Radia ----- Original Message ----- From: Silvano Gai Date: Saturday, June 9, 2007 10:01 am Subject: Re: [rbridge] per-VLAN instances of IS-IS > Anoop, > > The proposal for multicast is to move this information in the core > inbstance of ISIS. > > -- Silvano > > > -----Original Message----- > > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] > On > > Behalf Of Anoop Ghanwani > > Sent: Friday, June 08, 2007 6:25 PM > > To: Eastlake III Donald-LDE008 > > Cc: rbridge at postel.org > > Subject: Re: [rbridge] per-VLAN instances of IS-IS > > > > > > > > > -----Original Message----- > > > From: Eastlake III Donald-LDE008 > > > > > > See below at @@@ > > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org > > > [rbridge-bounces at postel.org] On > > > Behalf Of Anoop Ghanwani > > > Sent: Friday, June 08, 2007 12:59 PM > > > To: rbridge at postel.org > > > Subject: [rbridge] per-VLAN instances of IS-IS > > .. > > > > > > Have the scaling issues been considered > > > at all? It might actually be better to > > > just use the core IS-IS instance. > > > > > > @@@ These issues have been raised, although the possibility > > > of using the > > > core IS-IS instances hasn't been discussed much. If you do have > 1,000 > > > VLANs, using the core instance means that every Rbridge in the > campus > > > would have to know all end stations, even if that Rbridge is > > > in an area > > > of the campus that only uses one or a few VLANs. > > > > > > @@@ The WG appears to favor a change so that all Rbridges MUST be > able > > > to learn entirely from data, the way IEEE 802.1 bridges do, > based on > > > frames that they encapsulate and decapsulate. There are, however, > > > advantages to using the per VLAN IS-IS instances, such as improved > > > security in learning remote end node addresses if those end states > > > register with their local Rbridge using some layer 2 protocol such > as > > > 802.1X and IS-IS security is in use for the IS-IS messages. > > > So it seems > > > appropriate at this time to say in the draft that Rbridges > > > MAY implement > > > and use the per VLAN IS-IS technique. Of course, it should also be > > > possible to use a management protocol to configure end station > > > addresses, configure so as to turn off learning from data, etc. > > > > > > @@@ I expect the next version of the protocol specification to > reflect > > > this change so that learning only from data is the zero > configuration > > > method. > > > > > > The learning approach will work for unicast addresses. > > It will not work for pruning the trees for multicast > > addresses and flooding to VLANs. Those addresses > > and VLAN membership information needs to be sent > > around to all RBridges in the network. > > > > > > > > The following statement in Section 3.3.3.2 > > > of the draft appears to be incorrect/incomplete: > > > > > > "RBridges with endnodes in VLAN A also > > > receive and process the frame in their > > > VLAN-A IS-IS instance." > > > > > > The frame also has to be processed by all > > > RBridges that might be along the path for > > > reaching the VLANs, otherwise we wouldn't > > > be able to prune the distribution trees > > > correctly. > > > > > > @@@ Right. It actually says "... all RBridges forward it as > > > an ordinary > > > frame in VLAN A ..." in the previous paragraph. > > > > This doesn't work. See my response to Eric > > for why it doesn't. > > > > Thanks, > > Anoop > > > > _______________________________________________ > > rbridge mailing list > > 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 touch at ISI.EDU Mon Jun 11 08:48:23 2007 From: touch at ISI.EDU (Joe Touch) Date: Mon, 11 Jun 2007 08:48:23 -0700 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <46684169.8050502@sun.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> <46684169.8050502@sun.com> Message-ID: <466D6EC7.5020407@isi.edu> Radia Perlman wrote: > Re: Is multicast pruning a MAY or MUST: > > I'm not sure there's been enough opinion voiced to have a consensus on this. > I'd be happy with MAY or SHOULD, since it really it just an optimization. IMO, optimizations should be expressed as MAY. To say "SHOULD" is to say that implementations that do not implement the optimization should have a good reason for not doing so. I don't think the presumption should be tilted that way. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- 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/20070611/64269fe9/signature.bin From eric.gray at ericsson.com Mon Jun 11 08:55:29 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Mon, 11 Jun 2007 10:55:29 -0500 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E1572@HQ-EXCH-5.corp.brocade.com> References: <941D5DCD8C42014FAF70FB7424686DCF0104ABD4@eusrcmw721.eamcs.ericsson.se> <4C94DE2070B172459E4F1EE14BD2364E0E1572@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01081245@eusrcmw721.eamcs.ericsson.se> Anoop, Thanks for the well thought out reply. Please see continuing discussion below... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Friday, June 08, 2007 9:15 PM > To: Eric Gray (LO/EUS) > Cc: rbridge at postel.org > Subject: RE: [rbridge] per-VLAN instances of IS-IS > Importance: High > > > > -----Original Message----- > > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] > > > > Having per-VLAN instances of IS-IS helps to simplify > > interactions - thus increasing the likelihood of correct > > specification leading to interoperable implementations. > > > > This is accomplished at some cost in extremely complex > > deployment scenarios - such as the one you cite as an example > > - but the cost is not nearly as high as you make it sound. > > > > Please see in-line comments below for further details. > ... > > > > I am not convinced that you do. Having a per-VLAN IS-IS > > instance greatly simplifies interactions, and allows us > > to effectively define RBridges in a single VLAN context > > - leaving implementers free to implement inter-VLAN as > > already implemented in 802.1Q (and related) implementation. > > > > This is more than just "useful." See below for further > > clarification. > > I'm not quite sure I get it, but I'll look below. > > > > If an end rBridge > > > participates in 1000 VLANs, it will have > > > to maintain 1000 adjacencies. > > > > This is effectively true if we postulate only a single IS-IS > > instance for all VLANs, because you have to scope routing > > activities, link-state, etc. - on a per-VLAN basis even if > > that is the case. > > > > What you accomplish by using a single instance is to make it > > far more difficult to describe, understand and correctly > > implement RBridge routing protocol behaviors. > > I understand there will be some complexity in > describing all the VLANs and multicast addresses > in a single instance, but I think it scales better > than multiple instances. Why? Consider the > following picture: > > D > | > v1 -- A -- B -- C -- v1 > | > E > > A-E are RBridges. > > In this picture VLAN v1 is configured only on A > and C. B doesn't have v1 configured on it. Yet > B needs to know about VLAN v1's location in order > to correctly prune its trees. Note that this configuration - if A-E were Q-bridges - would be pathological, resulting in segmenting v1. I believe you've over-simplified interactions to make a point, and the result is an example that does not make that point. In the above scenario, two simple approaches might have been used that would not share the pathology of the given example: 1) B might be configured to support v1 (flat model). 2) A and C might be configured to tunnel (e.g. - Q-in-Q) v1 via B, using a VID for which B is configured (hierarchical model). It may be difficult to imagine why the second choice may be useful, given the over-simplified example, but it is actually quite likely to be useful in complex secnarios - particularly involving edge bridges with very large numbers of subscriber-facing ports with large overlap in VLAN membership among edge bridges. These same approaches are also useful with RBridges. > > What I'm getting at is that all RBridges in the > network need to know about all VLANs so that they > can prune their trees for each VLAN correctly. Yes, in a flat model, this would be true. With the alternative approach, only edge RBridges really have to know about VLANs at the edge. Pruding in core RBridges occurs as a consequence of Q-in-Q (or like approach) configuration. > > If you have an instance per VLAN we are talking > about maintain up to 4K instances in each Rbridge. > And it's not unheard of to configure a 1000 > VLANs in regular 802.1Q device. > Yes. I believe this essentially makes my point. It is done today, with today's bridges, hence scalability is apparently not a real concern (yet). > > > > Plus, it looks like for the per-VLAN IS-IS > > > instance, the RBridge network operates > > > as single LAN segment. That would mean > > > having to go through DR/BDR election for > > > each instance. > > > > And this would be correct behavior. An RBridge should only > > be eligible for ingress and egress to a local VLAN is it is > > configured to participate in that local VLAN. Hence, it may > > only participate in DR election for VLANs on a local bridged > > LAN if it participates in those VLANs. > > See above for why this is not true. Or > tell me how I can do pruning without interior > RBridges knowing about all VLANs. Use a hierarchical model model with VID-based tunneling. This is not a trivially easy configuration for some real-world deployment scenarios we can all probably imagine. But it is also not as trivially easy to break, once correctly configured. > > > This is central to one of the issues with specifying - and > > correctly implementing - RBridge functionality. > > > > There are optimizations we may consider at a later date that > > will reduce - for example - messaging overhead, and there are > > already existing optimizations to reduce the actual state > > maintenance overhead to roughly the same as would be the case > > with a single IS-IS instance. > > > > > > > > Operating 100's of routers on a single > > > LAN segment would poses its own set of > > > scaling issues. Having per VLAN instances > > > exacerbates the problem. > > > > Are there deployment scenarios in today's bridging community > > where we support this kind of network as a bidged network? > > Not in a bridged network. But if I recall correctly, > and I may be off since the charter may have changed > since the beginning, one of the goals of rBridges was > to be able to build large campuses without routers > and routing-related configuration. Has that gone away? > It is not atypical to find a campus with 20K users > on 100's of VLANs with ~100 nodes. That never was a goal. There are people who might like to make it one, but that's (IMO) a malignant nightmare. There is no conceivable way to build devices that do everything a router does without incorporating all of the complexity (read "cost") of a router into that device. If that's what somebody really wants to do, then I'd like to hear how they propose to design routing complexity - using a routing protocol, and putting everything else a router does into it - without the end product actually being MORE complex (read "expensive") than anybody's current routing implementation. > > > If there are not, then please recall that sclability of the > > current solution is targetted only for routghly the same > > size networks as can be established with bridging today. > > Even with a network of today's bridges there would > be scaling issues if you had say 20-30 rBridges > all trying to establish adjacencies between groups > of themselves for a few 100 VLANs. It is not > atypical to have ~1000 VLANs configured in core > switches. So, for IS-IS (or OSPF), issues with "adjacencies" are not subject to the same sorts of concerns as (for example) BGP. What maintaining adjacencies really means is keeping up to date on link state for a peer-set. What you're pointing out is that - for many VLANs - the numer of peer-sets for which link state has to be maintained may be large. Short of using hierarchical VLANs, this is competely and absolutely unavoidable - unless we're going to accept the consequences of specifying incorrect VLAN interactions as a mechanism for effectively doing the same thing (i.e. - effectively specifying hierarchy using some other means, or simply hoping that people can somehow get it right). If you assume - as I do - that VLAN traffic is only supposed to traverse links for which that VLAN is configured (either explicitly or implicity), than not including a VLAN (again, either explicitly or implicitly) in the configuration for a specific link means that that VLAN's traffic is not supposed to traverse that link. Period. > > > You make it sound as if we're expected to solve problems > > with RBridges for which solutions have never been specified > > for routing. > > > > As for complicating the problem with VLAN instances, think > > about how complicated this scenario would be already with > > 802.1Q VLANs running any of today's spanning tree protocols. > > They scale just fine because they limit the > maximum number of trees and have some VLANs share > a tree. They don't try to run one STP instance > per VLAN. Right. Assuming you've gotten your head around the notion of hierarchical VLANs, how is this different? > > > Also, note that in this same situation with routers in place > > of RBridges, each router would most likely be required to > > have a logical interface in each VLAN on every link to which > > it is connected. > > This cannot be compared with routers. We're talking > about bridging here. If we routed, we'd just terminate > the MAC domain at the edge router and we wouldn't > run into any of these issues. No sense in having a > VLAN interface on every router in the campus. > (One could design the network that way, but it would > be a really bad way to do it.) The point is that - if you had 1000 (or 4000) VLANs, in a subnet, you would terminate a large percentage of those on connected routers. If you imagine that there are many sch subnets (as seems to be implied in your earlier comments), then this would also be true for other physical interfaces on each router. Also, if you believe that RBridges may be used to replace routers, then you compound this issue. > > > In other words, this situation is just plain complicated - > > irrespective of what you're trying to do to deal with it. > > > > > > > > Have the scaling issues been considered > > > at all? It might actually be better to > > > just use the core IS-IS instance. > > > > Scaling has been considered. Large increases in scalability > > are not a primary goal - relative to existing bridging, for > > example. > > > > RTFC! Increased scalability over existing bridging was > > explicitly NOT included in the charter as a goal. > > I thought I knew what the charter was but I went back > and read it again anyway. I didn't find much there > to work with with respect to scalability requirements. > It talks about a "problem statement and applicability" > document. I'm not sure which of the published documents > that is. It is the one that has that name. Joe Touch is the main author/editor (with Radia Perlman). It apparently has been allowed to expire. See: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=147 71 for more information. By the way, it actually did not expire very long ago, so it is likely that there is a new version in the works. However, the way that IETF charters typically work is that they are exclusive, rather than inclusive, by default. In other words, the fact that the charter does not explicitly include increased scalability as a goal CANNOT be read to mean that it may be a goal because it is not explicitly excluded. Per the charter, the design goals for the TRILL solution are: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions There is nothing in these explicitly listed goals that can be stretched to include the notion of hugely increased scale, or replacement of routers. > > Anoop > From sgai at nuovasystems.com Mon Jun 11 09:32:10 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 11 Jun 2007 09:32:10 -0700 Subject: [rbridge] multicast pruning in TRILL In-Reply-To: <466D6EC7.5020407@isi.edu> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com><46684169.8050502@sun.com> <466D6EC7.5020407@isi.edu> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20199864B@nuova-ex1.hq.nuovaimpresa.com> I agree with Joe. In general we should use only MAY or MUST, not SHOULD -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Joe Touch > Sent: Monday, June 11, 2007 8:48 AM > To: Radia Perlman > Cc: rbridge at postel.org > Subject: Re: [rbridge] multicast pruning in TRILL > > > > Radia Perlman wrote: > > Re: Is multicast pruning a MAY or MUST: > > > > I'm not sure there's been enough opinion voiced to have a consensus on > this. > > I'd be happy with MAY or SHOULD, since it really it just an > optimization. > > IMO, optimizations should be expressed as MAY. > > To say "SHOULD" is to say that implementations that do not implement the > optimization should have a good reason for not doing so. I don't think > the presumption should be tilted that way. > > Joe > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment From caitlinb at broadcom.com Mon Jun 11 09:50:49 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 11 Jun 2007 09:50:49 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA20199851D@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D04116DA2@NT-IRVA-0750.brcm.ad.broadcom.com> Silvano Gai wrote: > Anoop, > > You are right; there is a tremendous scalability issue. > > My proposal is to completely drop the per-VLAN ISIS instance > and learn from data frames. Proven, scalable, it works. > An RFC does not tell any implementation how to store the bits and bytes used to retain configuration data. It merely specifies what information is retained, not how. I do not see how the method of learning the information is relevant to efficiently encoding it. If your presumption is that information learned form data frames is droppable then the efficiency in storage comes from giving an implementation the option to forget information that it does not find useful. But given that all implementations have finite limits on their storage it would seem to be an implicit part of any protocol that did not demand that the a node drop out of the network when it hit is memory limit. The only other possible optimization on information retention is if you allow assumptions about the data. Examples that come to mind, but which are probably not acceptable, include: a) assuming that a MAC address is unique. b) assuming that the topology is the same for all VLANs. That is the topology for any VLAN is a subset of "the" topology. Were you thinking of these or other encoding optimizations? Or is the scalability strictly a matter of gaining the option to forget? If so, why wouldn't the option to forget be valuable/necessary no matter what other decisions are made? From anoop at brocade.com Mon Jun 11 09:58:12 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 11 Jun 2007 09:58:12 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01081245@eusrcmw721.eamcs.ericsson.se> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0E16DA@HQ-EXCH-5.corp.brocade.com> Eric, I don't think it's worth continuing this discussion since it looks like there is agreement from several others that understand the scaling issues and it looks like there is consensus that it needs to be addressed. That's all that I was hoping to achieve. Thanks, Anoop > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] > Sent: Monday, June 11, 2007 8:55 AM > To: Anoop Ghanwani > Cc: rbridge at postel.org > Subject: RE: [rbridge] per-VLAN instances of IS-IS > > Anoop, > > Thanks for the well thought out reply. Please see > continuing discussion below... > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: Anoop Ghanwani [mailto:anoop at brocade.com] > > Sent: Friday, June 08, 2007 9:15 PM > > To: Eric Gray (LO/EUS) > > Cc: rbridge at postel.org > > Subject: RE: [rbridge] per-VLAN instances of IS-IS > > Importance: High > > > > > > > -----Original Message----- > > > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] > > > > > > Having per-VLAN instances of IS-IS helps to simplify > interactions - > > > thus increasing the likelihood of correct specification > leading to > > > interoperable implementations. > > > > > > This is accomplished at some cost in extremely complex > deployment > > > scenarios - such as the one you cite as an example > > > - but the cost is not nearly as high as you make it sound. > > > > > > Please see in-line comments below for further details. > > ... > > > > > > I am not convinced that you do. Having a per-VLAN IS-IS instance > > > greatly simplifies interactions, and allows us to > effectively define > > > RBridges in a single VLAN context > > > - leaving implementers free to implement inter-VLAN as already > > > implemented in 802.1Q (and related) implementation. > > > > > > This is more than just "useful." See below for further > > > clarification. > > > > I'm not quite sure I get it, but I'll look below. > > > > > > If an end rBridge > > > > participates in 1000 VLANs, it will have to maintain 1000 > > > > adjacencies. > > > > > > This is effectively true if we postulate only a single IS-IS > > > instance for all VLANs, because you have to scope routing > > > activities, link-state, etc. - on a per-VLAN basis even > if that is > > > the case. > > > > > > What you accomplish by using a single instance is to make it far > > > more difficult to describe, understand and correctly implement > > > RBridge routing protocol behaviors. > > > > I understand there will be some complexity in describing > all the VLANs > > and multicast addresses in a single instance, but I think it scales > > better than multiple instances. Why? Consider the > following picture: > > > > D > > | > > v1 -- A -- B -- C -- v1 > > | > > E > > > > A-E are RBridges. > > > > In this picture VLAN v1 is configured only on A and C. B > doesn't have > > v1 configured on it. Yet B needs to know about VLAN v1's > location in > > order to correctly prune its trees. > > Note that this configuration - if A-E were Q-bridges - would > be pathological, resulting in segmenting v1. > > I believe you've over-simplified interactions to make a > point, and the result is an example that does not make that point. > > In the above scenario, two simple approaches might have been > used that would not share the pathology of the given > example: > > 1) B might be configured to support v1 (flat model). > 2) A and C might be configured to tunnel (e.g. - Q-in-Q) > v1 via B, using a VID for which B is configured > (hierarchical model). > > It may be difficult to imagine why the second choice may be > useful, given the over-simplified example, but it is actually > quite likely to be useful in complex secnarios > - particularly involving edge bridges with very large numbers > of subscriber-facing ports with large overlap in VLAN > membership among edge bridges. > > These same approaches are also useful with RBridges. > > > > > What I'm getting at is that all RBridges in the network > need to know > > about all VLANs so that they can prune their trees for each VLAN > > correctly. > > Yes, in a flat model, this would be true. With the > alternative approach, only edge RBridges really have to know > about VLANs at the edge. Pruding in core RBridges occurs as > a consequence of Q-in-Q (or like > approach) configuration. > > > > > If you have an instance per VLAN we are talking about > maintain up to > > 4K instances in each Rbridge. > > And it's not unheard of to configure a 1000 VLANs in regular 802.1Q > > device. > > > > Yes. I believe this essentially makes my point. It is done > today, with today's bridges, hence scalability is apparently > not a real concern (yet). > > > > > > > Plus, it looks like for the per-VLAN IS-IS instance, > the RBridge > > > > network operates as single LAN segment. That would > mean having to > > > > go through DR/BDR election for each instance. > > > > > > And this would be correct behavior. An RBridge should only be > > > eligible for ingress and egress to a local VLAN is it is > configured > > > to participate in that local VLAN. Hence, it may only > participate > > > in DR election for VLANs on a local bridged LAN if it > participates > > > in those VLANs. > > > > See above for why this is not true. Or tell me how I can > do pruning > > without interior RBridges knowing about all VLANs. > > Use a hierarchical model model with VID-based tunneling. > > This is not a trivially easy configuration for some > real-world deployment scenarios we can all probably imagine. > But it is also not as trivially easy to break, once correctly > configured. > > > > > > This is central to one of the issues with specifying - > and correctly > > > implementing - RBridge functionality. > > > > > > There are optimizations we may consider at a later date that will > > > reduce - for example - messaging overhead, and there are already > > > existing optimizations to reduce the actual state maintenance > > > overhead to roughly the same as would be the case with a single > > > IS-IS instance. > > > > > > > > > > > Operating 100's of routers on a single LAN segment > would poses its > > > > own set of scaling issues. Having per VLAN instances > exacerbates > > > > the problem. > > > > > > Are there deployment scenarios in today's bridging > community where > > > we support this kind of network as a bidged network? > > > > Not in a bridged network. But if I recall correctly, and I > may be off > > since the charter may have changed since the beginning, one of the > > goals of rBridges was to be able to build large campuses without > > routers and routing-related configuration. Has that gone away? > > It is not atypical to find a campus with 20K users on 100's > of VLANs > > with ~100 nodes. > > That never was a goal. There are people who might like to > make it one, but that's (IMO) a malignant nightmare. > > There is no conceivable way to build devices that do > everything a router does without incorporating all of the > complexity (read > "cost") of a router into that device. If that's what > somebody really wants to do, then I'd like to hear how they > propose to design routing complexity - using a routing > protocol, and putting everything else a router does into it - > without the end product actually being MORE complex (read > "expensive") than anybody's current routing implementation. > > > > > > If there are not, then please recall that sclability of > the current > > > solution is targetted only for routghly the same size networks as > > > can be established with bridging today. > > > > Even with a network of today's bridges there would be > scaling issues > > if you had say 20-30 rBridges all trying to establish adjacencies > > between groups of themselves for a few 100 VLANs. It is > not atypical > > to have ~1000 VLANs configured in core switches. > > So, for IS-IS (or OSPF), issues with "adjacencies" are not > subject to the same sorts of concerns as (for example) BGP. > > What maintaining adjacencies really means is keeping up to > date on link state for a peer-set. What you're pointing out > is that - for many VLANs - the numer of peer-sets for which > link state has to be maintained may be large. > > Short of using hierarchical VLANs, this is competely and > absolutely unavoidable - unless we're going to accept the > consequences of specifying incorrect VLAN interactions as a > mechanism for effectively doing the same thing (i.e. - > effectively specifying hierarchy using some other means, or > simply hoping that people can somehow get it right). > > If you assume - as I do - that VLAN traffic is only supposed > to traverse links for which that VLAN is configured (either > explicitly or implicity), than not including a VLAN (again, > either explicitly or implicitly) in the configuration for a > specific link means that that VLAN's traffic is not supposed > to traverse that link. Period. > > > > > > You make it sound as if we're expected to solve problems with > > > RBridges for which solutions have never been specified > for routing. > > > > > > As for complicating the problem with VLAN instances, > think about how > > > complicated this scenario would be already with 802.1Q > VLANs running > > > any of today's spanning tree protocols. > > > > They scale just fine because they limit the maximum number of trees > > and have some VLANs share a tree. They don't try to run one STP > > instance per VLAN. > > Right. Assuming you've gotten your head around the notion of > hierarchical VLANs, how is this different? > > > > > > Also, note that in this same situation with routers in place of > > > RBridges, each router would most likely be required to have a > > > logical interface in each VLAN on every link to which it is > > > connected. > > > > This cannot be compared with routers. We're talking about bridging > > here. If we routed, we'd just terminate the MAC domain at the edge > > router and we wouldn't run into any of these issues. No sense in > > having a VLAN interface on every router in the campus. > > (One could design the network that way, but it would be a > really bad > > way to do it.) > > The point is that - if you had 1000 (or 4000) VLANs, in a > subnet, you would terminate a large percentage of those on > connected routers. > > If you imagine that there are many sch subnets (as seems to > be implied in your earlier comments), then this would also be > true for other physical interfaces on each router. > > Also, if you believe that RBridges may be used to replace > routers, then you compound this issue. > > > > > > In other words, this situation is just plain complicated - > > > irrespective of what you're trying to do to deal with it. > > > > > > > > > > > Have the scaling issues been considered at all? It > might actually > > > > be better to just use the core IS-IS instance. > > > > > > Scaling has been considered. Large increases in > scalability are not > > > a primary goal - relative to existing bridging, for example. > > > > > > RTFC! Increased scalability over existing bridging was > explicitly > > > NOT included in the charter as a goal. > > > > I thought I knew what the charter was but I went back and read it > > again anyway. I didn't find much there to work with with > respect to > > scalability requirements. > > It talks about a "problem statement and applicability" > > document. I'm not sure which of the published documents that is. > > It is the one that has that name. Joe Touch is the main > author/editor (with Radia Perlman). It apparently has been > allowed to expire. > > See: > > https://datatracker.ietf.org/public/idindex.cgi?command=id_det ail&id=147 > 71 > > for more information. > > By the way, it actually did not expire very long ago, so it > is likely that there is a new version in the works. > > However, the way that IETF charters typically work is that > they are exclusive, rather than inclusive, by default. In > other words, the fact that the charter does not explicitly > include increased scalability as a goal CANNOT be read to > mean that it may be a goal because it is not explicitly excluded. > > Per the charter, the design goals for the TRILL solution are: > > - Minimal or no configuration required > - Load-splitting among multiple paths > - Routing loop mitigation (possibly through a TTL field) > - Support of multiple points of attachment > - Support for broadcast and multicast > - No significant service delay after attachment > - No less secure than existing bridged solutions > > There is nothing in these explicitly listed goals that can be > stretched to include the notion of hugely increased scale, or > replacement of routers. > > > > > Anoop > > > From eric.gray at ericsson.com Mon Jun 11 10:24:04 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Mon, 11 Jun 2007 12:24:04 -0500 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E16DA@HQ-EXCH-5.corp.brocade.com> References: <941D5DCD8C42014FAF70FB7424686DCF01081245@eusrcmw721.eamcs.ericsson.se> <4C94DE2070B172459E4F1EE14BD2364E0E16DA@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF010813AA@eusrcmw721.eamcs.ericsson.se> Anoop, Two things: 1) From Radia's response, I think this is (again) a case of my getting confused by the strange use of "per-VLAN" in this context. On that score, I agree that there is little point in continuing that part of this discussion. Part of the reason for my confusion on this score is that I was under the impression that the specific scalability concern you raised doesn't exist any more. 2) On the issue of scalability - in general - the responses I've seen are not sufficient to justify your observation for the general issue of scalability. What I've seen is agreement on the specific issues associated with "per-VLAN" announcements - which, as Radia indicates, is going away. I believe we all need to get on that page (the one where that particular misnomer doesn't exist). Otherwise, we're going to continue to create confusion over the use of IS-IS instances (in general) and the impact that this has on scalability. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Monday, June 11, 2007 12:58 PM > To: Eric Gray (LO/EUS) > Cc: rbridge at postel.org > Subject: RE: [rbridge] per-VLAN instances of IS-IS > Importance: High > > > Eric, > > I don't think it's worth continuing this discussion > since it looks like there is agreement from several > others that understand the scaling issues and it > looks like there is consensus that it needs to be > addressed. That's all that I was hoping to achieve. > > Thanks, > Anoop > > > -----Original Message----- > > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] > > Sent: Monday, June 11, 2007 8:55 AM > > To: Anoop Ghanwani > > Cc: rbridge at postel.org > > Subject: RE: [rbridge] per-VLAN instances of IS-IS > > > > Anoop, > > > > Thanks for the well thought out reply. Please see > > continuing discussion below... > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: Anoop Ghanwani [mailto:anoop at brocade.com] > > > Sent: Friday, June 08, 2007 9:15 PM > > > To: Eric Gray (LO/EUS) > > > Cc: rbridge at postel.org > > > Subject: RE: [rbridge] per-VLAN instances of IS-IS > > > Importance: High > > > > > > > > > > -----Original Message----- > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] > > > > > > > > Having per-VLAN instances of IS-IS helps to simplify > > interactions - > > > > thus increasing the likelihood of correct specification > > leading to > > > > interoperable implementations. > > > > > > > > This is accomplished at some cost in extremely complex > > deployment > > > > scenarios - such as the one you cite as an example > > > > - but the cost is not nearly as high as you make it sound. > > > > > > > > Please see in-line comments below for further details. > > > ... > > > > > > > > I am not convinced that you do. Having a per-VLAN > IS-IS instance > > > > greatly simplifies interactions, and allows us to > > effectively define > > > > RBridges in a single VLAN context > > > > - leaving implementers free to implement inter-VLAN as already > > > > implemented in 802.1Q (and related) implementation. > > > > > > > > This is more than just "useful." See below for further > > > > clarification. > > > > > > I'm not quite sure I get it, but I'll look below. > > > > > > > > If an end rBridge > > > > > participates in 1000 VLANs, it will have to maintain 1000 > > > > > adjacencies. > > > > > > > > This is effectively true if we postulate only a single IS-IS > > > > instance for all VLANs, because you have to scope routing > > > > activities, link-state, etc. - on a per-VLAN basis even > > if that is > > > > the case. > > > > > > > > What you accomplish by using a single instance is to > make it far > > > > more difficult to describe, understand and correctly implement > > > > RBridge routing protocol behaviors. > > > > > > I understand there will be some complexity in describing > > all the VLANs > > > and multicast addresses in a single instance, but I think > it scales > > > better than multiple instances. Why? Consider the > > following picture: > > > > > > D > > > | > > > v1 -- A -- B -- C -- v1 > > > | > > > E > > > > > > A-E are RBridges. > > > > > > In this picture VLAN v1 is configured only on A and C. B > > doesn't have > > > v1 configured on it. Yet B needs to know about VLAN v1's > > location in > > > order to correctly prune its trees. > > > > Note that this configuration - if A-E were Q-bridges - would > > be pathological, resulting in segmenting v1. > > > > I believe you've over-simplified interactions to make a > > point, and the result is an example that does not make that point. > > > > In the above scenario, two simple approaches might have been > > used that would not share the pathology of the given > > example: > > > > 1) B might be configured to support v1 (flat model). > > 2) A and C might be configured to tunnel (e.g. - Q-in-Q) > > v1 via B, using a VID for which B is configured > > (hierarchical model). > > > > It may be difficult to imagine why the second choice may be > > useful, given the over-simplified example, but it is actually > > quite likely to be useful in complex secnarios > > - particularly involving edge bridges with very large numbers > > of subscriber-facing ports with large overlap in VLAN > > membership among edge bridges. > > > > These same approaches are also useful with RBridges. > > > > > > > > What I'm getting at is that all RBridges in the network > > need to know > > > about all VLANs so that they can prune their trees for each VLAN > > > correctly. > > > > Yes, in a flat model, this would be true. With the > > alternative approach, only edge RBridges really have to know > > about VLANs at the edge. Pruding in core RBridges occurs as > > a consequence of Q-in-Q (or like > > approach) configuration. > > > > > > > > If you have an instance per VLAN we are talking about > > maintain up to > > > 4K instances in each Rbridge. > > > And it's not unheard of to configure a 1000 VLANs in > regular 802.1Q > > > device. > > > > > > > Yes. I believe this essentially makes my point. It is done > > today, with today's bridges, hence scalability is apparently > > not a real concern (yet). > > > > > > > > > > Plus, it looks like for the per-VLAN IS-IS instance, > > the RBridge > > > > > network operates as single LAN segment. That would > > mean having to > > > > > go through DR/BDR election for each instance. > > > > > > > > And this would be correct behavior. An RBridge should only be > > > > eligible for ingress and egress to a local VLAN is it is > > configured > > > > to participate in that local VLAN. Hence, it may only > > participate > > > > in DR election for VLANs on a local bridged LAN if it > > participates > > > > in those VLANs. > > > > > > See above for why this is not true. Or tell me how I can > > do pruning > > > without interior RBridges knowing about all VLANs. > > > > Use a hierarchical model model with VID-based tunneling. > > > > This is not a trivially easy configuration for some > > real-world deployment scenarios we can all probably imagine. > > But it is also not as trivially easy to break, once correctly > > configured. > > > > > > > > > This is central to one of the issues with specifying - > > and correctly > > > > implementing - RBridge functionality. > > > > > > > > There are optimizations we may consider at a later date > that will > > > > reduce - for example - messaging overhead, and there > are already > > > > existing optimizations to reduce the actual state maintenance > > > > overhead to roughly the same as would be the case with a single > > > > IS-IS instance. > > > > > > > > > > > > > > Operating 100's of routers on a single LAN segment > > would poses its > > > > > own set of scaling issues. Having per VLAN instances > > exacerbates > > > > > the problem. > > > > > > > > Are there deployment scenarios in today's bridging > > community where > > > > we support this kind of network as a bidged network? > > > > > > Not in a bridged network. But if I recall correctly, and I > > may be off > > > since the charter may have changed since the beginning, > one of the > > > goals of rBridges was to be able to build large campuses without > > > routers and routing-related configuration. Has that gone away? > > > It is not atypical to find a campus with 20K users on 100's > > of VLANs > > > with ~100 nodes. > > > > That never was a goal. There are people who might like to > > make it one, but that's (IMO) a malignant nightmare. > > > > There is no conceivable way to build devices that do > > everything a router does without incorporating all of the > > complexity (read > > "cost") of a router into that device. If that's what > > somebody really wants to do, then I'd like to hear how they > > propose to design routing complexity - using a routing > > protocol, and putting everything else a router does into it - > > without the end product actually being MORE complex (read > > "expensive") than anybody's current routing implementation. > > > > > > > > > If there are not, then please recall that sclability of > > the current > > > > solution is targetted only for routghly the same size > networks as > > > > can be established with bridging today. > > > > > > Even with a network of today's bridges there would be > > scaling issues > > > if you had say 20-30 rBridges all trying to establish adjacencies > > > between groups of themselves for a few 100 VLANs. It is > > not atypical > > > to have ~1000 VLANs configured in core switches. > > > > So, for IS-IS (or OSPF), issues with "adjacencies" are not > > subject to the same sorts of concerns as (for example) BGP. > > > > What maintaining adjacencies really means is keeping up to > > date on link state for a peer-set. What you're pointing out > > is that - for many VLANs - the numer of peer-sets for which > > link state has to be maintained may be large. > > > > Short of using hierarchical VLANs, this is competely and > > absolutely unavoidable - unless we're going to accept the > > consequences of specifying incorrect VLAN interactions as a > > mechanism for effectively doing the same thing (i.e. - > > effectively specifying hierarchy using some other means, or > > simply hoping that people can somehow get it right). > > > > If you assume - as I do - that VLAN traffic is only supposed > > to traverse links for which that VLAN is configured (either > > explicitly or implicity), than not including a VLAN (again, > > either explicitly or implicitly) in the configuration for a > > specific link means that that VLAN's traffic is not supposed > > to traverse that link. Period. > > > > > > > > > You make it sound as if we're expected to solve problems with > > > > RBridges for which solutions have never been specified > > for routing. > > > > > > > > As for complicating the problem with VLAN instances, > > think about how > > > > complicated this scenario would be already with 802.1Q > > VLANs running > > > > any of today's spanning tree protocols. > > > > > > They scale just fine because they limit the maximum > number of trees > > > and have some VLANs share a tree. They don't try to run one STP > > > instance per VLAN. > > > > Right. Assuming you've gotten your head around the notion of > > hierarchical VLANs, how is this different? > > > > > > > > > Also, note that in this same situation with routers in place of > > > > RBridges, each router would most likely be required to have a > > > > logical interface in each VLAN on every link to which it is > > > > connected. > > > > > > This cannot be compared with routers. We're talking > about bridging > > > here. If we routed, we'd just terminate the MAC domain > at the edge > > > router and we wouldn't run into any of these issues. No sense in > > > having a VLAN interface on every router in the campus. > > > (One could design the network that way, but it would be a > > really bad > > > way to do it.) > > > > The point is that - if you had 1000 (or 4000) VLANs, in a > > subnet, you would terminate a large percentage of those on > > connected routers. > > > > If you imagine that there are many sch subnets (as seems to > > be implied in your earlier comments), then this would also be > > true for other physical interfaces on each router. > > > > Also, if you believe that RBridges may be used to replace > > routers, then you compound this issue. > > > > > > > > > In other words, this situation is just plain complicated - > > > > irrespective of what you're trying to do to deal with it. > > > > > > > > > > > > > > Have the scaling issues been considered at all? It > > might actually > > > > > be better to just use the core IS-IS instance. > > > > > > > > Scaling has been considered. Large increases in > > scalability are not > > > > a primary goal - relative to existing bridging, for example. > > > > > > > > RTFC! Increased scalability over existing bridging was > > explicitly > > > > NOT included in the charter as a goal. > > > > > > I thought I knew what the charter was but I went back and read it > > > again anyway. I didn't find much there to work with with > > respect to > > > scalability requirements. > > > It talks about a "problem statement and applicability" > > > document. I'm not sure which of the published documents that is. > > > > It is the one that has that name. Joe Touch is the main > > author/editor (with Radia Perlman). It apparently has been > > allowed to expire. > > > > See: > > > > https://datatracker.ietf.org/public/idindex.cgi?command=id_det > ail&id=147 > > 71 > > > > for more information. > > > > By the way, it actually did not expire very long ago, so it > > is likely that there is a new version in the works. > > > > However, the way that IETF charters typically work is that > > they are exclusive, rather than inclusive, by default. In > > other words, the fact that the charter does not explicitly > > include increased scalability as a goal CANNOT be read to > > mean that it may be a goal because it is not explicitly excluded. > > > > Per the charter, the design goals for the TRILL solution are: > > > > - Minimal or no configuration required > > - Load-splitting among multiple paths > > - Routing loop mitigation (possibly through a TTL field) > > - Support of multiple points of attachment > > - Support for broadcast and multicast > > - No significant service delay after attachment > > - No less secure than existing bridged solutions > > > > There is nothing in these explicitly listed goals that can be > > stretched to include the notion of hugely increased scale, or > > replacement of routers. > > > > > > > > Anoop > > > > > > From Radia.Perlman at sun.com Thu Jun 14 21:53:53 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 14 Jun 2007 21:53:53 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0E1572@HQ-EXCH-5.corp.brocade.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1572@HQ-EXCH-5.corp.brocade.com> Message-ID: <46721B61.9000201@sun.com> I'm catching up after travelling, so if someone else answered this, sorry about that. Anoop Ghanwani wrote: > > What I'm getting at is that all RBridges in the > network need to know about all VLANs so that they > can prune their trees for each VLAN correctly. Yes--all the intermediate RBridges need to know which edge RBridges (where an "edge RBridge is one that is acting as a Designated RBridge on a link) are attached to which VLANs. But an RBridge that is not an edge RBridge does *not* need to know about any endnodes. And an RBridge that is not the DR for a link in VLAN A does *not* need to know about endnodes in VLAN A. So...mostly I'm confused (and I think others are) about what is meant by "a per-VLAN instance of IS-IS". When I was using the phrase I meant the piece of IS-IS that announced VLAN A endnodes, and that information only would have to go to RBridges that are Designated RBridge for a link in VLAN A. But, as Donald said, we are switching to having the default case being that the mapping between (ingress RBridge, source endnode) is learned by the egress RBridge that decapsulates a data packet onto its link. That way only Designated RBridges learn endnode locations, and only learn endnode locations that are talking to endnodes on that RBridge's link. We are also allowing optional advertisement of attached endnodes in VLAN A, and optional learning from these, in a "per-VLAN IS-IS instance", which does nothing but advertise the location of endnodes, and is broadcast only to Designated RBridges attached to that VLAN. The intention is that endnodes announced in this way would be endnodes that are definitively learned through some sort of layer 2 enrollment protocol. Radia From Radia.Perlman at sun.com Thu Jun 14 22:30:42 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 14 Jun 2007 22:30:42 -0700 Subject: [rbridge] TRILL header format, understanding the pros and cons (was "multicastpruning") In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA20199851C@nuova-ex1.hq.nuovaimpresa.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790029FB149@de01exm64.ds.mot.com> <46686A8B.7020807@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA20199851C@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <46722402.5030802@sun.com> Sorry, Silvano, I do believe it is worthwhile to calmly list all points for and against something even if the issue has been decided. I understand the problem of a committee being like the proverbial donkey starving because it is equidistant between two bales of hay and can't decide which one to go to. And I understand also how at some point, unless something is really broken, it's better to just go off in the original direction rather than never converging. However, I believe it is also always a useful exercise to summarize all the arguments in one place. And sometimes when doing so, it might make sense to change the decision. So...the way the TRILL header is now, intermediate RBridges have to find the inner frame and look for: a) VLAN tag (to do VLAN pruning) b) the original destination address (in case it's an IP multicast, in order to do IP multicast pruning) c) the IP protocol type (for IGMP), and parsing enough of the IGMP message to know that this is an IGMP reply (in order for it to get sent only to links with IP multicast routers) Moving the VLAN tag into the TRILL header (as a fixed field rather than an option) makes the packet 2 bytes longer when there is no inner VLAN, but makes the packet 2 bytes shorter when there was an inner VLAN (because the VLAN can be deleted from the inner frame). Signalling that the packet is an IGMP reply (so should be pruned to only send to links with IP multicast routers) can be done with a single bit in the TRILL header. Moving the original destination address into the TRILL header could theoretically be done without adding to the length of the packet, by merely considering the first 6 bytes of the packet to be the final 6 bytes of the TRILL header. So the cost of moving these into the TRILL header are 2 bytes +1 bit, and actually the 2 byte cost is only a cost when there was no VLAN tag in the inner header. I'd think the advantages of doing so would be a) easier for transit RBridges to make a forwarding decision b) in a sense more "architecturally pure" since the transit RBridges would not need to look at anything more than the TRILL header c) if 802 invented a new kind of tag, since tags are not TLV encoded, transit RBridges would not need to be upgraded to understand the new tag in order to find the fields in the inner packet. I'm not saying we have to change the TRILL format...I just want to carefully understand the pros and cons. What arguments have I missed? (either more arguments for moving everything necessary for forwarding into the TRILL header, or against it). Thanks, Radia Silvano Gai wrote: > Folks, > > We had a detailed discussion on the header format which included all the > points that Radia list below. We had a strong consensus on one solution. > The WG chairs confirmed this consensus on the mailing list. > > There is no new piece of information. We have not discovered anything > that was not known at the time of the consensus. I propose we stick with > the current header format. > > If we continue to change things we will never converge and the frame > format needs to be stable ASAP. > > If we reopen the frame format discussion, then I want to reopen nickname > vs address ;-) :-) :-) ;-) > > -- Silvano > > >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] >> > On > >> Behalf Of Radia Perlman >> Sent: Thursday, June 07, 2007 1:29 PM >> To: Eastlake III Donald-LDE008 >> Cc: rbridge at postel.org >> Subject: Re: [rbridge] multicast pruning in TRILL >> >> (revisiting the issue of moving whatever is necessary for transit >> bridges to look at >> for pruning of multicasts (VLAN tag and destination multicast address) >> to the portion of the frame outside the tunnel, i.e., either the TRILL >> header or >> the outer header) >> >> The mailing list archives are daunting, even though I've been trying >> > to > >> follow it all along. >> I'd like to see the arguments both sides of this issue summarized >> > rather > >> than >> pointing people at the mailing list -- just now I tried to review the >> mailing list >> on this issue and got discouraged. It never hurts to summarize the >> issues again. >> >> I'll start by writing down concisely what I do remember, and perhaps >> people can >> concisely add other arguments: >> >> a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer >> bits total (since you >> don't need the Ethertype) to include it as a tag in the inner header), >> it's easier to find since >> transit RBridges don't need to find the inner header, >> the TRILL header is still fixed length. Minuses: It takes up room >> > even > >> when there is >> no VLAN tag in the inner header >> >> b) moving VLAN tag to TRILL header as an option: Pluses: it only takes >> up room >> when there is a VLAN tag in the inner frame. Minus: it makes the TRILL >> header >> variable length >> >> c) moving the inner multicast address (for IP multicast pruning) into >> the TRILL header: I don't think this was discussed. But it would >> > clearly > >> have to be done as an option in the TRILL >> header since we wouldn't want to make space for it in the TRILL header >> on unicast >> packets, so it would make the TRILL header variable length >> >> d) copying the inner multicast address (for IP multicast pruning) into >> the *outer* Ethernet >> header. I don't think this was discussed at all on the mailing list. I >> assume that it wouldn't >> confuse non-RBridge devices listening to that multicast address that >> might hear the >> packet because the Ethertype would be TRILL, so they'd (hopefully) >> > drop > >> it without >> getting confused. >> >> Whatever I've missed, can someone add to this? >> >> Thanks, >> >> Radia >> >> >> Eastlake III Donald-LDE008 wrote: >> >>> @@@ Indeed, for precisely the reason you give, it was and remains my >>> strong personal opinion that the VLAN-tag information should be part >>> > of > >>> the TRILL Header where it would be at least 14 bytes earlier and you >>> would also save the 2 bytes of tag Ethertype. It contains priority >>> > as > >>> well as the VLAN ID info. >>> >>> @@@ However, the working group appears to be of the opinion that the >>> VLAN-tag should be inserted inside the inner frame with an >>> > Ethertype. > >>> See the May mail here which includes arguments on the other side of >>> > the > >>> issue: >>> http://www.postel.org/pipermail/rbridge/2007-May/thread.html. >>> >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> From touch at ISI.EDU Fri Jun 15 04:43:57 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 15 Jun 2007 04:43:57 -0700 Subject: [rbridge] TRILL header format, understanding the pros and cons (was "multicastpruning") In-Reply-To: <46722402.5030802@sun.com> References: <4C94DE2070B172459E4F1EE14BD2364E0E1057@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790029FB149@de01exm64.ds.mot.com> <46686A8B.7020807@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA20199851C@nuova-ex1.hq.nuovaimpresa.com> <46722402.5030802@sun.com> Message-ID: <46727B7D.60808@isi.edu> I'll add some info in the spirit of summarizing the reasons for a decision already made. Radia Perlman wrote: ... > Moving the VLAN tag into the TRILL header (as a fixed field > rather than an option) makes the packet 2 bytes longer when there is no > inner VLAN, > but makes the packet 2 bytes shorter when there was an inner VLAN > (because the > VLAN can be deleted from the inner frame). I disagree that TRILL operations should ever modify their payload. Even when done only at the ingress/egress, and only as an optimization, this means that separate code is needed to parse headers inside vs. outside, rather than just adding code to parse TRILL headers. Such code would be used by trace debuggers, as well as by TRILL devices supporting other fields that "should have been copied" into the TRILL header had we known about them. Any existing ethernet header that can be parsed now (or in the future) in its original place can be parsed by TRILL using a fixed offset. There's zero utility in copying or moving data - it presents opportunities for more bugs and complexity. > Signalling that the packet is an IGMP reply (so should be pruned to only > send to > links with IP multicast routers) can be done with a single bit in the > TRILL header. The same issue applies here. ... > So the cost of moving these into the TRILL header are 2 bytes +1 bit, and > actually the 2 byte cost is only a cost when there was no VLAN tag in > the inner header. > > I'd think the advantages of doing so would be I disagree that the following are agreed... > a) easier for transit RBridges to make a forwarding decision It is irrelevant where a header value is so long as it is in a fixed location. There could be minor efficiencies in grabbing data in large chunks, but such chunks are just as likely to grab both TRILL and the inner ethernet headers in their entirety. > b) in a sense more "architecturally pure" since the transit RBridges > would not > need to look at anything more than the TRILL header This is a fallacy. It is not architecturally "pure" to move a header; it's still a field of the inner header, and moving it - if anything - adds pollutes the architecture because it gives the misimpression that TRILL is making decisions on only _its_ information. > c) if 802 invented a new kind of tag, since tags are not TLV encoded, > transit RBridges > would not need to be upgraded to understand the new tag in order to find the > fields in the inner packet. If 802 invented a new kind of tag, it's possible it wouldn't fit in the current TRILL header, which means everything in TRILL would need to be updated anyway. Also, I don't believe there will be devices that support only transit or only ingress/egress; ethernet plug-and-play compatibility means that every device ought to support both functions (albeit with different efficiency or scale in different devices). > I'm not saying we have to change the TRILL format...I just want to > carefully understand > the pros and cons. What arguments have I missed? (either more arguments > for moving > everything necessary for forwarding into the TRILL header, or against it). I think you missed the pros, and omitted the cons (most of which you posed as pros anyway). 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/20070615/ae8196ab/signature.bin From anoop at brocade.com Fri Jun 15 11:14:43 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 15 Jun 2007 11:14:43 -0700 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <46721B61.9000201@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E12BAC2@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Thursday, June 14, 2007 9:54 PM > To: Anoop Ghanwani > Cc: Eric Gray (LO/EUS); rbridge at postel.org > Subject: Re: [rbridge] per-VLAN instances of IS-IS > > I'm catching up after travelling, so if someone else answered this, > sorry about that. > > Anoop Ghanwani wrote: > > > > What I'm getting at is that all RBridges in the > > network need to know about all VLANs so that they > > can prune their trees for each VLAN correctly. > > Yes--all the intermediate RBridges need to know which edge > RBridges (where > an "edge RBridge is one that is acting as a Designated > RBridge on a link) > are attached to which VLANs. > > But an RBridge that is not an edge RBridge does *not* need to > know about > any endnodes. And an RBridge that is not the DR for a link in > VLAN A does > *not* need to know about endnodes in VLAN A. That is correct. However, even in that scenario, I don't think it makes sense to have a per-VLAN IS-IS instance - maintaining the adjacencies for a given instance won't scale to large numbers of VLANs. I would probably be better to just use the single instance and encode the information in such a way that the receiver can quickly determine what it needs to care about. However, as you point out below, I think it makes more sense to solve this problem using learning at the edge RBridges. But that doesn't solve the problem for multicasts so those will have to be advertised anyway, and they will have to be sent to all Rbridges in the network. > So...mostly I'm confused (and I think others are) about what > is meant by > "a per-VLAN instance of IS-IS". When I was using the phrase I meant > the piece of IS-IS that announced VLAN A endnodes, and that > information > only would have to go to RBridges that are Designated RBridge > for a link > in VLAN A. > > But, as Donald said, we are switching to having the default > case being > that the > mapping between (ingress RBridge, source endnode) is learned > by the egress > RBridge that decapsulates a data packet onto its link. That way only > Designated > RBridges learn endnode locations, and only learn endnode > locations that are > talking to endnodes on that RBridge's link. > > We are also allowing optional advertisement of attached > endnodes in VLAN A, > and optional learning from these, in a "per-VLAN IS-IS > instance", which does > nothing but advertise the location of endnodes, and is > broadcast only to > Designated RBridges attached to that VLAN. The intention is > that endnodes > announced in this way would be endnodes that are definitively learned > through > some sort of layer 2 enrollment protocol. If you absolutely had to have multiple IS-IS instances, it might make sense to have some number 'n' and then define a mapping of VLANs to each instance. Having 4K instances of IS-IS running in an RBridge won't scale. Anoop From Donald.Eastlake at motorola.com Fri Jun 15 12:40:36 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 15 Jun 2007 15:40:36 -0400 Subject: [rbridge] per-VLAN instances of IS-IS In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E12BAC2@HQ-EXCH-5.corp.brocade.com> References: <46721B61.9000201@sun.com> <4C94DE2070B172459E4F1EE14BD2364E12BAC2@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D979002AC2860@de01exm64.ds.mot.com> You only have an instance of IS-IS for VLAN x in Rbridge y is Rbridge y is advertising that it has directly connected end stations in VLAN x. Is it plausible that an Rbridge would be reporting that it has directly connected end stations in all of 4K VLANs? Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani Sent: Friday, June 15, 2007 2:15 PM To: Radia Perlman Cc: rbridge at postel.org Subject: Re: [rbridge] per-VLAN instances of IS-IS ... If you absolutely had to have multiple IS-IS instances, it might make sense to