From d3e3e3 at gmail.com Fri Sep 12 12:03:17 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 12 Sep 2008 15:03:17 -0400 Subject: [rbridge] Fwd: Call for IETF Nominees Message-ID: <1028365c0809121203n397b87eehfa943442b3952a2d@mail.gmail.com> Hi, The NomCom Chair has requested that working group chairs forward this request to the working group mailing lists so I am doing that. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com ---------- Forwarded message ---------- From: NomCom Chair Date: Fri, Sep 12, 2008 at 12:46 PM Subject: Call for Nominees To: IETF Announcement list The 2008-9 IETF Nominating Committee needs your help. We have started getting candidates. If we are going to do our job in time, we have only 3 more weeks to get enough candidates to have a reasonable pool for all the jobs. At the moment, we do not have a reasonable pool for any jobs. If you are willing to serve, please nominate yourself. If there is someone you think would do a good job, please nominate them. The web site at: http://wiki.tools.ietf.org/group/nomcom/08 Has the list of positions we are seeking people for, as well as tools for providing both nominations and feedback. Alternatively, you can submit nominations by sending email to me. Please help us. Thank you, Joel M. Halpern jmh at joelhalpern.com nomcom-chair at ietf.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080912/383553db/attachment.html From Radia.Perlman at sun.com Mon Sep 15 22:10:39 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 15 Sep 2008 22:10:39 -0700 Subject: [rbridge] Proposal to make VLAN mapping work Message-ID: <48CF3FCF.6010204@sun.com> Some people expressed a desire to make "VLAN mapping" work with RBridges, since it does work with bridges. The current version of the spec attempts to detect VLAN mapping on a layer 2 cloud (caused by bridge configuration within a cloud), and declare it a misconfiguration. Some people objected (privately to me) to treating VLAN mapping as an error case, and said that customers actually use it with bridges and might be unhappy if the feature were removed in RBridges. So this note is proposing what we might do to the RBridge spec to allow the VLAN mapping feature. First, What is VLAN mapping? It is when a packet marked as VLAN A turns into a VLAN B packet. Bridges can do it explicitly ("If something tagged as VLAN-A comes in on port p1, change the tag to VLAN-B if forwarding onto port p2"). Or, a bridge B1 might be configured to emit packets on port p1 with no tags, so B1 removes the VLAN-A tag, and B2 (on the same link) might be configured to assume that untagged packets are assumed to be VLAN-B. Second, why would anyone want this (obviously scary if misconfigured) feature? Here are two examples: a) two companies, say "East" and "West" merge, and join their networks into one big layer 2 network. Both have used the tag "VLAN A" for one of their VLANs, but do not want the East VLAN-A nodes in the same VLAN as the West VLAN-A nodes. The "right" solution is to change all the bridges (and any nodes that actually are emitting tagged packets) in, say, East, to renumber "A" to some other unused tag. But for whatever reason, the customer might not want to do that, and instead wants all the work to be done by bridges on the "cut set" between East and West (where "cut set" means the bridges that connect East and West). b) second example: a company decides it wants to partition VLAN A into two separate VLANs, say A1 and A2, and they are lucky enough that all the A1 links are in a different location within their bridged Ethernet from all the A2 links. A goal is that the only bridges (RBridges in our case) that need to do anything special for the VLAN mapping are the ones on the cut set. ******************************************* So here's a proposal. First, how to deal with VLAN mapping on a layer 2 cloud within the campus. If VLAN A maps to VLAN B, the only real problem is if there is a different appointed forwarder for the two VLANs. So the only thing we need to do is put the original VLAN tag of a Hello inside the Hello (as the spec already says to do), and decide what to do as a result (which the spec does not currently say). If R1 is the appointed forwarder for VLAN-A, it must transmit a Hello tagged with VLAN A (this is already specified). And VLAN-A is inside the packet as well as being in the outer Ethernet header, where a VLAN mapping bridge might muck with it. If R2 receives a packet with tag VLAN-B, with "A" inside, R2 must inform the Designated RBridge "VLAN A maps to B", and the DRB must make sure that the same RBridge is appointed forwarder for A and B. If we are worried about there being too many VLANs being mapped to report it, I'd be happy with a single bit "VLAN mapping is going on", in which case the DRB must appoint only a single appointed RBridge forwarder for the entire cloud. So the only issue is how to encode "VLAN mapping is going on". Second, how to deal with VLAN mapping within the campus. Let's simplify the example and assume no bridges. Let's assume that two clouds, East and West, are being merged and we want to differentiate East-VLAN-A from West-VLAN A. ------------------------ First issue: data packets: Let's say that R1, R2, and R3 each are connected to both East and West. The only RBridges that will need to be configured are R1, R2, and R3. ------------- ----------------- | | | | | |------R1---------| | | West | | East |----R6 | |------R2---------| | | | | | | VLAN y | |------R3---------| | | ------------- ----------------- D | East-A = X | R4 West-A = Y R5 | | VLAN A VLAN A | | S S1 ********* Hmm. My beautiful ASCII art picture seems to have gotten mangled when I moved the text from notepad into my email send buffer. In case it is mangled as you receive it, the picture is supposed to indicate two clouds, "East" and "West", with three RBridges; R1, R2, R3 connecting the clouds, and VLAN-A on East is translated to VLAN-X in West, and VLAN-A in West is translated to VLAN-Y on East, and R4, in West, is connected to VLAN-A endnode S, and R6 in East is connected to VLAN-Y endnode D (where S and D, due to remapping, should be in the same VLAN). ******** Both East and West have used VLAN A, but you don't want to merge the two VLAN A's. Choose two unused VLAN numbers, say X and Y. R1, R2, and R3 are all configured to change the tag of a VLAN-A tagged packet they see on their East port to VLAN X when forwarding to West. Also, to change the tag of a VLAN-A tagged packet they see on their West port to VLAN Y. R1, R2, and R3 all claim, in their LSP, to be connected to A, X, and Y. Suppose S tries to talk to D. First assume R4 does not know where D is. R4 injects a VLAN-A tagged unknown destination packet. Since R1, R2, and R3 all claim to be connected (in their LSP) to VLAN A, they all receive the multicast. Assuming they are on the distribution tree, they change the tag from "A" to "Y" when forwarding from West to East. R6 receives the packet. R6 learns that "S" on VLAN Y is connected to R4. Now when D replies to S, there is no problem. The packet, tagged with VLAN Y is sent to R4, and along the way, one of R1, R2, or R3 change the tag to "VLAN-A". R4 learns that VLAN-X endnode "D" is connected to R6. I believe that all works. Even if a path goes from West to East and back to West. The data packet's inner Ethernet header tag would get translated each time the packet traverses one of the border RBridges. ------------------ The next thing is how LSPs work ("core" LSPs). I don't think there is any complication. R4 will see that R5 also claims to be connected to VLAN A, but that is actually irrelevant, as long as R4 is learning endnodes based on received traffic. However, what about endnode advertisements (which the spec currently calls ESADI, for End System Advertisement Instance). R4 will issue an ESADI about R4's attacked VLAN-A endnodes. I believe the ESADI is known as a VLAN-A advertisement based solely on the tag on the inner Ethernet header of the encapsualted ESADI packet. Assuming that is true, then all that has to happen is that R1, R2, and R3 do their VLAN translation of the inner Ethernet header tag as they would for any data packet, and when a VLAN-A ESADI moves from West to East, it magically turns into a VLAN-Y tag. Note that R1, when it translates the tag, is *not* messing with the contents of R4's LSP -- just the tag in the Ethernet header. **************** In summary, I think very little has to change in the spec. I think the only changes are: a) make sure there is a way of notifying the DRB, in your Hello, if you detect VLAN mapping within a layer 2 cloud b) make sure that the only indication that an ESADI belongs to VLAN-A is based on the tag in the Ethernet header, and not anything in the body of the LSP. I think a separate document should specify the behavior of a VLAN mapping RBridge. And my preference would be that there would be a way of reporting in your (core) LSP "I'm mapping VLAN A to VLAN X", just for management purposes, but RBridges should ignore the field. Comments? Radia From Caitlin.Bestler at neterion.com Tue Sep 16 14:54:58 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Tue, 16 Sep 2008 17:54:58 -0400 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48CF3FCF.6010204@sun.com> References: <48CF3FCF.6010204@sun.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> My first inclination is that supporting VLAN remapping is something that RBridges should support. One of the strengths of RBridge as compared to proposals such as Shortest Path Bridging (SPB) is that RBridges can be added at the edges and use the existing L2 network as is. Most 802.1 defined enhancements, in contrast, are only defined over the scope of a cloud consisting solely of bridges and end stations that are advertise their awareness of the enhanced protocol. But given that objective, I did not follow why a simpler solution would not work. Basically, we could require that there be a consistent set of VLANs that is used for all interactions between RBridges. But then we could specifically allow RBridges to do VLAN mapping when encapsulating or decapsulating. Essentially the VLAN Mapping could be a feature of the 802.1Q bridge co-located with the RBridge. The main defect I can see with this is that a frame originating in Universe A would be translated on ingress, sent to the destination RBridge and then translated back for delivery. If the destination was also in Universe A then the double translation was unnecessary. But it would work. From Radia.Perlman at sun.com Tue Sep 16 22:06:28 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 16 Sep 2008 22:06:28 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> Message-ID: <48D09054.7090406@sun.com> Not sure I understand what you said, but my understanding was that people wanted to be able to take two clouds (say "East" and "West") and not do any configuration of any of the RBridges inside either of the clouds, but only have the intelligence about VLAN mapping in the RBridges that connect the two clouds. It sounds like you are suggesting that every ingress/egress RBridge associated with a mapped VLAN would need to be configured. What I was suggesting would only require the three RBridges in my picture that connect East and West to know about VLAN mapping. Also, if there really is a difference between "East-VLAN-A" and "West-VLAN-A", I'm not sure how the egress RBridge can know whether the packet originated from "East" or "West". It couldn't even be based on the identity of the ingress RBridge ("R1 is in East") because an RBridge could have some ports in East and some in West. But it's certainly possible I misunderstood your note. What I think I did understand is that you are supporting us making sure that we do allow for VLAN mapping. Thanks, Radia Caitlin Bestler wrote: > My first inclination is that supporting VLAN remapping is something > that RBridges should support. One of the strengths of RBridge > as compared to proposals such as Shortest Path Bridging (SPB) > is that RBridges can be added at the edges and use the existing > L2 network as is. > > Most 802.1 defined enhancements, in contrast, are only defined > over the scope of a cloud consisting solely of bridges and > end stations that are advertise their awareness of the > enhanced protocol. > > But given that objective, I did not follow why a simpler > solution would not work. Basically, we could require that > there be a consistent set of VLANs that is used for all > interactions between RBridges. But then we could specifically > allow RBridges to do VLAN mapping when encapsulating or > decapsulating. > > Essentially the VLAN Mapping could be a feature of the > 802.1Q bridge co-located with the RBridge. > > The main defect I can see with this is that a frame > originating in Universe A would be translated on ingress, > sent to the destination RBridge and then translated back > for delivery. If the destination was also in Universe > A then the double translation was unnecessary. > > But it would work. > > From Caitlin.Bestler at neterion.com Wed Sep 17 00:41:11 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Wed, 17 Sep 2008 03:41:11 -0400 Subject: [rbridge] Proposal to make VLAN mapping work References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> Yes, the solution solution I was suggesting puts the burden of VLAN mapping on the RBridges that act as ingress/egress to subnets that have "alternate" VLAN maps. In some scenarios this would indeed mean that more RBridges had to be configured. But the configurations would be purely local. There would be zero impact on RBridge interactions. It's more of an administrative burden, but keeps the protocols simpler. But I fully agree on the main point. A key strength of RBridges is that they can be deployed from the edges on an incremental basis rather than being forced to build out from a set of enhanced Bridges that all talk directly to each other. When you are building from the center out, it is not that unreasonable to state that as the enhanced cloud grows each addition has to adhere to the same set of VLANs. But if you're just plopping down RBridges and letting them discover each other through an existing network then it makes more sense to try to work with any network that actually works, and not just those that are configured the way we would prefer. I suppose what I am suggesting is that "special needs" networks should be supported, but not necessarily with a zero-configuration option. Explicit administrative action may be required, but we should not require reconfiguring existing bridges and end stations. But requiring that the RBridges be configured manually to deal with unique deployments does not strike me as being that onerous. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080917/0866a165/attachment.html From ddutt at cisco.com Wed Sep 17 08:19:00 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 17 Sep 2008 08:19:00 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> Message-ID: <48D11FE4.8020903@cisco.com> Caitlin, I was of the same opinion, until I realized that VLAN pruning in the broadcast trees and multicast pruning requires us to modify the control protocol, especially since the Rbridges that are doing the mapping are sort of in the core of the network when the networks are merging. Dinesh Caitlin Bestler wrote: > > Yes, the solution solution I was suggesting puts the burden of VLAN > mapping > on the RBridges that act as ingress/egress to subnets that have > "alternate" > VLAN maps. > > In some scenarios this would indeed mean that more RBridges had to be > configured. But the configurations would be purely local. There would be > zero impact on RBridge interactions. > > It's more of an administrative burden, but keeps the protocols simpler. > > But I fully agree on the main point. A key strength of RBridges is that > they can be deployed from the edges on an incremental basis rather > than being forced to build out from a set of enhanced Bridges that > all talk directly to each other. > > When you are building from the center out, it is not that unreasonable > to state that as the enhanced cloud grows each addition has to adhere > to the same set of VLANs. > > But if you're just plopping down RBridges and letting them discover > each other through an existing network then it makes more sense to > try to work with any network that actually works, and not just those > that are configured the way we would prefer. > > I suppose what I am suggesting is that "special needs" networks should > be supported, but not necessarily with a zero-configuration option. > Explicit administrative action may be required, but we should not > require reconfiguring existing bridges and end stations. But requiring > that the RBridges be configured manually to deal with unique > deployments does not strike me as being that onerous. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Caitlin.Bestler at neterion.com Wed Sep 17 10:17:38 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Wed, 17 Sep 2008 13:17:38 -0400 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D11FE4.8020903@cisco.com> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Wednesday, September 17, 2008 8:19 AM > To: Caitlin Bestler > Cc: Radia Perlman; rbridge at postel.org > Subject: Re: [rbridge] Proposal to make VLAN mapping work > > Caitlin, > > I was of the same opinion, until I realized that VLAN pruning in the > broadcast trees and multicast pruning requires us to modify the control > protocol, especially since the Rbridges that are doing the mapping are > sort of in the core of the network when the networks are merging. > > Dinesh Dinesh, Are you saying that in the "merged network" scenario, that there would essentially be an "East Core" and a "West Core", and that each needs to do its own VLAN pruning separate from the East/West VLAN Mapping Bridges are considered? That would be a justification for the more complex solution. But just to kick the tires one more time, why can't the end stations and bridges operating with legacy non-integrated VLAN Maps be partitioned at the edges? From ddutt at cisco.com Wed Sep 17 10:28:08 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 17 Sep 2008 10:28:08 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> Message-ID: <48D13E28.8040604@cisco.com> Hi Caitlin, I don't think doing everything at the edge works. Consider a ARP request originating in the East Cloud in VLAN X. It must hit all end stations in VLAN X in the East Cloud and all end stations in VLAN Y in the West Cloud (assuming X is mapped to Y going from E->W). If I don't change the VLAN mapping at the RBridge connecting the two clouds, then it'll reach the wrong set of stations in the total cloud. Was that clear ? It's not that each core needs to do its own VLAN pruning. Consider a simple 3 switch network where VLAN 1 is mapped to VLAN 4 going from E->W and VLAN 1 is mapped to VLAN 3 going from W->E. R2 is doing the mapping (though in this trivial case, the edge mapping works fine, but add another switch to either side of R2 and edge mapping doesn't work). R1 -- R2 -- R3 Since there are no endstations in VLAN 1, VLAN 3 or VLAN 4 connected to R2, if R2 doesn't express an interest in at least VLAN 1, neither R1 nor R3 will send it any multi-destination VLAN 1 frames and R2 can therefore not really propagate the frames from one side to another. Dinesh Caitlin Bestler wrote: > >> -----Original Message----- >> From: Dinesh G Dutt [mailto:ddutt at cisco.com] >> Sent: Wednesday, September 17, 2008 8:19 AM >> To: Caitlin Bestler >> Cc: Radia Perlman; rbridge at postel.org >> Subject: Re: [rbridge] Proposal to make VLAN mapping work >> >> Caitlin, >> >> I was of the same opinion, until I realized that VLAN pruning in the >> broadcast trees and multicast pruning requires us to modify the >> > control > >> protocol, especially since the Rbridges that are doing the mapping are >> sort of in the core of the network when the networks are merging. >> >> Dinesh >> > > Dinesh, > > Are you saying that in the "merged network" scenario, that there would > essentially be an "East Core" and a "West Core", and that each needs > to do its own VLAN pruning separate from the East/West VLAN Mapping > Bridges are considered? > > That would be a justification for the more complex solution. > > But just to kick the tires one more time, why can't the end stations > and bridges operating with legacy non-integrated VLAN Maps be > partitioned at the edges? > > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Caitlin.Bestler at neterion.com Wed Sep 17 11:23:30 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Wed, 17 Sep 2008 14:23:30 -0400 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D13E28.8040604@cisco.com> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Wednesday, September 17, 2008 10:28 AM > To: Caitlin Bestler > Cc: Radia Perlman; rbridge at postel.org > Subject: Re: [rbridge] Proposal to make VLAN mapping work > > Hi Caitlin, > > I don't think doing everything at the edge works. Consider a ARP > request > originating in the East Cloud in VLAN X. It must hit all end stations > in > VLAN X in the East Cloud and all end stations in VLAN Y in the West > Cloud (assuming X is mapped to Y going from E->W). If I don't change > the > VLAN mapping at the RBridge connecting the two clouds, then it'll reach > the wrong set of stations in the total cloud. > > Was that clear ? > My assumption was that the ingress RBridge would map legacy VLAN X to common VLAN Z and distribute it to the other RBridges. The egress RBridges would translate back to legacy VLAN X or legacy VLAN Y according to their own edge configurations. The key caveats to this approach are: a) Every RBridge that supports a local sub-cloud using legacy VLAN Maps must be manually configured to do the mapping to from a common map. b) When a frame originates in legacy VLAN X and is destined to legacy VLAN X it will undergo two translations that probably could have been avoided (assuming the entire path was part of either the "East" or "West" campus. Do you see a problem with this solution working? Independent of whether it works, there is a second question of how common these steps would be and exactly how onerous they are compared to the cost of making the core protocols slightly more complex. My current assumption is that this scenario is relatively rare, and therefore the burdens would have to be very onerous to justify adding a complexity to the protocol that all RBridges would have to deal with all of the time. Of course, that is only an assumption on my part. I haven't done any market survey to confirm this or anything like that. If you change those assumptions, for example by assuming that zero configuration should work even when there are multiple VLAN maps in use, then you would have to conclude that edge remapping is not a viable solution. However, I am not convinced that this "East/West Campus merger" scenario is something that zero configuration has to deal with. From ddutt at cisco.com Wed Sep 17 12:01:41 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 17 Sep 2008 12:01:41 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> Message-ID: <48D15415.7020509@cisco.com> Hi Caitlin, Caitlin Bestler wrote: > The key caveats to this approach are: > a) Every RBridge that supports a local sub-cloud using legacy > VLAN Maps must be manually configured to do the mapping to > from a common map. > How do you achieve this by only VLAN mapping at the edges and not touching any other device ? > b) When a frame originates in legacy VLAN X and is destined to > legacy VLAN X it will undergo two translations that probably > could have been avoided (assuming the entire path was part > of either the "East" or "West" campus. > This is OK for me, but I can't see how to do this without VLAN renumbering (in addition to mapping at the edges) my entire network. If I have to renumber, I won't remap. > My current assumption is that this scenario is relatively > rare, and therefore the burdens would have to be very onerous > to justify adding a complexity to the protocol that all > RBridges would have to deal with all of the time. Of course, > that is only an assumption on my part. I haven't done any > market survey to confirm this or anything like that. > > If you change those assumptions, for example by assuming > that zero configuration should work even when there are > multiple VLAN maps in use, then you would have to conclude > that edge remapping is not a viable solution. However, I > am not convinced that this "East/West Campus merger" > scenario is something that zero configuration has to > deal with. > I agree that it is not a common scenario, Dinesh -- 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 Sep 17 13:24:18 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 17 Sep 2008 13:24:18 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D15415.7020509@cisco.com> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> <48D15415.7020509@cisco.com> Message-ID: <48D16772.6090106@sun.com> I think I understand what Caitlin is saying, and let me say it in different words. What Caitlin is saying: Avoid VLAN mapping entirely by just renumbering the VLAN that needs to change. Suppose we start with VLAN A in both "East" and "West". If there is a VLAN number, say, X, that is unused in both East and West, then we can simply rename VLAN A in West to VLAN X. This would involve reconfiguring all RBridges, bridges, and VLAN-aware endnodes in West to reconfigure "A" to "X". East doesn't need to be renumbered, since it can simply keep using "A". Indeed, that would solve the problem, and not require any VLAN mapping. Any packets in the core tagged with "A" would be East's A. No confusion. And indeed this seems like something the owner of the network ought to ultimately do. VLAN mapping seems really scary to me, especially with the possibility of misconfiguration. But I was told that some customers want to take the two clouds, not reconfigure anyone in either cloud, and glue them together with magic boxes that map. If that's what they want to do, then I think you need to do something like what I said in the first email on this thread. And assuming what I wrote works, there is very little implication on the spec, or on RBridges that do not want to do VLAN mapping. I would certainly be personally happy if I'd never heard of VLAN mapping, and if the problem were always solved by manually reconfiguring all bridges, RBridges, and VLAN-aware endnodes connected to the VLAN that needs to be mapped. However, the claim is that some customers like the bridge "VLAN mapping" feature that allows gluing islands together and changing the VLAN numbers. So I think our options are: a) explicitly not support VLAN mapping. Declare it a misconfiguration if it is detected, and make the network owner renumber things so no VLAN mapping is occurring. (this is how the current spec reads) b) allow for support by changing the spec to include information in IS-IS Hellos to alert the DRB that VLAN mapping is going on. So, anyway...I recommend we do "b", namely alert the DRB that VLAN mapping is going on, and have the DRB make sure there is only one forwarder for any mapped VLANs, and don't say anything else in the spec about VLAN mapping. That way there are sufficient hooks so that someone can implement VLAN mapping if they want. The wording change from version 8 I'd propose is the following: In section 4.2.3.1.3, where version 8 currently says " When a VLAN mapping from X to Y is detected, the RBridge detecting it disables its appointed forwarder status for both X and Y. The idea is to produce a clean failure so the network operator will correct the bridged LAN configuration. " I'd propose it instead say something like: "When a VLAN mapping from X to Y is detected by RBridge RB1, RB1 informs the DRB, RB2, that VLANs X and Y are mapped on the cloud. If RB1 is appointed forwarder for both X and Y, then RB1 continues forwarding for both X and Y. However, if the DRB's Hello indicates a different appointed forwarder than RB1 for VLAN Y, then RB1 disables its appointed forwarder status for X and Y." alternatively (if we want to just have a single bit in the Hello indicating that VLAN mapping is going on, rather than a list of which VLANs map to which other VLANs, and live with requiring only a single appointed forwarder for all VLANs in that case): "When any VLAN mapping is detected by RB1, RB1 informs the DRB with a flag in RB1's Hello saying "VLAN mapping is detected on this link". In the case of VLAN mapping on a link, there must be only a single appointed forwarder, which will forward for all VLANs. If the DRB's Hello indicates more than one appointed forwarder for the link, then RB1 disables its appointed forwarder status for all VLANs until the DRB's Hello indicates just a single appointed forwarder for the link." Dinesh G Dutt wrote: > Hi Caitlin, > > > Caitlin Bestler wrote: >> The key caveats to this approach are: >> a) Every RBridge that supports a local sub-cloud using legacy >> VLAN Maps must be manually configured to do the mapping to >> from a common map. >> > How do you achieve this by only VLAN mapping at the edges and not > touching any other device ? >> b) When a frame originates in legacy VLAN X and is destined to >> legacy VLAN X it will undergo two translations that probably >> could have been avoided (assuming the entire path was part >> of either the "East" or "West" campus. >> > This is OK for me, but I can't see how to do this without VLAN > renumbering (in addition to mapping at the edges) my entire network. > If I have to renumber, I won't remap. >> My current assumption is that this scenario is relatively >> rare, and therefore the burdens would have to be very onerous >> to justify adding a complexity to the protocol that all >> RBridges would have to deal with all of the time. Of course, >> that is only an assumption on my part. I haven't done any >> market survey to confirm this or anything like that. >> >> If you change those assumptions, for example by assuming >> that zero configuration should work even when there are >> multiple VLAN maps in use, then you would have to conclude >> that edge remapping is not a viable solution. However, I >> am not convinced that this "East/West Campus merger" >> scenario is something that zero configuration has to >> deal with. >> > I agree that it is not a common scenario, > > Dinesh > From ddutt at cisco.com Wed Sep 17 13:40:38 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 17 Sep 2008 13:40:38 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D16772.6090106@sun.com> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> <48D15415.7020509@cisco.com> <48D16772.6090106@sun.com> Message-ID: <48D16B46.6060302@cisco.com> Radia Perlman wrote: > I think I understand what Caitlin is saying, and let me say it in > different words. > What Caitlin is saying: Avoid VLAN mapping entirely by just > renumbering the VLAN that needs to change. I understood the same. That's unfortunately not always the choice, > So I think our options are: > a) explicitly not support VLAN mapping. Declare it a misconfiguration > if it is detected, and > make the network owner renumber things so no VLAN mapping is > occurring. (this is > how the current spec reads) > b) allow for support by changing the spec to include information in > IS-IS Hellos > to alert the DRB that VLAN mapping is going on. > > So, anyway...I recommend we do "b", namely alert the DRB that VLAN > mapping is going on, and have the DRB make sure there is only one > forwarder for any mapped VLANs, and don't say anything else in the > spec about VLAN mapping. That way there are sufficient hooks so > that someone can implement VLAN mapping if they want. That is fine by me. That is why I believe you suggested documenting the other changes in a separate draft. Dinesh -- 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 Sep 17 21:28:10 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 17 Sep 2008 21:28:10 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D16B46.6060302@cisco.com> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> <48D15415.7020509@cisco.com> <48D16772.6090106@sun.com> <48D16B46.6060302@cisco.com> Message-ID: <48D1D8DA.9010200@sun.com> Dinesh, which of the alternative approaches to b) do you prefer, namely: 1) If RB1 notices X maps to Y, RB1 reports "X maps to Y" in its Hello, and there must only be one forwarder for the set {X,Y}, but all the other VLANs can be divvied out to lots of other forwarders 2) If RB1 notices that any VLAN maps to any other VLAN, it simply sets a flag in its Hello saying "VLAN mapping is occurring on this cloud", and there must be only one appointed forwarder for all VLANs on that link. I personally prefer 2). I would have preferred only the DRB forward to/from the link (simpler, safer) in all cases, but certainly if we say that there can only be a single forwarder in the (hopefully rare) case where VLANs are being mapped within the link, that seems like not a big restriction. If we do 2), that means a whole lot information to encode in a Hello. Just a flag "I've detected VLAN mapping". The alternative (1) requires encoding which VLANs map to which other VLANs. Radia Dinesh G Dutt wrote: > Radia Perlman wrote: > >> I think I understand what Caitlin is saying, and let me say it in >> different words. >> What Caitlin is saying: Avoid VLAN mapping entirely by just >> renumbering the VLAN that needs to change. >> > I understood the same. That's unfortunately not always the choice, > >> So I think our options are: >> a) explicitly not support VLAN mapping. Declare it a misconfiguration >> if it is detected, and >> make the network owner renumber things so no VLAN mapping is >> occurring. (this is >> how the current spec reads) >> b) allow for support by changing the spec to include information in >> IS-IS Hellos >> to alert the DRB that VLAN mapping is going on. >> >> So, anyway...I recommend we do "b", namely alert the DRB that VLAN >> mapping is going on, and have the DRB make sure there is only one >> forwarder for any mapped VLANs, and don't say anything else in the >> spec about VLAN mapping. That way there are sufficient hooks so >> that someone can implement VLAN mapping if they want. >> > That is fine by me. That is why I believe you suggested documenting the > other changes in a separate draft. > > Dinesh > > From anoop at brocade.com Thu Sep 18 00:06:58 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Thu, 18 Sep 2008 00:06:58 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D16B46.6060302@cisco.com> References: <48CF3FCF.6010204@sun.com><78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter><48D09054.7090406@sun.com><78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter><48D11FE4.8020903@cisco.com><78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter><48D13E28.8040604@cisco.com><78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter><48D15415.7020509@cisco.com> <48D16772.6090106@sun.com> <48D16B46.6060302@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E01EA5BA8@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt > Sent: Thursday, September 18, 2008 5:41 AM > To: Radia Perlman > Cc: rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Proposal to make VLAN mapping work > > > > > So, anyway...I recommend we do "b", namely alert the DRB that VLAN > > mapping is going on, and have the DRB make sure there is only one > > forwarder for any mapped VLANs, and don't say anything else in the > > spec about VLAN mapping. That way there are sufficient hooks so > > that someone can implement VLAN mapping if they want. > > That is fine by me. That is why I believe you suggested > documenting the > other changes in a separate draft. Considering all the issues being brought up, and the fact that "VLAN translation" (that's the 802.1 term for this) is not a standard function for C-tags, this is the option I prefer -- we detect it and do something to make sure nothing nasty happens, rather than try to actually make it all work. Anoop From ddutt at cisco.com Thu Sep 18 08:38:24 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 18 Sep 2008 08:38:24 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D1D8DA.9010200@sun.com> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> <48D15415.7020509@cisco.com> <48D16772.6090106@sun.com> <48D16B46.6060302@cisco.com> <48D1D8DA.9010200@sun.com> Message-ID: <48D275F0.6000600@cisco.com> Option 2 is fine with me, Radia. We can extend it later, if need be. Dinesh Radia Perlman wrote: > Dinesh, which of the alternative approaches to b) do you prefer, namely: > > 1) If RB1 notices X maps to Y, RB1 reports "X maps to Y" in its Hello, > and there must only be one forwarder for the set {X,Y}, but all the > other VLANs > can be divvied out to lots of other forwarders > > 2) If RB1 notices that any VLAN maps to any other VLAN, it simply > sets a flag in its Hello saying "VLAN mapping is occurring on this > cloud", > and there must be only one appointed forwarder for all VLANs on that > link. > > I personally prefer 2). I would have preferred only the DRB forward > to/from > the link (simpler, safer) in all cases, but certainly if we say that > there can > only be a single forwarder in the (hopefully rare) case where VLANs are > being mapped within the link, that seems like not a big restriction. > > If we do 2), that means a whole lot information to encode in a Hello. > Just > a flag "I've detected VLAN mapping". The alternative (1) requires > encoding > which VLANs map to which other VLANs. > > Radia > > > > > Dinesh G Dutt wrote: >> Radia Perlman wrote: >> >>> I think I understand what Caitlin is saying, and let me say it in >>> different words. >>> What Caitlin is saying: Avoid VLAN mapping entirely by just >>> renumbering the VLAN that needs to change. >>> >> I understood the same. That's unfortunately not always the choice, >> >>> So I think our options are: >>> a) explicitly not support VLAN mapping. Declare it a >>> misconfiguration if it is detected, and >>> make the network owner renumber things so no VLAN mapping is >>> occurring. (this is >>> how the current spec reads) >>> b) allow for support by changing the spec to include information in >>> IS-IS Hellos >>> to alert the DRB that VLAN mapping is going on. >>> >>> So, anyway...I recommend we do "b", namely alert the DRB that VLAN >>> mapping is going on, and have the DRB make sure there is only one >>> forwarder for any mapped VLANs, and don't say anything else in the >>> spec about VLAN mapping. That way there are sufficient hooks so >>> that someone can implement VLAN mapping if they want. >>> >> That is fine by me. That is why I believe you suggested documenting >> the other changes in a separate draft. >> >> Dinesh >> >> > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Caitlin.Bestler at neterion.com Thu Sep 18 10:13:41 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Thu, 18 Sep 2008 13:13:41 -0400 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <48D1D8DA.9010200@sun.com> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> <48D15415.7020509@cisco.com> <48D16772.6090106@sun.com> <48D16B46.6060302@cisco.com> <48D1D8DA.9010200@sun.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77044A2029@nekter> > > 1) If RB1 notices X maps to Y, RB1 reports "X maps to Y" in its Hello, > and there must only be one forwarder for the set {X,Y}, but all the > other VLANs > can be divvied out to lots of other forwarders > > 2) If RB1 notices that any VLAN maps to any other VLAN, it simply > sets a flag in its Hello saying "VLAN mapping is occurring on this > cloud", > and there must be only one appointed forwarder for all VLANs on that > link. > My understanding of the problem being solved is as follows: - An existing campus has at least two "zones". There are VLANs that exist in both zones, but different VLAN IDs are used. - Existing Bridges translate VLAN IDs on frames that cross between the zones. - If RBridges are added in multiple zones, the existing VLAN-translating bridges will not know to translate the RBridge encapsulated frame. Ultimately the required solution is that only RBridges that are aware of the required VLAN translation will send RBridge encapsulated frames across a zone boundary. How a specific RBRidge supports VLAN Translation would be outside the scope of the specification. The only thing being specified is identifying when the problem exists. Is that correct? Is the assumption that the single appointed forwarder for the link will do the VLAN Translation? Is that truly required, or is that merely *a* method of achieving the goal? Could the response of RB1 be merely to state "based on your HELLO there is clearly a VLAN Translation occurring that you are unaware of. Please try again once you've fixed this problem." I am also assuming the following: - Requiring administrative configuration of RBridges that forward across zone boundaries is acceptable given that "multi-zone" campuses are the exception. - Nothing in the standard will require an RBridge to be capable of doing VLAN Translations to enable inter-zone forwarding, merely that it must not do inter-zone forwarding incorrectly. From Radia.Perlman at sun.com Thu Sep 18 19:50:29 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 18 Sep 2008 19:50:29 -0700 Subject: [rbridge] Proposal to make VLAN mapping work In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77044A2029@nekter> References: <48CF3FCF.6010204@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704419299@nekter> <48D09054.7090406@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C17C@nekter> <48D11FE4.8020903@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1CB3@nekter> <48D13E28.8040604@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A1D23@nekter> <48D15415.7020509@cisco.com> <48D16772.6090106@sun.com> <48D16B46.6060302@cisco.com> <48D1D8DA.9010200@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD77044A2029@nekter> Message-ID: <48D31375.8000704@sun.com> No. I don't think you and I are thinking of the same problem scenario. Let me try to explain my understanding of the problem. ******* First, forget bridges for a moment, and assume we only have RBridges. The problem is that you have two zones, East and West, with a different number for a particular VLAN in East vs West. (because you want to join what is called "VLAN A" on one side with "VLAN X" on the other side. The desire is to accomplish this by putting RBridges connecting East and West, so that VLAN-aware nodes in either zone are not aware of any mapping going on. When East sends a broadcast to "VLAN A", it magically gets received by all nodes in VLAN X in West. I believe we can provide for this without changing anything in the spec, and perhaps how to build the RBridges that connect the two zones and translate VLANs should be fully described in another document. So as long as there are two clear zones, East and West, and all the RBridges connecting the two zones are properly configured, and there is no ambiguity about whether a port is in East or West, it all works. ************ Now assume that we have East and West, and instead of having the zones connected by, say, three VLAN-mapping RBridges R1, R2, and R3, instead we replace, say, R1 with a bridged cloud that does VLAN mapping. R4 ---- VLAN-mapping-cloud ------R5 instead of West ---------------R1--------------East R4 and R5 are not doing any VLAN mapping. R4 acts just like an RBridge in West in the upper scenario, and R5 acts like an RBridge in East. We already have hooks in the Hellos so that when R5 issues a Hello with tag VLAN A, R4 notices that it receives it with VLAN X. (because bridges between R4 and R4 are translating VLAN A to VLAN X). The current spec says "panic if you notice mapping going on on your link and don't forward on behalf of any VLANs that are getting mapped". But really, the only way VLAN mapping can cause a loop is if you have a different appointed forwarder for one VLAN than another. So I'm proposing that instead of "panic", that link is constrained to have just a single appointed forwarder for all VLANs. Then I think that customers can do whatever VLAN mapping they want with either bridges or with special VLAN-mapping RBridges, that we should specify in a separate document. But all we need to make sure we can add on VLAN-mapping RBridges is a bit in the Hello saying "VLAN mapping is going on", and a rule that if the DRB sees that flag in anyone's Hello, it must have a single appointed forwarder for the link. Radia Hope this is clearer. Radia Caitlin Bestler wrote: >> 1) If RB1 notices X maps to Y, RB1 reports "X maps to Y" in its Hello, >> and there must only be one forwarder for the set {X,Y}, but all the >> other VLANs >> can be divvied out to lots of other forwarders >> >> 2) If RB1 notices that any VLAN maps to any other VLAN, it simply >> sets a flag in its Hello saying "VLAN mapping is occurring on this >> cloud", >> and there must be only one appointed forwarder for all VLANs on that >> link. >> >> > > My understanding of the problem being solved is as follows: > > - An existing campus has at least two "zones". There are VLANs > that exist in both zones, but different VLAN IDs are used. > - Existing Bridges translate VLAN IDs on frames that cross > between the zones. > - If RBridges are added in multiple zones, the existing > VLAN-translating bridges will not know to translate > the RBridge encapsulated frame. > > Ultimately the required solution is that only RBridges > that are aware of the required VLAN translation will send > RBridge encapsulated frames across a zone boundary. How > a specific RBRidge supports VLAN Translation would be > outside the scope of the specification. The only thing > being specified is identifying when the problem exists. > > Is that correct? > > Is the assumption that the single appointed forwarder > for the link will do the VLAN Translation? > > Is that truly required, or is that merely *a* method > of achieving the goal? Could the response of RB1 be > merely to state "based on your HELLO there is clearly > a VLAN Translation occurring that you are unaware of. > Please try again once you've fixed this problem." > > > I am also assuming the following: > > - Requiring administrative configuration of RBridges > that forward across zone boundaries is acceptable > given that "multi-zone" campuses are the exception. > - Nothing in the standard will require an RBridge to > be capable of doing VLAN Translations to enable > inter-zone forwarding, merely that it must not do > inter-zone forwarding incorrectly. > From trill at punk.co.nz Sat Sep 27 00:10:59 2008 From: trill at punk.co.nz (Kris Price) Date: Sat, 27 Sep 2008 15:10:59 +0800 Subject: [rbridge] Questions - VLANs & MPLS Message-ID: <48DDDC83.1050701@punk.co.nz> Hi, I was recently introduced to RBridges by Radia Perlman's interesting techtalk at Google. Is there a digest somewhere that explains the options considered or the iterations it has been through? It seems (on the face of it) that RBridges may reconnect partitioned VLANs or allow access to VLANs used for security (rightly or wrongly). E.g. when two RBridges are separated by an Ethernet that has partitioned VLANs (or some VLANs disallowed on a trunk ports) the RBridges will complete the link for those VLANs. Do I understand right? Also, I was curious why MPLS wasn't used as the forwarding method..? I searched the mailing list, but google stops at 93 posts, and most of the references I could find mentioning MPLS were about using the header in some form, not LSPs for forwarding. But if it's feasible to use LSPs to forward frames. The LSRs would only need to understand encap/decap of Ethernet frames onto these TRILL LSPs and a new protocol to establish the LSPs at the same time as distributing the MAC addresses. E.g. perhaps modified IS-IS as with RBridges. The drawbacks would seem to be loss of MAC learning. But I'd have thought much of the hardware is already there to support such forwarding. Thanks Kris From d3e3e3 at gmail.com Sat Sep 27 09:59:24 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 27 Sep 2008 12:59:24 -0400 Subject: [rbridge] Questions - VLANs & MPLS In-Reply-To: <48DDDC83.1050701@punk.co.nz> References: <48DDDC83.1050701@punk.co.nz> Message-ID: <1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com> Hi Kris, On Sat, Sep 27, 2008 at 3:10 AM, Kris Price wrote: > Hi, > > I was recently introduced to RBridges by Radia Perlman's interesting > techtalk at Google. Is there a digest somewhere that explains the > options considered or the iterations it has been through? No. The creation of a thorough digest of that type would be an enormous effort, You are welcome to volunteer to try but, of course, you will never get everyone to agree that your digest is accurate or complete. I would suggest that you look at the IETF Proceedings and the TRILL WG presentations and minutes therein as well as reading the change history in the base protocol document. > It seems (on the face of it) that RBridges may reconnect partitioned > VLANs or allow access to VLANs used for security (rightly or wrongly). E.g. when two RBridges are separated by an Ethernet that has partitioned > VLANs (or some VLANs disallowed on a trunk ports) the RBridges will > complete the link for those VLANs. Do I understand right? > Yes, that's more or less correct. RBridges take the default view from 802.1Q where if you followed the default of having most VLANs on most ports dynamically registrable, the same sort of thing would happen via the mandatory to implement VLAN registration protocol. The way to avoid this in TRILL would have been to add an additional qualifier to the VLAN ID. For example, in effect, adding an additional high order octet. Then if you wanted to have two disjoint islands of VLAN 0x007, you could configure them to have different values for this additional qualifier and be, in effect, VLAN 0x0007 and 0x1007. Then TRILL would know that the islands were really "different" VLANs and not connect them. But after discussion it was decided not to do this. Also, I was curious why MPLS wasn't used as the forwarding method..? > Why should it have? The starting point for TRILL/RBridges was always to do Layer 2 forwarding based on link state routing as proposed in Radia's original Infocom paper: http://www.ieee-infocom.org/2004/Papers/26_1.PDF Nowhere in your message do you state any reason why MPLS would be a better idea. I searched the mailing list, but google stops at 93 posts, and most of > the references I could find mentioning MPLS were about using the header > in some form, not LSPs for forwarding. But if it's feasible to use LSPs > to forward frames. The LSRs would only need to understand encap/decap of > Ethernet frames onto these TRILL LSPs and a new protocol to establish > the LSPs at the same time as distributing the MAC addresses. E.g. > perhaps modified IS-IS as with RBridges. The drawbacks would seem to be > loss of MAC learning. But I'd have thought much of the hardware is > already there to support such forwarding. Thanks > Kris > Thanks, Donald -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080927/27959c15/attachment.html From trill at punk.co.nz Sun Sep 28 01:53:52 2008 From: trill at punk.co.nz (Kris Price) Date: Sun, 28 Sep 2008 16:53:52 +0800 Subject: [rbridge] Questions - VLANs & MPLS In-Reply-To: <1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com> References: <48DDDC83.1050701@punk.co.nz> <1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com> Message-ID: <48DF4620.8060900@punk.co.nz> Donald Eastlake wrote: > I would suggest that you look at the IETF Proceedings and the TRILL WG > presentations and minutes therein as well as reading the change history > in the base protocol document. Will check these out, thanks. > Also, I was curious why MPLS wasn't used as the forwarding method..? > > > Why should it have? The starting point for TRILL/RBridges was always to > do Layer 2 forwarding based on link state routing as proposed in Radia's > original Infocom paper: > http://www.ieee-infocom.org/2004/Papers/26_1.PDF > Nowhere in your message do you state any reason why MPLS would be a > better idea. Sorry my original phrasing may have suggested I thought it should. I don't necessarily think it should've been used, but it seems it could feasibly be used to achieve a similar outcome. I realise this is simplifying a lot of whats involved though, and I should maybe think it through more. So I was curious if it had been considered and rejected and why. Maybe its something thats been given thought previously in another WG. I figured the benefits were: * Use of an existing forwarding method * Existing hardware support - this is an assumption. It may not be so simple and may require just as much work as is needed to implement RBridges. Cheers Kris From ddutt at cisco.com Sun Sep 28 11:45:46 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Sun, 28 Sep 2008 11:45:46 -0700 Subject: [rbridge] Questions - VLANs & MPLS In-Reply-To: <48DF4620.8060900@punk.co.nz> References: <48DDDC83.1050701@punk.co.nz> <1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com> <48DF4620.8060900@punk.co.nz> Message-ID: <48DFD0DA.9030802@cisco.com> Hi Kris, MPLS format was originally considered and rejected for a few reasons. For example, we wanted the source and destination RBridge addresses instead of only the destination RBridge because of the need to support things like IEEE's congestion management, support troubleshooting tools such as traceroute and ping within an TRILL cloud etc. Dinesh P.S: Please ignore my previous email. TBird decided to use my personal email address for some reason. sigh Kris Price wrote: > Donald Eastlake wrote: >> I would suggest that you look at the IETF Proceedings and the TRILL WG >> presentations and minutes therein as well as reading the change history >> in the base protocol document. > > Will check these out, thanks. > >> Also, I was curious why MPLS wasn't used as the forwarding method..? >> >> >> Why should it have? The starting point for TRILL/RBridges was always to >> do Layer 2 forwarding based on link state routing as proposed in Radia's >> original Infocom paper: >> http://www.ieee-infocom.org/2004/Papers/26_1.PDF >> Nowhere in your message do you state any reason why MPLS would be a >> better idea. > > Sorry my original phrasing may have suggested I thought it should. > > I don't necessarily think it should've been used, but it seems it could > feasibly be used to achieve a similar outcome. I realise this is > simplifying a lot of whats involved though, and I should maybe think it > through more. > > So I was curious if it had been considered and rejected and why. Maybe > its something thats been given thought previously in another WG. > > I figured the benefits were: > > * Use of an existing forwarding method > > * Existing hardware support - this is an assumption. It may not be so > simple and may require just as much work as is needed to implement RBridges. > > > Cheers > Kris > _______________________________________________ > 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 Internet-Drafts at ietf.org Mon Sep 29 19:15:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 29 Sep 2008 19:15:01 -0700 (PDT) Subject: [rbridge] I-D Action:draft-ietf-trill-prob-05.txt Message-ID: <20080930021501.713953A6AEE@core3.amsl.com> From touch at ISI.EDU Mon Sep 29 20:11:16 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 29 Sep 2008 20:11:16 -0700 Subject: [rbridge] I-D Action:draft-ietf-trill-prob-05.txt In-Reply-To: <20080930021501.713953A6AEE@core3.amsl.com> References: <20080930021501.713953A6AEE@core3.amsl.com> Message-ID: <48E198D4.6060506@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, FYI, this draft represents the updates from the Last Call. Joe Internet-Drafts at ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. > > > Title : Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement > Author(s) : J. Touch, R. Perlman > Filename : draft-ietf-trill-prob-05.txt > Pages : 17 > Date : 2008-09-29 > > Current Ethernet (802.1) link layers use spanning tree protocols that > have a number of challenges. These protocols need to strictly avoid > loops, even temporary ones, during route propagation, because of the > lack of header loop detection support. Routing tends not to take full > advantage of alternate paths, or even non-overlapping pairwise paths > (in the case of spanning trees). This document addresses these > concerns and suggests that they can be addressed by applying modern > > > network layer routing protocols at the link layer. This document > assumes that solutions would not address issues of scalability beyond > that of existing bridged (802.1) links, but that a solution would be > backward compatible with 802.1, including hubs, bridges, and their > existing plug-and-play capabilities. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjhmNQACgkQE5f5cImnZruv2wCfYp8m9tYtqKrzqg/Rp7/aJLI6 f60AoOhEC5Gnqlo6NuAx9HuJXcrHzPG5 =PQgR -----END PGP SIGNATURE----- From james.d.carlson at sun.com Tue Sep 30 05:13:45 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 30 Sep 2008 08:13:45 -0400 Subject: [rbridge] Questions - VLANs & MPLS In-Reply-To: <48DFD0DA.9030802@cisco.com> References: <48DDDC83.1050701@punk.co.nz> <1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com> <48DF4620.8060900@punk.co.nz> <48DFD0DA.9030802@cisco.com> Message-ID: <18658.6137.271907.615010@gargle.gargle.HOWL> Dinesh G Dutt writes: > MPLS format was originally considered and rejected for a few reasons. For > example, we wanted the source and destination RBridge addresses instead of > only the destination RBridge because of the need to support things like > IEEE's congestion management, support troubleshooting tools such as > traceroute and ping within an TRILL cloud etc. I think a more important reason for it is that you can't do MAC address learning of decapsulated packets unless you know where (what encapsulator) they came from. I would have preferred MPLS as well to avoid inventing something new, but the lack of an easily determined sender identity is a problem. (You could do it if you had a full mesh of LSPs among all of the routers in the network, because the destination label would tell you which of the LSPs it belonged to and therefore which sender originally encapsulated the message.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ddutt at cisco.com Tue Sep 30 07:31:10 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 30 Sep 2008 07:31:10 -0700 Subject: [rbridge] Questions - VLANs & MPLS In-Reply-To: <18658.6137.271907.615010@gargle.gargle.HOWL> References: <48DDDC83.1050701@punk.co.nz> <1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com> <48DF4620.8060900@punk.co.nz> <48DFD0DA.9030802@cisco.com> <18658.6137.271907.615010@gargle.gargle.HOWL> Message-ID: <48E2382E.4040501@cisco.com> You're right. I forgot about that, Dinesh James Carlson wrote: > Dinesh G Dutt writes: > >> MPLS format was originally considered and rejected for a few reasons. For >> example, we wanted the source and destination RBridge addresses instead of >> only the destination RBridge because of the need to support things like >> IEEE's congestion management, support troubleshooting tools such as >> traceroute and ping within an TRILL cloud etc. >> > > I think a more important reason for it is that you can't do MAC > address learning of decapsulated packets unless you know where (what > encapsulator) they came from. > > I would have preferred MPLS as well to avoid inventing something new, > but the lack of an easily determined sender identity is a problem. > (You could do it if you had a full mesh of LSPs among all of the > routers in the network, because the destination label would tell you > which of the LSPs it belonged to and therefore which sender originally > encapsulated the message.) > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan