From ddutt at cisco.com Wed Aug 1 10:43:47 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 01 Aug 2007 10:43:47 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags In-Reply-To: <46AE9B0D.4080606@sun.com> References: <46AE9B0D.4080606@sun.com> Message-ID: <46B0C653.8010304@cisco.com> OK, based on emails from James Carlson and Radia, I went back and thought about my reasons for objecting to the suggested proposal. I also spoke to some field engineers to validate my understanding of what I thought the issues were. There are two issues that we're dealing with here: - Simplifying DRB election to conduct it only on VLAN 1 - Merging partitioned VLANs. I'd like to separate the two issues. Let me discuss only the first issue, the simplified DRB election in this email. I'll send out a separate email on the other issue. Assuming VLAN 1 exists everywhere is an acceptable alternative. I was informed that even with STP, customers enable VLAN 1 and allow only control traffic on it and not data traffic. If we have VLAN 1 present as a common configuration, then running DRB only on VLAN 1 and following Radia's proposal (or fixing it to work) seems acceptable, except for one caveat. However, in the event of a misconfiguration and VLAN 1 not being present, while the scheme proposed partitions the network and prevents loops, it seems to me that there is a period during which temporary loops can happen and duplicate frames are delivered by two DRBs. This seems unacceptable to me from a customer point of view. If we can fix this temporary loop (or someone can explain to me why there are no temporary loops), I'd be willing to support this proposal. BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of customer networks and so we cannot assume or mandate their being there. Dinesh Radia Perlman wrote: > I had a conversation with Anoop, and he is (quite understandably) > uneasy about sending IS-IS Hellos tagged with every VLAN. So he > made the following suggestion, which I think makes sense. > > a) declare that bridges must be configured > so that VLAN 1 (default VLAN) must not be > partitioned on a layer 2 cloud. We will detect the misconfiguration > if it occurs (see d)) so that we at least do not have loops, but TRILL > will not > stand on its head to support what will be declared a gross misconfiguration. > > b) Run the IS-IS election tagged with VLAN 1. Each RBridge has > the following information in its IS-IS Hello: > > . I am R1 > . I hear Hellos from {R2, R3, R7, R11} > . If I am DRB, the pseudonode name will be R1.59 > . My priority for the set of VLANs {A, D, W} is 7 > . My priority for the set of VLANs {B, C, F, G, H} is 3 > > c) If R1 becomes DRB for at least one of the VLANs on the cloud, > then R1 announces, in R1's LSP on behalf of pseudonode R1.59, > the ID of the root bridge on the primary spanning tree > instance for that layer 2 cloud, along with the set of VLANs for which > R1 is DRB on that cloud. > > Note: The current draft spec isn't clear what information R1 reports in > the pseudonode > LSP and what it reports in its own LSP. > I'm suggesting reporting the bridge ID and > set of VLANs in the pseudonode LSP. > > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, > and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A > listed as one of the VLANs, this indicates that VLAN 1 on that layer > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding > data to/from that cloud for VLAN A. Use ID as a tie breaker, so > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN A > traffic to and from the port that has root bridge r11. > This is the behavior that will occur if VLAN 1 on that port is > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would > have seen each other's Hellos and not both think they are DRB for VLAN A (or > any other VLAN). > > e) This proposal supports multiple DRBs on a cloud for load splitting > based on VLANs, since the RBridges can have different priorities > for different VLANs. It still requires only sending one Hello, tagged > with VLAN 1. R2 should > not panic if R2 notices that R1.59 has the same root bridge as on > a port on which R2 is DRB, if R1.59's listed set of VLANs does not > include any VLANs for which R2 is DRB on the link with > that root bridge. If there is only partial overlap > of VLAN IDs, say the overlap is VLANs {D, F, and H}, > then (the loser based on ID tie-breaker) will stop forwarding traffic > to/from that link that is tagged with VLANs D, F, or H. > > f) If some VLAN, say VLAN C, is actually partitioned, then the > result of this is that some VLAN C endnodes on that layer 2 cloud > will be orphaned. We will choose NOT to solve that. > > > The result of this proposal is that > RBridges will only need to send IS-IS Hellos tagged > with VLAN 1, and the only thing it does NOT solve (over > the current proposal of sending Hellos with every possible VLAN tag on > each port) is that sometimes endnodes might get orphaned if you have > a partitioned VLAN. > > > We *could* in that case, if someone *actually wanted* to have VLAN A > partitioned on that cloud, configure the RBridges on that layer 2 > cloud to explicitly run a different election > for VLAN A (and note in the pseudonode LSP that VLAN A had > an explicit election tagged with VLAN A so that if there were > two DRBs they wouldn't panic). But I'd prefer not solving this case and > keeping it simpler (and safer). > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Radia.Perlman at sun.com Wed Aug 1 14:37:38 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 01 Aug 2007 14:37:38 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags In-Reply-To: <46B0C653.8010304@cisco.com> References: <46AE9B0D.4080606@sun.com> <46B0C653.8010304@cisco.com> Message-ID: <46B0FD22.7030200@sun.com> Dinesh, I think you are right that there can be a temporary loop due to a partitioned VLAN 1. And I think we can make it sufficiently unlikely to occur with a suggestion I'll make after I explain the problem. The temporary loop would be if R1 and R2, on the same layer 2 cloud, have connectivity through VLAN A but not VLAN 1. So there would be two DRBs, on both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 and R2.62, and both would claim to be connected to both VLAN A and VLAN 1, and both would claim the same root bridge, say 5134. A multicast tagged with VLAN 1 would not be too much of a problem because anything R1 decapsulates onto that VLAN-1-partitioned cloud would not make it through the partitioned cloud to R2. But since we are not running the DRB election tagged with VLAN A, R1 and R2 do not realize that they can talk via VLAN A. Therefore, a VLAN A-tagged packet would get picked up by both R1 and R2, and both would assume they are DRB. Also, if R1 receives a (inner header) VLAN-A tagged frame from the campus, R1 will decapsulate it onto the layer 2 cloud as a VLAN-A tagged packet, and R2 will see it and re-encapsulate it onto the campus, and R1 would see it again and decapsulate it, etc. This loop will eventually be fixed when R1 sees the LSP from pseudonode R2.62 indicating that the root bridge is 5134, since R1 will also think that the cloud that R1 is DRB for has root bridge 5134. So here's a possible fix: R1 does not decapsulate a multidestination packet with ingress RBridge R2 unless R1 has an LSP from R2, and has LSPs from all pseudonodes that R2 claims (in R2's LSP) to be DRB for. Note that I'm suggesting adding another flag in the neighbor list in R2's LSP saying "not only am I attached to this pseudonode, but I am DRB for it". If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if the root bridge listed is the same as the one for the link on which R2 would like to decapsulate, and if it is, then don't decapsulate. We were already saying that if R1 notices that R2.79 has the same root bridge as a link R1 wants to be DRB for that one of R1 or R2 would lose, based on a tie-breaker based on ID, and stop forwarding traffic to/from the link. What I'm suggesting is that you also don't forward multidestination traffic to/from a link if you don't yet have all the associated LSP information from the ingress RBridge that can assure you there isn't a common root bridge. Radia Dinesh G Dutt wrote: > OK, based on emails from James Carlson and Radia, I went back and > thought about my reasons for objecting to the suggested proposal. I > also spoke to some field engineers to validate my understanding of > what I thought the issues were. > > There are two issues that we're dealing with here: > - Simplifying DRB election to conduct it only on VLAN 1 > - Merging partitioned VLANs. > > I'd like to separate the two issues. Let me discuss only the first > issue, the simplified DRB election in this email. I'll send out a > separate email on the other issue. > > Assuming VLAN 1 exists everywhere is an acceptable alternative. I was > informed that even with STP, customers enable VLAN 1 and allow only > control traffic on it and not data traffic. If we have VLAN 1 present > as a common configuration, then running DRB only on VLAN 1 and > following Radia's proposal (or fixing it to work) seems acceptable, > except for one caveat. > > However, in the event of a misconfiguration and VLAN 1 not being > present, while the scheme proposed partitions the network and prevents > loops, it seems to me that there is a period during which temporary > loops can happen and duplicate frames are delivered by two DRBs. This > seems unacceptable to me from a customer point of view. If we can fix > this temporary loop (or someone can explain to me why there are no > temporary loops), I'd be willing to support this proposal. > > BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of > customer networks and so we cannot assume or mandate their being there. > > Dinesh > Radia Perlman wrote: >> I had a conversation with Anoop, and he is (quite understandably) >> uneasy about sending IS-IS Hellos tagged with every VLAN. So he >> made the following suggestion, which I think makes sense. >> >> a) declare that bridges must be configured >> so that VLAN 1 (default VLAN) must not be >> partitioned on a layer 2 cloud. We will detect the misconfiguration >> if it occurs (see d)) so that we at least do not have loops, but >> TRILL will not >> stand on its head to support what will be declared a gross >> misconfiguration. >> >> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has >> the following information in its IS-IS Hello: >> >> . I am R1 >> . I hear Hellos from {R2, R3, R7, R11} >> . If I am DRB, the pseudonode name will be R1.59 >> . My priority for the set of VLANs {A, D, W} is 7 >> . My priority for the set of VLANs {B, C, F, G, H} is 3 >> >> c) If R1 becomes DRB for at least one of the VLANs on the cloud, >> then R1 announces, in R1's LSP on behalf of pseudonode R1.59, >> the ID of the root bridge on the primary spanning tree >> instance for that layer 2 cloud, along with the set of VLANs for which >> R1 is DRB on that cloud. >> >> Note: The current draft spec isn't clear what information R1 reports >> in the pseudonode >> LSP and what it reports in its own LSP. >> I'm suggesting reporting the bridge ID and >> set of VLANs in the pseudonode LSP. >> >> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, >> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A >> listed as one of the VLANs, this indicates that VLAN 1 on that layer >> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding >> data to/from that cloud for VLAN A. Use ID as a tie breaker, so >> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding >> VLAN A >> traffic to and from the port that has root bridge r11. >> This is the behavior that will occur if VLAN 1 on that port is >> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 >> would >> have seen each other's Hellos and not both think they are DRB for >> VLAN A (or >> any other VLAN). >> >> e) This proposal supports multiple DRBs on a cloud for load splitting >> based on VLANs, since the RBridges can have different priorities >> for different VLANs. It still requires only sending one Hello, tagged >> with VLAN 1. R2 should >> not panic if R2 notices that R1.59 has the same root bridge as on >> a port on which R2 is DRB, if R1.59's listed set of VLANs does not >> include any VLANs for which R2 is DRB on the link with >> that root bridge. If there is only partial overlap >> of VLAN IDs, say the overlap is VLANs {D, F, and H}, >> then (the loser based on ID tie-breaker) will stop forwarding traffic >> to/from that link that is tagged with VLANs D, F, or H. >> >> f) If some VLAN, say VLAN C, is actually partitioned, then the >> result of this is that some VLAN C endnodes on that layer 2 cloud >> will be orphaned. We will choose NOT to solve that. >> >> >> The result of this proposal is that >> RBridges will only need to send IS-IS Hellos tagged >> with VLAN 1, and the only thing it does NOT solve (over >> the current proposal of sending Hellos with every possible VLAN tag on >> each port) is that sometimes endnodes might get orphaned if you have >> a partitioned VLAN. >> >> >> We *could* in that case, if someone *actually wanted* to have VLAN A >> partitioned on that cloud, configure the RBridges on that layer 2 >> cloud to explicitly run a different election >> for VLAN A (and note in the pseudonode LSP that VLAN A had >> an explicit election tagged with VLAN A so that if there were >> two DRBs they wouldn't panic). But I'd prefer not solving this case and >> keeping it simpler (and safer). >> >> Radia >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > From sgai at nuovasystems.com Thu Aug 2 14:59:42 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 2 Aug 2007 14:59:42 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E3CABAE@HQ-EXCH-5.corp.brocade.com> References: <46AE9B0D.4080606@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com><46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com><46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E3CABAE@HQ-EXCH-5.corp.brocade.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201D777FE@nuova-ex1.hq.nuovaimpresa.com> Anoop, Inline, > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Tuesday, July 31, 2007 4:06 PM > To: Silvano Gai; Radia Perlman; Dinesh G Dutt > Cc: rbridge at postel.org > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > withallthe VLAN tags > > > Hi Silvano, > > Believe it or not there are customers out there that > use GVRP. They might not be a majority, but they > do exist. > You are making my point: "we cannot rely on GVRP to have a solution" -- Silvano > As far as I'm aware, it is _not_ very common > for customers to be reusing VLAN IDs within the > enterprise. If they do reuse them, they are in > physically separate portions of the network that > are interconnected by routers. That's the normal > tiered architecture that one tends to see in > enterprises. > > I have never come across a customer that uses > partitioned VLANs the way you mention, so I find > it hard to believe they are common. There's always > the oddball, strange architecture out there. > Do we really need to force everyone to send per-VLAN > hellos to deal with that? We can always design to > make that type of configuration work, but we should > optimize for the common case. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > > Sent: Tuesday, July 31, 2007 2:40 PM > > To: Radia Perlman; Dinesh G Dutt > > Cc: rbridge at postel.org > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > > tagged withallthe VLAN tags > > > > > > Radia, > > > > We are describing to you how VLANs are deployed today in > > Enterprise networks. You may say that "you don't like it", we > > may agree with you, but this does not change how they are deployed. > > > > For RBridges to be successful they need to be able to replace > > core bridges without messing up the existing network configurations. > > > > Today most customers do not deploy VLANs end-to-end and they > > do reuse VLANs number in different part of the enterprise. If > > RBridges are not capable of supporting this, they are not attractive. > > > > Remember that the #1 customer requirement we have for TRILL > > is: "replace core bridges with RBridges to enable Equal Cost > > Multi Path, all the rest MUST remain the same". > > > > GVRP is not deployed; I am not sure which customers Anoop is > > referring to. > > > > -- Silvano > > > > > -----Original Message----- > > > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > > > Sent: Tuesday, July 31, 2007 11:19 AM > > > To: Dinesh G Dutt > > > Cc: Silvano Gai; rbridge at postel.org > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > > with > > > allthe VLAN tags > > > > > > I don't understand that problem. What you're describing might argue > > for > > > bridges using a unique > > > spanning tree per VLAN in order to optimize traffic flow for that > > VLAN, > > > but I don't > > > see what it has to do with wanting to partition VLANs. > > > > > > Radia > > > > > > > > > Dinesh G Dutt wrote: > > > > Radia Perlman wrote: > > > >> I'd like to understand what problem customers are attempting to > > solve > > > >> with > > > >> partitioned VLANs, and what hardship it would present to > > require at > > > >> least one of the > > > >> > > > > The primary problem with having a VLAN everywhere is that the root > > of > > > > the spanning tree moves around leading to non-optimal > > forwarding in > > > > enterprise networks. Enterprise networks are carefully engineered > > > > networks and in the event of failure, they want to localize the > > > > effects as much as possible. So, they want each VLAN to > > be localized > > > > and roots where they want it to be. Having a common VLAN > > messes up > > > > that arrangement. Also, VLAN 1 is the default VLAN when a switch > > comes > > > > up and there is typically lots of customer data on it. > > > >> VLANs to *not* be partitioned. With TRILL, if a customer > > eventually > > > >> replaces all bridges, the customer will not be able to partition > > > >> VLANs > > anymore. > > > > As I raised it in the meeting, this is a side-effect that has not > > been > > > > considered before and needs to be carefully thought > > through. I don't > > > > think many people are aware of this issue with TRILL that doesn't > > > > exist with 802.1Q bridges today. > > > >> Also, from > > > >> what Anoop was explaining to me, the GVRP protocol would > > automatically > > > >> configure the switch-to-switch links to join all the islands of > > > >> VLANs. So it would seem as though it can't be that fatal > > to solving > > > >> customer problems > > to > > > >> require > > > >> *one* VLAN on a layer 2 cloud to not be partitioned. > > > >> > > > > GVRP is not deployed by a significant majority of customers. > > > > > > > > Dinesh > > > > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > From anoop at brocade.com Thu Aug 2 15:02:36 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Thu, 2 Aug 2007 15:02:36 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201D777FE@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com><46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com><46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E3CABAE@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA201D777FE@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E3CAFDB@HQ-EXCH-5.corp.brocade.com> Silvano, I don't think I ever suggested using GVRP to solve our problem. All I was saying is that the fact that something like GVRP exists, means that 802.1Q wasn't designed to handle partitioned VLANs as the norm. Anoop > -----Original Message----- > From: Silvano Gai [mailto:sgai at nuovasystems.com] > Sent: Thursday, August 02, 2007 3:00 PM > To: Anoop Ghanwani; Radia Perlman; Dinesh G Dutt > Cc: rbridge at postel.org > Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged withallthe VLAN tags > > > Anoop, > > Inline, > > > -----Original Message----- > > From: Anoop Ghanwani [mailto:anoop at brocade.com] > > Sent: Tuesday, July 31, 2007 4:06 PM > > To: Silvano Gai; Radia Perlman; Dinesh G Dutt > > Cc: rbridge at postel.org > > Subject: RE: [rbridge] Avoiding sending multiple IS-IS > Hellos tagged > > withallthe VLAN tags > > > > > > Hi Silvano, > > > > Believe it or not there are customers out there that use > GVRP. They > > might not be a majority, but they do exist. > > > > You are making my point: "we cannot rely on GVRP to have a solution" > > -- Silvano > > > As far as I'm aware, it is _not_ very common > > for customers to be reusing VLAN IDs within the > > enterprise. If they do reuse them, they are in > > physically separate portions of the network that > > are interconnected by routers. That's the normal > > tiered architecture that one tends to see in > > enterprises. > > > > I have never come across a customer that uses > > partitioned VLANs the way you mention, so I find > > it hard to believe they are common. There's always > > the oddball, strange architecture out there. > > Do we really need to force everyone to send per-VLAN > > hellos to deal with that? We can always design to > > make that type of configuration work, but we should > > optimize for the common case. > > > > Anoop > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org > > > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > > > Sent: Tuesday, July 31, 2007 2:40 PM > > > To: Radia Perlman; Dinesh G Dutt > > > Cc: rbridge at postel.org > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > > > tagged withallthe VLAN tags > > > > > > > > > Radia, > > > > > > We are describing to you how VLANs are deployed today in > > > Enterprise networks. You may say that "you don't like it", we > > > may agree with you, but this does not change how they are > deployed. > > > > > > For RBridges to be successful they need to be able to replace > > > core bridges without messing up the existing network > configurations. > > > > > > Today most customers do not deploy VLANs end-to-end and they > > > do reuse VLANs number in different part of the enterprise. If > > > RBridges are not capable of supporting this, they are not > attractive. > > > > > > Remember that the #1 customer requirement we have for TRILL > > > is: "replace core bridges with RBridges to enable Equal Cost > > > Multi Path, all the rest MUST remain the same". > > > > > > GVRP is not deployed; I am not sure which customers Anoop is > > > referring to. > > > > > > -- Silvano > > > > > > > -----Original Message----- > > > > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > > > > Sent: Tuesday, July 31, 2007 11:19 AM > > > > To: Dinesh G Dutt > > > > Cc: Silvano Gai; rbridge at postel.org > > > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged > > > with > > > > allthe VLAN tags > > > > > > > > I don't understand that problem. What you're describing might > argue > > > for > > > > bridges using a unique > > > > spanning tree per VLAN in order to optimize traffic > flow for that > > > VLAN, > > > > but I don't > > > > see what it has to do with wanting to partition VLANs. > > > > > > > > Radia > > > > > > > > > > > > Dinesh G Dutt wrote: > > > > > Radia Perlman wrote: > > > > >> I'd like to understand what problem customers are > attempting to > > > solve > > > > >> with > > > > >> partitioned VLANs, and what hardship it would present to > > > require at > > > > >> least one of the > > > > >> > > > > > The primary problem with having a VLAN everywhere is that the > root > > > of > > > > > the spanning tree moves around leading to non-optimal > > > forwarding in > > > > > enterprise networks. Enterprise networks are carefully > engineered > > > > > networks and in the event of failure, they want to > localize the > > > > > effects as much as possible. So, they want each VLAN to > > > be localized > > > > > and roots where they want it to be. Having a common VLAN > > > messes up > > > > > that arrangement. Also, VLAN 1 is the default VLAN > when a switch > > > comes > > > > > up and there is typically lots of customer data on it. > > > > >> VLANs to *not* be partitioned. With TRILL, if a customer > > > eventually > > > > >> replaces all bridges, the customer will not be able to > partition > > > > >> VLANs > > > anymore. > > > > > As I raised it in the meeting, this is a side-effect that has > not > > > been > > > > > considered before and needs to be carefully thought > > > through. I don't > > > > > think many people are aware of this issue with TRILL that > doesn't > > > > > exist with 802.1Q bridges today. > > > > >> Also, from > > > > >> what Anoop was explaining to me, the GVRP protocol would > > > automatically > > > > >> configure the switch-to-switch links to join all the > islands of > > > > >> VLANs. So it would seem as though it can't be that fatal > > > to solving > > > > >> customer problems > > > to > > > > >> require > > > > >> *one* VLAN on a layer 2 cloud to not be partitioned. > > > > >> > > > > > GVRP is not deployed by a significant majority of customers. > > > > > > > > > > Dinesh > > > > > > > > > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge at postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > From sgai at nuovasystems.com Thu Aug 2 15:09:09 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 2 Aug 2007 15:09:09 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <46AFE276.1050601@sun.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> Radia, One of the goal of TRILL is plug and play. To most people this means "no configuration", to me it means that I should be able to replace a bridge with an RBridge in an existing network, configure the RBridge like the replaced bridge and continue to work. I DON'T want to ask the network manager to change its VLAN management scheme and as a result its IP subnet management scheme to be able to deploy RBridges. If I ask a network manager to do so, he/she will probably choose to use an IP routed backbone, defeating the original goal of TRILL. WE MUST be able to drop RBridges in existing networks without asking for global reconfigurations. I say all this because we shouldn't care "what problem customers are trying to solve with partitioned VLANs", we know they exists and we don't want to ask customers to design from scratch to be able to use RBridges. -- Silvano > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Tuesday, July 31, 2007 6:32 PM > To: Silvano Gai > Cc: Dinesh G Dutt; rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with > allthe VLAN tags > > Silvano....I still don't know what problem customers are trying to solve > with partitioned VLANs. > If it's that they want more than 4000 VLANs, then the design we had > (before > Anoop's suggestion) also won't help them with that. > If it is an important problem to use more than 4000 VLANs, > we could (by extending the size of the VLAN tag within a TRILL campus) > solve that > problem in a much more robust, easily understandable way than > configuring interswitch > ports to block some VLANs. And I absolutely do not understand any other > problems > that might be solved with intentionally partitioning VLANs, and it's > impossible to design > something without understand the problem that needs to be solved. > > We do have to carefully consider what "breaks" (in the > proposal we are currently considering) if a customer does actually > configure > bridges in some layer 2 cloud so that VLAN 1 is partitioned. > I believe the only consequence of a customer configuring > bridges so that VLAN 1 is partitioned in some layer 2 cloud is that core > RBridges that might have connectivity to each > other through some VLAN other than > VLAN 1 will not realize they are adjacent, and will therefore not form > IS-IS adjacencies, which > means fewer RBridge-RBridge links in the core than there might actually > be. This might > actually cause the campus to get partitioned (since the only > connectivity between RBridges > will be using VLAN 1, and if all the links in the cut set require an > outer tag of other > than 1 in order for RBridges to talk, these links won't be found or > used). It might cause less good paths. However, it will *not* cause > loops, because if > there is no connectivity for flooding of LSPs, data also won't flow in > the core. > > The advantage of this proposal is simplicity and scalability -- only one > Hello per port. > > As I said, I cannot understand what functionality is lost if all switch > ports within a layer 2 > cloud must be configured to pass VLAN 1, and until we do understand some > important hardship that this rule imposes, I'd say this (Anoop's proposal) > is obviously the right thing to do. > > Radia > > > Silvano Gai wrote: > > Radia, > > > > We are describing to you how VLANs are deployed today in Enterprise > > networks. You may say that "you don't like it", we may agree with you, > > but this does not change how they are deployed. > > > > For RBridges to be successful they need to be able to replace core > > bridges without messing up the existing network configurations. > > > > Today most customers do not deploy VLANs end-to-end and they do reuse > > VLANs number in different part of the enterprise. If RBridges are not > > capable of supporting this, they are not attractive. > > > > Remember that the #1 customer requirement we have for TRILL is: "replace > > core bridges with RBridges to enable Equal Cost Multi Path, all the rest > > MUST remain the same". > > > > GVRP is not deployed; I am not sure which customers Anoop is referring > > to. > > > > -- Silvano > > > > > >> -----Original Message----- > >> From: Radia Perlman [mailto:Radia.Perlman at sun.com] > >> Sent: Tuesday, July 31, 2007 11:19 AM > >> To: Dinesh G Dutt > >> Cc: Silvano Gai; rbridge at postel.org > >> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > >> > > with > > > >> allthe VLAN tags > >> > >> I don't understand that problem. What you're describing might argue > >> > > for > > > >> bridges using a unique > >> spanning tree per VLAN in order to optimize traffic flow for that > >> > > VLAN, > > > >> but I don't > >> see what it has to do with wanting to partition VLANs. > >> > >> Radia > >> > >> > >> Dinesh G Dutt wrote: > >> > >>> Radia Perlman wrote: > >>> > >>>> I'd like to understand what problem customers are attempting to > >>>> > > solve > > > >>>> with > >>>> partitioned VLANs, and what hardship it would present to require at > >>>> least one of the > >>>> > >>>> > >>> The primary problem with having a VLAN everywhere is that the root > >>> > > of > > > >>> the spanning tree moves around leading to non-optimal forwarding in > >>> enterprise networks. Enterprise networks are carefully engineered > >>> networks and in the event of failure, they want to localize the > >>> effects as much as possible. So, they want each VLAN to be localized > >>> and roots where they want it to be. Having a common VLAN messes up > >>> that arrangement. Also, VLAN 1 is the default VLAN when a switch > >>> > > comes > > > >>> up and there is typically lots of customer data on it. > >>> > >>>> VLANs to *not* be partitioned. With TRILL, if a customer eventually > >>>> replaces > >>>> all bridges, the customer will not be able to partition VLANs > >>>> > > anymore. > > > >>> As I raised it in the meeting, this is a side-effect that has not > >>> > > been > > > >>> considered before and needs to be carefully thought through. I don't > >>> think many people are aware of this issue with TRILL that doesn't > >>> exist with 802.1Q bridges today. > >>> > >>>> Also, from > >>>> what Anoop was explaining to me, the GVRP protocol would > >>>> > > automatically > > > >>>> configure the switch-to-switch links to join all the islands of > >>>> VLANs. So it would > >>>> seem as though it can't be that fatal to solving customer problems > >>>> > > to > > > >>>> require > >>>> *one* VLAN on a layer 2 cloud to not be partitioned. > >>>> > >>>> > >>> GVRP is not deployed by a significant majority of customers. > >>> > >>> Dinesh > >>> > >>> > > > > From Radia.Perlman at sun.com Thu Aug 2 17:23:26 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 02 Aug 2007 17:23:26 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <46B2757E.9090608@sun.com> Silvano, I strongly believe that one can't design something reasonable without understanding the problem you're trying to solve. But at this point, whether or not it is useful to understand the problem being solved is not useful to debate (though the last chapter of my book has a great anecdote about why it is desirable to know what problem you're solving :-) ). But at this point let's close this issue, which is basically to adopt Anoop's proposal of only sending IS-IS Hellos tagged with VLAN 1, plus my addendum to avoid temporary loops when VLAN 1 is partitioned by having RB2 refuse to decapsulate packets onto a port from ingress RBridge RB1 unless RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB for. ************* To review it: a) declare that bridges must be configured so that VLAN 1 (default VLAN) must not be partitioned on a layer 2 cloud. We will detect the misconfiguration if it occurs (see d)) so that we do not have loops, but if VLAN 1 is partitioned parts of the layer 2 cloud might wind up orphaned from the rest of the campus. b) Send IS-IS Hellos tagged with VLAN 1, containing the following: . I am R1 . I hear Hellos from {R2, R3, R7, R11} . If I am DRB, the pseudonode name will be R1.59 . My priority for the set of VLANs {A, D, W} is 7 . My priority for the set of VLANs {B, C, F, G, H} is 3 c) If R1 becomes DRB for at least one of the VLANs on the cloud, then R1 announces (in R1's LSP) connectivity to pseudonode R1.59, together with a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on behalf of pseudonode R1.59, R1 announces the ID of the root bridge on the primary spanning tree instance for that layer 2 cloud, along with the set of VLANs for which R1 is DRB on that cloud. d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A listed as one of the VLANs, this indicates that VLAN 1 on that layer 2 cloud is partitioned. So one of R1 or R2 should stop forwarding data to/from that cloud for VLAN A. Use ID as a tie breaker, so if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN A traffic to and from the port that has root bridge r11. This is the behavior that will occur if VLAN 1 on that port is actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would have seen each other's Hellos and not both think they are DRB for VLAN A (or any other VLAN). e) This proposal supports multiple DRBs on a cloud for load splitting based on VLANs, since the RBridges can have different priorities for different VLANs. It still requires only sending one Hello, tagged with VLAN 1. R2 should not panic if R2 notices that R1.59 has the same root bridge as on a port on which R2 is DRB, if R1.59's listed set of VLANs does not include any VLANs for which R2 is DRB on the link with that root bridge. If there is only partial overlap of VLAN IDs, say the overlap is VLANs {D, F, and H}, then (the loser based on ID tie-breaker) will stop forwarding traffic to/from that link that is tagged with VLANs D, F, or H. f) If some VLAN, say VLAN C, is actually partitioned, then the result of this is that some VLAN C endnodes on that layer 2 cloud will be orphaned. We will choose NOT to solve that. g) To avoid temporary loops when VLAN 1 is partitioned, for each other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate from", provided that RB2 has an LSP from RB1 and all pseudonodes RB1 claims to be attached to. If RB2 receives a frame from ingress RB1 and this flag is NOT true, then RB2 will refuse to decapsulate the packet onto any ports. (regardless of VLAN and regardless of whether the frame is multidestination or unicast). Radia Silvano Gai wrote: > Radia, > > One of the goal of TRILL is plug and play. > > To most people this means "no configuration", to me it means that I > should be able to replace a bridge with an RBridge in an existing > network, configure the RBridge like the replaced bridge and continue to > work. > > I DON'T want to ask the network manager to change its VLAN management > scheme and as a result its IP subnet management scheme to be able to > deploy RBridges. > > If I ask a network manager to do so, he/she will probably choose to use > an IP routed backbone, defeating the original goal of TRILL. > > WE MUST be able to drop RBridges in existing networks without asking for > global reconfigurations. > > I say all this because we shouldn't care "what problem customers are > trying to solve with partitioned VLANs", we know they exists and we > don't want to ask customers to design from scratch to be able to use > RBridges. > > -- Silvano > > >> -----Original Message----- >> From: Radia Perlman [mailto:Radia.Perlman at sun.com] >> Sent: Tuesday, July 31, 2007 6:32 PM >> To: Silvano Gai >> Cc: Dinesh G Dutt; rbridge at postel.org >> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged >> > with > >> allthe VLAN tags >> >> Silvano....I still don't know what problem customers are trying to >> > solve > >> with partitioned VLANs. >> If it's that they want more than 4000 VLANs, then the design we had >> (before >> Anoop's suggestion) also won't help them with that. >> If it is an important problem to use more than 4000 VLANs, >> we could (by extending the size of the VLAN tag within a TRILL campus) >> solve that >> problem in a much more robust, easily understandable way than >> configuring interswitch >> ports to block some VLANs. And I absolutely do not understand any >> > other > >> problems >> that might be solved with intentionally partitioning VLANs, and it's >> impossible to design >> something without understand the problem that needs to be solved. >> >> We do have to carefully consider what "breaks" (in the >> proposal we are currently considering) if a customer does actually >> configure >> bridges in some layer 2 cloud so that VLAN 1 is partitioned. >> I believe the only consequence of a customer configuring >> bridges so that VLAN 1 is partitioned in some layer 2 cloud is that >> > core > >> RBridges that might have connectivity to each >> other through some VLAN other than >> VLAN 1 will not realize they are adjacent, and will therefore not form >> IS-IS adjacencies, which >> means fewer RBridge-RBridge links in the core than there might >> > actually > >> be. This might >> actually cause the campus to get partitioned (since the only >> connectivity between RBridges >> will be using VLAN 1, and if all the links in the cut set require an >> outer tag of other >> than 1 in order for RBridges to talk, these links won't be found or >> used). It might cause less good paths. However, it will *not* cause >> loops, because if >> there is no connectivity for flooding of LSPs, data also won't flow in >> the core. >> >> The advantage of this proposal is simplicity and scalability -- only >> > one > >> Hello per port. >> >> As I said, I cannot understand what functionality is lost if all >> > switch > >> ports within a layer 2 >> cloud must be configured to pass VLAN 1, and until we do understand >> > some > >> important hardship that this rule imposes, I'd say this (Anoop's >> > proposal) > >> is obviously the right thing to do. >> >> Radia >> >> >> Silvano Gai wrote: >> >>> Radia, >>> >>> We are describing to you how VLANs are deployed today in Enterprise >>> networks. You may say that "you don't like it", we may agree with >>> > you, > >>> but this does not change how they are deployed. >>> >>> For RBridges to be successful they need to be able to replace core >>> bridges without messing up the existing network configurations. >>> >>> Today most customers do not deploy VLANs end-to-end and they do >>> > reuse > >>> VLANs number in different part of the enterprise. If RBridges are >>> > not > >>> capable of supporting this, they are not attractive. >>> >>> Remember that the #1 customer requirement we have for TRILL is: >>> > "replace > >>> core bridges with RBridges to enable Equal Cost Multi Path, all the >>> > rest > >>> MUST remain the same". >>> >>> GVRP is not deployed; I am not sure which customers Anoop is >>> > referring > >>> to. >>> >>> -- Silvano >>> >>> >>> >>>> -----Original Message----- >>>> From: Radia Perlman [mailto:Radia.Perlman at sun.com] >>>> Sent: Tuesday, July 31, 2007 11:19 AM >>>> To: Dinesh G Dutt >>>> Cc: Silvano Gai; rbridge at postel.org >>>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos >>>> > tagged > >>> with >>> >>> >>>> allthe VLAN tags >>>> >>>> I don't understand that problem. What you're describing might argue >>>> >>>> >>> for >>> >>> >>>> bridges using a unique >>>> spanning tree per VLAN in order to optimize traffic flow for that >>>> >>>> >>> VLAN, >>> >>> >>>> but I don't >>>> see what it has to do with wanting to partition VLANs. >>>> >>>> Radia >>>> >>>> >>>> Dinesh G Dutt wrote: >>>> >>>> >>>>> Radia Perlman wrote: >>>>> >>>>> >>>>>> I'd like to understand what problem customers are attempting to >>>>>> >>>>>> >>> solve >>> >>> >>>>>> with >>>>>> partitioned VLANs, and what hardship it would present to require >>>>>> > at > >>>>>> least one of the >>>>>> >>>>>> >>>>>> >>>>> The primary problem with having a VLAN everywhere is that the root >>>>> >>>>> >>> of >>> >>> >>>>> the spanning tree moves around leading to non-optimal forwarding >>>>> > in > >>>>> enterprise networks. Enterprise networks are carefully engineered >>>>> networks and in the event of failure, they want to localize the >>>>> effects as much as possible. So, they want each VLAN to be >>>>> > localized > >>>>> and roots where they want it to be. Having a common VLAN messes up >>>>> that arrangement. Also, VLAN 1 is the default VLAN when a switch >>>>> >>>>> >>> comes >>> >>> >>>>> up and there is typically lots of customer data on it. >>>>> >>>>> >>>>>> VLANs to *not* be partitioned. With TRILL, if a customer >>>>>> > eventually > >>>>>> replaces >>>>>> all bridges, the customer will not be able to partition VLANs >>>>>> >>>>>> >>> anymore. >>> >>> >>>>> As I raised it in the meeting, this is a side-effect that has not >>>>> >>>>> >>> been >>> >>> >>>>> considered before and needs to be carefully thought through. I >>>>> > don't > >>>>> think many people are aware of this issue with TRILL that doesn't >>>>> exist with 802.1Q bridges today. >>>>> >>>>> >>>>>> Also, from >>>>>> what Anoop was explaining to me, the GVRP protocol would >>>>>> >>>>>> >>> automatically >>> >>> >>>>>> configure the switch-to-switch links to join all the islands of >>>>>> VLANs. So it would >>>>>> seem as though it can't be that fatal to solving customer >>>>>> > problems > >>> to >>> >>> >>>>>> require >>>>>> *one* VLAN on a layer 2 cloud to not be partitioned. >>>>>> >>>>>> >>>>>> >>>>> GVRP is not deployed by a significant majority of customers. >>>>> >>>>> Dinesh >>>>> >>>>> >>>>> >>> > > From ddutt at cisco.com Thu Aug 2 18:07:06 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 02 Aug 2007 18:07:06 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags In-Reply-To: <46B0FD22.7030200@sun.com> References: <46AE9B0D.4080606@sun.com> <46B0C653.8010304@cisco.com> <46B0FD22.7030200@sun.com> Message-ID: <46B27FBA.5010304@cisco.com> Radia, I thought about this solution but think that it still doesn't fix the problem of duplicates. If both R1 and R2 think that they're DRB for VLAN A, when they both receive a frame on VLAN A from the 802.1D cloud (unknown unicast for example), they both think that they can forward it onto the TRILL network. The destination host will now receive duplicate frames till one of them stops being DRB. Am I mistaken ? Dinesh Radia Perlman wrote: > Dinesh, > > I think you are right that there can be a temporary loop due to a > partitioned VLAN 1. > And I think we can make it sufficiently unlikely to occur with a > suggestion I'll make > after I explain the problem. > > The temporary loop would be if R1 and R2, on the same layer 2 cloud, have > connectivity through VLAN A but not VLAN 1. So there would be two > DRBs, on > both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 and > R2.62, > and both would claim to be connected to both VLAN A and VLAN 1, and both > would claim the same root bridge, say 5134. > > A multicast tagged with VLAN 1 would not be too much of a problem > because anything > R1 decapsulates onto that VLAN-1-partitioned cloud would not make it > through > the partitioned cloud to R2. But since we are not running the DRB > election tagged > with VLAN A, R1 and R2 do not realize that they can talk via VLAN A. > > Therefore, a VLAN A-tagged packet would get picked up by both R1 and R2, > and both would assume they are DRB. > Also, if R1 receives a (inner header) VLAN-A tagged frame > from the campus, R1 will decapsulate it onto the layer 2 cloud as a > VLAN-A > tagged packet, and R2 will see it > and re-encapsulate it onto the campus, and R1 would see it again and > decapsulate it, etc. > > This loop will eventually be fixed when R1 sees the LSP from > pseudonode R2.62 indicating > that the root bridge is 5134, since R1 will also think that the cloud > that R1 is DRB for has > root bridge 5134. > > So here's a possible fix: > > R1 does not decapsulate a multidestination packet with ingress RBridge > R2 unless R1 > has an LSP from R2, and has LSPs from all pseudonodes that R2 claims > (in R2's > LSP) to be DRB for. Note that I'm suggesting adding another flag in > the neighbor > list in R2's LSP saying "not only am I attached to this pseudonode, > but I am > DRB for it". > > If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if > the root bridge > listed is the same as the one for the link on which R2 would like to > decapsulate, and if it is, > then don't decapsulate. > > We were already saying that if R1 notices that R2.79 has the same root > bridge as > a link R1 wants to be DRB for that one of R1 or R2 would lose, based > on a tie-breaker > based on ID, and stop forwarding traffic to/from the link. What I'm > suggesting is that > you also don't forward multidestination traffic to/from a link if you > don't yet have all > the associated LSP information from the ingress RBridge that can > assure you there > isn't a common root bridge. > > Radia > > > > > Dinesh G Dutt wrote: >> OK, based on emails from James Carlson and Radia, I went back and >> thought about my reasons for objecting to the suggested proposal. I >> also spoke to some field engineers to validate my understanding of >> what I thought the issues were. >> >> There are two issues that we're dealing with here: >> - Simplifying DRB election to conduct it only on VLAN 1 >> - Merging partitioned VLANs. >> >> I'd like to separate the two issues. Let me discuss only the first >> issue, the simplified DRB election in this email. I'll send out a >> separate email on the other issue. >> >> Assuming VLAN 1 exists everywhere is an acceptable alternative. I was >> informed that even with STP, customers enable VLAN 1 and allow only >> control traffic on it and not data traffic. If we have VLAN 1 present >> as a common configuration, then running DRB only on VLAN 1 and >> following Radia's proposal (or fixing it to work) seems acceptable, >> except for one caveat. >> >> However, in the event of a misconfiguration and VLAN 1 not being >> present, while the scheme proposed partitions the network and >> prevents loops, it seems to me that there is a period during which >> temporary loops can happen and duplicate frames are delivered by two >> DRBs. This seems unacceptable to me from a customer point of view. If >> we can fix this temporary loop (or someone can explain to me why >> there are no temporary loops), I'd be willing to support this proposal. >> >> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of >> customer networks and so we cannot assume or mandate their being there. >> >> Dinesh >> Radia Perlman wrote: >>> I had a conversation with Anoop, and he is (quite understandably) >>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he >>> made the following suggestion, which I think makes sense. >>> >>> a) declare that bridges must be configured >>> so that VLAN 1 (default VLAN) must not be >>> partitioned on a layer 2 cloud. We will detect the misconfiguration >>> if it occurs (see d)) so that we at least do not have loops, but >>> TRILL will not >>> stand on its head to support what will be declared a gross >>> misconfiguration. >>> >>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has >>> the following information in its IS-IS Hello: >>> >>> . I am R1 >>> . I hear Hellos from {R2, R3, R7, R11} >>> . If I am DRB, the pseudonode name will be R1.59 >>> . My priority for the set of VLANs {A, D, W} is 7 >>> . My priority for the set of VLANs {B, C, F, G, H} is 3 >>> >>> c) If R1 becomes DRB for at least one of the VLANs on the cloud, >>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59, >>> the ID of the root bridge on the primary spanning tree >>> instance for that layer 2 cloud, along with the set of VLANs for which >>> R1 is DRB on that cloud. >>> >>> Note: The current draft spec isn't clear what information R1 reports >>> in the pseudonode >>> LSP and what it reports in its own LSP. >>> I'm suggesting reporting the bridge ID and >>> set of VLANs in the pseudonode LSP. >>> >>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge >>> r11, >>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A >>> listed as one of the VLANs, this indicates that VLAN 1 on that layer >>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding >>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so >>> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding >>> VLAN A >>> traffic to and from the port that has root bridge r11. >>> This is the behavior that will occur if VLAN 1 on that port is >>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 >>> would >>> have seen each other's Hellos and not both think they are DRB for >>> VLAN A (or >>> any other VLAN). >>> >>> e) This proposal supports multiple DRBs on a cloud for load splitting >>> based on VLANs, since the RBridges can have different priorities >>> for different VLANs. It still requires only sending one Hello, tagged >>> with VLAN 1. R2 should >>> not panic if R2 notices that R1.59 has the same root bridge as on >>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not >>> include any VLANs for which R2 is DRB on the link with >>> that root bridge. If there is only partial overlap >>> of VLAN IDs, say the overlap is VLANs {D, F, and H}, >>> then (the loser based on ID tie-breaker) will stop forwarding traffic >>> to/from that link that is tagged with VLANs D, F, or H. >>> >>> f) If some VLAN, say VLAN C, is actually partitioned, then the >>> result of this is that some VLAN C endnodes on that layer 2 cloud >>> will be orphaned. We will choose NOT to solve that. >>> >>> >>> The result of this proposal is that >>> RBridges will only need to send IS-IS Hellos tagged >>> with VLAN 1, and the only thing it does NOT solve (over >>> the current proposal of sending Hellos with every possible VLAN tag on >>> each port) is that sometimes endnodes might get orphaned if you have >>> a partitioned VLAN. >>> >>> >>> We *could* in that case, if someone *actually wanted* to have VLAN A >>> partitioned on that cloud, configure the RBridges on that layer 2 >>> cloud to explicitly run a different election >>> for VLAN A (and note in the pseudonode LSP that VLAN A had >>> an explicit election tagged with VLAN A so that if there were >>> two DRBs they wouldn't panic). But I'd prefer not solving this case and >>> keeping it simpler (and safer). >>> >>> Radia >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From anoop at brocade.com Thu Aug 2 18:18:48 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Thu, 2 Aug 2007 18:18:48 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com><46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com><46AF7CF6.8090105@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com><46AFE276.1050601@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E3CB06D@HQ-EXCH-5.corp.brocade.com> Silvano, There are typically a lot of VLANs at the edge and only a few in the core. Today, a typically enterprise could have 100's (may be a couple of 1000) VLANs configured on a typical bridge. But, we don't enable routing protocols on those VLANs because that's just the edge. Once in the core, there are typically only a handful of VLANs on which routing protocols are enabled. We don't have experience sending hellos on so many VLANs and so many ports. Unlike a router, an RBridge has to start sending hellos on all its ports as soon as it comes up. I don't think things can be made to work if we have to send these hellos for every VLAN configured on a port. I understand that in the ideal case we'd like to work with any arbitrary configuration. However, I don't understand how per-VLAN hellos would keep things working correctly. If I have a partitioned VLAN and, as a result, have 2 RBridges that become DRBs for that VLAN, and if there exists some other path between these RBridges (via TRILL), then these two partitioned sections will now function as a single partition for that VLAN (via the RBridges). So how have I simplified the network managers job? He would still have to change his/her VLAN configuration if he/she intends to keep the two partitions disconnected even after introducing the RBridges. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > Sent: Thursday, August 02, 2007 3:09 PM > To: Radia Perlman > Cc: rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged withallthe VLAN tags > > Radia, > > One of the goal of TRILL is plug and play. > > To most people this means "no configuration", to me it means > that I should be able to replace a bridge with an RBridge in > an existing network, configure the RBridge like the replaced > bridge and continue to work. > > I DON'T want to ask the network manager to change its VLAN > management scheme and as a result its IP subnet management > scheme to be able to deploy RBridges. > > If I ask a network manager to do so, he/she will probably > choose to use an IP routed backbone, defeating the original > goal of TRILL. > > WE MUST be able to drop RBridges in existing networks without > asking for global reconfigurations. > > I say all this because we shouldn't care "what problem > customers are trying to solve with partitioned VLANs", we > know they exists and we don't want to ask customers to design > from scratch to be able to use RBridges. > > -- Silvano > > > -----Original Message----- > > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > > Sent: Tuesday, July 31, 2007 6:32 PM > > To: Silvano Gai > > Cc: Dinesh G Dutt; rbridge at postel.org > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > with > > allthe VLAN tags > > > > Silvano....I still don't know what problem customers are trying to > solve > > with partitioned VLANs. > > If it's that they want more than 4000 VLANs, then the design we had > > (before Anoop's suggestion) also won't help them with that. > > If it is an important problem to use more than 4000 VLANs, we could > > (by extending the size of the VLAN tag within a TRILL campus) solve > > that problem in a much more robust, easily understandable way than > > configuring interswitch ports to block some VLANs. And I > absolutely do > > not understand any > other > > problems > > that might be solved with intentionally partitioning VLANs, > and it's > > impossible to design something without understand the problem that > > needs to be solved. > > > > We do have to carefully consider what "breaks" (in the proposal we > > are currently considering) if a customer does actually configure > > bridges in some layer 2 cloud so that VLAN 1 is partitioned. > > I believe the only consequence of a customer configuring bridges so > > that VLAN 1 is partitioned in some layer 2 cloud is that > core > > RBridges that might have connectivity to each other through > some VLAN > > other than VLAN 1 will not realize they are adjacent, and will > > therefore not form IS-IS adjacencies, which means fewer > > RBridge-RBridge links in the core than there might > actually > > be. This might > > actually cause the campus to get partitioned (since the only > > connectivity between RBridges will be using VLAN 1, and if all the > > links in the cut set require an outer tag of other than 1 > in order for > > RBridges to talk, these links won't be found or used). It > might cause > > less good paths. However, it will *not* cause loops, > because if there > > is no connectivity for flooding of LSPs, data also won't > flow in the > > core. > > > > The advantage of this proposal is simplicity and scalability -- only > one > > Hello per port. > > > > As I said, I cannot understand what functionality is lost if all > switch > > ports within a layer 2 > > cloud must be configured to pass VLAN 1, and until we do understand > some > > important hardship that this rule imposes, I'd say this (Anoop's > proposal) > > is obviously the right thing to do. > > > > Radia > > > > > > Silvano Gai wrote: > > > Radia, > > > > > > We are describing to you how VLANs are deployed today in > Enterprise > > > networks. You may say that "you don't like it", we may agree with > you, > > > but this does not change how they are deployed. > > > > > > For RBridges to be successful they need to be able to > replace core > > > bridges without messing up the existing network configurations. > > > > > > Today most customers do not deploy VLANs end-to-end and they do > reuse > > > VLANs number in different part of the enterprise. If RBridges are > not > > > capable of supporting this, they are not attractive. > > > > > > Remember that the #1 customer requirement we have for TRILL is: > "replace > > > core bridges with RBridges to enable Equal Cost Multi > Path, all the > rest > > > MUST remain the same". > > > > > > GVRP is not deployed; I am not sure which customers Anoop is > referring > > > to. > > > > > > -- Silvano > > > > > > > > >> -----Original Message----- > > >> From: Radia Perlman [mailto:Radia.Perlman at sun.com] > > >> Sent: Tuesday, July 31, 2007 11:19 AM > > >> To: Dinesh G Dutt > > >> Cc: Silvano Gai; rbridge at postel.org > > >> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged > > >> > > > with > > > > > >> allthe VLAN tags > > >> > > >> I don't understand that problem. What you're describing > might argue > > >> > > > for > > > > > >> bridges using a unique > > >> spanning tree per VLAN in order to optimize traffic flow for that > > >> > > > VLAN, > > > > > >> but I don't > > >> see what it has to do with wanting to partition VLANs. > > >> > > >> Radia > > >> > > >> > > >> Dinesh G Dutt wrote: > > >> > > >>> Radia Perlman wrote: > > >>> > > >>>> I'd like to understand what problem customers are attempting to > > >>>> > > > solve > > > > > >>>> with > > >>>> partitioned VLANs, and what hardship it would present > to require > at > > >>>> least one of the > > >>>> > > >>>> > > >>> The primary problem with having a VLAN everywhere is > that the root > > >>> > > > of > > > > > >>> the spanning tree moves around leading to non-optimal forwarding > in > > >>> enterprise networks. Enterprise networks are carefully > engineered > > >>> networks and in the event of failure, they want to localize the > > >>> effects as much as possible. So, they want each VLAN to be > localized > > >>> and roots where they want it to be. Having a common > VLAN messes up > > >>> that arrangement. Also, VLAN 1 is the default VLAN when a switch > > >>> > > > comes > > > > > >>> up and there is typically lots of customer data on it. > > >>> > > >>>> VLANs to *not* be partitioned. With TRILL, if a customer > eventually > > >>>> replaces > > >>>> all bridges, the customer will not be able to partition VLANs > > >>>> > > > anymore. > > > > > >>> As I raised it in the meeting, this is a side-effect > that has not > > >>> > > > been > > > > > >>> considered before and needs to be carefully thought through. I > don't > > >>> think many people are aware of this issue with TRILL > that doesn't > > >>> exist with 802.1Q bridges today. > > >>> > > >>>> Also, from > > >>>> what Anoop was explaining to me, the GVRP protocol would > > >>>> > > > automatically > > > > > >>>> configure the switch-to-switch links to join all the > islands of > > >>>> VLANs. So it would seem as though it can't be that fatal to > > >>>> solving customer > problems > > >>>> > > > to > > > > > >>>> require > > >>>> *one* VLAN on a layer 2 cloud to not be partitioned. > > >>>> > > >>>> > > >>> GVRP is not deployed by a significant majority of customers. > > >>> > > >>> Dinesh > > >>> > > >>> > > > > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From dwcarder at doit.wisc.edu Thu Aug 2 20:44:59 2007 From: dwcarder at doit.wisc.edu (Dale W. Carder) Date: Thu, 02 Aug 2007 22:44:59 -0500 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E3CB06D@HQ-EXCH-5.corp.brocade.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E3CB06D@HQ-EXCH-5.corp.brocade.com> Message-ID: <4F5D08D1-1A28-4462-9C65-2D8AB2DE33D9@doit.wisc.edu> Comments inline: On Aug 2, 2007, at 8:18 PM, Anoop Ghanwani wrote: > There are typically a lot of VLANs at the edge > and only a few in the core. Today, a typically > enterprise could have 100's (may be a couple of > 1000) VLANs configured on a typical bridge. The capabilities of typical small edge switches (the 48 port kind) seem to max out at about 16-128 vlans total, and may have other limitations if the switch is maintaining STP for each vlan. This edge limitation is one of the reasons an enterprise partitions vlans. Larger, "core" switches have enough capability to run up to 4096 vlans at a time. Another issue causing vlans to be partitioned is because some bridges only support vlan numbers < 1024 and there simply is a need for vlan number reuse throughout the enterprise. Vlans are also partitioned is because flooding unknown unicast frames takes up unnecessary bandwidth on 802.1q links, and can fill up mac address tables on less-capable switches. When there are situations like arp storms (no network is ever loop free), partitioning vlan usage is even more of an issue. > But, we don't enable routing protocols on those > VLANs because that's just the edge. Once in the > core, there are typically only a handful of VLANs > on which routing protocols are enabled. > We don't > have experience sending hellos on so many VLANs > and so many ports. I disagree with this argument. Many enterprises and carriers deploy multiple routers on each edge subnet for redundancy. To do this, VRRP or HSRP sends out hellos per vlan. If they are running multicast routing, PIM sends out hellos per vlan also. Some places even tune these hellos to very aggressive settings such as 1 per second or less. Large core switches running rapid-STP can send a BPDU every 2 seconds across around 10,000 instances (m vlans * n ports) today. These switches are also usually sending out (LLDP or CDP) and UDLD frames on every port, too. > Unlike a router, an RBridge > has to start sending hellos on all its ports as soon > as it comes up. I don't think things can be > made to work if we have to send these hellos > for every VLAN configured on a port. Again, big switches have been doing this for a while for rapid-STP. Routers with large numbers of vlans (sub-interfaces) are also doing this today. The larger issue I see with Radia's proposal is simply the choice of vlan #1. It could be a poor choice in large enterprises because of scalability concerns and also compatability with existing implementations. As a few others have brought up, many deployments (including mine) have disabled vlan 1 altogether. One of these issues is that vlan 1 is often untagged on 802.1q trunk links. As a security precaution, it is common to disable vlan 1 across switches to prevent malicious vlan-hopping. Perhaps a compromise would be to use vlan 1 as the default, but a TRILL implementation MAY allow this to be configurable by the administrator. Dale From Radia.Perlman at sun.com Thu Aug 2 21:19:22 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 02 Aug 2007 21:19:22 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags In-Reply-To: <46B27FBA.5010304@cisco.com> References: <46AE9B0D.4080606@sun.com> <46B0C653.8010304@cisco.com> <46B0FD22.7030200@sun.com> <46B27FBA.5010304@cisco.com> Message-ID: <46B2ACCA.2070300@sun.com> Yes, Dinesh, in your example if there are temporarily k RBridges on the same layer 2 cloud that all think they are DRB, you might multiply by k, each packet going off the cloud. However, this is not as disastrous as a loop. We can avoid that though by saying that you shouldn't start encapsulating or decapsulating data off the link until you've synchronized LSP datases with each of your RBridge neighbors. IS-IS exchanges LSP database information (a "complete sequence numbers packet") when a link comes up. I think we should throw that rule in as well. Radia Dinesh G Dutt wrote: > Radia, > > I thought about this solution but think that it still doesn't fix the > problem of duplicates. If both R1 and R2 think that they're DRB for VLAN > A, when they both receive a frame on VLAN A from the 802.1D cloud > (unknown unicast for example), they both think that they can forward it > onto the TRILL network. The destination host will now receive duplicate > frames till one of them stops being DRB. > > Am I mistaken ? > > Dinesh > Radia Perlman wrote: > >> Dinesh, >> >> I think you are right that there can be a temporary loop due to a >> partitioned VLAN 1. >> And I think we can make it sufficiently unlikely to occur with a >> suggestion I'll make >> after I explain the problem. >> >> The temporary loop would be if R1 and R2, on the same layer 2 cloud, have >> connectivity through VLAN A but not VLAN 1. So there would be two >> DRBs, on >> both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 and >> R2.62, >> and both would claim to be connected to both VLAN A and VLAN 1, and both >> would claim the same root bridge, say 5134. >> >> A multicast tagged with VLAN 1 would not be too much of a problem >> because anything >> R1 decapsulates onto that VLAN-1-partitioned cloud would not make it >> through >> the partitioned cloud to R2. But since we are not running the DRB >> election tagged >> with VLAN A, R1 and R2 do not realize that they can talk via VLAN A. >> >> Therefore, a VLAN A-tagged packet would get picked up by both R1 and R2, >> and both would assume they are DRB. >> Also, if R1 receives a (inner header) VLAN-A tagged frame >> from the campus, R1 will decapsulate it onto the layer 2 cloud as a >> VLAN-A >> tagged packet, and R2 will see it >> and re-encapsulate it onto the campus, and R1 would see it again and >> decapsulate it, etc. >> >> This loop will eventually be fixed when R1 sees the LSP from >> pseudonode R2.62 indicating >> that the root bridge is 5134, since R1 will also think that the cloud >> that R1 is DRB for has >> root bridge 5134. >> >> So here's a possible fix: >> >> R1 does not decapsulate a multidestination packet with ingress RBridge >> R2 unless R1 >> has an LSP from R2, and has LSPs from all pseudonodes that R2 claims >> (in R2's >> LSP) to be DRB for. Note that I'm suggesting adding another flag in >> the neighbor >> list in R2's LSP saying "not only am I attached to this pseudonode, >> but I am >> DRB for it". >> >> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if >> the root bridge >> listed is the same as the one for the link on which R2 would like to >> decapsulate, and if it is, >> then don't decapsulate. >> >> We were already saying that if R1 notices that R2.79 has the same root >> bridge as >> a link R1 wants to be DRB for that one of R1 or R2 would lose, based >> on a tie-breaker >> based on ID, and stop forwarding traffic to/from the link. What I'm >> suggesting is that >> you also don't forward multidestination traffic to/from a link if you >> don't yet have all >> the associated LSP information from the ingress RBridge that can >> assure you there >> isn't a common root bridge. >> >> Radia >> >> >> >> >> Dinesh G Dutt wrote: >> >>> OK, based on emails from James Carlson and Radia, I went back and >>> thought about my reasons for objecting to the suggested proposal. I >>> also spoke to some field engineers to validate my understanding of >>> what I thought the issues were. >>> >>> There are two issues that we're dealing with here: >>> - Simplifying DRB election to conduct it only on VLAN 1 >>> - Merging partitioned VLANs. >>> >>> I'd like to separate the two issues. Let me discuss only the first >>> issue, the simplified DRB election in this email. I'll send out a >>> separate email on the other issue. >>> >>> Assuming VLAN 1 exists everywhere is an acceptable alternative. I was >>> informed that even with STP, customers enable VLAN 1 and allow only >>> control traffic on it and not data traffic. If we have VLAN 1 present >>> as a common configuration, then running DRB only on VLAN 1 and >>> following Radia's proposal (or fixing it to work) seems acceptable, >>> except for one caveat. >>> >>> However, in the event of a misconfiguration and VLAN 1 not being >>> present, while the scheme proposed partitions the network and >>> prevents loops, it seems to me that there is a period during which >>> temporary loops can happen and duplicate frames are delivered by two >>> DRBs. This seems unacceptable to me from a customer point of view. If >>> we can fix this temporary loop (or someone can explain to me why >>> there are no temporary loops), I'd be willing to support this proposal. >>> >>> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of >>> customer networks and so we cannot assume or mandate their being there. >>> >>> Dinesh >>> Radia Perlman wrote: >>> >>>> I had a conversation with Anoop, and he is (quite understandably) >>>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he >>>> made the following suggestion, which I think makes sense. >>>> >>>> a) declare that bridges must be configured >>>> so that VLAN 1 (default VLAN) must not be >>>> partitioned on a layer 2 cloud. We will detect the misconfiguration >>>> if it occurs (see d)) so that we at least do not have loops, but >>>> TRILL will not >>>> stand on its head to support what will be declared a gross >>>> misconfiguration. >>>> >>>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has >>>> the following information in its IS-IS Hello: >>>> >>>> . I am R1 >>>> . I hear Hellos from {R2, R3, R7, R11} >>>> . If I am DRB, the pseudonode name will be R1.59 >>>> . My priority for the set of VLANs {A, D, W} is 7 >>>> . My priority for the set of VLANs {B, C, F, G, H} is 3 >>>> >>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud, >>>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59, >>>> the ID of the root bridge on the primary spanning tree >>>> instance for that layer 2 cloud, along with the set of VLANs for which >>>> R1 is DRB on that cloud. >>>> >>>> Note: The current draft spec isn't clear what information R1 reports >>>> in the pseudonode >>>> LSP and what it reports in its own LSP. >>>> I'm suggesting reporting the bridge ID and >>>> set of VLANs in the pseudonode LSP. >>>> >>>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge >>>> r11, >>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A >>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer >>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding >>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so >>>> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding >>>> VLAN A >>>> traffic to and from the port that has root bridge r11. >>>> This is the behavior that will occur if VLAN 1 on that port is >>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 >>>> would >>>> have seen each other's Hellos and not both think they are DRB for >>>> VLAN A (or >>>> any other VLAN). >>>> >>>> e) This proposal supports multiple DRBs on a cloud for load splitting >>>> based on VLANs, since the RBridges can have different priorities >>>> for different VLANs. It still requires only sending one Hello, tagged >>>> with VLAN 1. R2 should >>>> not panic if R2 notices that R1.59 has the same root bridge as on >>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not >>>> include any VLANs for which R2 is DRB on the link with >>>> that root bridge. If there is only partial overlap >>>> of VLAN IDs, say the overlap is VLANs {D, F, and H}, >>>> then (the loser based on ID tie-breaker) will stop forwarding traffic >>>> to/from that link that is tagged with VLANs D, F, or H. >>>> >>>> f) If some VLAN, say VLAN C, is actually partitioned, then the >>>> result of this is that some VLAN C endnodes on that layer 2 cloud >>>> will be orphaned. We will choose NOT to solve that. >>>> >>>> >>>> The result of this proposal is that >>>> RBridges will only need to send IS-IS Hellos tagged >>>> with VLAN 1, and the only thing it does NOT solve (over >>>> the current proposal of sending Hellos with every possible VLAN tag on >>>> each port) is that sometimes endnodes might get orphaned if you have >>>> a partitioned VLAN. >>>> >>>> >>>> We *could* in that case, if someone *actually wanted* to have VLAN A >>>> partitioned on that cloud, configure the RBridges on that layer 2 >>>> cloud to explicitly run a different election >>>> for VLAN A (and note in the pseudonode LSP that VLAN A had >>>> an explicit election tagged with VLAN A so that if there were >>>> two DRBs they wouldn't panic). But I'd prefer not solving this case and >>>> keeping it simpler (and safer). >>>> >>>> Radia >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> > > From Radia.Perlman at sun.com Thu Aug 2 21:36:36 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 02 Aug 2007 21:36:36 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <4F5D08D1-1A28-4462-9C65-2D8AB2DE33D9@doit.wisc.edu> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E3CB06D@HQ-EXCH-5.corp.brocade.com> <4F5D08D1-1A28-4462-9C65-2D8AB2DE33D9@doit.wisc.edu> Message-ID: <46B2B0D4.8060708@sun.com> Dale, I certainly don't care which VLAN we choose. There should be a default one, and we should also allow an implementation to be configurable to set it to a different VLAN tag, or even a set of VLAN tags (in which case the RBridge would issue multiple IS-IS Hellos, one with each configured VLAN tag). If RBa receives an IS-IS Hello, it should accept it regardless of what VLAN it is tagged with. If RBa transmits IS-IS Hellos tagged with VLAN A, and RBb transmits IS-IS Hellos tagged with VLAN B, and RBC, .... etc. Then RBa will assume it has an adjacency with RBc if "RBa" appears in RBc's IS-IS Hello (as someone that RBc has seen Hellos from). And RBa would use VLAN tag A when talking across the link to any RBridge that RBa has an adjacency with. This may be a bit confusing to understand but I don't think there's a problem with it. So...what do you think the default VLAN tag should be for sending IS-IS Hellos? Radia Dale W. Carder wrote: > > The larger issue I see with Radia's proposal is simply the choice > of vlan #1. It could be a poor choice in large enterprises because > of scalability concerns and also compatability with existing > implementations. As a few others have brought up, many deployments > (including mine) have disabled vlan 1 altogether. > > One of these issues is that vlan 1 is often untagged on 802.1q trunk > links. As a security precaution, it is common to disable vlan 1 > across switches to prevent malicious vlan-hopping. > > Perhaps a compromise would be to use vlan 1 as the default, but a > TRILL implementation MAY allow this to be configurable by the > administrator. > > Dale From Radia.Perlman at sun.com Thu Aug 2 22:39:06 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 02 Aug 2007 22:39:06 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <46B2B0D4.8060708@sun.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E3CB06D@HQ-EXCH-5.corp.brocade.com> <4F5D08D1-1A28-4462-9C65-2D8AB2DE33D9@doit.wisc.edu> <46B2B0D4.8060708@sun.com> Message-ID: <46B2BF7A.3010403@sun.com> Rereading what I wrote, I'd be surprised if anyone actually understood what I was saying from what I wrote, so let me explain again. Let's say you have 5 RBridges, RBa, RBb, RBc, RBd, and RBe. RBa transmits Hellos with tag VLAN A, RBb tags its hellos with VLAN B, and so forth. If RBa *only* sends things on the link tagged with VLAN A, it can still tell if it has an adjacency to, say, RBc, which only transmits Hellos tagged with VLAN C, because the IS-IS Hello includes the list of RBridges that the transmitting RBridge has heard Hellos from. So even if RBc always talks to RBa using VLAN C, and RBa always talks to RBc using VLAN A, things will work. RBa knows it will work because RBc indicates in its Hello, that it heard a Hello from RBa. Not sure if that's any clearer, but at least I get credit for trying. Maybe partial credit? Radia Radia Perlman wrote: > Dale, > > I certainly don't care which VLAN we choose. There should be a default > one, and > we should also allow an implementation to be configurable to set it to > a different VLAN tag, or even a set of VLAN tags (in which case the RBridge > would issue multiple IS-IS Hellos, one with each configured VLAN tag). > > If RBa receives an IS-IS Hello, it should accept it regardless of what > VLAN it is > tagged with. If RBa transmits IS-IS Hellos tagged with VLAN A, and RBb > transmits > IS-IS Hellos tagged with VLAN B, and RBC, .... etc. Then RBa will assume it > has an adjacency with RBc if "RBa" appears in RBc's IS-IS Hello (as > someone that > RBc has seen Hellos from). And RBa would use VLAN tag A when talking across > the link to any RBridge that RBa has an adjacency with. This may be a > bit confusing > to understand but I don't think there's a problem with it. > > So...what do you think the default VLAN tag should be for sending IS-IS > Hellos? > > Radia > > > > Dale W. Carder wrote: > >> The larger issue I see with Radia's proposal is simply the choice >> of vlan #1. It could be a poor choice in large enterprises because >> of scalability concerns and also compatability with existing >> implementations. As a few others have brought up, many deployments >> (including mine) have disabled vlan 1 altogether. >> >> One of these issues is that vlan 1 is often untagged on 802.1q trunk >> links. As a security precaution, it is common to disable vlan 1 >> across switches to prevent malicious vlan-hopping. >> >> Perhaps a compromise would be to use vlan 1 as the default, but a >> TRILL implementation MAY allow this to be configurable by the >> administrator. >> >> Dale >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Fri Aug 3 10:07:24 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 3 Aug 2007 10:07:24 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <4F5D08D1-1A28-4462-9C65-2D8AB2DE33D9@doit.wisc.edu> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E3CB06D@HQ-EXCH-5.corp.brocade.com> <4F5D08D1-1A28-4462-9C65-2D8AB2DE33D9@doit.wisc.edu> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E3CB0FC@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: Dale W. Carder [mailto:dwcarder at doit.wisc.edu] > Sent: Thursday, August 02, 2007 8:45 PM > To: Anoop Ghanwani > Cc: Silvano Gai; Radia Perlman; rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos > tagged withallthe VLAN tags > > > On Aug 2, 2007, at 8:18 PM, Anoop Ghanwani wrote: > > There are typically a lot of VLANs at the edge > > and only a few in the core. Today, a typically > > enterprise could have 100's (may be a couple of > > 1000) VLANs configured on a typical bridge. > > The capabilities of typical small edge switches (the 48 port > kind) seem to max out at about 16-128 vlans total, and may have > other limitations if the switch is maintaining STP for each vlan. > This edge limitation is one of the reasons an enterprise partitions > vlans. > > Larger, "core" switches have enough capability to run up to 4096 > vlans at a time. > > Another issue causing vlans to be partitioned is because some > bridges only support vlan numbers < 1024 and there simply is a need > for vlan number reuse throughout the enterprise. Just to make it clear, we're talking about VLAN reuse within a single bridged LAN as opposed to VLAN reuse LANs that are isolated by routers. I don't see how that can be common. It would be a configuration nightmare to administer and also to debug. > Vlans are also partitioned is because flooding unknown unicast > frames takes up unnecessary bandwidth on 802.1q links, and can fill > up mac address tables on less-capable switches. When there are > situations like arp storms (no network is ever loop free), > partitioning vlan usage is even more of an issue. > > > But, we don't enable routing protocols on those > > VLANs because that's just the edge. Once in the > > core, there are typically only a handful of VLANs > > on which routing protocols are enabled. > > > We don't > > have experience sending hellos on so many VLANs > > and so many ports. > > I disagree with this argument. Many enterprises and carriers > deploy multiple routers on each edge subnet for redundancy. To > do this, VRRP or HSRP sends out hellos per vlan. If they are > running multicast routing, PIM sends out hellos per vlan also. > Some places even tune these hellos to very aggressive settings > such as 1 per second or less. Most folks don't enable routing/VRRP on all VLANs. Many switches that are capable of having 4K VLANs configured are not capable of even having IP configured on all 4K VLANs let alone turning on VRRP. > Large core switches running rapid-STP can send a BPDU every 2 > seconds across around 10,000 instances (m vlans * n ports) today. > These switches are also usually sending out (LLDP or CDP) and > UDLD frames on every port, too. This is completely wrong! RSTP is not VLAN aware. MSTP is, but it is limited to 64 instances. This is quite a different number than the 10000 that you quote. > > Unlike a router, an RBridge > > has to start sending hellos on all its ports as soon > > as it comes up. I don't think things can be > > made to work if we have to send these hellos > > for every VLAN configured on a port. > > Again, big switches have been doing this for a while for rapid-STP. > Routers with large numbers of vlans (sub-interfaces) are also doing > this today. > > The larger issue I see with Radia's proposal is simply the choice > of vlan #1. It could be a poor choice in large enterprises because > of scalability concerns and also compatability with existing > implementations. As a few others have brought up, many deployments > (including mine) have disabled vlan 1 altogether. > > One of these issues is that vlan 1 is often untagged on 802.1q trunk > links. As a security precaution, it is common to disable vlan 1 > across switches to prevent malicious vlan-hopping. > > Perhaps a compromise would be to use vlan 1 as the default, but a > TRILL implementation MAY allow this to be configurable by the > administrator. I agree. As also pointed out by Arien Vijn, we could select any VLAN as the "default RBridge VLAN", but we do need one. Anoop From Donald.Eastlake at motorola.com Fri Aug 3 13:36:45 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 3 Aug 2007 16:36:45 -0400 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags In-Reply-To: <46B2757E.9090608@sun.com> References: <46AE9B0D.4080606@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com><46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com><46AF7CF6.8090105@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com><46AFE276.1050601@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> <46B2757E.9090608@sun.com> Message-ID: <3870C46029D1F945B1472F170D2D979002DDE0B8@de01exm64.ds.mot.com> So why should the default be to tag Hellos with any VLAN ID? It seems to me that there are two cases. If you know, via configuration or otherwise, that there are no intervening legacy bridges (doesn't particularly matter if its point-to-point between two Rbridges or a multiaccess link with several Rbridges as long as there are no bridges in the way), then all TRILL IS-IS and TRILL data frames should be untagged. If there are or might be intervening bridges, then I would think the default should be for Hellos to be priority tagged with priority 7. This means the tag has the null VLAN ID zero, that is, it does not specify any VLAN. If it turns out there actually aren't any bridges, this works fine. If the link is actually a bridged LAN, the requirement is then that the bridge ports that the Rbridges are connected to be configured to be the same VLAN, whatever that is, and that that VLAN be connected through that particular bridged LAN. If these bridge ports are default configured, this means the TRILL IS-IS Hello frames will acquire VLAN 1 tagging on bridged LAN ingress and have that tag stripped on bridged LAN egress and you would want VLAN 1 to be well connected through the bridged LAN. If, for some reason, VLAN 1 is inconvenient for the network operator to use in the particular bridged LAN in question, the network operator would be free to configure the bridge ports so that the TRILL frames get tagged with whatever VLAN is more convenient for them to use to provide connectivity. It could still be possible to configure Rbridges, on a per port basis, to tag outgoing TRILL frames with some specific VLAN ID if that is more convenient. I would like to point out that, while the proposal from Radia below is much more detailed and better worked out and while the related provisions in the current protocol draft are much more vague, nevertheless, the current protocol draft approximately corresponds to this proposal. In particular, due to previous concerns about multiple Hellos, among other things the protocol draft (-05) says: Section 2, Page 7: If a link is actually a bridged LAN configured for VLANs, it is possible that the link might be partitioned with respect to some VLANs. The default is to run a single DRB election on a link, with the IS-IS Hellos either with no VLAN tag (the default), or with the VLAN tag specifying the default VLAN for the link. If the RBridge is configured to support a set of k VLANs on the link, then the RBridge runs the IS-IS DRB election up to k times, each instance tagged with one of the VLANs in that set of VLANs depending on its configuration. Therefore there might be multiple DRBs on the link, but at most one on that link per VLAN. By configuration, the DRB for some VLANs may be set by copying the DRB status in the relevant RBridges from a different VLAN rather than by election. So, arguably, the single Hello proposal below is approximately like using the current vague provisions in the protocol configured to only Hello on VLAN 1 and applying the result to all VLANs. The main difference is the proposal provides the per VLAN priorities in the Hello so you don't need this stuff about copying DRB status but can independently determine it for different VLANs without a per VLAN Hello... Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Thursday, August 02, 2007 8:23 PM Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags ... But at this point let's close this issue, which is basically to adopt Anoop's proposal of only sending IS-IS Hellos tagged with VLAN 1, plus my addendum to avoid temporary loops when VLAN 1 is partitioned by having RB2 refuse to decapsulate packets onto a port from ingress RBridge RB1 unless RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB for. ************* To review it: a) declare that bridges must be configured so that VLAN 1 (default VLAN) must not be partitioned on a layer 2 cloud. We will detect the misconfiguration if it occurs (see d)) so that we do not have loops, but if VLAN 1 is partitioned parts of the layer 2 cloud might wind up orphaned from the rest of the campus. b) Send IS-IS Hellos tagged with VLAN 1, containing the following: . I am R1 . I hear Hellos from {R2, R3, R7, R11} . If I am DRB, the pseudonode name will be R1.59 . My priority for the set of VLANs {A, D, W} is 7 . My priority for the set of VLANs {B, C, F, G, H} is 3 c) If R1 becomes DRB for at least one of the VLANs on the cloud, then R1 announces (in R1's LSP) connectivity to pseudonode R1.59, together with a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on behalf of pseudonode R1.59, R1 announces the ID of the root bridge on the primary spanning tree instance for that layer 2 cloud, along with the set of VLANs for which R1 is DRB on that cloud. d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A listed as one of the VLANs, this indicates that VLAN 1 on that layer 2 cloud is partitioned. So one of R1 or R2 should stop forwarding data to/from that cloud for VLAN A. Use ID as a tie breaker, so if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN A traffic to and from the port that has root bridge r11. This is the behavior that will occur if VLAN 1 on that port is actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would have seen each other's Hellos and not both think they are DRB for VLAN A (or any other VLAN). e) This proposal supports multiple DRBs on a cloud for load splitting based on VLANs, since the RBridges can have different priorities for different VLANs. It still requires only sending one Hello, tagged with VLAN 1. R2 should not panic if R2 notices that R1.59 has the same root bridge as on a port on which R2 is DRB, if R1.59's listed set of VLANs does not include any VLANs for which R2 is DRB on the link with that root bridge. If there is only partial overlap of VLAN IDs, say the overlap is VLANs {D, F, and H}, then (the loser based on ID tie-breaker) will stop forwarding traffic to/from that link that is tagged with VLANs D, F, or H. f) If some VLAN, say VLAN C, is actually partitioned, then the result of this is that some VLAN C endnodes on that layer 2 cloud will be orphaned. We will choose NOT to solve that. g) To avoid temporary loops when VLAN 1 is partitioned, for each other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate from", provided that RB2 has an LSP from RB1 and all pseudonodes RB1 claims to be attached to. If RB2 receives a frame from ingress RB1 and this flag is NOT true, then RB2 will refuse to decapsulate the packet onto any ports. (regardless of VLAN and regardless of whether the frame is multidestination or unicast). Radia From sgai at nuovasystems.com Fri Aug 3 14:59:04 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Fri, 3 Aug 2007 14:59:04 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withall the VLAN tags In-Reply-To: <3870C46029D1F945B1472F170D2D979002DDE0B8@de01exm64.ds.mot.com> References: <46AE9B0D.4080606@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com><46AF6557.2080109@sun.com><46AF701E.1060609@cisco.com><46AF7CF6.8090105@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com><46AFE276.1050601@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com><46B2757E.9090608@sun.com> <3870C46029D1F945B1472F170D2D979002DDE0B8@de01exm64.ds.mot.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201DBD98A@nuova-ex1.hq.nuovaimpresa.com> Donald, I am OK with the text in -05, I thought that Radia wanted to change it. As far as I am not prevented from running one DRB per VLAN, I don't care too much which is the default. I don't want TRILL to mandate implementing a single DRB election and additional tests that don't cover all the cases. Let's keep it simple. The current text is fine. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Friday, August 03, 2007 1:37 PM > To: rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > withall the VLAN tags > > So why should the default be to tag Hellos with any VLAN ID? It seems to > me that there are two cases. > > If you know, via configuration or otherwise, that there are no > intervening legacy bridges (doesn't particularly matter if its > point-to-point between two Rbridges or a multiaccess link with several > Rbridges as long as there are no bridges in the way), then all TRILL > IS-IS and TRILL data frames should be untagged. > > If there are or might be intervening bridges, then I would think the > default should be for Hellos to be priority tagged with priority 7. This > means the tag has the null VLAN ID zero, that is, it does not specify > any VLAN. If it turns out there actually aren't any bridges, this works > fine. If the link is actually a bridged LAN, the requirement is then > that the bridge ports that the Rbridges are connected to be configured > to be the same VLAN, whatever that is, and that that VLAN be connected > through that particular bridged LAN. If these bridge ports are default > configured, this means the TRILL IS-IS Hello frames will acquire VLAN 1 > tagging on bridged LAN ingress and have that tag stripped on bridged LAN > egress and you would want VLAN 1 to be well connected through the > bridged LAN. If, for some reason, VLAN 1 is inconvenient for the network > operator to use in the particular bridged LAN in question, the network > operator would be free to configure the bridge ports so that the TRILL > frames get tagged with whatever VLAN is more convenient for them to use > to provide connectivity. It could still be possible to configure > Rbridges, on a per port basis, to tag outgoing TRILL frames with some > specific VLAN ID if that is more convenient. > > I would like to point out that, while the proposal from Radia below is > much more detailed and better worked out and while the related > provisions in the current protocol draft are much more vague, > nevertheless, the current protocol draft approximately corresponds to > this proposal. In particular, due to previous concerns about multiple > Hellos, among other things the protocol draft (-05) says: > > Section 2, Page 7: > If a link is actually a bridged LAN configured for VLANs, it is > possible that the link might be partitioned with respect to some > VLANs. The default is to run a single DRB election on a link, with > the IS-IS Hellos either with no VLAN tag (the default), or with the > VLAN tag specifying the default VLAN for the link. If the RBridge is > configured to support a set of k VLANs on the link, then the RBridge > runs the IS-IS DRB election up to k times, each instance tagged with > one of the VLANs in that set of VLANs depending on its configuration. > Therefore there might be multiple DRBs on the link, but at most one > on that link per VLAN. By configuration, the DRB for some VLANs may > be set by copying the DRB status in the relevant RBridges from a > different VLAN rather than by election. > > So, arguably, the single Hello proposal below is approximately like > using the current vague provisions in the protocol configured to only > Hello on VLAN 1 and applying the result to all VLANs. The main > difference is the proposal provides the per VLAN priorities in the Hello > so you don't need this stuff about copying DRB status but can > independently determine it for different VLANs without a per VLAN > Hello... > > Donald > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Thursday, August 02, 2007 8:23 PM > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > with allthe VLAN tags > > ... > > But at this point let's close this issue, which is basically to adopt > Anoop's > proposal of only sending IS-IS Hellos tagged with VLAN 1, > plus my addendum to avoid temporary loops when VLAN 1 is partitioned by > having RB2 refuse to decapsulate packets onto a port from ingress > RBridge RB1 unless > RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB for. > > ************* > To review it: > > a) declare that bridges must be configured > so that VLAN 1 (default VLAN) must not be > partitioned on a layer 2 cloud. We will detect the misconfiguration > if it occurs (see d)) so that we do not have loops, but if VLAN 1 > is partitioned parts of the layer 2 cloud might wind up orphaned > from the rest of the campus. > > b) Send IS-IS Hellos tagged with VLAN 1, containing the following: > > . I am R1 > . I hear Hellos from {R2, R3, R7, R11} > . If I am DRB, the pseudonode name will be R1.59 > . My priority for the set of VLANs {A, D, W} is 7 > . My priority for the set of VLANs {B, C, F, G, H} is 3 > > c) If R1 becomes DRB for at least one of the VLANs on the cloud, > then R1 announces (in R1's LSP) > connectivity to pseudonode R1.59, together with > a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on > behalf of pseudonode R1.59, R1 announces > the ID of the root bridge on the primary spanning tree > instance for that layer 2 cloud, along with the set of VLANs for which > R1 is DRB on that cloud. > > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, > and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A > listed as one of the VLANs, this indicates that VLAN 1 on that layer > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding > data to/from that cloud for VLAN A. Use ID as a tie breaker, so > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding > VLAN A > traffic to and from the port that has root bridge r11. > This is the behavior that will occur if VLAN 1 on that port is > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 > would > have seen each other's Hellos and not both think they are DRB for VLAN A > (or > any other VLAN). > > e) This proposal supports multiple DRBs on a cloud for load splitting > based on VLANs, since the RBridges can have different priorities > for different VLANs. It still requires only sending one Hello, tagged > with VLAN 1. R2 should > not panic if R2 notices that R1.59 has the same root bridge as on > a port on which R2 is DRB, if R1.59's listed set of VLANs does not > include any VLANs for which R2 is DRB on the link with > that root bridge. If there is only partial overlap > of VLAN IDs, say the overlap is VLANs {D, F, and H}, > then (the loser based on ID tie-breaker) will stop forwarding traffic > to/from that link that is tagged with VLANs D, F, or H. > > f) If some VLAN, say VLAN C, is actually partitioned, then the > result of this is that some VLAN C endnodes on that layer 2 cloud > will be orphaned. We will choose NOT to solve that. > > g) To avoid temporary loops when VLAN 1 is partitioned, for each > other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate > from", provided that RB2 has an LSP from RB1 and all pseudonodes > RB1 claims to be attached to. If RB2 receives a frame from ingress > RB1 and this flag is NOT true, then RB2 will refuse to decapsulate > the packet onto any ports. (regardless of VLAN and regardless of whether > the frame is multidestination or unicast). > > > Radia > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Sat Aug 4 20:57:58 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 4 Aug 2007 23:57:58 -0400 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withall the VLAN tags In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201DBD98A@nuova-ex1.hq.nuovaimpresa.com> References: <46AE9B0D.4080606@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com><46AF6557.2080109@sun.com><46AF701E.1060609@cisco.com><46AF7CF6.8090105@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com><46AFE276.1050601@sun.com><34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com><46B2757E.9090608@sun.com> <3870C46029D1F945B1472F170D2D979002DDE0B8@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201DBD98A@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <3870C46029D1F945B1472F170D2D979002DDE1DF@de01exm64.ds.mot.com> Silvano, I think that the provisions in the draft should be changed. At a minimum, it seems useful when someone is doing a DRB election on one VLAN intending to produce results that apply to multiple VLANs that the Hellos list the VLANs and be able to specify different priorities for them so the elections are not all required to come out the same. And some additional logic to handle partitions seems reasonable. Donald -----Original Message----- From: Silvano Gai [mailto:sgai at nuovasystems.com] Sent: Friday, August 03, 2007 5:59 PM To: Eastlake III Donald-LDE008; rbridge at postel.org Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withall the VLAN tags Donald, I am OK with the text in -05, I thought that Radia wanted to change it. As far as I am not prevented from running one DRB per VLAN, I don't care too much which is the default. I don't want TRILL to mandate implementing a single DRB election and additional tests that don't cover all the cases. Let's keep it simple. The current text is fine. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Friday, August 03, 2007 1:37 PM > To: rbridge at postel.org > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > withall the VLAN tags > > So why should the default be to tag Hellos with any VLAN ID? It seems to > me that there are two cases. > > If you know, via configuration or otherwise, that there are no > intervening legacy bridges (doesn't particularly matter if its > point-to-point between two Rbridges or a multiaccess link with several > Rbridges as long as there are no bridges in the way), then all TRILL > IS-IS and TRILL data frames should be untagged. > > If there are or might be intervening bridges, then I would think the > default should be for Hellos to be priority tagged with priority 7. This > means the tag has the null VLAN ID zero, that is, it does not specify > any VLAN. If it turns out there actually aren't any bridges, this works > fine. If the link is actually a bridged LAN, the requirement is then > that the bridge ports that the Rbridges are connected to be configured > to be the same VLAN, whatever that is, and that that VLAN be connected > through that particular bridged LAN. If these bridge ports are default > configured, this means the TRILL IS-IS Hello frames will acquire VLAN 1 > tagging on bridged LAN ingress and have that tag stripped on bridged LAN > egress and you would want VLAN 1 to be well connected through the > bridged LAN. If, for some reason, VLAN 1 is inconvenient for the network > operator to use in the particular bridged LAN in question, the network > operator would be free to configure the bridge ports so that the TRILL > frames get tagged with whatever VLAN is more convenient for them to use > to provide connectivity. It could still be possible to configure > Rbridges, on a per port basis, to tag outgoing TRILL frames with some > specific VLAN ID if that is more convenient. > > I would like to point out that, while the proposal from Radia below is > much more detailed and better worked out and while the related > provisions in the current protocol draft are much more vague, > nevertheless, the current protocol draft approximately corresponds to > this proposal. In particular, due to previous concerns about multiple > Hellos, among other things the protocol draft (-05) says: > > Section 2, Page 7: > If a link is actually a bridged LAN configured for VLANs, it is > possible that the link might be partitioned with respect to some > VLANs. The default is to run a single DRB election on a link, with > the IS-IS Hellos either with no VLAN tag (the default), or with the > VLAN tag specifying the default VLAN for the link. If the RBridge is > configured to support a set of k VLANs on the link, then the RBridge > runs the IS-IS DRB election up to k times, each instance tagged with > one of the VLANs in that set of VLANs depending on its configuration. > Therefore there might be multiple DRBs on the link, but at most one > on that link per VLAN. By configuration, the DRB for some VLANs may > be set by copying the DRB status in the relevant RBridges from a > different VLAN rather than by election. > > So, arguably, the single Hello proposal below is approximately like > using the current vague provisions in the protocol configured to only > Hello on VLAN 1 and applying the result to all VLANs. The main > difference is the proposal provides the per VLAN priorities in the Hello > so you don't need this stuff about copying DRB status but can > independently determine it for different VLANs without a per VLAN > Hello... > > Donald > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Thursday, August 02, 2007 8:23 PM > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged > with allthe VLAN tags > > ... > > But at this point let's close this issue, which is basically to adopt > Anoop's > proposal of only sending IS-IS Hellos tagged with VLAN 1, > plus my addendum to avoid temporary loops when VLAN 1 is partitioned by > having RB2 refuse to decapsulate packets onto a port from ingress > RBridge RB1 unless > RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB for. > > ************* > To review it: > > a) declare that bridges must be configured > so that VLAN 1 (default VLAN) must not be > partitioned on a layer 2 cloud. We will detect the misconfiguration > if it occurs (see d)) so that we do not have loops, but if VLAN 1 > is partitioned parts of the layer 2 cloud might wind up orphaned > from the rest of the campus. > > b) Send IS-IS Hellos tagged with VLAN 1, containing the following: > > . I am R1 > . I hear Hellos from {R2, R3, R7, R11} > . If I am DRB, the pseudonode name will be R1.59 > . My priority for the set of VLANs {A, D, W} is 7 > . My priority for the set of VLANs {B, C, F, G, H} is 3 > > c) If R1 becomes DRB for at least one of the VLANs on the cloud, > then R1 announces (in R1's LSP) > connectivity to pseudonode R1.59, together with > a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on > behalf of pseudonode R1.59, R1 announces > the ID of the root bridge on the primary spanning tree > instance for that layer 2 cloud, along with the set of VLANs for which > R1 is DRB on that cloud. > > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11, > and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A > listed as one of the VLANs, this indicates that VLAN 1 on that layer > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding > data to/from that cloud for VLAN A. Use ID as a tie breaker, so > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding > VLAN A > traffic to and from the port that has root bridge r11. > This is the behavior that will occur if VLAN 1 on that port is > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 > would > have seen each other's Hellos and not both think they are DRB for VLAN A > (or > any other VLAN). > > e) This proposal supports multiple DRBs on a cloud for load splitting > based on VLANs, since the RBridges can have different priorities > for different VLANs. It still requires only sending one Hello, tagged > with VLAN 1. R2 should > not panic if R2 notices that R1.59 has the same root bridge as on > a port on which R2 is DRB, if R1.59's listed set of VLANs does not > include any VLANs for which R2 is DRB on the link with > that root bridge. If there is only partial overlap > of VLAN IDs, say the overlap is VLANs {D, F, and H}, > then (the loser based on ID tie-breaker) will stop forwarding traffic > to/from that link that is tagged with VLANs D, F, or H. > > f) If some VLAN, say VLAN C, is actually partitioned, then the > result of this is that some VLAN C endnodes on that layer 2 cloud > will be orphaned. We will choose NOT to solve that. > > g) To avoid temporary loops when VLAN 1 is partitioned, for each > other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate > from", provided that RB2 has an LSP from RB1 and all pseudonodes > RB1 claims to be attached to. If RB2 receives a frame from ingress > RB1 and this flag is NOT true, then RB2 will refuse to decapsulate > the packet onto any ports. (regardless of VLAN and regardless of whether > the frame is multidestination or unicast). > > > Radia > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From dwcarder at doit.wisc.edu Mon Aug 6 08:48:53 2007 From: dwcarder at doit.wisc.edu (Dale W. Carder) Date: Mon, 06 Aug 2007 10:48:53 -0500 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E3CB0FC@HQ-EXCH-5.corp.brocade.com> References: <46AE9B0D.4080606@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D2E5F3@nuova-ex1.hq.nuovaimpresa.com> <46AF6557.2080109@sun.com> <46AF701E.1060609@cisco.com> <46AF7CF6.8090105@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D76D3E@nuova-ex1.hq.nuovaimpresa.com> <46AFE276.1050601@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201D77813@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E3CB06D@HQ-EXCH-5.corp.brocade.com> <4F5D08D1-1A28-4462-9C65-2D8AB2DE33D9@doit.wisc.edu> <4C94DE2070B172459E4F1EE14BD2364E3CB0FC@HQ-EXCH-5.corp.brocade.com> Message-ID: <6E7BE0B0-EB88-4E9C-8F82-7592BE88DA46@doit.wisc.edu> On Aug 3, 2007, at 12:07 PM, Anoop Ghanwani wrote: >> Large core switches running rapid-STP can send a BPDU every 2 >> seconds across around 10,000 instances (m vlans * n ports) today. >> These switches are also usually sending out (LLDP or CDP) and >> UDLD frames on every port, too. > > This is completely wrong! RSTP is not VLAN aware. > MSTP is, but it is limited to 64 instances. This > is quite a different number than the 10000 that you > quote. I was referring in this case to a proprietary implementation, but my point is that it seems possible that it can be done. I am not saying that sending hellos on every vlan is a great idea, but I just wanted to show that I believe it is feasible based on deployments I have seen that are running protocols that do send hellos or similar on every vlan today. >> Perhaps a compromise would be to use vlan 1 as the default, but a >> TRILL implementation MAY allow this to be configurable by the >> administrator. > > I agree. As also pointed out by Arien Vijn, we could > select any VLAN as the "default RBridge VLAN", but we do > need one. I don't think there is any easy solution. Could the default be to use vlan 1 *untagged*? This would allow an rbridge to be plugged in almost anywhere. If a network operator wanted to change the vlan number she could do it on her existing bridged lan. Is there a more formal name for the "default RBridge VLAN"? Dale From ddutt at cisco.com Mon Aug 6 10:03:29 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 06 Aug 2007 10:03:29 -0700 Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags In-Reply-To: <46B2ACCA.2070300@sun.com> References: <46AE9B0D.4080606@sun.com> <46B0C653.8010304@cisco.com> <46B0FD22.7030200@sun.com> <46B27FBA.5010304@cisco.com> <46B2ACCA.2070300@sun.com> Message-ID: <46B75461.6040201@cisco.com> Radia, I don't believe what you suggested below works including what you detailed later. The problem is that when Rb1 and Rb2 both think that they're DRBs on VLAN A but cannot communicate oN VLAN 1, they may have synchronized their LSP databases with their neighbors, but it doesn't fix the problem because the information of the other DRB hasn't yet reached the neighbor. I think at this point, I'm leaning towards saying that the default SHOULD be to support per-VLAN DRB election, but provide the option to do DRB only on a single VLAN, VLAN 1. Allowing which VLAN to carry out the DRB on is another potential misconfiguration and so I'm worried about this knob, though I won't protest providing it. Doing it this way solves Anoop's problem for the cases he's worried about, but makes the network robust by default. Dinesh Radia Perlman wrote: > Yes, Dinesh, in your example if there are temporarily k RBridges on > the same layer 2 cloud > that all think they are DRB, you might multiply by k, each packet > going off the cloud. > > However, this is not as disastrous as a loop. > > We can avoid that though by saying that you shouldn't start > encapsulating or decapsulating > data off the link until you've synchronized LSP datases with each of > your RBridge neighbors. > IS-IS exchanges LSP database information (a "complete sequence numbers > packet") when > a link comes up. I think we should throw that rule in as well. > > Radia > > > > > Dinesh G Dutt wrote: >> Radia, >> >> I thought about this solution but think that it still doesn't fix the >> problem of duplicates. If both R1 and R2 think that they're DRB for >> VLAN A, when they both receive a frame on VLAN A from the 802.1D >> cloud (unknown unicast for example), they both think that they can >> forward it onto the TRILL network. The destination host will now >> receive duplicate frames till one of them stops being DRB. >> >> Am I mistaken ? >> >> Dinesh >> Radia Perlman wrote: >> >>> Dinesh, >>> >>> I think you are right that there can be a temporary loop due to a >>> partitioned VLAN 1. >>> And I think we can make it sufficiently unlikely to occur with a >>> suggestion I'll make >>> after I explain the problem. >>> >>> The temporary loop would be if R1 and R2, on the same layer 2 cloud, >>> have >>> connectivity through VLAN A but not VLAN 1. So there would be two >>> DRBs, on >>> both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 >>> and R2.62, >>> and both would claim to be connected to both VLAN A and VLAN 1, and >>> both >>> would claim the same root bridge, say 5134. >>> >>> A multicast tagged with VLAN 1 would not be too much of a problem >>> because anything >>> R1 decapsulates onto that VLAN-1-partitioned cloud would not make it >>> through >>> the partitioned cloud to R2. But since we are not running the DRB >>> election tagged >>> with VLAN A, R1 and R2 do not realize that they can talk via VLAN A. >>> >>> Therefore, a VLAN A-tagged packet would get picked up by both R1 and >>> R2, >>> and both would assume they are DRB. >>> Also, if R1 receives a (inner header) VLAN-A tagged frame >>> from the campus, R1 will decapsulate it onto the layer 2 cloud as a >>> VLAN-A >>> tagged packet, and R2 will see it >>> and re-encapsulate it onto the campus, and R1 would see it again and >>> decapsulate it, etc. >>> >>> This loop will eventually be fixed when R1 sees the LSP from >>> pseudonode R2.62 indicating >>> that the root bridge is 5134, since R1 will also think that the >>> cloud that R1 is DRB for has >>> root bridge 5134. >>> >>> So here's a possible fix: >>> >>> R1 does not decapsulate a multidestination packet with ingress >>> RBridge R2 unless R1 >>> has an LSP from R2, and has LSPs from all pseudonodes that R2 claims >>> (in R2's >>> LSP) to be DRB for. Note that I'm suggesting adding another flag in >>> the neighbor >>> list in R2's LSP saying "not only am I attached to this pseudonode, >>> but I am >>> DRB for it". >>> >>> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if >>> the root bridge >>> listed is the same as the one for the link on which R2 would like to >>> decapsulate, and if it is, >>> then don't decapsulate. >>> >>> We were already saying that if R1 notices that R2.79 has the same >>> root bridge as >>> a link R1 wants to be DRB for that one of R1 or R2 would lose, based >>> on a tie-breaker >>> based on ID, and stop forwarding traffic to/from the link. What I'm >>> suggesting is that >>> you also don't forward multidestination traffic to/from a link if >>> you don't yet have all >>> the associated LSP information from the ingress RBridge that can >>> assure you there >>> isn't a common root bridge. >>> >>> Radia >>> >>> >>> >>> >>> Dinesh G Dutt wrote: >>> >>>> OK, based on emails from James Carlson and Radia, I went back and >>>> thought about my reasons for objecting to the suggested proposal. I >>>> also spoke to some field engineers to validate my understanding of >>>> what I thought the issues were. >>>> >>>> There are two issues that we're dealing with here: >>>> - Simplifying DRB election to conduct it only on VLAN 1 >>>> - Merging partitioned VLANs. >>>> >>>> I'd like to separate the two issues. Let me discuss only the first >>>> issue, the simplified DRB election in this email. I'll send out a >>>> separate email on the other issue. >>>> >>>> Assuming VLAN 1 exists everywhere is an acceptable alternative. I >>>> was informed that even with STP, customers enable VLAN 1 and allow >>>> only control traffic on it and not data traffic. If we have VLAN 1 >>>> present as a common configuration, then running DRB only on VLAN 1 >>>> and following Radia's proposal (or fixing it to work) seems >>>> acceptable, except for one caveat. >>>> >>>> However, in the event of a misconfiguration and VLAN 1 not being >>>> present, while the scheme proposed partitions the network and >>>> prevents loops, it seems to me that there is a period during which >>>> temporary loops can happen and duplicate frames are delivered by >>>> two DRBs. This seems unacceptable to me from a customer point of >>>> view. If we can fix this temporary loop (or someone can explain to >>>> me why there are no temporary loops), I'd be willing to support >>>> this proposal. >>>> >>>> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of >>>> customer networks and so we cannot assume or mandate their being >>>> there. >>>> >>>> Dinesh >>>> Radia Perlman wrote: >>>> >>>>> I had a conversation with Anoop, and he is (quite understandably) >>>>> uneasy about sending IS-IS Hellos tagged with every VLAN. So he >>>>> made the following suggestion, which I think makes sense. >>>>> >>>>> a) declare that bridges must be configured >>>>> so that VLAN 1 (default VLAN) must not be >>>>> partitioned on a layer 2 cloud. We will detect the misconfiguration >>>>> if it occurs (see d)) so that we at least do not have loops, but >>>>> TRILL will not >>>>> stand on its head to support what will be declared a gross >>>>> misconfiguration. >>>>> >>>>> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has >>>>> the following information in its IS-IS Hello: >>>>> >>>>> . I am R1 >>>>> . I hear Hellos from {R2, R3, R7, R11} >>>>> . If I am DRB, the pseudonode name will be R1.59 >>>>> . My priority for the set of VLANs {A, D, W} is 7 >>>>> . My priority for the set of VLANs {B, C, F, G, H} is 3 >>>>> >>>>> c) If R1 becomes DRB for at least one of the VLANs on the cloud, >>>>> then R1 announces, in R1's LSP on behalf of pseudonode R1.59, >>>>> the ID of the root bridge on the primary spanning tree >>>>> instance for that layer 2 cloud, along with the set of VLANs for >>>>> which >>>>> R1 is DRB on that cloud. >>>>> >>>>> Note: The current draft spec isn't clear what information R1 >>>>> reports in the pseudonode >>>>> LSP and what it reports in its own LSP. >>>>> I'm suggesting reporting the bridge ID and >>>>> set of VLANs in the pseudonode LSP. >>>>> >>>>> d) If R2 thinks itself is DRB for VLAN A on a port with root >>>>> bridge r11, >>>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A >>>>> listed as one of the VLANs, this indicates that VLAN 1 on that layer >>>>> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding >>>>> data to/from that cloud for VLAN A. Use ID as a tie breaker, so >>>>> if R2's IS-IS system ID is lower than R1's, then R2 stops >>>>> forwarding VLAN A >>>>> traffic to and from the port that has root bridge r11. >>>>> This is the behavior that will occur if VLAN 1 on that port is >>>>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and >>>>> R2 would >>>>> have seen each other's Hellos and not both think they are DRB for >>>>> VLAN A (or >>>>> any other VLAN). >>>>> >>>>> e) This proposal supports multiple DRBs on a cloud for load splitting >>>>> based on VLANs, since the RBridges can have different priorities >>>>> for different VLANs. It still requires only sending one Hello, tagged >>>>> with VLAN 1. R2 should >>>>> not panic if R2 notices that R1.59 has the same root bridge as on >>>>> a port on which R2 is DRB, if R1.59's listed set of VLANs does not >>>>> include any VLANs for which R2 is DRB on the link with >>>>> that root bridge. If there is only partial overlap >>>>> of VLAN IDs, say the overlap is VLANs {D, F, and H}, >>>>> then (the loser based on ID tie-breaker) will stop forwarding traffic >>>>> to/from that link that is tagged with VLANs D, F, or H. >>>>> >>>>> f) If some VLAN, say VLAN C, is actually partitioned, then the >>>>> result of this is that some VLAN C endnodes on that layer 2 cloud >>>>> will be orphaned. We will choose NOT to solve that. >>>>> >>>>> >>>>> The result of this proposal is that >>>>> RBridges will only need to send IS-IS Hellos tagged >>>>> with VLAN 1, and the only thing it does NOT solve (over >>>>> the current proposal of sending Hellos with every possible VLAN >>>>> tag on >>>>> each port) is that sometimes endnodes might get orphaned if you have >>>>> a partitioned VLAN. >>>>> >>>>> >>>>> We *could* in that case, if someone *actually wanted* to have VLAN A >>>>> partitioned on that cloud, configure the RBridges on that layer 2 >>>>> cloud to explicitly run a different election >>>>> for VLAN A (and note in the pseudonode LSP that VLAN A had >>>>> an explicit election tagged with VLAN A so that if there were >>>>> two DRBs they wouldn't panic). But I'd prefer not solving this >>>>> case and >>>>> keeping it simpler (and safer). >>>>> >>>>> Radia >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge at postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >> >> > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From sgai at nuovasystems.com Mon Aug 6 10:07:45 2007 From: sgai at nuovasystems.com (Silv