From james.d.carlson at Sun.COM Mon Mar 2 05:54:38 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Mon, 2 Mar 2009 08:54:38 -0500 Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames In-Reply-To: <4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com> References: <48EFDA99.9070304@sun.com> <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com> <48F08FEA.1000302@cisco.com> <1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com> <49A85BAB.9060703@sun.com> <18856.28188.700649.936645@gargle.gargle.HOWL> <4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com> Message-ID: <18859.58654.253695.410225@gargle.gargle.HOWL> Jim Burrows writes: > I'll have to agree with Jim Carlson with regard to the notion of "Foo > over X" documents and specs whose scope intermingles one specific > protocol from one level into a specification at another level. I'm new > here, and I don't know how far folks may have gotten in implementing > the draft 10 spec, vs the 09 or the 11, but it also feels wrong to > stick with a problem that crept into a latish but not final draft of > the spec fore backward compatibility reasons. I've had to live with > the sort of problems that this introduces too often. > > Is it really too late to fix this? Yes, that's essentially what has been said. It appeared in -10 and it's already too late in -11 to fix it. Just to make it clear (since the follow-up above seems to suggest that it's not): although I have misgivings about the direction being taken, and the direction is already causing me design headaches in a previously known-working implementation, I was _not_ requesting a change in direction. Instead, I was expressing support for Radia's solution, explicitly because (a) I've had my say and (b) I need agreement to move forward. -- 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 jim.burrows at stellarswitches.com Mon Mar 2 09:28:26 2009 From: jim.burrows at stellarswitches.com (Jim Burrows) Date: Mon, 2 Mar 2009 12:28:26 -0500 Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames In-Reply-To: <18859.58654.253695.410225@gargle.gargle.HOWL> References: <48EFDA99.9070304@sun.com> <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com> <48F08FEA.1000302@cisco.com> <1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com> <49A85BAB.9060703@sun.com> <18856.28188.700649.936645@gargle.gargle.HOWL> <4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com> <18859.58654.253695.410225@gargle.gargle.HOWL> Message-ID: <92B5AA64-105F-476E-965C-D01F0554377E@stellarswitches.com> No problem. I'm a late comer to this party and shared your concerns, so I thought it worth asking if it was too late to do anything. If it is, then that's life and we move on. Thanks, JimB. On Mar 2, 2009, at 9:28 AM, "James Carlson" wrote: > Jim Burrows writes: >> I'll have to agree with Jim Carlson with regard to the notion of "Foo >> over X" documents and specs whose scope intermingles one specific >> protocol from one level into a specification at another level. I'm >> new >> here, and I don't know how far folks may have gotten in implementing >> the draft 10 spec, vs the 09 or the 11, but it also feels wrong to >> stick with a problem that crept into a latish but not final draft of >> the spec fore backward compatibility reasons. I've had to live with >> the sort of problems that this introduces too often. >> >> Is it really too late to fix this? > > Yes, that's essentially what has been said. It appeared in -10 and > it's already too late in -11 to fix it. > > Just to make it clear (since the follow-up above seems to suggest that > it's not): although I have misgivings about the direction being taken, > and the direction is already causing me design headaches in a > previously known-working implementation, I was _not_ requesting a > change in direction. Instead, I was expressing support for Radia's > solution, explicitly because (a) I've had my say and (b) I need > agreement to move forward. > > -- > 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 d3e3e3 at gmail.com Mon Mar 2 13:07:11 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 2 Mar 2009 16:07:11 -0500 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <1028365c0902251818p571b0ba4v7ea3db412ff8fbfd@mail.gmail.com> References: <1028365c0902190758l2d564959lc80c60f06bf48f0b@mail.gmail.com> <1028365c0902251818p571b0ba4v7ea3db412ff8fbfd@mail.gmail.com> Message-ID: <1028365c0903021307qb90415p447e06eeab28aa0b@mail.gmail.com> Hi Ayan, Thinking about this a bit more, I guess I wasn't thinking too clearly about the distinction between known unicast and multi-destination. I hope you would agree, there is no problem at all with known unicast frames, which should act the way I described. The possible problem is with multi-destination frames would primarily be with the Reverse Path Forwarding Check. It may make that check a bit easier if multi-destination frames are sent over only one of two or more parallel one hop links between RBridges. It seems confusing to refer to these additional factors (circuit ids) as tree tie-breakers. I suppose it is an implementation detail but to my mind these parallel one-hop links are only visible locally and appear as a single connection in the topology and in any tree being built. In any case, it seems better to call them "local decision criteria" or the like. Presumably they would be used by the sending RBridge to choose which of the parallel link to send multi-destination TRILL data frames on. And when setting up the RPF check filters, you could assume that decision at the send and then discard multi-destination frames arriving on the "wrong" links out of the set of parallel links. A couple of questions: Does this really make the RPF check significantly easier to calculate or perform? If one is a P2P link and other is LAN, is it actually guaranteed that you couldn't have an extended circuit id that was equal to a lan circuit id? Maybe the tie breaker should be to favor P2P links, which presumably are less likely to have conflicting traffic, and then use id as the next level of tie breaker? Thanks, Donald On Wed, Feb 25, 2009 at 9:18 PM, Donald Eastlake wrote: > Hi Ayan, > > It looks like we are essentially in agreement on your first two > points. See below on your third point. > > On Wed, Feb 25, 2009 at 1:46 PM, Ayan Banerjee wrote: > > Donald, > > > > ... > > > > On 2/19/09 7:58 AM, "Donald Eastlake" wrote: > >> Hi Ayan, > >> > >> See below... > >> > >> On Tue, Jan 13, 2009 at 5:56 PM, Ayan Banerjee > wrote: > >>> Radia and Donald, > >>> > >>> ... > >>> > >>> Parallel links between rbridges: > >>> We need information in the draft that states that we break ties using > (a) > >>> extended circuit id on P2P links (makes 3-way handshake mandatory) and > (b) > >>> in a LAN, use lan circuit id. > >> > >> I'm confused by what you say. Assume we have RBridges 1 and 2 such > >> that there is, say, a point to point link between port A on RB1 and > >> port A on RB2 and also between port B on RB1 and port B on RB2. There > >> are two points of view depending on whether you are one of these two > >> RBridges or some other RBridge in the campus: > >> > >> Assume you are some other RBridge, RB3. Do you even see both the A and > >> B adjacencies in the link state? I would think not and that this > >> should be reported as only a single adjacency in the RB1 and RB2 LSPs. > >> If, for some reason, you do see it as two adjacencies, why would you > >> care? As long as you know there is connectivity between RB1 and RB2 > >> you can use that in SPF calculations. I suppose you need a way of > >> determining the cost from the two costs you would see but you could > >> just use the minimum of the two or something. And if for some really > >> bizarre reason, even though you are remote from RB1 and RB2 you not > >> only see the two parallel paths in the link state but you actually > >> care which path is taken, there is no space in the LSP TLVs to encode > >> any tie breaking information such as you suggest. So I don't see any > >> need for a tiebreaker here. > >> > >> Assume the other case, that you are either RB1 or RB2. I don't see any > >> difficulty here either. You should accept TRILL traffic on both > >> connections and we should say that as a clarification. (You wouldn't > >> want the Reverse Path Forwarding Check or something causing TRILL > >> frames on one of the parallel connections to be discarded.) And you > >> can send traffic on either connection. Or can do Equal Cost MultiPath > >> on both. But if you send over only one of them then, assuming they are > >> equal cost, it seems like a purely local decision which one and I > >> don't see why we need to specify a tie breaker. > > > > When you have two parallel links and only one of them becomes a member of > > the tree, then RPF as you have pointed out will fail on the other. If the > > parallel links are part of a bundle, we do not need this. However, if the > > user has specifically made them distinct, we need a method to ensure that > > tree is computed along only one of them. > > What does it mean when you say "only one of them becomes a member of > the tree"? How does that happen? As I say above, remotely from the > RBridges with these two (or more) between them, I don't think you > should be able to tell that there is more than one connection. And if > you could, you shouldn't care whether one or the other is used or > traffic is split across them. The topology is still the same > regardless of which of these happens. And if you did care, there is no > place in the LSP to add tie breaking info. > > And locally (that is, you are one of the two multiply connected > RBridges), it's should just a local choice how to send, and you should > have to be able to receive on any of the parallel links. > > Apparently the problem you see is just with the Reverse Path > Forwarding Check at the receiving end of two or more parallel links > between the same pair of RBridges. > > I responded above on that point by saying "You should accept TRILL > traffic on both connections and we should say that [in the protocol > specification] as a clarification. (You wouldn't want the Reverse Path > Forwarding Check or something causing TRILL frames on one of the > parallel connections to be discarded.)" Isn't that a satisfactory > answer? (Maybe I shouldn't have said "both" because there could be > more than two...) Why should the local RBridges be forced to tie break > and leave all but one of there parallel point-to-point links idle? > > Thanks, > Donald > > >>> Thanks, > >>> Ayan > >>> > >>> ... > >>> > >> > >> Thanks, > >> Donald > > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > -- ============================= 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/20090302/d14ea918/attachment.html From ayabaner at cisco.com Mon Mar 2 14:26:15 2009 From: ayabaner at cisco.com (Ayan Banerjee) Date: Mon, 02 Mar 2009 14:26:15 -0800 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <1028365c0903021307qb90415p447e06eeab28aa0b@mail.gmail.com> Message-ID: Donald, I agree that this is required for multi-destination frames only. I am fine with giving preference to P2P links and then to LAN etc. Thanks, Ayan On 3/2/09 1:07 PM, "Donald Eastlake" wrote: > Hi Ayan, > > Thinking about this a bit more, I guess I wasn't thinking too clearly about > the distinction between known unicast and multi-destination. I hope you would > agree, there is no problem at all with known unicast frames, which should act > the way I described. > > The possible problem is with multi-destination frames would primarily be with > the Reverse Path Forwarding Check. It may make that check a bit easier if > multi-destination frames are sent over only one of two or more parallel one > hop links between RBridges. > > It seems confusing to refer to these additional factors (circuit ids) as tree > tie-breakers. I suppose it is an implementation detail but to my mind these > parallel one-hop links are only visible locally and appear?as a single > connection?in the topology and in any tree being built. In any case, it seems > better to call them "local decision criteria" or the like. Presumably they > would be used by the sending RBridge to choose which of the parallel link to > send multi-destination TRILL data frames on. And when setting up the RPF check > filters, you could assume that decision at the send and then discard > multi-destination frames arriving on the "wrong" links out of the set of > parallel links. > > A couple of questions: > ?? ? Does this really make the RPF check significantly easier to calculate or > perform? > ?? ? If one is a P2P link and other is LAN, is it actually?guaranteed?that you > couldn't have an extended circuit id that was equal to a lan circuit id? Maybe > the tie breaker should be to favor P2P links, which presumably are less likely > to have conflicting traffic, and then use id as the next level of tie breaker? > > Thanks, > Donald > > On Wed, Feb 25, 2009 at 9:18 PM, Donald Eastlake wrote: >> Hi Ayan, >> >> It looks like we are essentially in agreement on your first two >> points. See below on your third point. >> >> On Wed, Feb 25, 2009 at 1:46 PM, Ayan Banerjee wrote: >>> > Donald, >>> > >>> > ... >>> > >>> > On 2/19/09 7:58 AM, "Donald Eastlake" wrote: >>>> >> Hi Ayan, >>>> >> >>>> >> See below... >>>> >> >>>> >> On Tue, Jan 13, 2009 at 5:56 PM, Ayan Banerjee >>>> wrote: >>>>> >>> Radia and Donald, >>>>> >>> >>>>> >>> ... >>>>> >>> >>>>> >>> Parallel links between rbridges: >>>>> >>> We need information in the draft that states that we break ties using (a) >>>>> >>> extended circuit id on P2P links (makes 3-way handshake mandatory) and (b) >>>>> >>> in a LAN, use lan circuit id. >>>> >> >>>> >> I'm confused by what you say. Assume we have RBridges 1 and 2 such >>>> >> that there is, say, a point to point link between port A on RB1 and >>>> >> port A on RB2 and also between port B on RB1 and port B on RB2. There >>>> >> are two points of view depending on whether you are one of these two >>>> >> RBridges or some other RBridge in the campus: >>>> >> >>>> >> Assume you are some other RBridge, RB3. Do you even see both the A and >>>> >> B adjacencies in the link state? I would think not and that this >>>> >> should be reported as only a single adjacency in the RB1 and RB2 LSPs. >>>> >> If, for some reason, you do see it as two adjacencies, why would you >>>> >> care? As long as you know there is connectivity between RB1 and RB2 >>>> >> you can use that in SPF calculations. I suppose you need a way of >>>> >> determining the cost from the two costs you would see but you could >>>> >> just use the minimum of the two or something. And if for some really >>>> >> bizarre reason, even though you are remote from RB1 and RB2 you not >>>> >> only see the two parallel paths in the link state but you actually >>>> >> care which path is taken, there is no space in the LSP TLVs to encode >>>> >> any tie breaking information such as you suggest. So I don't see any >>>> >> need for a tiebreaker here. >>>> >> >>>> >> Assume the other case, that you are either RB1 or RB2. I don't see any >>>> >> difficulty here either. You should accept TRILL traffic on both >>>> >> connections and we should say that as a clarification. (You wouldn't >>>> >> want the Reverse Path Forwarding Check or something causing TRILL >>>> >> frames on one of the parallel connections to be discarded.) And you >>>> >> can send traffic on either connection. Or can do Equal Cost MultiPath >>>> >> on both. But if you send over only one of them then, assuming they are >>>> >> equal cost, it seems like a purely local decision which one and I >>>> >> don't see why we need to specify a tie breaker. >>> > >>> > When you have two parallel links and only one of them becomes a member of >>> > the tree, then RPF as you have pointed out will fail on the other. If the >>> > parallel links are part of a bundle, we do not need this. However, if the >>> > user has specifically made them distinct, we need a method to ensure that >>> > tree is computed along only one of them. >> >> What does it mean when you say "only one of them becomes a member of >> the tree"? How does that happen? As I say above, remotely from the >> RBridges with these two (or more) between them, I don't think you >> should be able to tell that there is more than one connection. And if >> you could, you shouldn't care whether one or the other is used or >> traffic is split across them. The topology is still the same >> regardless of which of these happens. And if you did care, there is no >> place in the LSP to add tie breaking info. >> >> And locally (that is, you are one of the two multiply connected >> RBridges), it's should just a local choice how to send, and you should >> have to be able to receive on any of the parallel links. >> >> Apparently the problem you see is just with the Reverse Path >> Forwarding Check at the receiving end of two or more parallel links >> between the same pair of RBridges. >> >> I responded above on that point by saying "You should accept TRILL >> traffic on both connections and we should say that [in the protocol >> specification] as a clarification. (You wouldn't want the Reverse Path >> Forwarding Check or something causing TRILL frames on one of the >> parallel connections to be discarded.)" Isn't that a satisfactory >> answer? (Maybe I shouldn't have said "both" because there could be >> more than two...) Why should the local RBridges be forced to tie break >> and leave all but one of there parallel point-to-point links idle? >> >> Thanks, >> Donald >> >>>>> >>> Thanks, >>>>> >>> Ayan >>>>> >>> >>>>> >>> ... >>>>> >>> >>>> >> >>>> >> 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/20090302/297beab0/attachment-0001.html From Radia.Perlman at sun.com Mon Mar 2 22:46:20 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 02 Mar 2009 22:46:20 -0800 Subject: [rbridge] parallel links Message-ID: <49ACD23C.1090902@sun.com> A discussion of how to compute trees when there are parallel links between R1 and R2 appeared, but could have been missed by people because it was included in a thread with a somewhat generic subject line (WG last call on draft-trill-rbridge-protocol-10.txt), and the thread was discussing several issues. The issue is that if R1 and R2 have, say, k parallel links between them, and they are all reported in the link state protocol, then it would be bad for R1 and R2 to disagree about which link should be in the tree. The result would not be a loop (I'm pretty sure), but instead, packets would be dropped because if R1 is sending on a link and R2 doesn't think that link is in the tree, R2 will drop the packet. Now, as Don pointed out -- this issue does not affect some other RBridge, say R3. It only affects the RBridges attached to the link. Ayan suggested that we put in a tie breaker so that R1 and R2 agree on which link should be used. That seems harmless. First of course, the link with lowest cost should be used (it wouldn't be a tie otherwise, so this doesn't need to be clarified). Then, we can use what Ayan suggested, namely: >>We need information in the draft that states that we break ties using (a) >>extended circuit id on P2P links (makes 3-way handshake mandatory) and (b) >>in a LAN, use lan circuit id. Don might be correct that as long as R2 is "liberal in what it receives", and is willing to accept multicast traffic from R1 on either of those links, that there wouldn't be a problem, but it seems safer to do a tiebreaker. Now for load-splitting fans, who might want to see both of those links used: I think that should be a feature between R1 and R2, perhaps even something we put into the spec (or some add-on spec). R1 and R2, noticing that there are multiple parallel links between them, can treat them like one "fat pipe", only reporting a single link, and making sure that packets going over the multiple links don't cause packets from the same flow to get out of order. This can be done by hashing and making sure that the same flow goes over the same link, or it could be done by using a protocol between R1 and R2 where the packets are numbered and put back in order (that way even packets from the same flow can use multiple links). I suspect some IS-IS implementations already have this feature. I vaguely remember it being discussed years ago, for instance, even when I was at Digital a hundred years ago or so. So I'm not sure we need to put it into the TRILL spec now. But we could... Radia From trill at punk.co.nz Tue Mar 3 22:53:26 2009 From: trill at punk.co.nz (Kris Price) Date: Wed, 04 Mar 2009 19:53:26 +1300 Subject: [rbridge] MPLS forwarding In-Reply-To: <48E76EDE.7070406@punk.co.nz> 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> <48E76EDE.7070406@punk.co.nz> Message-ID: <49AE2566.5050806@punk.co.nz> Hi, So, further to my previous email about MPLS forwarding: I've been unable to get the subject out of my head, and after pondering it at some length I thought I would summarise the basics here, in case it interests other people too, who think it's worth discussing (perhaps elsewhere), or who have considered it and can share the flaws with me. I apologise for any controversy. It seems to me that RBridges could be achieved using MPLS encapsulation and forwarding. It may resemble VPLS in many ways, but would use new or adapted control-plane protocols operating at layer-2 instead of layer-3. Such a system would share many similarities to RBridges and the problems that TRILL has already solved (or is solving) for RBridges, but the encapsulation and forwarding would be different. Why MPLS? Mainly for the re-use of existing hardware. I assume adding new control-planes is much simpler as it is predominantly a matter of software development. Re-using hardware would (again, I'm assuming) reduce development costs and the time to market. Also, MPLS seems to have won the race in the transport area, so there may be practical advantages to consolidating on using MPLS hardware for aggregation and campus as well. (Rather than splitting effort.) But that's well beyond me to say. In summary: Routers run a link-state protocol, building a topological database from which they identify the shortest paths to other routers. Routers set up label switched paths (LSPs) to the other routers. Routers use either control-plane or data-plane learning of reachability information. In control-plane learning, routers learn the MAC addresses of active end stations on attached links, as a normal IEEE bridge would, and distribute this over the link-state protocol so that sending routers can identify the appropriate LSPs on which to forward frames. In data-plane learning, each router learns the appropriate LSPs by examining packets during decapsulation. When a frame from an end station arrives at a router, the router looks up the destination MAC address, identifying the egress router and appropriate label switch path. The router encapsulates the frame in an MPLS header, and the encapsulated frame is then label switched across the network to the egress node. At the egress node the label is popped and the frame forwarded out the appropriate interface. Single-destination frames would be forwarded on multipoint-to-point (MP2P) LSPs. Point-to-point (P2P) LSPs do not scale as well. For single-destination forwarding, scaling is essentially O(n) using MP2P LSPs compared to O(n^2) using P2P LSPs. It appears from the experience of TRILL that data-plane learning is a desirable feature. To achieve this, there are two options apparent to me that could be explored: The first is to place an extra label in the stack when encapsulating a frame in MPLS, which can be used by the egress router to identify the ingress router. In essence these are P2P LSPs tunnelled over the MP2P LSPs. The second is to look at using some kind of MAC-in-MAC encapsulation before the MPLS encapsulation, with the outer MAC header identifying the source and destination addresses of the routers in question (where only the source address is actually relevant). The egress router, after popping the MPLS label, would learn the ingress router via this outer MAC header. Multi-destination forwarding is naturally trickier. Trees would need to be set up, either shared trees as per RBridges, or source-based trees similar to PLSB and approaches considered for VPLS. Additional trees would be set up for constrained distribution (more later). With multi-destination forwarding there are so many ways to skin it, and it depends on many factors such as: how VLANs and IP multicast is to be handled; trade offs between bending the rules in the MPLS architecture, any requirements for data-plane learning, and balancing the intricacy of the control-plane. VLANs could be managed in a couple of ways: Some form of multi-topology routing could be used to discover the topology of each VLAN, and when transmitting across each link the outer MAC header would contain the VLAN tag of the topology in question, on receipt the router can use this additional information to classify the packet. This can be seen to increase the MPLS label space ("per-subinterface") and constrain the forwarding of frames in a VLAN to links which are in those VLANs. Directly coupled router to router links would simply be full 802.1Q trunks. Another option is not to be concerned about constraining frames to only those links which allow those VLANs, and each router advertises VLAN membership, with constrained distribution trees established for each VLAN. The outer VLAN tags used on each link wouldn't be relevant. IP multicast can also be optimised with constrained trees, and the mcast group membership information distributed by the link-state protocol. I did discover that MPLS encapsulation was proposed for RBridges in draft-bryant-perlman-trill-pwe-encap-00, which from my understanding violates the MPLS architecture, because label assignments are made upstream, but that upstream allocation does certainly make things easier for the control-plane in a system like this (if it's a violation you can live with). The draft does discuss how the paths would be established and it is possible to conceive ways of establishing additional constrained trees for VLANs and IP multicast optimisation too. However, after cursory examination of methods for this, it would seem to require routers to do SPF computations for all routers in the network. A router would need to know its position in the tree to decide if it needed to install relevant forwarding state. This may be considerable overhead, but that does not seem to bother the people behind PLSB, and I do not have the wisdom to declare whether it is or is not. A signalling protocol in the control-plane (perhaps separate, or perhaps carried on the link-state protocol) could remove the need to do these SPF computations, and remove the upstream assignment of labels, making it compliant to the MPLS architecture. But this would be a trade off in that the resulting protocol might be considered more intricate. That is the sum of it. The rest gets into the details of weighing these approaches against each other and designing the protocols. Again, I apologise for any controversy, unfortunately I've no one who understands these subjects well enough that I can bounce the idea off. I just wanted to put it out there with a slightly better explanation in case there were likeminded people who thought it worthy of discussion (perhaps in another forum) or were able to open my mind to the flaws in it. Regards Kris Price From james.d.carlson at sun.com Wed Mar 4 06:38:54 2009 From: james.d.carlson at sun.com (James Carlson) Date: Wed, 4 Mar 2009 09:38:54 -0500 Subject: [rbridge] MPLS forwarding In-Reply-To: <49AE2566.5050806@punk.co.nz> 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> <48E76EDE.7070406@punk.co.nz> <49AE2566.5050806@punk.co.nz> Message-ID: <18862.37502.743900.917272@gargle.gargle.HOWL> Kris Price writes: > So, further to my previous email about MPLS forwarding: I've been unable > to get the subject out of my head, and after pondering it at some length > I thought I would summarise the basics here, in case it interests other > people too, who think it's worth discussing (perhaps elsewhere), or who > have considered it and can share the flaws with me. I apologise for any > controversy. I and others have had similar thoughts. And the hardware reuse is very attractive indeed. > The first is to place an extra label in the stack when encapsulating a > frame in MPLS, which can be used by the egress router to identify the > ingress router. In essence these are P2P LSPs tunnelled over the MP2P LSPs. Yes; that's what I'd expect you'd need to do. It should work, though it does mean that the ingress somehow (through signaling) needs to know what label the egress needs to use as the outer label when sending data in the opposite direction. It's just not what the working group long ago adopted. That's the key problem with the approach. I realize that doesn't sound like a promising answer, but we're years down the path of getting consensus. Developing a brand new protocol, at least in *this* working group, doesn't seem like a viable option. > The second is to look at using some kind of MAC-in-MAC encapsulation > before the MPLS encapsulation, with the outer MAC header identifying the > source and destination addresses of the routers in question (where only > the source address is actually relevant). The egress router, after > popping the MPLS label, would learn the ingress router via this outer > MAC header. That doesn't sound as good to me. The egress learning function needs to have a clear path back to the ingress. In MPLS, that means a label. If you're doing MAC-in-MAC, this means that the egress needs to have some sort of table that maps source MAC addresses back to the labels that are actually needed, which sounds far more complex than just including the information as a stacked ready-to-use label. > A signalling protocol in the control-plane (perhaps separate, or perhaps > carried on the link-state protocol) could remove the need to do these > SPF computations, and remove the upstream assignment of labels, making > it compliant to the MPLS architecture. But this would be a trade off in > that the resulting protocol might be considered more intricate. Actually, I think the SPF computations are a *good* thing. The only issues would be carrying labels in the LSPs instead of nicknames, determining what to do about any MPLS-only (no RBridgishness) portions of the core network, and figuring out how label distribution ought to work. -- 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 erik.nordmark at sun.com Wed Mar 4 10:48:21 2009 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 04 Mar 2009 10:48:21 -0800 Subject: [rbridge] MPLS forwarding In-Reply-To: <49AE2566.5050806@punk.co.nz> 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> <48E76EDE.7070406@punk.co.nz> <49AE2566.5050806@punk.co.nz> Message-ID: <49AECCF5.2080907@sun.com> Kris Price wrote: > It seems to me that RBridges could be achieved using MPLS encapsulation > and forwarding. It may resemble VPLS in many ways, but would use new or > adapted control-plane protocols operating at layer-2 instead of layer-3. > > Such a system would share many similarities to RBridges and the problems > that TRILL has already solved (or is solving) for RBridges, but the > encapsulation and forwarding would be different. > > Why MPLS? Mainly for the re-use of existing hardware. I assume adding > new control-planes is much simpler as it is predominantly a matter of > software development. Re-using hardware would (again, I'm assuming) > reduce development costs and the time to market. Kris, It has been a while since the MPLS encapsulation was discussed in the WG but there are two key things I remember as being issues: - TRILL wants a hopcount in the header for loop safety - For multipath of multicast (or multi-destination frames in general) TRILL needs the ingress rbridge in the header While one could extend the MPLS encapsulation for TTL, and one can somehow use the tag as a tag for the ingress for multi-destination frames, doing so probably means that existing MPLS hardware couldn't be reused. You might be able to find more details on the discussion we had in the WG email archives. Erik From james.d.carlson at Sun.COM Wed Mar 4 11:12:52 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Wed, 4 Mar 2009 14:12:52 -0500 Subject: [rbridge] MPLS forwarding In-Reply-To: <49AECCF5.2080907@sun.com> 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> <48E76EDE.7070406@punk.co.nz> <49AE2566.5050806@punk.co.nz> <49AECCF5.2080907@sun.com> Message-ID: <18862.53940.387364.305580@gargle.gargle.HOWL> Erik Nordmark writes: > It has been a while since the MPLS encapsulation was discussed in the WG > but there are two key things I remember as being issues: > - TRILL wants a hopcount in the header for loop safety MPLS already makes a provision for determining the MPLS TTL from some other procedure; section 2.4.4 of RFC 3032. > - For multipath of multicast (or multi-destination frames in general) > TRILL needs the ingress rbridge in the header A stacked header does that reasonably well. > While one could extend the MPLS encapsulation for TTL, and one can > somehow use the tag as a tag for the ingress for multi-destination > frames, doing so probably means that existing MPLS hardware couldn't be > reused. I don't think that part is true. At least I *know* it's not true for the hardware that was designed at IronBridge. It was capable of pushing multiple labels at ingress and popping multiple at egress, precisely to support tunnels-in-tunnels. As for those in the middle of the proposed scheme (the network core), all they need to do is what any LSR needs to do: look at the outer label and forward, swapping as usual. Thus, it would be compatible with existing machines, and is an interesting thing to explore. I just don't think it's something that would be explored in this working group. -- 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 trill at punk.co.nz Wed Mar 4 17:30:43 2009 From: trill at punk.co.nz (Kris Price) Date: Thu, 05 Mar 2009 14:30:43 +1300 Subject: [rbridge] MPLS forwarding In-Reply-To: <49AECCF5.2080907@sun.com> 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> <48E76EDE.7070406@punk.co.nz> <49AE2566.5050806@punk.co.nz> <49AECCF5.2080907@sun.com> Message-ID: <49AF2B43.5060307@punk.co.nz> [Oops. Resending to list from correct address.] Hi Erik, > - For multipath of multicast (or multi-destination frames in general) > TRILL needs the ingress rbridge in the header As I see it, multi-destination would have to be handled using either point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) LSPs. *MP2MP* A MP2MP LSP delivers packets amongst routers in a group. Any router in the group can transmit a packet and it will be received by all of the other routers in the group. I am partial to this, because in many properly designed networks there are usually only a few such shared trees that are needed. Identifying the ingress router is a problem with MP2MP LSPs because a router will recieve packets from all of the members in the group with the same incoming label. Label stacking could be used but pretty much requires a special case violation of the MPLS arch to permit upstream assignment. In that case each router advertises its identifying label for other routers to install the appropriate state for. Note the reason for upstream assignment is of course that the same MPLS packet is sent to multiple downstreams -- so of course there is no way for it to have a different bottom label for each downstream it reaches. If this upstream assignment is seen as too ugly, but MP2MP LSPs were determined necessary, then it is back to some kind of MAC-in-MAC-o-MPLS possibility. Perhaps think of it like each router has an 802.1ah bridge layer, that out one side connects to the Ethernet LANs, and the other to other routers via this MPLS system. (Uglier perhaps.) Or data-plane learning is dropped should MP2MP LSPs be used. *P2MP* A P2MP LSP delivers packets from a single ingress router to a group of egress routers. This has the advantage that when a router recieves a packet on the LSP, it knows which source it came from. (Depending in part on how the LSP is set up.) At a minimum, there would need to be a default P2MP LSP rooted on every router, so that broadcasts/unknowns reach all other routers. From there constrained trees could be set up in any number of ways and it opens up into a big topic. Pro: downstream assignment can be used, and data plane learning still possible. Con: potential scalability constraints with downstream assignment dependant on requirements. > You might be able to find more details on the discussion we had in the > WG email archives. I did try searching for anything relevant in the archives, but seems my search foo is just not up to it. Question: is there any (rough or otherwise) scalability requirements someone can outline or point me to for systems like this and RBridge? Maximum number of bridges or end-stations, that kind of thing. Cheers Kris From Internet-Drafts at ietf.org Thu Mar 5 11:00:01 2009 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Thu, 5 Mar 2009 11:00:01 -0800 (PST) Subject: [rbridge] I-D Action:draft-ietf-trill-prob-06.txt Message-ID: <20090305190001.A33D03A6952@core3.amsl.com> From touch at ISI.EDU Thu Mar 5 11:38:38 2009 From: touch at ISI.EDU (Joe Touch) Date: Thu, 05 Mar 2009 11:38:38 -0800 Subject: [rbridge] I-D Action:draft-ietf-trill-prob-06.txt In-Reply-To: <20090305190001.A33D03A6952@core3.amsl.com> References: <20090305190001.A33D03A6952@core3.amsl.com> Message-ID: <49B02A3E.5000907@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, This update reflects IESG requests for changes, the bulk of which are clarification. Credit and many thanks to Donald Eastlake who coordinated this update's contents. FYI. 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-06.txt > Pages : 18 > Date : 2009-03-05 > > Current IEE 802.1 LANs 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 IEEE 802.1 bridged 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-06.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 iEYEARECAAYFAkmwKj4ACgkQE5f5cImnZrszGACdGSv6O5wEiPaq3Oeu1NYZeH7n D54AoNEQQAnEPKFQwjVGeqK1+00d93HU =3+H8 -----END PGP SIGNATURE----- From Radia.Perlman at sun.com Thu Mar 5 21:51:29 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 05 Mar 2009 21:51:29 -0800 Subject: [rbridge] parallel links In-Reply-To: <49ACD23C.1090902@sun.com> References: <49ACD23C.1090902@sun.com> Message-ID: <49B0B9E1.1050106@sun.com> So, is it obvious what can be used for a tie-breaker? Ayan's suggestion of "circuit ID on a LAN" is probably the pseudonode ID. But in the case where R1 (the DRB) decides to suppress the psueonode, this might not work. Can we have a flag in the Hello that says "don't bother with a pseuodonode" (instead of noting no pseudonode by using 0 for the pseudonode ID)? Then the DRB will always put in a unique pseudonode ID, but just set a flag saying "just report this as a pt-to-pt links". And the link will have a unique pseuonode ID for R1 and R2 to use as a tie-breaker. This pseuodnode ID will not be visible outside the link -- just visible to R1 and R2. Radia Radia Perlman wrote: > > >>We need information in the draft that states that we break ties using > (a) > >>extended circuit id on P2P links (makes 3-way handshake mandatory) > and (b) > >>in a LAN, use lan circuit id. > From Internet-Drafts at ietf.org Mon Mar 9 10:45:02 2009 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 9 Mar 2009 10:45:02 -0700 (PDT) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-12.txt Message-ID: <20090309174502.669C63A6CF2@core3.amsl.com> From trill at punk.co.nz Tue Mar 10 21:25:34 2009 From: trill at punk.co.nz (Kris Price) Date: Wed, 11 Mar 2009 17:25:34 +1300 Subject: [rbridge] Abridged history of the RBridge header Message-ID: <49B73D3E.2000309@punk.co.nz> Hi, Since the last time I bothered the mailing list with questions about MPLS I found the relevant period where the header changed shape. And FWIW I compiled the following abridged history. (Only late 2007 onwards to go in my reading of the mailing list now. ...) *An abridged history of the RBridge header* Note: Names and references have been excluded to prevent anyone being unwillingly associated with my interpretation of events. Naturally I have no visibility of meetings or private discussions. The details can be found by reading the TRILL mailing list archive of the period from October to December, 2006. TRILL initially looked to use MPLS based encapsulation for RBridges, as described in draft-bryant-perlman-trill-pwe-encap-00. The approach created a global MPLS labelspace from which RBridges selected their nicknames. The MPLS header would only include egress RBridge, CoS, and TTL information. An RBridge would make additional forwarding decisions, for example to constrain delivery of a VLAN tagged frame to only those links on which that VLAN is active, by using the information in the encapsulated MAC header. This was a deviation from the general architecture of MPLS that such forwarding decisions are made at the edge by selecting the correct label switch path. The responsibility falling to the control-plane to set up the necessary label switched paths accordingly. Hence the amount of hardware re-use at the time may have been limited depending on whether this filtering became a strict requirement or an option that could be phased in as new hardware was developed. Because this type of filtering has unrelated benefits it may well find its way into many platforms anyway, and today some platforms may already have some of this capability for that reason. A potential requirement for the inclusion of ingress RBridge information within the header was raised on the mailing list in October 2006. It was based on the need to possibly support 802.1au Congestion Notification, in which notifications must be returned to the end-station that sent the triggering frame. To do this, it was argued that an RBridge trying to send such a notification would need to know the ingress RBridge. It was suggested that the ingress RBridge could be identified by looking at the source MAC address in the encapsulated MAC header. One group felt it was inappropriate for a core RBridge to maintain all of the MAC reachability information, as would be required in order to do this lookup. Another group felt this was reasonable, as that is what core IEEE bridges to today. In the case where all of the MAC reachability information was not maintained, the approach of sending the notification over the multi-destination delivery tree (since it is then effectively an unknown destination frame) was rejected as having negative impacts. Other fields were also proposed for inclusion in the header at this time, as described in draft-gai-perlman-trill-encap-00, but these were eventually ruled out, or incorporated in other ways. The resulting approach that was settled on was to include ingress and egress RBridge information. This was seen as more natural and flexible to future requirements. The option of continuing to use MPLS based encapsulation was raised, using a label stack, with the top label as per the original proposal, and the bottom label identifying the ingress RBridge. This appears to have received very little attention. I can only speculate that it was rejected out of a belief that MPLS based encapsulation brought little benefit, in which case a simplified 6-byte header versus an 8-byte header was more elegant. The use of the encapsulation defined for 802.1ah Provider Backbone Bridges was raised at the IETF-67 meeting in November, 2006. At the time 802.1ah was on its way to becoming a standard, and the question was whether there were any synergies between it and RBridges that could be capitalised on. Subsequent discussions on the mailing list ultimately rejected the idea for a few reasons. There was a feeling that 802.1ah was targeted at the provider market and so unsuitable for the enterprise and data centre market, although it is unclear why this made it unsuitable. There was a larger concern that 802.1ah would require a partial move away from zero configuration, although this was never clearly detailed. The clearest arguments against the use of 802.1ah were the lack of a TTL in the header, and the lack of a next-hop address. It was suggested that a TTL could be accommodated in the header before the standard was finalised, but the lack of a next-hop address was unresolved. RBridges uses the outer MAC encapsulation to define the next-hop on each link, this allows load balancing to multiple next-hop RBridges across a shared link. It is unclear whether the benefits of this versus the benefits of a shared encapsulation were weighed. When 802.1ah based encapsulation was proposed it was noted that by using a non-IEEE frame format TRILL would be assuming responsibility for implementing all of the features developed by IEEE. Subsequent to this the header acquired the options field to permit extensions, and it has resulted in the TRILL header seen today. The end. Regards Kris From trill at punk.co.nz Fri Mar 13 16:38:51 2009 From: trill at punk.co.nz (Kris Price) Date: Sat, 14 Mar 2009 12:38:51 +1300 Subject: [rbridge] VLAN hopping: firewall on a stick Message-ID: <49BAEE8B.8000504@punk.co.nz> Hi, I asked about this last year, but at the time I was more interested in the use of MPLS. I'm hoping I am just misunderstanding something here, but my reading of TRILL is that it bypasses the configured policy, and enables a kind of VLAN hopping. Is it possible to send a frame with an inner VLAN tag across a link that does not ordinarily permit that VLAN tag? I'll try to explain with an overly-simplistic case. *Diagram* Office floor : Server room ------------ : ----------- : +---Sw1---+ +---Sw2---+ | [Vlan1]-|--Vlan1--|-[Vlan1] | +---------+ | [Vlan2] |--dot1Q--[Firewall] : +---------+ : | : dot1Q : | : +---Sw3---+ : | [Vlan1] | : | [Vlan2] | : +---------+ Traffic between VLAN 1 and VLAN 2 must go via the firewall. Sw3 is reaching EOL so a smart thinking engineer decides to replace with an RBridge. At first there is no problem because the engineer configures the RBridge to only allow the correct VLANs on the access ports. Traffic between VLAN 1 and VLAN 2 must still go via the firewall. An unscrupulous individual comes on the scene and connects an RBridge to Sw1 which is accessible, or simply emulates an RBridge on her PC, either way there are now two RBridges seeking each other out across VLAN 1. She can bypass the firewall to reach VLAN 2, sending packets via the RBridge that replaced Sw3. Do I understand right? Regards Kris From d3e3e3 at gmail.com Sat Mar 14 11:10:20 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 14 Mar 2009 14:10:20 -0400 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49BAEE8B.8000504@punk.co.nz> References: <49BAEE8B.8000504@punk.co.nz> Message-ID: <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> Hi, On Fri, Mar 13, 2009 at 7:38 PM, Kris Price wrote: > Hi, > > I asked about this last year, but at the time I was more interested in > the use of MPLS. I'm hoping I am just misunderstanding something here, > but my reading of TRILL is that it bypasses the configured policy, and > enables a kind of VLAN hopping. > > Is it possible to send a frame with an inner VLAN tag across a link that > does not ordinarily permit that VLAN tag? Yes. It's a feature mentioned a few places in the protocol draft. The TRILL view, as stated in the draft, is that a VLAN represents a layer 2 community and that all end stations in that VLAN within a campus should be able to get to each other. Many people believe that is the spirit of 802.1Q and is why, in 802.1Q, dynamic VLAN registration is mandatory to implement and is the default for almost all VLANs on almost all ports, so that all end stations in a VLAN are connected. Anyway, if there are two or more islands of a particular VLAN in a bridged networks, replacing enough of the bridges with RBridges will heal the partitioning of that VLAN. > I'll try to explain with an overly-simplistic case. > > *Diagram* > > ? ? Office floor : Server room > ? ? ------------ : ----------- > ? ? ? ? ? ? ? ? ?: > ? +---Sw1---+ ? ? ? ? +---Sw2---+ > ? | [Vlan1]-|--Vlan1--|-[Vlan1] | > ? +---------+ ? ? ? ? | [Vlan2] |--dot1Q--[Firewall] > ? ? ? ? ? ? ? ? ?: ? ?+---------+ > ? ? ? ? ? ? ? ? ?: ? ? ? ?| > ? ? ? ? ? ? ? ? ?: ? ? ?dot1Q > ? ? ? ? ? ? ? ? ?: ? ? ? ?| > ? ? ? ? ? ? ? ? ?: ? ?+---Sw3---+ > ? ? ? ? ? ? ? ? ?: ? ?| [Vlan1] | > ? ? ? ? ? ? ? ? ?: ? ?| [Vlan2] | > ? ? ? ? ? ? ? ? ?: ? ?+---------+ > > Traffic between VLAN 1 and VLAN 2 must go via the firewall. I find your diagram very confusing. Does "dot1Q" in the middle of a link means that frames on that link are VLAN tagged? Does a list of VLANs inside a box means that the ports of that box which are shown are configured to enable output of frames in that VLAN (except perhaps for the horizontal link between Sw1 and Sw2 which has "Vlan 1" in the middle of it, presumably meaning that the ports at both ends are configured for VLAN 1 only?)? Is this Firewall an end station? Why do frames go to the firewall? Are they addressed to it? Couldn't any end station connected to Sw2 or Sw3 do VLAN mapping on frame it receives? > Sw3 is reaching EOL so a smart thinking engineer decides to replace with > an RBridge. At first there is no problem because the engineer configures > the RBridge to only allow the correct VLANs on the access ports. Traffic > between VLAN 1 and VLAN 2 must still go via the firewall. If you are replacing a bridge with an RBridge, of course you have to do the same VLAN configuration on its ports as the bridge ports had. And, unless you are using the optional RBridge VLAN mapping feature (see draft-ietf-trill-rbridge-vlan-mapping-00.txt), you can only map frames from one VLAN to another via an end station or by using port configurations so a VLAN tag gets stripped on transmission and a different tag added on receipt. > An unscrupulous individual comes on the scene and connects an RBridge to > Sw1 which is accessible, or simply emulates an RBridge on her PC, either > way there are now two RBridges seeking each other out across VLAN 1. She > can bypass the firewall to reach VLAN 2, sending packets via the RBridge > that replaced Sw3. I don't really understand what you mean by "reach VLAN 2". First of all, if someone "unscrupulous" attaches a hardware or software RBridge and you have no TRILL IS-IS security, you're pretty well screwed anyway. See the Security Considerations section of the protocols draft. Second, if you mean they can send a VLAN 1 frame that would be delivered to a VLAN 2 end station which is attached to an RBridge port where only VLAN 2 is enabled, I don't see why you think that. There seems to be vast amounts of detail you are assuming and not describing. > Do I understand right? Probably, although I'm not sure. Try looking at Section 2.3, 4.1.2, and 6.1 of draft-ietf-trill-rbridge-protocol-12.txt. > Regards > Kris Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From trill at punk.co.nz Sat Mar 14 23:25:45 2009 From: trill at punk.co.nz (Kris Price) Date: Sun, 15 Mar 2009 19:25:45 +1300 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> Message-ID: <49BC9F69.8070407@punk.co.nz> Hi Donald, >> Is it possible to send a frame with an inner VLAN tag across a link that >> does not ordinarily permit that VLAN tag? > > Yes. It's a feature mentioned a few places in the protocol draft. > > The TRILL view, as stated in the draft, is that a VLAN represents a > layer 2 community and that all end stations in that VLAN within a > campus should be able to get to each other. Many people believe that > is the spirit of 802.1Q and is why, in 802.1Q, dynamic VLAN > registration is mandatory to implement and is the default for almost > all VLANs on almost all ports, so that all end stations in a VLAN are > connected. Anyway, if there are two or more islands of a particular > VLAN in a bridged networks, replacing enough of the bridges with > RBridges will heal the partitioning of that VLAN. I think I understood the TRILL view on VLANs, but it didn't seem to align to my understanding of 802.1Q or the real world networks I've worked on and seen. 802.1Q does permit VLAN topologies to be constrained or partitioned through the use of management controls (i.e. by allowing or denying VLANs on links). This comes through clear to me in the standard but anyone please feel free to disabuse me of this belief if it's wrong. Either way it certainly comes through clear in practise. So I think you've confirmed my suspicion for me, along with section 6 of the draft. If I'm not wrong, is this behaviour such a good idea? I'll go into a bit more detail. > I find your diagram very confusing. Does "dot1Q" in the middle of a [snip] So much for my attempt at simple. :) This can actually be broken down into an even simpler case, so I'll change tack a little bit. I am concerned that TRILL appears to take the view that removing partitions is OK when they are often there for a very good reason. These kinds of partitions are also *very* far from infrequent. +----+ +----+ +----+ | B1 |--dot1Q--| B2 |--dot1Q--| B3 | +----+ +----+ +----+ B1 is in an untrusted location so from a security perspective should be treated as potentially compromised. The administrator wants to control access to VLAN X so disallows VLAN X on the dot1Q trunk between B1 and B2. Rightly or wrongly this is very common. In a situation where B1 and B3 are replaced with RBridges is it possible for B1 to bypass the restriction configured on B2 and access any VLAN on the network? It looks to me like B1 can send an TRILL data frame with an inner VLAN tag X over the Designated VLAN to B3, and B3 will decapsulate it and forward the encapsulated frame quite happily. Clearly TRILL cannot assume that every RBridge is trusted. There may be administrative divisions and all kinds of things, let alone determined attackers. Just as a provider would not place a PE router on an unsecure customer site, because if compromised they have the keys to the kingdom. > I don't really understand what you mean by "reach VLAN 2". First of > all, if someone "unscrupulous" attaches a hardware or software RBridge > and you have no TRILL IS-IS security, you're pretty well screwed > anyway. See the Security Considerations section of the protocols > draft. Second, if you mean they can send a VLAN 1 frame that would be [snip] This seems very dangerous to me. In an 802.1Q network you are not so screwed when someone attaches or compromises a device because people do this kind of filtering for that very reason. I think it is important for TRILL to err towards safety and security. (Actually, I see it's a goal not to be less secure.) *Solutions* Without thinking too hard about it, here are some possible solutions that may have other serious problems with them of course. :) The hard fix would be to copy the inner VLAN tag to the outer VLAN tag. Thus the frame could still only travel on the same links it could in a pre-RBridge deployment. The drawback would be that the shortest path may traverse a bridge where this VLAN is filtered and so frames are dropped, whereas prior to the RBridge deployment the spanning tree for that VLAN allowed communication to continue via the long way around. But this is much safer, and it is very much more realistically caused by a misconfiguration than in the other case of filtering. When it happens, it's most likely because the engineer allowed the VLAN on some other link, communications worked because that was the spanning tree route, and he forgot to allow it on this shortest path as well. Such a failure should come up during deployment within the outage window, and it isn't hard for the engineer to understand what is going on. Quite simply he can see packets on VLAN X are being dropped between his shiny new RBridges, he looks at the network and sees VLAN X is blocked on a trunk. To him the VLAN forwarding behaviour of RBridges and Bridges remains similar. He doesn't have to understand that some VLAN X frames now travel on VLAN 1. The *soft* solution is probably to use something like the protection Hello's with the outer VLAN tags. An RBridge will drop frames if they arrive with an inner VLAN tag from another RBridge which it hasn't seen a protection Hello from with that as the outer VLAN tag. It knows then that that RBridge can't send frames with that VLAN tag to it because it never got a Hello on that VLAN, so why should it see frames with the inner tag, it shouldn't, and should be respectful and drop them. But this is fairly soft and subject to spoofing and the like. It may be possible to do something cryptographically to ensure that packets aren't spoofed, but this adds complexity and configuration. The third option is a configuration option if the implementation of RBridges permits. The engineer should, provided he understands TRILL and his network well enough, be able to add inner VLAN filtering on the appropriate Designated VLANs. Thus he could filter VLAN X on the designated VLAN on B3 that links through B2 to B1. The filter would look at the inner tag of arriving TRILL data frames, and discard VLAN X. A fourth option might be something like MST-like regions, where TRILL only does TRILL on RBridge-RBridge links. Might require the TRILL region appearing as a bridge for the purpose of STP, or RPF checks and the like to get around potential looping issues. But does mean that you can have different admin domains too. >> Do I understand right? > > Probably, although I'm not sure. Try looking at Section 2.3, 4.1.2, > and 6.1 of draft-ietf-trill-rbridge-protocol-12.txt. I coudn't see anything prohibiting this in the sections you mentioned, other than to confirm my concerns, which is possibly described (but a little unclearly to me) in section 6. *Digressing a bit* Forgive me if I am well off the reservation saying this. Saying the following as an outsider with possibly fresh eyes: I think TRILL must be careful not end up sold as requiring similar or less configuration than bridges, especially in terms of replacing bridges with RBridges. I've heard zero-conf and simplicity mentioned quite a bit as a goal, but it seems to only apply to greenfields deployments, and even then perhaps not always. TRILL's behaviour is unlike anything else. It neither behaves like 802.1 bridges that people have become accustomed to, or routers in that it treats all VLANs on an interface as the same link. Its deployment requires a reasonable level of TRILL specific knowledge. One of the things I thought TRILL was about was making safe networks by default. So if every engineer who was deploying these was at a level of understanding and working with the potential caveats of TRILL, we'd have lots of really good engineers and have less need for TRILL in most environments. So is TRILL perhaps now targeted more at scale out clusters and greenfields, perhaps with an eventual trickle down to the existing enterprise, and so on, as prices drop and engineers become more comfortable with the technology? If so perhaps it would benefit significantly from a recognition of that and study of what effect it could have on the protocol. Regards Kris From cait at asomi.com Sun Mar 15 12:13:39 2009 From: cait at asomi.com (Caitlin Bestler) Date: Sun, 15 Mar 2009 12:13:39 -0700 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49BC9F69.8070407@punk.co.nz> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> Message-ID: <49BD5363.6050604@asomi.com> Kris Price wrote: > > I am concerned that TRILL appears to take the view that removing > partitions is OK when they are often there for a very good reason. These > kinds of partitions are also *very* far from infrequent. > > +----+ +----+ +----+ > | B1 |--dot1Q--| B2 |--dot1Q--| B3 | > +----+ +----+ +----+ > > B1 is in an untrusted location so from a security perspective should be > treated as potentially compromised. The administrator wants to control > access to VLAN X so disallows VLAN X on the dot1Q trunk between B1 and > B2. Rightly or wrongly this is very common. > > In a situation where B1 and B3 are replaced with RBridges is it possible > for B1 to bypass the restriction configured on B2 and access any VLAN on > the network? > I am not following how B2 is supposed to be enforcing a restriction. A frame that belongs to VLAN X can only be originated on an endstation that belongs to VLAN X, and 802.1Q Bridges enforce that. A frame that belongs to VLAN X can only be delivered to an endstation that belongs to VLAN X, and again 802.1Q Bridges enforce that. Bridges also seek to avoid forwarding frames to locations where they cannot be delivered to any endstations -- but that's a matter of optimizing network utilization. All of the above is also true for RBridges. If B1 and B3 both are members of VLAN X then it is appropriate for frames originated in B1 to be delivered in B3, no matter what B2 thinks. If "VLAN X" in B1 and "VLAN X" in B3 are different networks then they should have different VLAN IDs. Even without RBridges, any *new* path between B1 and B3 can bypass B2's attempt to partition VLAN X into two VLANs. If you two VLANs are distinct, use different VLAN IDs. -- Caitlin Bestler cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume.html From Radia.Perlman at sun.com Sun Mar 15 12:32:39 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 15 Mar 2009 12:32:39 -0700 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49BC9F69.8070407@punk.co.nz> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> Message-ID: <49BD57D7.9070203@sun.com> Although it's good to have people look at things with a fresh eye, part of the problem with looking at it so late is that some decisions might have been made that you might disagree with, and you didn't have a chance to argue about it at the time. We did discuss this issue, and the conclusion was that RBridges didn't have to behave *exactly* like bridges in various configuration-intensive situations. However, in this case -- VLAN hopping -- if you really want the feature of keeping two communities, both labelled "VLAN 5" distinct within a layer 2 cloud, can't you accomplish that with VLAN mapping, which RBridges do support? Radia Kris Price wrote: > Hi Donald, > > >>> Is it possible to send a frame with an inner VLAN tag across a link that >>> does not ordinarily permit that VLAN tag? >>> >> Yes. It's a feature mentioned a few places in the protocol draft. >> >> The TRILL view, as stated in the draft, is that a VLAN represents a >> layer 2 community and that all end stations in that VLAN within a >> campus should be able to get to each other. Many people believe that >> is the spirit of 802.1Q and is why, in 802.1Q, dynamic VLAN >> registration is mandatory to implement and is the default for almost >> all VLANs on almost all ports, so that all end stations in a VLAN are >> connected. Anyway, if there are two or more islands of a particular >> VLAN in a bridged networks, replacing enough of the bridges with >> RBridges will heal the partitioning of that VLAN. >> > > I think I understood the TRILL view on VLANs, but it didn't seem to > align to my understanding of 802.1Q or the real world networks I've > worked on and seen. > > 802.1Q does permit VLAN topologies to be constrained or partitioned > through the use of management controls (i.e. by allowing or denying > VLANs on links). This comes through clear to me in the standard but > anyone please feel free to disabuse me of this belief if it's wrong. > Either way it certainly comes through clear in practise. > > So I think you've confirmed my suspicion for me, along with section 6 of > the draft. If I'm not wrong, is this behaviour such a good idea? I'll go > into a bit more detail. > > >> I find your diagram very confusing. Does "dot1Q" in the middle of a >> > [snip] > > So much for my attempt at simple. :) This can actually be broken down > into an even simpler case, so I'll change tack a little bit. > > I am concerned that TRILL appears to take the view that removing > partitions is OK when they are often there for a very good reason. These > kinds of partitions are also *very* far from infrequent. > > +----+ +----+ +----+ > | B1 |--dot1Q--| B2 |--dot1Q--| B3 | > +----+ +----+ +----+ > > B1 is in an untrusted location so from a security perspective should be > treated as potentially compromised. The administrator wants to control > access to VLAN X so disallows VLAN X on the dot1Q trunk between B1 and > B2. Rightly or wrongly this is very common. > > In a situation where B1 and B3 are replaced with RBridges is it possible > for B1 to bypass the restriction configured on B2 and access any VLAN on > the network? > > It looks to me like B1 can send an TRILL data frame with an inner VLAN > tag X over the Designated VLAN to B3, and B3 will decapsulate it and > forward the encapsulated frame quite happily. > > Clearly TRILL cannot assume that every RBridge is trusted. There may be > administrative divisions and all kinds of things, let alone determined > attackers. Just as a provider would not place a PE router on an unsecure > customer site, because if compromised they have the keys to the kingdom. > > >> I don't really understand what you mean by "reach VLAN 2". First of >> all, if someone "unscrupulous" attaches a hardware or software RBridge >> and you have no TRILL IS-IS security, you're pretty well screwed >> anyway. See the Security Considerations section of the protocols >> draft. Second, if you mean they can send a VLAN 1 frame that would be >> > [snip] > > This seems very dangerous to me. In an 802.1Q network you are not so > screwed when someone attaches or compromises a device because people do > this kind of filtering for that very reason. > > I think it is important for TRILL to err towards safety and security. > (Actually, I see it's a goal not to be less secure.) > > *Solutions* > > Without thinking too hard about it, here are some possible solutions > that may have other serious problems with them of course. :) > > The hard fix would be to copy the inner VLAN tag to the outer VLAN tag. > Thus the frame could still only travel on the same links it could in a > pre-RBridge deployment. > > The drawback would be that the shortest path may traverse a bridge where > this VLAN is filtered and so frames are dropped, whereas prior to the > RBridge deployment the spanning tree for that VLAN allowed communication > to continue via the long way around. > > But this is much safer, and it is very much more realistically caused by > a misconfiguration than in the other case of filtering. When it happens, > it's most likely because the engineer allowed the VLAN on some other > link, communications worked because that was the spanning tree route, > and he forgot to allow it on this shortest path as well. Such a failure > should come up during deployment within the outage window, and it isn't > hard for the engineer to understand what is going on. Quite simply he > can see packets on VLAN X are being dropped between his shiny new > RBridges, he looks at the network and sees VLAN X is blocked on a trunk. > To him the VLAN forwarding behaviour of RBridges and Bridges remains > similar. He doesn't have to understand that some VLAN X frames now > travel on VLAN 1. > > The *soft* solution is probably to use something like the protection > Hello's with the outer VLAN tags. An RBridge will drop frames if they > arrive with an inner VLAN tag from another RBridge which it hasn't seen > a protection Hello from with that as the outer VLAN tag. It knows then > that that RBridge can't send frames with that VLAN tag to it because it > never got a Hello on that VLAN, so why should it see frames with the > inner tag, it shouldn't, and should be respectful and drop them. > > But this is fairly soft and subject to spoofing and the like. It may be > possible to do something cryptographically to ensure that packets aren't > spoofed, but this adds complexity and configuration. > > The third option is a configuration option if the implementation of > RBridges permits. The engineer should, provided he understands TRILL and > his network well enough, be able to add inner VLAN filtering on the > appropriate Designated VLANs. Thus he could filter VLAN X on the > designated VLAN on B3 that links through B2 to B1. The filter would look > at the inner tag of arriving TRILL data frames, and discard VLAN X. > > A fourth option might be something like MST-like regions, where TRILL > only does TRILL on RBridge-RBridge links. Might require the TRILL region > appearing as a bridge for the purpose of STP, or RPF checks and the like > to get around potential looping issues. But does mean that you can have > different admin domains too. > > >>> Do I understand right? >>> >> Probably, although I'm not sure. Try looking at Section 2.3, 4.1.2, >> and 6.1 of draft-ietf-trill-rbridge-protocol-12.txt. >> > > I coudn't see anything prohibiting this in the sections you mentioned, > other than to confirm my concerns, which is possibly described (but a > little unclearly to me) in section 6. > > > > *Digressing a bit* > > Forgive me if I am well off the reservation saying this. Saying the > following as an outsider with possibly fresh eyes: > > I think TRILL must be careful not end up sold as requiring similar or > less configuration than bridges, especially in terms of replacing > bridges with RBridges. > > I've heard zero-conf and simplicity mentioned quite a bit as a goal, but > it seems to only apply to greenfields deployments, and even then perhaps > not always. > > TRILL's behaviour is unlike anything else. It neither behaves like 802.1 > bridges that people have become accustomed to, or routers in that it > treats all VLANs on an interface as the same link. Its deployment > requires a reasonable level of TRILL specific knowledge. One of the > things I thought TRILL was about was making safe networks by default. So > if every engineer who was deploying these was at a level of > understanding and working with the potential caveats of TRILL, we'd have > lots of really good engineers and have less need for TRILL in most > environments. > > So is TRILL perhaps now targeted more at scale out clusters and > greenfields, perhaps with an eventual trickle down to the existing > enterprise, and so on, as prices drop and engineers become more > comfortable with the technology? If so perhaps it would benefit > significantly from a recognition of that and study of what effect it > could have on the protocol. > > > > Regards > > Kris > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From trill at punk.co.nz Sun Mar 15 23:56:20 2009 From: trill at punk.co.nz (Kris Price) Date: Mon, 16 Mar 2009 19:56:20 +1300 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49BD57D7.9070203@sun.com> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> <49BD57D7.9070203@sun.com> Message-ID: <49BDF814.6080304@punk.co.nz> Hi Radia, Radia Perlman wrote: > Although it's good to have people look at things with a fresh eye, part > of the problem with looking at it > so late is that some decisions might have been made that you might > disagree with, and you didn't have a chance > to argue about it at the time. I respect that and realise it's probably too late to revisit the overall architecture or some of these decisions, but I like idea behind TRILL and really want it to be successful, so (lacking any diplomacy perhaps) I can't help but question things that seem counter intuitive or contradictory to me. Maybe I'd be better to explore those things in a paper or some such tho. > We did discuss this issue, and the conclusion was that RBridges didn't > have to behave *exactly* like bridges in > various configuration-intensive situations. Okay. My experience differs, and maybe that's due to a regional thing. Down under I would say this kind of configuration is the norm, perhaps considered intensive, but certainly the norm. I haven't personally seen a configuration free 802.1 network since 1999, and at that time we were still using thinnet there. Even very small sites here are configured with VLANs for remote management and such. And when I imagine replacing them with an RBridge it would seem to never require less configuration. But in quite a few RBridges would seem to require more configuration due to security, and in quite a few places be disqualified from use if what I've been talking about isn't solvable. Which is why I wondered if it had evolved to being really just targeted at people with big clusters. > However, in this case -- VLAN hopping -- if you really want the feature > of keeping two communities, both > labelled "VLAN 5" distinct within a layer 2 cloud, can't you accomplish > that with VLAN mapping, which RBridges > do support? It might do. I'm reading draft-ietf-trill-rbridge-vlan-mapping-00.txt but it isn't completely clear to me. Let's see if I have it right. In the diagram the <1, 2, n> lists the VLANs allowed on the link as configured on the ports at both ends. If these were all 802.1Q bridges then B1 would not be able to reach stations in VLANs 2 and 3 attached to B2 or B3, even if it changed its configuration. Let's assume again that B1 and B3 have been swapped out to RBridges and B2 is still the 802.1Q bridge. Again B1 is untrusted so capable of changing its port configuration or crafting frames, etc. +----+ +----+ +----+ | B1 |--<1>--| B2 |--<1,2,3>--x B3 | +----+ +----+ +----+ We want to prevent B1 from accessing VLANs 2 and 3. Remembering B1 is untrusted, so possibly compromised and capable of changing its port configuration or crafting frames, etc. Using VLAN mapping, would we configure a map on the port "x" on B3, to map the VLANs we want to protect to other VLAN IDs? E.g. map VLAN 2 to VLAN 998 and map VLAN 3 to VLAN 999. Then make sure VLAN IDs 998 and 999 are never used for anything else. Is that how we'd do it? Can we map 2 and 3 to the same garbage VLAN ID or do we need to make a 1 for 1 mapping for every VLAN we want to protect? Can we do this inbound/outbound on the same trunk port? What happens if B1 sends a crafted frame tagged with 998 or 999 to B3, does it get mapped back to 2 or 3? Regards Kris From trill at punk.co.nz Mon Mar 16 00:19:37 2009 From: trill at punk.co.nz (Kris Price) Date: Mon, 16 Mar 2009 20:19:37 +1300 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49BD5363.6050604@asomi.com> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> <49BD5363.6050604@asomi.com> Message-ID: <49BDFD89.4030901@punk.co.nz> Hi Caitlin, Caitlin Bestler wrote: > Kris Price wrote: > >> I am concerned that TRILL appears to take the view that removing >> partitions is OK when they are often there for a very good reason. These >> kinds of partitions are also *very* far from infrequent. >> >> +----+ +----+ +----+ >> | B1 |--dot1Q--| B2 |--dot1Q--| B3 | >> +----+ +----+ +----+ >> >> B1 is in an untrusted location so from a security perspective should be >> treated as potentially compromised. The administrator wants to control >> access to VLAN X so disallows VLAN X on the dot1Q trunk between B1 and >> B2. Rightly or wrongly this is very common. >> >> In a situation where B1 and B3 are replaced with RBridges is it possible >> for B1 to bypass the restriction configured on B2 and access any VLAN on >> the network? >> > > I am not following how B2 is supposed to be enforcing a restriction. Okay, I'm officially seeking a sanity check now. :) Using a real world configuration may make what I'm saying clearer, so in Cisco terms we configure the following on B2: interface switchport trunk encapsulation dot1q switchport trunk allowed vlan 1,2,3 switchport mode trunk In this configuration the trunk port on B2 is statically configured to be a member of VLANs 1, 2, and 3. If B2 receives a frame that is tagged with VLAN 100 from B1 what does it do? It should discard it because the trunk port is not a member of VLAN 100, right? If B2 receives a frame, say its a broadcast for an easy example, tagged with VLAN 100 from an attached end station or B3, it floods it over the spanning tree, but does not forward it out the trunk port to B1 because that port is not a member of VLAN 100. Replacing B1 and B3 with RBridges, as currently specified, bypasses this kind of behaviour. > A frame that belongs to VLAN X can only be originated on an endstation > that belongs to VLAN X, and 802.1Q Bridges enforce that. Yep. > A frame that belongs to VLAN X can only be delivered to an endstation > that belongs to VLAN X, and again 802.1Q Bridges enforce that. Yep. 802.1Q says a frame that belongs to VLAN X will only be delivered to a LAN that is a member of VLAN X. > All of the above is also true for RBridges. > > If B1 and B3 both are members of VLAN X then it is appropriate for > frames originated in B1 to be delivered in B3, no matter what B2 thinks. > If "VLAN X" in B1 and "VLAN X" in B3 are different networks then they > should have different VLAN IDs. I don't think this is true or reflective of 802.1Q, but granted I'm not an 802 expert. I am going from my practical experience and a quick look at the 802.1Q Std. I think saying they should have different VLAN IDs is missing the point that we don't trust what comes out of B1. People use this feature of bridges extensively in practise as a way of securing their networks. It certainly might be TRILL's decision to do it this way regardless, but that decision shouldn't be due to any notion that this feature of 802.1Q isn't important or widely used. > Even without RBridges, any *new* path between B1 and B3 can bypass > B2's attempt to partition VLAN X into two VLANs. If you two VLANs > are distinct, use different VLAN IDs. 802.1Q covers this point and says you need to consider the full mesh when configuring such filtering. My experience is that people do this well, configuring allowed VLANs correctly on all paths. If you do configure an allowed VLAN on one link, and the spanning tree changes to a link you forgot to configure it on, that VLAN becomes partitioned. And vice versa, if you forget to remove it from a link and the topology changes it might be reconnected. But this is a clear case of misconfiguration. Is it a good security principal for TRILL to reduce the security of the network to the lowest common denominator? Philosophically it isn't for me. Not so sure that many would think it is. But maybe I'm out of date. At a minimum I think RBridges need to implement administrative filtering of the inner VLAN if not some other solution. The filtering should be such that administrators, provided they properly understand TRILL's behaviour, can mimic their existing security policy. This may be considered an issue left for implementers to add as a feature, but I think it'd be very beneficial to be included as a management control in the spec. Just as 802.1Q seems to deem it fit to define the behaviour in the spec. Radia suggests the VLAN mapping might enable this so I'll take a look at that, but if not I think the group should consider putting it in there. Also by design TRILL shouldn't, whether via some automatic configuration, easy to ignore default, or ambiguous behaviour, allow any existing security like this to be bypassed. It ideally should only happen via some informed decision. But I'll accept I may be the only one to think that's a philosophically bad stance. Regards Kris From ddutt at cisco.com Mon Mar 16 08:49:27 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 16 Mar 2009 08:49:27 -0700 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49BDFD89.4030901@punk.co.nz> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> <49BD5363.6050604@asomi.com> <49BDFD89.4030901@punk.co.nz> Message-ID: <49BE7507.3060606@cisco.com> Kris, You're right about the difference in behavior between an 802.1Q/D bridge and an Rbridge w.r.t. VLANs. I raised this specific issue about six months to a year back. I thought that customers and field engineers would agree with me. I found much to my surprise by polling the field and a few customers that they actually preferred the approach of TRILL. The key advantage of this approach is that VLANs becomes an edge only feature and customers felt that they can get connectivity by only configuring VLANs at the edges and not at every switch. People tend to run into issues because they forgot to enable a VLAN somewhere in the middle. With people tending to larger L2 clouds due to various reasons, this ease of configuration becomes even more important. One way to address the issue of preventing a VLAN from traveling over a specific trunk is to prevent IS-IS from announcing reachability to that VLAN on its links. A switch could also provide local config to prevent locally originated traffic from going over specified links. In short, the issue was raised and discussed before and the current mode found to be more desirable. Thanks for the questions, Dinesh Kris Price wrote: > Hi Caitlin, > > Caitlin Bestler wrote: > >> Kris Price wrote: >> >> >>> I am concerned that TRILL appears to take the view that removing >>> partitions is OK when they are often there for a very good reason. These >>> kinds of partitions are also *very* far from infrequent. >>> >>> +----+ +----+ +----+ >>> | B1 |--dot1Q--| B2 |--dot1Q--| B3 | >>> +----+ +----+ +----+ >>> >>> B1 is in an untrusted location so from a security perspective should be >>> treated as potentially compromised. The administrator wants to control >>> access to VLAN X so disallows VLAN X on the dot1Q trunk between B1 and >>> B2. Rightly or wrongly this is very common. >>> >>> In a situation where B1 and B3 are replaced with RBridges is it possible >>> for B1 to bypass the restriction configured on B2 and access any VLAN on >>> the network? >>> >>> >> I am not following how B2 is supposed to be enforcing a restriction. >> > > Okay, I'm officially seeking a sanity check now. :) > > Using a real world configuration may make what I'm saying clearer, so in > Cisco terms we configure the following on B2: > > interface > switchport trunk encapsulation dot1q > switchport trunk allowed vlan 1,2,3 > switchport mode trunk > > In this configuration the trunk port on B2 is statically configured to > be a member of VLANs 1, 2, and 3. > > If B2 receives a frame that is tagged with VLAN 100 from B1 what does it > do? It should discard it because the trunk port is not a member of VLAN > 100, right? > > If B2 receives a frame, say its a broadcast for an easy example, tagged > with VLAN 100 from an attached end station or B3, it floods it over the > spanning tree, but does not forward it out the trunk port to B1 because > that port is not a member of VLAN 100. > > Replacing B1 and B3 with RBridges, as currently specified, bypasses this > kind of behaviour. > > >> A frame that belongs to VLAN X can only be originated on an endstation >> that belongs to VLAN X, and 802.1Q Bridges enforce that. >> > > Yep. > > >> A frame that belongs to VLAN X can only be delivered to an endstation >> that belongs to VLAN X, and again 802.1Q Bridges enforce that. >> > > Yep. > > 802.1Q says a frame that belongs to VLAN X will only be delivered to a > LAN that is a member of VLAN X. > > >> All of the above is also true for RBridges. >> >> If B1 and B3 both are members of VLAN X then it is appropriate for >> frames originated in B1 to be delivered in B3, no matter what B2 thinks. >> If "VLAN X" in B1 and "VLAN X" in B3 are different networks then they >> should have different VLAN IDs. >> > > I don't think this is true or reflective of 802.1Q, but granted I'm not > an 802 expert. I am going from my practical experience and a quick look > at the 802.1Q Std. > > I think saying they should have different VLAN IDs is missing the point > that we don't trust what comes out of B1. People use this feature of > bridges extensively in practise as a way of securing their networks. > > It certainly might be TRILL's decision to do it this way regardless, but > that decision shouldn't be due to any notion that this feature of 802.1Q > isn't important or widely used. > > >> Even without RBridges, any *new* path between B1 and B3 can bypass >> B2's attempt to partition VLAN X into two VLANs. If you two VLANs >> are distinct, use different VLAN IDs. >> > > 802.1Q covers this point and says you need to consider the full mesh > when configuring such filtering. My experience is that people do this > well, configuring allowed VLANs correctly on all paths. If you do > configure an allowed VLAN on one link, and the spanning tree changes to > a link you forgot to configure it on, that VLAN becomes partitioned. And > vice versa, if you forget to remove it from a link and the topology > changes it might be reconnected. But this is a clear case of > misconfiguration. > > Is it a good security principal for TRILL to reduce the security of the > network to the lowest common denominator? Philosophically it isn't for > me. Not so sure that many would think it is. But maybe I'm out of date. > > At a minimum I think RBridges need to implement administrative filtering > of the inner VLAN if not some other solution. The filtering should be > such that administrators, provided they properly understand TRILL's > behaviour, can mimic their existing security policy. This may be > considered an issue left for implementers to add as a feature, but I > think it'd be very beneficial to be included as a management control in > the spec. Just as 802.1Q seems to deem it fit to define the behaviour in > the spec. Radia suggests the VLAN mapping might enable this so I'll take > a look at that, but if not I think the group should consider putting it > in there. > > Also by design TRILL shouldn't, whether via some automatic > configuration, easy to ignore default, or ambiguous behaviour, allow any > existing security like this to be bypassed. It ideally should only > happen via some informed decision. But I'll accept I may be the only one > to think that's a philosophically bad stance. > > > > Regards > > 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 trill at punk.co.nz Tue Mar 17 23:21:55 2009 From: trill at punk.co.nz (Kris Price) Date: Wed, 18 Mar 2009 19:21:55 +1300 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49BE7507.3060606@cisco.com> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> <49BD5363.6050604@asomi.com> <49BDFD89.4030901@punk.co.nz> <49BE7507.3060606@cisco.com> Message-ID: <49C09303.9020204@punk.co.nz> Thanks Dinesh, I have a clearer picture now. TRILL's behaviour is intentionally more similar to MPLS than 802. But in that case the tight coupling to 802, yet not behaving like 802 makes me uncomfortable. E.g. VLANs shouldn't be called VLANs, being shackled to the C-TAG, etc. As I think I mentioned in another email, I think TRILL could benefit from decoupling this. I've explained some of this, and what I mean by this to Radia, so I want bother repeating it here. If it was an idea worthy of discussion, she can vet it and open it. Regards Kris Dinesh G Dutt wrote: > Kris, > > You're right about the difference in behavior between an 802.1Q/D bridge > and an Rbridge w.r.t. VLANs. I raised this specific issue about six > months to a year back. I thought that customers and field engineers > would agree with me. I found much to my surprise by polling the field > and a few customers that they actually preferred the approach of TRILL. > > The key advantage of this approach is that VLANs becomes an edge only > feature and customers felt that they can get connectivity by only > configuring VLANs at the edges and not at every switch. People tend to > run into issues because they forgot to enable a VLAN somewhere in the > middle. With people tending to larger L2 clouds due to various reasons, > this ease of configuration becomes even more important. > > One way to address the issue of preventing a VLAN from traveling over a > specific trunk is to prevent IS-IS from announcing reachability to that > VLAN on its links. A switch could also provide local config to prevent > locally originated traffic from going over specified links. > > In short, the issue was raised and discussed before and the current mode > found to be more desirable. > > Thanks for the questions, > > Dinesh From harih at cisco.com Thu Mar 19 10:56:24 2009 From: harih at cisco.com (Hari Balasubramanian (harih)) Date: Thu, 19 Mar 2009 10:56:24 -0700 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <49C09303.9020204@punk.co.nz> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> <49BD5363.6050604@asomi.com> <49BDFD89.4030901@punk.co.nz><49BE7507.3060606@cisco.com> <49C09303.9020204@punk.co.nz> Message-ID: <1CCF0A858F9B194FABEA71E9B65EA88B08CA6F45@xmb-sjc-214.amer.cisco.com> Kris, IMO, the entire group benefits from such discussions and seemingly differing viewpoints. I certainly hope that you will post, in this group, either the full or condensed version of the discussions you plan to have with Radia. Thanks, Hari > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Kris Price > Sent: Tuesday, March 17, 2009 11:22 PM > To: Dinesh G Dutt (ddutt) > Cc: rbridge at postel.org > Subject: Re: [rbridge] VLAN hopping: firewall on a stick > > Thanks Dinesh, > > I have a clearer picture now. TRILL's behaviour is > intentionally more similar to MPLS than 802. But in that case > the tight coupling to 802, yet not behaving like 802 makes me > uncomfortable. E.g. VLANs shouldn't be called VLANs, being > shackled to the C-TAG, etc. > > As I think I mentioned in another email, I think TRILL could > benefit from decoupling this. > > I've explained some of this, and what I mean by this to > Radia, so I want bother repeating it here. If it was an idea > worthy of discussion, she can vet it and open it. > > > Regards > > Kris > > > Dinesh G Dutt wrote: > > Kris, > > > > You're right about the difference in behavior between an 802.1Q/D > > bridge and an Rbridge w.r.t. VLANs. I raised this specific > issue about > > six months to a year back. I thought that customers and field > > engineers would agree with me. I found much to my surprise > by polling > > the field and a few customers that they actually preferred > the approach of TRILL. > > > > The key advantage of this approach is that VLANs becomes an > edge only > > feature and customers felt that they can get connectivity by only > > configuring VLANs at the edges and not at every switch. > People tend to > > run into issues because they forgot to enable a VLAN > somewhere in the > > middle. With people tending to larger L2 clouds due to various > > reasons, this ease of configuration becomes even more important. > > > > One way to address the issue of preventing a VLAN from > traveling over > > a specific trunk is to prevent IS-IS from announcing > reachability to > > that VLAN on its links. A switch could also provide local config to > > prevent locally originated traffic from going over specified links. > > > > In short, the issue was raised and discussed before and the current > > mode found to be more desirable. > > > > Thanks for the questions, > > > > Dinesh > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Fri Mar 20 12:02:36 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 20 Mar 2009 12:02:36 -0700 Subject: [rbridge] VLAN hopping: firewall on a stick In-Reply-To: <1CCF0A858F9B194FABEA71E9B65EA88B08CA6F45@xmb-sjc-214.amer.cisco.com> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> <49BD5363.6050604@asomi.com> <49BDFD89.4030901@punk.co.nz> <49BE7507.3060606@cisco.com> <49C09303.9020204@punk.co.nz> <1CCF0A858F9B194FABEA71E9B65EA88B08CA6F45@xmb-sjc-214.amer.cisco.com> Message-ID: <49C3E84C.6050808@sun.com> Of course. Off-line discussion is sometimes useful to keep down the volume on the main list, or if someone is afraid that their question or suggestion might be viewed as "stupid" they might want to try it out on a smaller subset of people first (for instance, I'm very nonscary and it's OK to ask me things or run suggestions by me if someone is reluctant to post to the list), but the intention is of course to make sure that anything substantive gets summarized to the list. Radia Hari Balasubramanian (harih) wrote: > Kris, > > IMO, the entire group benefits from such discussions and seemingly > differing viewpoints. I certainly hope that you will post, in this > group, either the full or condensed version of the discussions you plan > to have with Radia. > > Thanks, > Hari > > From Radia.Perlman at sun.com Fri Mar 20 18:39:55 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 20 Mar 2009 18:39:55 -0700 Subject: [rbridge] With short and long hellos, should we send Hellos twice as often? Message-ID: <49C4456B.1060207@sun.com> A few weeks ago, James Carlson noted that there was a problem because IS-IS pads hellos to "maximum length" and if some RBridge overestimates "maximum", Hellos won't get through, causing bad things to happen. So we decided (and it's in the current version of the spec) to have two kinds of Hellos -- big ones to test max PDU, and little ones to ensure there aren't multiple RBridges thinking they are DRB. What we didn't specify is how often each type of Hello should be sent. Various options: a) alternate big and little Hellos, with the same timer as before b) alternate big and little Hellos, with each having the same timer as before (meaning you'd send twice as many) Radia From trill at punk.co.nz Sat Mar 21 00:23:28 2009 From: trill at punk.co.nz (Kris Price) Date: Sat, 21 Mar 2009 20:23:28 +1300 Subject: [rbridge] Language, structure, and coupling to 802.1Q In-Reply-To: <1CCF0A858F9B194FABEA71E9B65EA88B08CA6F45@xmb-sjc-214.amer.cisco.com> References: <49BAEE8B.8000504@punk.co.nz> <1028365c0903141110y502b2c38na78ef03ada5c6aca@mail.gmail.com> <49BC9F69.8070407@punk.co.nz> <49BD5363.6050604@asomi.com> <49BDFD89.4030901@punk.co.nz><49BE7507.3060606@cisco.com> <49C09303.9020204@punk.co.nz> <1CCF0A858F9B194FABEA71E9B65EA88B08CA6F45@xmb-sjc-214.amer.cisco.com> Message-ID: <49C495F0.2000808@punk.co.nz> Hari Balasubramanian (harih) wrote: > Kris, > > IMO, the entire group benefits from such discussions and seemingly > differing viewpoints. I certainly hope that you will post, in this > group, either the full or condensed version of the discussions you plan > to have with Radia. > > Thanks, > Hari Ok, but so much of this has probably been debated and it is impossible for me to really be aware of every reason for these design choices. So bear in mind these are uninformed perspectives, not criticisms. And, hopefully I don't say something too stupid. :) I'll share my perspectives on three topics. The language of TRILL and whether it is appropriate to use 802 terms. The structure of the TRILL specification and whether it would be better if broken up into generic and 802 specific components. And whether TRILL would be better off (long term) if it did not use 802 header information during forwarding. Few parts to this, it will get long, hopefully I haven't oversimplified. It's a bit fast and rough, go with the flow... etc. The language point I think has merit, the rest maybe not so. *Background* To help you understand why I formed these perspectives I'll give some observations, so you see where I'm coming from. When imagining how to describe TRILL to someone or draw it on a whiteboard, it turns out TRILL has no easy comparisons. So when describing TRILL, some of the things I would have to say are: - TRILL is not a cloud that mimics a bridge as in an MST region. - TRILL is not a cloud that mimics a LAN as in 802.1ad and MPLS L2VPN. - TRILL neither appears as a link or bridge. - A TRILL cloud is formed of new devices called RBridges. - For the most part RBridges try to autoconnect to each other, in a purely greenfields deployment they will, but in almost any other deployment they probably wont without manual configuration. In mixed (existing) environments TRILL must be manually enabled on a different interface/VLAN, or the 802 links between the RBridges reconfigured to permit the require connectivity, etc. Similar to setting up any network layer protocol such as IP or MPLS. - This TRILL cloud mostly terminates BPDUs breaking up STP, though be aware it doesn't always do so, in quite a few cases you need to know when to configure it to tunnel them. In this sense TRILL is similar to a network layer protocol. It does not appear as a single bridge as with an MST region. It is does not appear as a single LAN similar to 802.1ad or L2VPN. - TRILL performs hop-by-hop routing of encapsulated payloads, using a shim like header. And the outer encapsulation header changes at each hop just as a when routing IP or MPLS. - TRILL may run over any layer-2 protocol, but by default configures for 802.3 links and by default sends 802.1Q tagged frames. - The TRILL control-plane protocol runs over the layer-2 links, in the same way they do for MPLS and IP. They are both equally constrained by the link topology. In comparison the 802 protocols (RSTP/MST) are not constrained this way. - Despite this, TRILL calls a LAN that runs 802.1Q a single link. Even if it has no interfaces on some of the VLANs. This is different to a router where the router would see each VLAN as a separate link over which to form adjacencies. To work around this TRILL does a lot of work with Hello's to try to understand the configured VLANs on a link. - Despite being called RBridges, they are more R, and less Bridges. :) - Despite using 802.1D and .1Q as the base, a TRILL cloud does not adhere to the underlying 802.1Q VLAN topology. - A TRILL VLAN and 802.1Q VLAN are different. TRILL maps 802.1Q VLANs at the edge to TRILL VLANs and the behaviour in the TRILL cloud is different. This is because TRILL does not adhere to the 802.1Q VLAN topology. RBridges in the TRILL cloud are all trusted, each has the same ability as any other to join or leave a VLAN. Very much like MPLS VPNs and very much unlike your 802 deployment. Once a frame ingresses at the edge it is free to go anywhere in the TRILL cloud. Think of it just like an MPLS VPN and very much unlike 802. For this reason, understand carefuly any security implications of this different behaviour to your network when you deploy. - Despite this, TRILL re-purposes the 802.1Q C-TAG in the encapsulated frame for identifying which TRILL VLAN a frame is in. - TRILL does kindly detect 802.1Q VLAN mapping (a non standard feature of 802.1Q) so that the auto-mapping of 802.1Q VLANs at the edge to TRILL VLANs is consistent across the TRILL cloud. This is not 802 like, it is a courtesy to make the auto-mapping work better. - Your end stations are going to see a TRILL connected bridged LAN as just a bridged LAN. Bridges wont. They will see RBridges as routers. - RBridges learn from the data-plane at the edge only. Not in the core like 802.1Q bridges do. RBridges also optionally learn from the control-plane. *Language* Could the language and terms used by TRILL be ambiguous or misleading to the people who haven't developed it but are going to work with it? Would it be better to distinguish TRILL behaviour from 802.1Q behaviour? Whenever TRILL is selective in its interpretation and implementation of an 802 standard, doesn't it end up creating something new? And so therefore shouldn't it be distinguished with a different name? An obvious example, given my recent question, is the use of the term VLAN. It's my opinion that an 802.1Q VLAN and a TRILL VLAN are very different (as described above). TRILL's definition is more like an MPLS VPN in its membership, and unlike anything else in its behaviour, and I feel it is ambiguous to call it a VLAN. People (like myself) may wrongly expect certain behaviours from it unless it is made distinct. Especially since TRILL talks about 802.1Q a lot. Would it be better if a TRILL VLAN were called something different that reflected what it did. And in the draft describe as an automatic mapping between an 802.1Q VLAN and a TRILL VLAN. Perhaps what TRILL creates is a kind of virtual multi-access link, VLink, or Routed LAN, RLAN... *shrug* This applies to all 802 standards. Say TRILL implements 802.1ad one day, but a Provider VLAN doesn't tunnel STP in the TRILL version, then it should be called something else. And so forth. 802.1au but handles it differently, call it something else, because it's a different implementation. *Structure* Could TRILL be defined as a generic mechanism in a base document, with modular extensions added to provide compatibility for the various 802 standards that TRILL wants to support? And for that matter extensions for TRILLs own standards should it simply diverge from 802 over time. And would this be better? So perhaps the architecture of TRILL looks something like this, which is roughly how I decipher it based on my reading and peoples explanations. +--------+ +---------+ +-----+ +--------------------------------+ Software | | 802.1Q | | 802.1ad | | ... | | +--------------------------------+ Hardware | | 802.1Q | | 802.1ad | | ... | | +--------------------------------+ +--------+-+---------+-+-----+ Routing | TRILL | +----------------------------+ Link | 802.3, PPP, etc. | +----------------------------+ Link: It just so happens at the moment it is tightly specified for 802.3 in the draft. But TRILL could use other layer-2 link types. So in a generic base TRILL it may say something to the effect of TRILL is enabled by default on all 802 ports on an RBridge... The base TRILL wouldn't specify VLAN discovery for instance, just base adjacency formation by sending untagged Hellos (configurable to be in a VLAN or whatever, but this base case would mimic basic 802.1D bridges). Routing: TRILL routes frames over any link types. There is a hardware component to the processing of the generic TRILL header and that hands off processing for the 802 specific fields in the encapsulated 802 header to those specific hardware parts. This part I would've thought was able to be fairly generic to many 802 Stds, the hand of based on the ethertype immediately following the TRILL header. If it doesn't understand the ethertype, it just keeps forwarding the header to the egress which hopefully does. Hardware: Plugged into generic TRILL is the hardware layers that recieve and process ingress/egress 802 frames. And that also process the specific 802 parts of the encapsulated headers for the TRILL routing decisions. At the moment TRILL is tightly coupled to 802.1Q and processing adding/removing/changing the C-TAG of the encapsulated header (good idea or not). But it could just as easily (it seems) be extended to include hardware that processes S-TAGs in the case of 802.1ad, and so on. This would be in the 802.1Q adaptation... Software: And of course there is the software aspect of providing that support. Such as forwarding reachability information. In the current case of 802.1Q doing as much auto-conf as possible, VLAN discovery, etc. To test my understanding let me consider how TRILL would handle an 802 standard it didn't understand, e.g. 802.1ad, and how support would be added. If TRILL recieves an 802.1ad frame on a port it will not recognise the ethertype and so will treat it as an untagged frame. Hence TRILL will instert another C-TAG before the S-TAG/C-TAG already in the frame and route it as if it were an ordinary untagged frame from an end station. Just as it would any new 802 standards that come out because it is not possible for TRILL to know what those are. So to make TRILL do something useful with 802.1ad before it has any implemented compatibility, provided the RBridges supported it, the engineer could configure RBridge ports like they were an L2VPN, into a particular C-VLAN (e.g. 100). Now the 802.1ad bridges at either edge of the TRILL cloud can forward frames to each other. At least I think this will work, it seems ugly, but I think it works. To make TRILL do something intelligent with 802.1ad, TRILL would define a addition to the draft. RBridges would impliment new 802.1ad layer to recieve and process 802.1ad tagged frames. New extensions would be made to IS-IS to distribute relevant 802.1ad information. And new port modes and such would be defined. Now an RBridge could have a port configured as an 802.1ad port, and recieve C-TAGged frames from customer LAN, apply an S-TAG, and all intermediate RBridges would have to be swapped out to understand this S-TAG in the inner encapsulated 802 header. Then they'd use that for their forwarding decisions. When one of these reaches an RBridge though that doesn't understand it, because it wasn't replaced with the new version, it get's handled as untagged and put in the native VLAN with a C-TAG before the S-TAG again, lost in the native TRILL VLAN where it goes nobody knows, or something like that. That seems a little messy but maybe there's some way around it. *Coupling to 802.1Q* Following from all of that. And this is where I get a bit out there and it's probably full of many flaws that aren't obvious to me, and I'm likely being too quick to share. :) If TRILL is going to be selective in how it interprets and implements 802 standards, wouldn't it be safer, cleaner, and more flexible to design equivalent adaptations that are specific to TRILL and its customer's needs? One day, if successful, most networks will be entirely TRILL, isn't that the aim? Simpler is better and my perspective is that simpler (for its target customers) would be something more like MPLS. Define a new stand-alone forwarding method that isn't dependant on understanding the payload. For example: Forget the C-TAG and processing of encapsulated 802 fields at each hop. Quite clearly layer 802 ontop of TRILL rather than the hybrid. Define a kind of generic TRILL base protocol with a header that includes a CoS field and some kind of VPN ID field (whether you call it VLAN, RLAN, VLink, etc.). This VPN ID is used to form a TRILL virtual bridge or TRILL virtual link or something. Then define adaptations of 802 standards for TRILL and in those adaptations the mapping between the TRILL/802 equivalents. Perhaps one of these "VPNs" in the base protocol would behave as a LAN for all protocols it does not recognise, but terminate and interact with those 802 protocols it does recognise. In this way behave transparently to any new 802 standard that comes along. Isn't this kind of layered encapsulation cleaner? Especially given TRILL's behaviour is closest to a network layer protocol... Of course this has been discussed (I imagine). But it makes more sense and is simpler to me and you asked me to share. :) Regards Kris From d3e3e3 at gmail.com Tue Mar 24 16:16:42 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 24 Mar 2009 19:16:42 -0400 Subject: [rbridge] All TRILL presentations have been uploaded Message-ID: <1028365c0903241616j1c5a2ae4n7fa179570f0efc3f@mail.gmail.com> The updated TRILL presentations actually shown at the meeting today have been uploaded to the Meeting Materials page at https://datatracker.ietf.org/meeting/74/materials.html Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Radia.Perlman at sun.com Wed Mar 25 09:57:41 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 25 Mar 2009 09:57:41 -0700 Subject: [rbridge] Proposed compromise for short/long hellos Message-ID: <49CA6285.9000402@sun.com> After listening to the discussion at the meeting, and talking to some people in the hall, I hope this might be palatable to everyone. a) have only one type of Hello: the original type, but say in the spec that Hellos MUST NOT be padded. Also mention a maximum size, and say that this might limit really really really creative appointments of lots of appointed forwarders for lots of VLANs. b) have another type of mechanism, perhaps called "MTU discovery", which would be a pairwise protocol between two RBridges R1 and R2, where R1 sends a padded message, and R2 acks it if R2 received it. This would be an optional protocol specified in a separate document c) we'd add a bit to the Hello saying "I support the MTU discovery protocol" From Radia.Perlman at sun.com Wed Mar 25 10:12:20 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 25 Mar 2009 10:12:20 -0700 Subject: [rbridge] multiple nicknames in an LSP? Message-ID: <49CA65F4.50704@sun.com> Someone asked me about whether it would be possible for an RBridge to request more than one nickname for itself. We could, I suppose, put in the encoding into the Hello, perhaps by changing the format of the TLV for "nickname", or just inherently from the length of the TLV, allowing a list of nicknames. So...the question is -- why might we want multiple nicknames? Some reasons people have mentioned to me I'm not sure I understand, so people can add them. Other layer 2-ish protocols play tricks with having multiple destination addresses, I think for allowing multiple routes to the same destination. I'm not sure those apply to TRILL One reason I do understand, but am not sure I understand how to accomplish it, is to allow multiple trees rooted at the same node R1, with the hope that the two trees can look different (for load sharing) and yet both be shortest paths from R1. If we had two nicknames for R1 then R1 can request some multicast packets travel on each of the trees. It's harder than just having the nicknames, because the way the spec reads today, exactly the same tree would be computed. I'd have to go thinking about this some more, and I think it would be an excellent research problem for a student -- how to calculate, without configuration, maximally load sharing'ness of trees rooted at the same place, or choosing which nodes to root trees on, etc. But here's a quick suggestion, just to show it's somewhat possible: Use the root nickname (or root ID, or some other field we can add to the LSP as a modifier of the nickname) as a way of doing the tie-breaker. so for instance, R1 can say "I want nicknames N1 and N2. I'd like the tiebreaker salt to be x for N1 and y for N2". Then when the tree rooted at N1 is being computed (by any RBridge), rather than choosing the ID of the parent as the tie-breaker (as it is today I think), use some sort of function of the salt, so that the tie-breaker would be different for the N1 tree than the N2 tree. Radia From ddutt at cisco.com Wed Mar 25 10:15:43 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 25 Mar 2009 10:15:43 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA6285.9000402@sun.com> References: <49CA6285.9000402@sun.com> Message-ID: <49CA66BF.3060402@cisco.com> I like this proposal, Dinesh Radia Perlman wrote: > After listening to the discussion at the meeting, and talking to some > people in the hall, I hope > this might be palatable to everyone. > > a) have only one type of Hello: the original type, but say in the spec > that Hellos > MUST NOT be padded. Also mention a maximum size, and say that this might > limit really really really creative appointments of lots of appointed > forwarders for lots > of VLANs. > > b) have another type of mechanism, perhaps called "MTU discovery", which > would > be a pairwise protocol between two RBridges R1 and R2, where R1 sends a > padded > message, and R2 acks it if R2 received it. This would be an optional > protocol specified > in a separate document > > c) we'd add a bit to the Hello saying "I support the MTU discovery protocol" > _______________________________________________ > 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 eric.gray at ericsson.com Wed Mar 25 10:57:16 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 25 Mar 2009 12:57:16 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA6285.9000402@sun.com> References: <49CA6285.9000402@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04DD0EC9@eusrcmw721.eamcs.ericsson.se> Radia, I like the outline of a compromise you propose, though I suspect that this is pretty much the opposite of what the IS-IS folks are very likely to find acceptable. Assuming we go with your proposal, I would suggest that we should be more precise in mentioning a maximum size. I would suggest something along the lines of: must be shorter than the lesser of the maximum presumed for the , or a configurable maximum value. The one reservation people may have is that what was discussed in the meeting was more along the lines of - 1) let's have one type of (IS-IS based) hello. 2) let's define a separate message type - if necessary (as it seems clear that it is) - to address this issue. (so far, consistent with your suggestion) 3) The hello message needs to ensure that the maximum packet size each end assumes is correct, since (one of) the purpose(s) of these PDUs (in IS-IS) is to determine whether an adjacency should be formed. 4) This means that the separate message type would need to address the issue with making sure that topologically adjacent RBridges are, in fact, discovered irrespective of the appropriateness of making them adjacent peers. All of that said, however, I think there was a clear sense that the important objective in the RBridge case is to protect against loop formation - which is unavoidable in the event that RBridge topological adjacencies are not discovered. Prevention of blackholing a subset of forwarded data because of excessive size is much less of a concern in this context. Hence the important message to define first is the one that allows this discovery of topologically adjacent RBridges. Since we have done all of this work to define how to do this using IS-IS, and the problem that arises is the padding of IS-IS hello messages, the simplest approach is to eliminate this padding. I agree with the proposal, otherwise, as you've proposed it. -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Wednesday, March 25, 2009 12:58 PM To: TRILL/RBridge Working Group Subject: [rbridge] Proposed compromise for short/long hellos After listening to the discussion at the meeting, and talking to some people in the hall, I hope this might be palatable to everyone. a) have only one type of Hello: the original type, but say in the spec that Hellos MUST NOT be padded. Also mention a maximum size, and say that this might limit really really really creative appointments of lots of appointed forwarders for lots of VLANs. b) have another type of mechanism, perhaps called "MTU discovery", which would be a pairwise protocol between two RBridges R1 and R2, where R1 sends a padded message, and R2 acks it if R2 received it. This would be an optional protocol specified in a separate document c) we'd add a bit to the Hello saying "I support the MTU discovery protocol" _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From dwfedyk at nortel.com Wed Mar 25 11:03:34 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 25 Mar 2009 14:03:34 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA6285.9000402@sun.com> References: <49CA6285.9000402@sun.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> Hi Radia I'm still not convinced you should be changing IS-IS. The root cause of the issue is RBridge forms adjacencies on links with non direct neighbors. It also make forwarding assumptions when it does not detect neighbors. This is different behavior from every other system that I know of. If RBridge defaulted to STP behavior as was pointed out by James then no modification to IS-IS would be needed plus the issue of looping packets would be nipped in the bud. You solution below only detect the problem you still need to assume an appropriate forwarding behavior and this is STP as a default. Regards, Don -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Wednesday, March 25, 2009 12:58 PM To: TRILL/RBridge Working Group Subject: [rbridge] Proposed compromise for short/long hellos After listening to the discussion at the meeting, and talking to some people in the hall, I hope this might be palatable to everyone. a) have only one type of Hello: the original type, but say in the spec that Hellos MUST NOT be padded. Also mention a maximum size, and say that this might limit really really really creative appointments of lots of appointed forwarders for lots of VLANs. b) have another type of mechanism, perhaps called "MTU discovery", which would be a pairwise protocol between two RBridges R1 and R2, where R1 sends a padded message, and R2 acks it if R2 received it. This would be an optional protocol specified in a separate document c) we'd add a bit to the Hello saying "I support the MTU discovery protocol" _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Wed Mar 25 12:08:22 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 25 Mar 2009 12:08:22 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> References: <49CA6285.9000402@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> Message-ID: <49CA8126.4030909@sun.com> I assume what you mean by "changing IS-IS" is the phrase "MUST NOT" pad hellos? Or are you talking about adding a bit "I support the (to be specified) MTU discovery protocol"? (or both perhaps). Anyway, when you say "as was pointed out by James", I don't remember what comment you are referring to, not sure which "James" we are talking about (James Carlson?) and don't know what it means to "default to STP behavior". So can you just be specific about the protocol behavior you are proposing, without referring to other things? One thing you might be referring to is a proposal that I liked, and was in some version of the spec, but got shot down by the WG (not sure I remember why), which is that the DRB election be the spanning tree election, and you are DRB if and only if you manage to become root of the bridge spanning tree. But that got shot down, and there would have needed to be another type of hello anyway in order to do the IS-IS stuff, like giving the pseudonode a name. But mostly, I just didn't understand your message... Thanks, Radia Don Fedyk wrote: > Hi Radia > > I'm still not convinced you should be changing IS-IS. > > The root cause of the issue is RBridge forms adjacencies on links with > non direct neighbors. It also make forwarding assumptions when it does > not detect neighbors. > > This is different behavior from every other system that I know of. > > If RBridge defaulted to STP behavior as was pointed out by James then no > modification to IS-IS would be needed plus the issue of looping packets > would be nipped in the bud. You solution below only detect the problem > you still need to assume an appropriate forwarding behavior and this is > STP as a default. > > Regards, > Don > > > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, March 25, 2009 12:58 PM > To: TRILL/RBridge Working Group > Subject: [rbridge] Proposed compromise for short/long hellos > > After listening to the discussion at the meeting, and talking to some > people in the hall, I hope > this might be palatable to everyone. > > a) have only one type of Hello: the original type, but say in the spec > that Hellos > MUST NOT be padded. Also mention a maximum size, and say that this might > limit really really really creative appointments of lots of appointed > forwarders for lots > of VLANs. > > b) have another type of mechanism, perhaps called "MTU discovery", which > > would > be a pairwise protocol between two RBridges R1 and R2, where R1 sends a > padded > message, and R2 acks it if R2 received it. This would be an optional > protocol specified > in a separate document > > c) we'd add a bit to the Hello saying "I support the MTU discovery > protocol" > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From ddutt at cisco.com Wed Mar 25 12:39:25 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 25 Mar 2009 12:39:25 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> References: <49CA6285.9000402@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> Message-ID: <49CA886D.9050209@cisco.com> Don, Don Fedyk wrote: > Hi Radia > > I'm still not convinced you should be changing IS-IS. > > The root cause of the issue is RBridge forms adjacencies on links with > non direct neighbors. It also make forwarding assumptions when it does > not detect neighbors. > > This is different behavior from every other system that I know of. > L3 routers work exactly this way i.e. form adj on links with non-direct neighbors. Dinesh > If RBridge defaulted to STP behavior as was pointed out by James then no > modification to IS-IS would be needed plus the issue of looping packets > would be nipped in the bud. You solution below only detect the problem > you still need to assume an appropriate forwarding behavior and this is > STP as a default. > > Regards, > Don > > > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, March 25, 2009 12:58 PM > To: TRILL/RBridge Working Group > Subject: [rbridge] Proposed compromise for short/long hellos > > After listening to the discussion at the meeting, and talking to some > people in the hall, I hope > this might be palatable to everyone. > > a) have only one type of Hello: the original type, but say in the spec > that Hellos > MUST NOT be padded. Also mention a maximum size, and say that this might > limit really really really creative appointments of lots of appointed > forwarders for lots > of VLANs. > > b) have another type of mechanism, perhaps called "MTU discovery", which > > would > be a pairwise protocol between two RBridges R1 and R2, where R1 sends a > padded > message, and R2 acks it if R2 received it. This would be an optional > protocol specified > in a separate document > > c) we'd add a bit to the Hello saying "I support the MTU discovery > protocol" > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From dwfedyk at nortel.com Wed Mar 25 13:13:37 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 25 Mar 2009 16:13:37 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA886D.9050209@cisco.com> References: <49CA6285.9000402@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA886D.9050209@cisco.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41923085E@zrtphxm2.corp.nortel.com> > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Wednesday, March 25, 2009 3:39 PM > To: Fedyk, Don (BL60:1A00) > Cc: Radia Perlman; TRILL/RBridge Working Group > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Don, > > Don Fedyk wrote: > > Hi Radia > > > > I'm still not convinced you should be changing IS-IS. > > > > The root cause of the issue is RBridge forms adjacencies on > links with > > non direct neighbors. It also make forwarding assumptions > when it does > > not detect neighbors. > > > > This is different behavior from every other system that I know of. > > > L3 routers work exactly this way i.e. form adj on links with > non-direct > neighbors. You are missing the point. They don't forward data packets without knowing about their neighbors. Don > > Dinesh > > If RBridge defaulted to STP behavior as was pointed out by > James then no > > modification to IS-IS would be needed plus the issue of > looping packets > > would be nipped in the bud. You solution below only detect > the problem > > you still need to assume an appropriate forwarding behavior > and this is > > STP as a default. > > > > Regards, > > Don > > > > > > > > -----Original Message----- > > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On > > Behalf Of Radia Perlman > > Sent: Wednesday, March 25, 2009 12:58 PM > > To: TRILL/RBridge Working Group > > Subject: [rbridge] Proposed compromise for short/long hellos > > > > After listening to the discussion at the meeting, and > talking to some > > people in the hall, I hope > > this might be palatable to everyone. > > > > a) have only one type of Hello: the original type, but say > in the spec > > that Hellos > > MUST NOT be padded. Also mention a maximum size, and say > that this might > > limit really really really creative appointments of lots of > appointed > > forwarders for lots > > of VLANs. > > > > b) have another type of mechanism, perhaps called "MTU > discovery", which > > > > would > > be a pairwise protocol between two RBridges R1 and R2, > where R1 sends a > > padded > > message, and R2 acks it if R2 received it. This would be an > optional > > protocol specified > > in a separate document > > > > c) we'd add a bit to the Hello saying "I support the MTU discovery > > protocol" > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > -- > We make our world significant by the courage of our questions and by > the depth of our answers. - Carl Sagan > > From dwfedyk at nortel.com Wed Mar 25 13:31:33 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 25 Mar 2009 16:31:33 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA8126.4030909@sun.com> References: <49CA6285.9000402@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA8126.4030909@sun.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4192308AE@zrtphxm2.corp.nortel.com> Hi Radia > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Wednesday, March 25, 2009 3:08 PM > To: Fedyk, Don (BL60:1A00) > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > I assume what you mean by "changing IS-IS" is the phrase > "MUST NOT" pad > hellos? > Or are you talking about adding a bit "I support the (to be > specified) > MTU discovery protocol"? > (or both perhaps). Don't change the behavior applies to all of the above. The point is you are only using IS-IS as an MTU mismatch detection mechanism and that does not address the root cause of the problem. IS-IS currently protects its own MTU integrity and that is all that is required. > > Anyway, when you say "as was pointed out by James", I don't remember > what comment you are > referring to, not sure which "James" we are talking about (James > Carlson?) and don't know what > it means to "default to STP behavior". So can you just be > specific about > the protocol behavior you > are proposing, without referring to other things? On Tuesday February 12th 2009 James Carlson wrote: Thread [rbridge] potential L2 forwarding loop issue in RBridges http://www.postel.org/pipermail/rbridge/2009-February/003238.html " B. Require RBridge implementations to include STP as well. However, the STP portion in this solution has (by design) no effect on TRILL itself. Instead, we use STP's link "forwarding" state to gate the AF behavior in the following ways: i. When STP reports that the link is not in "forwarding" state, we refuse to become AF for any VLAN. We become AF only if STP reports "forwarding" for the link *and* the DRB appoints us to do it. ii. When encapsulating from or decapsulating to native format, examine both the AF flag and the STP state. Discard the packet if not AF or if STP state is not "forwarding." " > > One thing you might be referring to is a proposal that I > liked, and was > in some version of the spec, but > got shot down by the WG (not sure I remember why), which is > that the DRB > election be the > spanning tree election, and you are DRB if and only if you manage to > become root of the bridge > spanning tree. But that got shot down, and there would have > needed to be > another type of hello > anyway in order to do the IS-IS stuff, like giving the > pseudonode a name. > I think defaulting to STP behavior of some form when you are connected to Bridges is a necessary operation from where I stand. > But mostly, I just didn't understand your message... In summary: Don't change IS-IS because it is not an IS-IS issue. It is an RBridge forwarding behavior that needs to be addressed within RBridge design itself. Once you address that issue IS-IS will work with padded MTUs just fine. Regards, Don > > Thanks, > > Radia > > From james.d.carlson at Sun.COM Wed Mar 25 12:51:38 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Wed, 25 Mar 2009 15:51:38 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA8126.4030909@sun.com> References: <49CA6285.9000402@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA8126.4030909@sun.com> Message-ID: <18890.35658.965990.541507@gargle.gargle.HOWL> Radia Perlman writes: > I assume what you mean by "changing IS-IS" is the phrase "MUST NOT" pad > hellos? > Or are you talking about adding a bit "I support the (to be specified) > MTU discovery protocol"? > (or both perhaps). Yes, I think that's what was meant. > Anyway, when you say "as was pointed out by James", I don't remember > what comment you are > referring to, not sure which "James" we are talking about (James > Carlson?) and don't know what > it means to "default to STP behavior". So can you just be specific about > the protocol behavior you > are proposing, without referring to other things? Just to be clear: I was only trying to brainstorm possible solutions to the MTU-caused problem that I had seen, and running STP in parallel with TRILL was one of the possible solutions. I quickly backed away from it when several helpful folks pointed out that it was at best untenable and at worst didn't actually fix the problem. I think that having protective Hello messages is the best answer we can have here. -- 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 dwfedyk at nortel.com Wed Mar 25 13:49:28 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 25 Mar 2009 16:49:28 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18890.35658.965990.541507@gargle.gargle.HOWL> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com><49CA8126.4030909@sun.com> <18890.35658.965990.541507@gargle.gargle.HOWL> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA419230914@zrtphxm2.corp.nortel.com> Hi James. > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Wednesday, March 25, 2009 3:52 PM > To: Radia Perlman > Cc: Fedyk, Don (BL60:1A00); TRILL/RBridge Working Group > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Radia Perlman writes: > > I assume what you mean by "changing IS-IS" is the phrase > "MUST NOT" pad > > hellos? > > Or are you talking about adding a bit "I support the (to be > specified) > > MTU discovery protocol"? > > (or both perhaps). > > Yes, I think that's what was meant. > > > Anyway, when you say "as was pointed out by James", I don't > remember > > what comment you are > > referring to, not sure which "James" we are talking about (James > > Carlson?) and don't know what > > it means to "default to STP behavior". So can you just be > specific about > > the protocol behavior you > > are proposing, without referring to other things? > > Just to be clear: I was only trying to brainstorm possible solutions > to the MTU-caused problem that I had seen, and running STP in parallel > with TRILL was one of the possible solutions. I quickly backed away > from it when several helpful folks pointed out that it was at best > untenable and at worst didn't actually fix the problem. Understood why you proposed it. Why does it not fix the problem? STP Bridge default behavior is the safe option and RBridge is promoted to RBridge forwarding only when it detects other RBridges. Regards, Don > > I think that having protective Hello messages is the best answer we > can have here. > > -- > 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 anoop at brocade.com Wed Mar 25 14:01:51 2009 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 25 Mar 2009 14:01:51 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA8126.4030909@sun.com> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA8126.4030909@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Wednesday, March 25, 2009 12:08 PM > To: Don Fedyk > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Anyway, when you say "as was pointed out by James", I don't remember > what comment you are > referring to, not sure which "James" we are talking about (James > Carlson?) and don't know what > it means to "default to STP behavior". So can you just be > specific about > the protocol behavior you > are proposing, without referring to other things? I think he's referring to one of the options discussed which was to have a big spanning tree that spanned the entire TRILL campus and all of the bridge islands that might need to be interconnected by TRILL. (Don, please clarify if I am misrepresenting what you wanted to say.) However, I disagree that that is a good approach because we will be stuck with dealing with STP convergence times before we can do anything useful in the TRILL network. STP can be very fast when the network is small and failures are fairly localized, but it gets worse as the network gets bigger. Anoop From erik.nordmark at sun.com Wed Mar 25 17:27:57 2009 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 25 Mar 2009 17:27:57 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41923085E@zrtphxm2.corp.nortel.com> References: <49CA6285.9000402@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA886D.9050209@cisco.com> <34B3EAA5B3066A42914D28C5ECF5FEA41923085E@zrtphxm2.corp.nortel.com> Message-ID: <49CACC0D.60404@sun.com> Don Fedyk wrote: > > >> -----Original Message----- >> From: Dinesh G Dutt [mailto:ddutt at cisco.com] >> Sent: Wednesday, March 25, 2009 3:39 PM >> To: Fedyk, Don (BL60:1A00) >> Cc: Radia Perlman; TRILL/RBridge Working Group >> Subject: Re: [rbridge] Proposed compromise for short/long hellos >> >> Don, >> >> Don Fedyk wrote: >>> Hi Radia >>> >>> I'm still not convinced you should be changing IS-IS. >>> >>> The root cause of the issue is RBridge forms adjacencies on >> links with >>> non direct neighbors. It also make forwarding assumptions >> when it does >>> not detect neighbors. >>> >>> This is different behavior from every other system that I know of. >>> >> L3 routers work exactly this way i.e. form adj on links with >> non-direct >> neighbors. > > You are missing the point. They don't forward data packets without > knowing about their neighbors. IP routers do that for the last hop since they do not have an adjencency with all the hosts. That is why IP routers need to elect a designated router for multicast traffic; only one IP router can forward multicast packets to and from an IP subnet. The TRILL case seems quite analogous; we need to elect a DRB to avoid multi-destination frames being decapsulated by one RBridge onto the link being picked and encapsulated by another RBridge. Erik From d3e3e3 at gmail.com Wed Mar 25 18:42:50 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 25 Mar 2009 21:42:50 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA6285.9000402@sun.com> References: <49CA6285.9000402@sun.com> Message-ID: <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> The decision not to default to STP behavior was made by the working group some time ago. Are there others who want to post an opinion on Radia's proposal? We would like to close this expeditiously. Thanks, Donald On Wed, Mar 25, 2009 at 12:57 PM, Radia Perlman wrote: > After listening to the discussion at the meeting, and talking to some > people in the hall, I hope > this might be palatable to everyone. > > a) have only one type of Hello: the original type, but say in the spec > that Hellos > MUST NOT be padded. Also mention a maximum size, and say that this might > limit really really really creative appointments of lots of appointed > forwarders for lots > of VLANs. > > b) have another type of mechanism, perhaps called "MTU discovery", which > would > be a pairwise protocol between two RBridges R1 and R2, where R1 sends a > padded > message, and R2 acks it if R2 received it. This would be an optional > protocol specified > in a separate document > > c) we'd add a bit to the Hello saying "I support the MTU discovery protocol" > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From dwfedyk at nortel.com Wed Mar 25 19:30:59 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 25 Mar 2009 22:30:59 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA8126.4030909@sun.com> <4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA419230B0C@zrtphxm2.corp.nortel.com> Hi Anoop > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > > I think he's referring to one of the options > discussed which was to have a big spanning tree > that spanned the entire TRILL campus and all of the > bridge islands that might need to be interconnected > by TRILL. > > (Don, please clarify if I am misrepresenting > what you wanted to say.) First I want to point out this is supposed to be an exception. MTUs don't change by themselves but you may find you plug in some equipment where you have an MTU problem. I'm thinking that Shortest Path Bridging can handle this on a neighbor basis so why can't RBridge? Perhaps we should list the cases this is an issue. James' (Jim's) example was rather straight forward and I could not see why RBridge would not behave like a bridge. But then you have a LAN with some RBridges and some Bridges and I can't say I know all the permutations. Does this create a big bridged network? That was not my intention but RBridges do link multiple spanning trees and there is a perhaps a danger defaulting to anything other than a stub on a link if there is a problem. Aside speaking with Radia it occurred to me Radia's proposals were to adapt to smaller MTU on a link. I believe you may be able to engineer a network to a lower (or larger) MTU size but my understanding is all IS-IS routers are expected to have the same ReceiveLSPBufferSize which must be lower or equal than MTU anywhere which means adapting on the fly for a specific link is probably not a good idea. So I'm not comfortable with changing the way MTUs I found this thread on the subject. http://www.ietf.org/mail-archive/web/isis-update/current/msg00072.html Regards, Don > > However, I disagree that that is a good approach > because we will be stuck with dealing with STP > convergence times before we can do anything useful > in the TRILL network. STP can be very fast when > the network is small and failures are fairly localized, > but it gets worse as the network gets bigger. > > Anoop > From dwfedyk at nortel.com Wed Mar 25 19:31:35 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 25 Mar 2009 22:31:35 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CACC0D.60404@sun.com> References: <49CA6285.9000402@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA886D.9050209@cisco.com> <34B3EAA5B3066A42914D28C5ECF5FEA41923085E@zrtphxm2.corp.nortel.com> <49CACC0D.60404@sun.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA419230B0D@zrtphxm2.corp.nortel.com> Hi Erik > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark at sun.com] > Sent: Wednesday, March 25, 2009 8:28 PM > To: Fedyk, Don (BL60:1A00) > Cc: Dinesh G Dutt; TRILL/RBridge Working Group; Radia Perlman > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Don Fedyk wrote: > > > > > >> -----Original Message----- > >> From: Dinesh G Dutt [mailto:ddutt at cisco.com] > >> Sent: Wednesday, March 25, 2009 3:39 PM > >> To: Fedyk, Don (BL60:1A00) > >> Cc: Radia Perlman; TRILL/RBridge Working Group > >> Subject: Re: [rbridge] Proposed compromise for short/long hellos > >> > >> Don, > >> > >> Don Fedyk wrote: > >>> Hi Radia > >>> > >>> I'm still not convinced you should be changing IS-IS. > >>> > >>> The root cause of the issue is RBridge forms adjacencies on > >> links with > >>> non direct neighbors. It also make forwarding assumptions > >> when it does > >>> not detect neighbors. > >>> > >>> This is different behavior from every other system that I > know of. > >>> > >> L3 routers work exactly this way i.e. form adj on links with > >> non-direct > >> neighbors. > > > > You are missing the point. They don't forward data packets without > > knowing about their neighbors. > > IP routers do that for the last hop since they do not have an > adjencency > with all the hosts. That is why IP routers need to elect a designated > router for multicast traffic; only one IP router can forward > multicast > packets to and from an IP subnet. > > The TRILL case seems quite analogous; we need to elect a DRB to avoid > multi-destination frames being decapsulated by one RBridge > onto the link > being picked and encapsulated by another RBridge. You may be right here. Radia mentioned a similar thing. Don > > Erik > From ayabaner at cisco.com Wed Mar 25 20:36:00 2009 From: ayabaner at cisco.com (Ayan Banerjee) Date: Wed, 25 Mar 2009 20:36:00 -0700 Subject: [rbridge] multiple nicknames in an LSP? In-Reply-To: <49CA65F4.50704@sun.com> Message-ID: Radia, Please see inline. Thanks, Ayan On 3/25/09 10:12 AM, "Radia Perlman" wrote: > Someone asked me about whether it would be possible for an RBridge to > request more > than one nickname for itself. We could, I suppose, put in the encoding > into the Hello, perhaps > by changing the format of the TLV for "nickname", or just inherently > from the length of the TLV, > allowing a list of nicknames. > > So...the question is -- why might we want multiple nicknames? > > Some reasons people have mentioned to me I'm not sure I understand, so > people can add them. > Other layer 2-ish protocols play tricks with having multiple destination > addresses, I think for > allowing multiple routes to the same destination. I'm not sure those > apply to TRILL > > One reason I do understand, but am not sure I understand how to > accomplish it, is to allow > multiple trees rooted at the same node R1, with the hope that the two > trees can look different (for load > sharing) and yet both be shortest paths from R1. If we had two nicknames > for R1 then R1 can > request some multicast packets travel on each of the trees. > > It's harder than just having the nicknames, because the way the spec > reads today, exactly the same > tree would be computed. > > I'd have to go thinking about this some more, and I think it would be an > excellent research problem for > a student -- how to calculate, without configuration, maximally load > sharing'ness of trees rooted at the same > place, or choosing which nodes to root trees on, etc. > > But here's a quick suggestion, just to show it's somewhat possible: > > Use the root nickname (or root ID, or some other field we can add to the > LSP as a modifier > of the nickname) as a way of doing the tie-breaker. > > so for instance, R1 can say "I want nicknames N1 and N2. I'd like the > tiebreaker salt to be x for N1 > and y for N2". > > Then when the tree rooted at N1 is being computed (by any RBridge), > rather than choosing the > ID of the parent as the tie-breaker (as it is today I think), use some > sort of function of > the salt, so that the tie-breaker would be different for the N1 tree > than the N2 tree. > [AB] It seems to me that given we have roots tied to graph-ids, we could associate N1 to a graph-id and that makes it "visible" only on that graph-id. Hence, other nodes computing their SPFs will see N1 only in graph-1 and N2 only in graph-2. I am guessing that you are essentially saying the same above, though I do not quite follow the tie-breaker. If it is explicit, node R1 can enforce multicast packets on trees that it desires. > Radia > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From trill at punk.co.nz Wed Mar 25 21:13:15 2009 From: trill at punk.co.nz (Kris Price) Date: Thu, 26 Mar 2009 17:13:15 +1300 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CA6285.9000402@sun.com> References: <49CA6285.9000402@sun.com> Message-ID: <49CB00DB.9020902@punk.co.nz> Radia Perlman wrote: > After listening to the discussion at the meeting, and talking to some > people in the hall, I hope > this might be palatable to everyone. > > a) have only one type of Hello: the original type, but say in the spec > that Hellos > MUST NOT be padded. Also mention a maximum size, and say that this might > limit really really really creative appointments of lots of appointed > forwarders for lots > of VLANs. Seems the only real solution if you want to still form adjacencies on a link and transmit on them without forming loops. (As opposed to just detecting a problem and disabling transmission onto that link.) Does it cause any problems with other IS-IS PDUs, i.e. do not all PDUs need to be set to the same "maximum" size if you assume the network doesn't support the IS-IS specified size.. > b) have another type of mechanism, perhaps called "MTU discovery", which [snip] > c) we'd add a bit to the Hello saying "I support the MTU discovery protocol" I've missed the need for the MTU discovery in this sitation, if the PDU size must be network wide, then... Cheers Kris From trill at punk.co.nz Wed Mar 25 21:20:04 2009 From: trill at punk.co.nz (Kris Price) Date: Thu, 26 Mar 2009 17:20:04 +1300 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA8126.4030909@sun.com> <4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> Message-ID: <49CB0274.4090203@punk.co.nz> Anoop Ghanwani wrote: [snip] > However, I disagree that that is a good approach > because we will be stuck with dealing with STP > convergence times before we can do anything useful > in the TRILL network. STP can be very fast when > the network is small and failures are fairly localized, > but it gets worse as the network gets bigger. I'm not sure the convergence time of RSTP should be considered a problem given the target for RBridges, as long as the result is safe, and simple to work with. The argument I've heard is if you want provider features (e.g. very fast convergence, more scalability than .1Q) go MPLS. I didn't think faster convergence and increased scalability was an aim for TRILL, but perhaps it creeped in. What Don suggests (or a variation on it) appears more elegant, it may have been rejected, but IMHO it's often worth reconsidering some things in light of new information or changing circumstances. As an aside, two totally off the cuff thoughts that may or may not help spark other useful ideas: 1. What about using a new, dedicated, RBridge bootstap/hello/protection protocol when RBridges start up? - very basic, sends small Hello's - on receipt of a Hello for which you do not have accompanying IIHs, stop transmissions out that port, fire off an "MTU error" and let the administrator sort it out. - If all links must support the IS-IS recieve buffer size then this seems the only option without modifying IS-IS... 2. Seems BFD could be used to cover the situation where an MTU changes. - Once a neighbour is discovered via the usual IS-IS Hello protocol, bootstrap up BFD to that neighbour. From that point on if your Hello hold timer lapses, but BFD is still up, you know the MTU has changed, and can disable transmission on the port, fire off an MTU error, etc. - Using BFD also provides nice fast failure detection, so maybe it alleviates some requirements for monitoring the BPDUs etc and waiting 30 seconds during a change even if there's no problem... (but I'm probably mistaken) - Having enough info to bootstrap BFD in the first place when IIH's are not getting through is an issue of course. Cheers Kris From ddutt at cisco.com Thu Mar 26 02:51:31 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 26 Mar 2009 02:51:31 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com> <49CA8126.4030909@sun.com> <4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> Message-ID: <49CB5023.6090407@cisco.com> Hi, Anoop Ghanwani wrote: > I think he's referring to one of the options > discussed which was to have a big spanning tree > that spanned the entire TRILL campus and all of the > bridge islands that might need to be interconnected > by TRILL. > > (Don, please clarify if I am misrepresenting > what you wanted to say.) > If this is the suggestion Don F is making, I strongly disagree with this approach as well. Customers are moving to TRILL to get out of spanning tree for multiple reasons. An Rbridge terminating the STP and not creating a giant spanning tree was expressly liked by many people that I spoke to. In light of customers moving to larger L2 networks, creating a single giant spanning tree is a very bad idea. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From d3e3e3 at gmail.com Thu Mar 26 10:06:57 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 26 Mar 2009 13:06:57 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> Message-ID: <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> I would like to point out that there were three polls on Hellos during the TRILL WG meeting: 1. Should we add a TLV to Hellos with what the sender believes the link MTU is? The response at the meeting was overwhelmingly positive on this. So it will happen (probably actually a sub-TLV) unless there is substantial opposition on the mailing list. 2. Should at least some Hellos be padded? The response at the meeting was exactly equally divided on this. 3. Should there be one or two types of Hello? The response at the meeting was a small majority in favor of one type of Hello. Radia's proposal seems to me to be consistent with the spirit of the responses to these last two polls: that many people want their to be a facility for a padded MTU test message but most would prefer one type of Hello. Of course, response on the mailing list could affect judgement as to what the opinion of the WG is. Donald On Wed, Mar 25, 2009 at 9:42 PM, Donald Eastlake wrote: > The decision not to default to STP behavior was made by the working > group some time ago. > > Are there others who want to post an opinion on Radia's proposal? We > would like to close this expeditiously. > > Thanks, > Donald > > > On Wed, Mar 25, 2009 at 12:57 PM, Radia Perlman wrote: >> After listening to the discussion at the meeting, and talking to some >> people in the hall, I hope >> this might be palatable to everyone. >> >> a) have only one type of Hello: the original type, but say in the spec >> that Hellos >> MUST NOT be padded. Also mention a maximum size, and say that this might >> limit really really really creative appointments of lots of appointed >> forwarders for lots >> of VLANs. >> >> b) have another type of mechanism, perhaps called "MTU discovery", which >> would >> be a pairwise protocol between two RBridges R1 and R2, where R1 sends a >> padded >> message, and R2 acks it if R2 received it. This would be an optional >> protocol specified >> in a separate document >> >> c) we'd add a bit to the Hello saying "I support the MTU discovery protocol" >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > > > > -- > ============================= > ?Donald E. Eastlake 3rd ? +1-508-634-2066 (home) > ?155 Beaver Street > ?Milford, MA 01757 USA > ?d3e3e3 at gmail.com > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From sajassi at cisco.com Thu Mar 26 10:08:51 2009 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Thu, 26 Mar 2009 10:08:51 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA419230B0C@zrtphxm2.corp.nortel.com> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com><49CA8126.4030909@sun.com><4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> <34B3EAA5B3066A42914D28C5ECF5FEA419230B0C@zrtphxm2.corp.nortel.com> Message-ID: <7F115A41909B2641A9550322C4DF9D568F8607@xmb-sjc-22d.amer.cisco.com> Don, As we have discussed, there are two issues in here related to this corner case (legacy hubs between Rbridges): a) possibility of loop when hello get discarded by interim hubs and b) black holing of data when there is no MTU negotiation. Both of these issues can be addressed by the initial proposal on this thread using a single hello type and then have a MTU discovery exchange. So, if it can be addressed easily like that, then one would wonder why to make the life more complicated and talk about introducing STP bridge protocol. > > I'm thinking that Shortest Path Bridging can handle this on a > neighbor basis so why can't RBridge? Perhaps we should list > the cases this is an issue. James' (Jim's) example was rather > straight forward and I could not see why RBridge would not > behave like a bridge. But then you have a LAN with some > RBridges and some Bridges and I can't say I know all the permutations. > The difference is that in case of 802.1aq as you know, the .1aq bridges don't need interoperate over legacy bridges/switches (for optimum forwarding). So, they don't from adjacencies and don't forward traffic. Whereas, in here, the interoperability over legacy LAN is of interest. Cheers, Ali From Radia.Perlman at sun.com Thu Mar 26 10:12:13 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 26 Mar 2009 10:12:13 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CB00DB.9020902@punk.co.nz> References: <49CA6285.9000402@sun.com> <49CB00DB.9020902@punk.co.nz> Message-ID: <49CBB76D.7040501@sun.com> Kris Price wrote: > > I've missed the need for the MTU discovery in this sitation, if the PDU > size must be network wide, then... > > > > Cheers > Kris > Good point. If there were fragmentation/reassembly like in theory there is with IP, it might make sense to have a network with heterogeneous link length capacity. Obviously we won't ever have that for layer 2. Perhaps what MTU discovery could be used for is to not report adjacencies to neighbors where, for whatever reason, the "network-wide" link length doesn't work. Your question leads to other possible tweaks: a) having RBridges (or at least the one RBridge with highest priority...) report what they believe the network-wide MTU size is, in their LSP. Perhaps other RBridges might adjust their buffer sizes accordingly, or something. b) (I'm sure we don't want to do this, but for completeness probably should mention it): report in an LSP, regarding an adjacency, what the MTU is. Then, in theory, packets that are too large could be routed on links that have the right capacity, if such paths exist. Radia From d3e3e3 at gmail.com Thu Mar 26 10:12:26 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 26 Mar 2009 13:12:26 -0400 Subject: [rbridge] A different wording question related to Hellos Message-ID: <1028365c0903261012x2c77d193yd9552f2f43c0f9b0@mail.gmail.com> The current -12 protocol specification draft has some wording in it that has been bothering me: the phrase "five Hellos times". Actually, there is no such thing as a "Hello time". There is just a "holding time". Different implementations send different numbers of Hellos per holding time. Although the I believe the ISO standard says you should send ten, many implementations send five or even three. If you hear no Hellos for the holding time of the sender, you declare them dead. I believe that all occurrences of "five Hellos times" or the like in the draft should be replace with "the holding time" or the like and, in each case, it needs to be made clear whether it is the holding time of the RBridge taking the action or the holding time that was in a Hellos received by that RBridge. Are there are objections or suggestions related to this wording change? Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From mshand at cisco.com Thu Mar 26 10:51:33 2009 From: mshand at cisco.com (mike shand) Date: Thu, 26 Mar 2009 17:51:33 +0000 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CBB76D.7040501@sun.com> References: <49CA6285.9000402@sun.com> <49CB00DB.9020902@punk.co.nz> <49CBB76D.7040501@sun.com> Message-ID: <49CBC0A5.4000101@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090326/548c9c44/attachment.html From dwfedyk at nortel.com Thu Mar 26 11:09:01 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Thu, 26 Mar 2009 14:09:01 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <7F115A41909B2641A9550322C4DF9D568F8607@xmb-sjc-22d.amer.cisco.com> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com><49CA8126.4030909@sun.com><4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> <34B3EAA5B3066A42914D28C5ECF5FEA419230B0C@zrtphxm2.corp.nortel.com> <7F115A41909B2641A9550322C4DF9D568F8607@xmb-sjc-22d.amer.cisco.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4192314FE@zrtphxm2.corp.nortel.com> Hi Ali > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > Sent: Thursday, March 26, 2009 1:09 PM > To: Fedyk, Don (BL60:1A00); Anoop Ghanwani; Radia Perlman > Cc: TRILL/RBridge Working Group > Subject: RE: [rbridge] Proposed compromise for short/long hellos > > > > Don, > > As we have discussed, there are two issues in here related to this > corner case (legacy hubs between Rbridges): a) possibility of > loop when > hello get discarded by interim hubs and b) black holing of data when > there is no MTU negotiation. IS-IS does not support MTU negotiation. The MTU is set and is essentially must be the same everywhere. There is some tolerance to accepting larger messages (less than MTU) but the recommendation is any node that cannot support the MTU the adjacency is lost. See http://www.ietf.org/mail-archive/web/isis-update/current/msg00072.html If you wish to learn of RBridges by some other protocol/means and then use IS-IS with all the same MTU then that would be OK. But the proposal to change IS-IS Hello messages changes IS-IS to a behavior it does not support. The reason is other bridges with larger MTU may have sent LSP that cannot be exchanged on a lower MTU link. This is not like your PC where you just negotiate a lower MTU. You have to change the whole network or get rid of the MTU restriction. And then you have the question of what do you do when you are and RBridge that cannot talk to another RBridge using IS-IS because but you know it is out there? I say for this case you must fall back to a bridge compatible mode of operation for the portion of the spanning tree that connects the adjacency. So to be clear the least you can do is: 1) Detect a lower MTU by some means. (MTU lower than the globally set IS-IS configuration.) 2) You cannot adapt a single RBridge to a lower MTU. (Within the current IS-IS design over layer 2) 3) And you need to take some action because you have to ensure that the RBridges that know about each other but cannot exchange topology do not mess up what they send. <- This peice is essential IMO. Regards, Don > > Both of these issues can be addressed by the initial proposal on this > thread using a single hello type and then have a MTU > discovery exchange. No see above. > So, if it can be addressed easily like that, then one would wonder why > to make the life more complicated and talk about introducing > STP bridge > protocol. No see above. > > > > > > I'm thinking that Shortest Path Bridging can handle this on a > > neighbor basis so why can't RBridge? Perhaps we should list > > the cases this is an issue. James' (Jim's) example was rather > > straight forward and I could not see why RBridge would not > > behave like a bridge. But then you have a LAN with some > > RBridges and some Bridges and I can't say I know all the > permutations. > > > > The difference is that in case of 802.1aq as you know, the > .1aq bridges > don't need interoperate over legacy bridges/switches (for optimum > forwarding). So, they don't from adjacencies and don't > forward traffic. What 802.1aq does is form a Shortest Path Tree region dynamically. The Region does not include legacy bridges but it forwards over them like a VLAN Bridge. Two SPT reqions will forward traffic over a legacy Bridge. > Whereas, in here, the interoperability over legacy LAN is of interest. The difference is that Trill performs its adjacency over the legacy LAN. (BTW .1aq can do this as well if we include shared interfaces but the difference would be that the data plane would use VLAN translation to the STP (or B-VLAN translation to the STP) at the legacy interfaces. Trill uses an encapsualtion that is the difference. Regards, Don > > Cheers, > Ali > > From james.d.carlson at sun.com Thu Mar 26 13:27:49 2009 From: james.d.carlson at sun.com (James Carlson) Date: Thu, 26 Mar 2009 16:27:49 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> Message-ID: <18891.58693.864527.360755@gargle.gargle.HOWL> Donald Eastlake writes: > 1. Should we add a TLV to Hellos with what the sender believes the > link MTU is? The response at the meeting was overwhelmingly positive > on this. So it will happen (probably actually a sub-TLV) unless there > is substantial opposition on the mailing list. In terms of configuration information for the RBridge nodes themselves, it's really a network-wide parameter. Everyone has to have the same MTU configured, or we're sunk. We can't define things such that if you see a "bad" Hello, you fail to establish an adjacency. Doing that alone risks potential forwarding loops by allowing multiple independent TRILL clouds (segregated only by configured MTU) to attach to the same bridged core network. It would work if the system with the smaller configured MTU was required to disable itself on that port (at least until it no longer sees Hello messages with a larger MTU). However, that doesn't cover the case I was really worried about, which is hidden MTU restrictions in the bridged network. You can't catch those by any new TLV: you have to send big packets and see when they fail. And if you have such a mechanism, it also happens to solve the problem that the proposed new TLV in the Hello message solves, so that doesn't seem necessary to me. > 2. Should at least some Hellos be padded? The response at the > meeting was exactly equally divided on this. Something needs to be padded if we're going to detect MTU restrictions automatically. If it's not the Hello messages (the simpler solution, I think), then it could be some brand new type of message that's required to be exchanged in order for the port to be enabled. > Radia's proposal seems to me to be consistent with the spirit of the > responses to these last two polls: that many people want their to be a > facility for a padded MTU test message but most would prefer one type > of Hello. Of course, response on the mailing list could affect > judgement as to what the opinion of the WG is. As long as there's a mechanism, I don't care much what it is. -- 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 trill at punk.co.nz Thu Mar 26 14:32:41 2009 From: trill at punk.co.nz (Kris Price) Date: Fri, 27 Mar 2009 10:32:41 +1300 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CBB76D.7040501@sun.com> References: <49CA6285.9000402@sun.com> <49CB00DB.9020902@punk.co.nz> <49CBB76D.7040501@sun.com> Message-ID: <49CBF479.5000107@punk.co.nz> Radia Perlman wrote: > Kris Price wrote: >> I've missed the need for the MTU discovery in this sitation, if the PDU >> size must be network wide, then... >> >> >> >> Cheers >> Kris >> > > Good point. Maybe this is more down to me missing something with IS-IS, I've just downloaded the ISO spec and had a quick squizz with some tired eyes, it looks to me (and seems to be confirmed by what people have said in some other emails) that: - The recieve buffer must accept 1492 bytes on all routers. - But you can control the size of what you send, IIHs, LSPs, by setting a smaller originateL1LSPbuffer size, the IIH's are paded up to that size. Any LSP you send will be limited to that size. - Problem is, you still have to recieve an LSP that another router might generate that is 1492 bytes, and send it out your links as part of flooding. So one very simple solution, as you suggested, define a maximum size limit in the draft. Leave it to implementors to define how to do it in IS-IS, but one obvious way is to permanently configure all the RBridges to set originate LSP buffers to that maximum size. That way no RBridge will generate an LSP larger than the limit. And IS-IS isn't changed to achieve that. (It's just a configuration adjustment) I didn't follow the part about what to do when you discover a neighbour via the small un-padded IIH and form an adjacency. When a larger LSP comes along into one of your other interfaces, you can't flood it across that small link. So some information wouldn't be getting through on parts of the network. Sounded undesirable to me, but possibly it doesn't matter. If it does matter than adjacencies can only form when all routers agree on this LSP size. Otherwise, is it the suggestion that an adjacency formed via a small IIH, but over a link later discovered to be smaller than the 1492 MTU, is a special case of adjacency? It's just used for DRB election...so if you don't implement MTU discovery...you never know its a special case? I'm reading 4.2.4.1, it seems to indicate that MTU padding in Hellos is: "For purposes of constructing the campus routing topology, RB1 and RB2 should only be considered adjacent if the largest TRILL data and IS-IS frames occurring in the campus can make it through Dev." Not sure why it relates to TRILL data frames...surely the largest might be 9000 bytes in some parts of a TRILL campus? And wouldn't the relation to IS-IS frames be covered by virtue of the fact that 1492 bytes is specified in the IS-IS spec, so is this section still telling us anything? Cheers Kris From sajassi at cisco.com Thu Mar 26 16:35:07 2009 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Thu, 26 Mar 2009 16:35:07 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4192314FE@zrtphxm2.corp.nortel.com> References: <49CA6285.9000402@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4191ED988@zrtphxm2.corp.nortel.com><49CA8126.4030909@sun.com><4C94DE2070B172459E4F1EE14BD2364E02BD1E12@HQ-EXCH-5.corp.brocade.com> <34B3EAA5B3066A42914D28C5ECF5FEA419230B0C@zrtphxm2.corp.nortel.com> <7F115A41909B2641A9550322C4DF9D568F8607@xmb-sjc-22d.amer.cisco.com> <34B3EAA5B3066A42914D28C5ECF5FEA4192314FE@zrtphxm2.corp.nortel.com> Message-ID: <7F115A41909B2641A9550322C4DF9D568F881F@xmb-sjc-22d.amer.cisco.com> Hi Don, > > IS-IS does not support MTU negotiation. The MTU is set and > is essentially must be the same everywhere. There is some > tolerance to accepting larger messages (less than MTU) but > the recommendation is any node that cannot support the MTU > the adjacency is lost. > See > http://www.ietf.org/mail-archive/web/isis-update/current/msg00 > 072.html > I see what you saying but my point is that if this issue can be resolved with a simple tweak of IS-IS, then adding a completely separate protocol such as STP, is overkill to say the least. > If you wish to learn of RBridges by some other protocol/means > and then use IS-IS with all the same MTU then that would be > OK. But the proposal to change IS-IS Hello messages changes > IS-IS to a behavior it does not support. The reason is other > bridges with larger MTU may have sent LSP that cannot be > exchanged on a lower MTU link. This is not like your PC where > you just negotiate a lower MTU. You have to change the whole > network or get rid of the MTU restriction. > I would assume when you impose MTU restrictions, it will not be just for hello messages but for all IS-IS messages including LSPs. So, when you change the hello to a given MTU size, this MTU size should apply to everything. Cheers, Ali > And then you have the question of what do you do when you are > and RBridge that cannot talk to another RBridge using IS-IS > because but you > know it is out there? I say for this case you must fall back to a > bridge compatible mode of operation for the portion of the > spanning tree that connects the adjacency. > > So to be clear the least you can do is: > 1) Detect a lower MTU by some means. (MTU lower than the > globally set IS-IS configuration.) > 2) You cannot adapt a single RBridge to a lower MTU. (Within > the current IS-IS design over layer 2) > 3) And you need to take some action because you have to > ensure that the RBridges that know about each other but > cannot exchange topology do not mess up what they send. <- > This peice is essential IMO. > > Regards, > Don > > > > > > Both of these issues can be addressed by the initial > proposal on this > > thread using a single hello type and then have a MTU discovery > > exchange. > > No see above. > > So, if it can be addressed easily like that, then one would > wonder why > > to make the life more complicated and talk about introducing STP > > bridge protocol. > > No see above. > > > > > > > > > > I'm thinking that Shortest Path Bridging can handle this on a > > > neighbor basis so why can't RBridge? Perhaps we should list the > > > cases this is an issue. James' (Jim's) example was rather > straight > > > forward and I could not see why RBridge would not behave like a > > > bridge. But then you have a LAN with some RBridges and > some Bridges > > > and I can't say I know all the > > permutations. > > > > > > > The difference is that in case of 802.1aq as you know, the .1aq > > bridges don't need interoperate over legacy bridges/switches (for > > optimum forwarding). So, they don't from adjacencies and > don't forward > > traffic. > What 802.1aq does is form a Shortest Path Tree region > dynamically. The Region does not include legacy bridges but > it forwards over them like a VLAN Bridge. Two SPT reqions > will forward traffic over a legacy Bridge. > > > > Whereas, in here, the interoperability over legacy LAN is > of interest. > The difference is that Trill performs its adjacency over the > legacy LAN. > (BTW .1aq can do this as well if we include shared interfaces > but the difference would be that the data plane would use > VLAN translation to the STP (or B-VLAN translation to the > STP) at the legacy interfaces. > Trill uses an encapsualtion that is the difference. > > Regards, > Don > > > > Cheers, > > Ali > > > > > From d3e3e3 at gmail.com Fri Mar 27 08:47:31 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 27 Mar 2009 11:47:31 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18891.58693.864527.360755@gargle.gargle.HOWL> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> <18891.58693.864527.360755@gargle.gargle.HOWL> Message-ID: <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> See below.... On Thu, Mar 26, 2009 at 4:27 PM, James Carlson wrote: > Donald Eastlake writes: >> ? ?1. Should we add a TLV to Hellos with what the sender believes the >> link MTU is? The response at the meeting was overwhelmingly positive >> on this. So it will happen (probably actually a sub-TLV) unless there >> is substantial opposition on the mailing list. > > In terms of configuration information for the RBridge nodes > themselves, it's really a network-wide parameter. ?Everyone has to > have the same MTU configured, or we're sunk. Well, if the MTU is low enough and IS-IS control frames are big enough that some of them get lost, then I'd say we're probably sunk. If all IS-IS control messages get through but some large data frames are lost, it's bad, but not as bad. And keep in mind that IS-IS control frames are limited because of their LSAP encoding. So without a substantial change in the TRILL IS-IS frame encoding, you're not going to see any jumbo IS-IS control frames. > We can't define things such that if you see a "bad" Hello, you fail to > establish an adjacency. ?Doing that alone risks potential forwarding > loops by allowing multiple independent TRILL clouds (segregated only > by configured MTU) to attach to the same bridged core network. I don't think the danger relates to adjacencies, I think it's related to being an uninhibited appointed forwarder. > It would work if the system with the smaller configured MTU was > required to disable itself on that port (at least until it no longer > sees Hello messages with a larger MTU). Yes, inhiibiting appointed forwarder status is what you need to do for safety. > However, that doesn't cover the case I was really worried about, which > is hidden MTU restrictions in the bridged network. ?You can't catch > those by any new TLV: you have to send big packets and see when they > fail. An advantage of Radia's proposal is that the MTU probe message is, presumably, not an IS-IS frame so it can be as big as any existing devices will handle, such as a 9K byte jumbo frame. > And if you have such a mechanism, it also happens to solve the problem > that the proposed new TLV in the Hello message solves, so that doesn't > seem necessary to me. You are probably right. >> ? ?2. Should at least some Hellos be padded? The response at the >> meeting was exactly equally divided on this. > > Something needs to be padded if we're going to detect MTU restrictions > automatically. ?If it's not the Hello messages (the simpler solution, > I think), then it could be some brand new type of message that's > required to be exchanged in order for the port to be enabled. As above, IS-IS Hellos can not be padded beyond the traditional Ethernet limit, plus tags. Thanks, Donald >> Radia's proposal seems to me to be consistent with the spirit of the >> responses to these last two polls: that many people want their to be a >> facility for a padded MTU test message but most would prefer one type >> of Hello. Of course, response on the mailing list could affect >> judgement as to what the opinion of the WG is. > > As long as there's a mechanism, I don't care much what it is. > > -- > 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 > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From anoop at brocade.com Fri Mar 27 16:04:07 2009 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 27 Mar 2009 16:04:07 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> References: <49CA6285.9000402@sun.com><1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com><1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com><18891.58693.864527.360755@gargle.gargle.HOWL> <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> Just responding to the thread in general and not any specific post... I think it makes sense to use the non-padded Hellos just because it is critical that they be seen. If they are not seen, what could result is a loop which is very bad. As a result of not padding the Hellos, we would lose the MTU discovery/validation benefit of L3 IS-IS. For that, we can probably define a new message. If we continue to pad messages, we could get loops as observed by Jim. We could define a new message/protocol specifically to detect such scenarios, but I personally think it is safer to prevent such a scenario by having it built into the core of the protocol. Anoop From Radia.Perlman at sun.com Sat Mar 28 09:44:50 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sat, 28 Mar 2009 09:44:50 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> <18891.58693.864527.360755@gargle.gargle.HOWL> <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> Message-ID: <49CE5402.5070202@sun.com> Yes. Simply not padding hellos seems like the simplest, safest thing for assuring the Hellos get through. As someone else pointed out, though, bad things (other than dropping large data packets) might happen if the MTU on the link was misconfigured, and control messages like CSNPs and LSPs didn't get through. So it seems quite important that we also define the "MTU discovery" protocol. That protocol should at least be a SHOULD rather than a MAY". It should be a very simple protocol. I also believe it is a good idea to have the highest priority router's LSP dictate the MTU size on the campus, and RBridges attached to a link that can't meet that MTU requirement would not report those links in their LSPs. I think Don said that at the meeting there was "overwhelming support" for adding a TLV to the hello saying what the MTU size was. I don't remember that, but I also think at the meeting some people thought that including a TLV for what you think the MTU size is completely replaced the padding of hellos mechanism. It doesn't. And since I believe we need a mechanism of sending padded messages and seeing if they get through (the "MTU discovery protocol"), putting a TLV for "I think the MTU size is x" doesn't really add anything. So to summarize what I think we should do: a) say Hellos MUST NOT be padded b) add a flag for "I support the MTU discovery protocol" to the Hello c) add a TLV in the LSP for "I think the campus-wide minimum MTU size for a link is x" d) specify a simple MTU discovery protocol which would be a message that is never forwarded by an RBridge, and which is padded to the size you want to test, and includes the size in the data, and an RBridge R2 that receives such a message from neighbor R1 (whether the message was unicast by R1 to R2, or multicast by R1 on the link) acknowledges with the size in the message: "I received your MTU discovery message with size q" e) if R1 doesn't receive an ack from R2 after sufficiently many MTU discovery messages, R1 drops the adjacency to R2. Radia Anoop Ghanwani wrote: > Just responding to the thread in general and not > any specific post... > > I think it makes sense to use the non-padded > Hellos just because it is critical that they > be seen. If they are not seen, what could > result is a loop which is very bad. > > As a result of not padding the Hellos, we would > lose the MTU discovery/validation benefit of > L3 IS-IS. For that, we can probably define > a new message. > > If we continue to pad messages, we could > get loops as observed by Jim. We could define > a new message/protocol specifically to detect > such scenarios, but I personally think it is > safer to prevent such a scenario by having it > built into the core of the protocol. > > Anoop > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Sun Mar 29 11:30:28 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 29 Mar 2009 11:30:28 -0700 Subject: [rbridge] multiple nicknames in an LSP? In-Reply-To: References: Message-ID: <49CFBE44.4010404@sun.com> The point someone was making is that they want multiple trees rooted at the same place (say R1) where all the trees are shortest path trees from R1, but that they use different links. The only way to do that is to have different tie breakers where there are choices. The way the spec is currently, the tie-breaker would be the same, so all the trees rooted at R1 would be identical. But anyway, for now, should we allow the encoding of the nickname TLV to allow asking for multiple nicknames? Seems not too hard..given that there is an "L" in the TLV. Is there anyone who would object to this? Is there anyone who would actually want this? Radia Ayan Banerjee wrote: > Radia, > > Please see inline. > > Thanks, > Ayan > > > On 3/25/09 10:12 AM, "Radia Perlman" wrote: > > >> Someone asked me about whether it would be possible for an RBridge to >> request more >> than one nickname for itself. We could, I suppose, put in the encoding >> into the Hello, perhaps >> by changing the format of the TLV for "nickname", or just inherently >> from the length of the TLV, >> allowing a list of nicknames. >> >> So...the question is -- why might we want multiple nicknames? >> >> Some reasons people have mentioned to me I'm not sure I understand, so >> people can add them. >> Other layer 2-ish protocols play tricks with having multiple destination >> addresses, I think for >> allowing multiple routes to the same destination. I'm not sure those >> apply to TRILL >> >> One reason I do understand, but am not sure I understand how to >> accomplish it, is to allow >> multiple trees rooted at the same node R1, with the hope that the two >> trees can look different (for load >> sharing) and yet both be shortest paths from R1. If we had two nicknames >> for R1 then R1 can >> request some multicast packets travel on each of the trees. >> >> It's harder than just having the nicknames, because the way the spec >> reads today, exactly the same >> tree would be computed. >> >> I'd have to go thinking about this some more, and I think it would be an >> excellent research problem for >> a student -- how to calculate, without configuration, maximally load >> sharing'ness of trees rooted at the same >> place, or choosing which nodes to root trees on, etc. >> >> But here's a quick suggestion, just to show it's somewhat possible: >> >> Use the root nickname (or root ID, or some other field we can add to the >> LSP as a modifier >> of the nickname) as a way of doing the tie-breaker. >> >> so for instance, R1 can say "I want nicknames N1 and N2. I'd like the >> tiebreaker salt to be x for N1 >> and y for N2". >> >> Then when the tree rooted at N1 is being computed (by any RBridge), >> rather than choosing the >> ID of the parent as the tie-breaker (as it is today I think), use some >> sort of function of >> the salt, so that the tie-breaker would be different for the N1 tree >> than the N2 tree. >> >> > > [AB] It seems to me that given we have roots tied to graph-ids, we could > associate N1 to a graph-id and that makes it "visible" only on that > graph-id. Hence, other nodes computing their SPFs will see N1 only in > graph-1 and N2 only in graph-2. I am guessing that you are essentially > saying the same above, though I do not quite follow the tie-breaker. If it > is explicit, node R1 can enforce multicast packets on trees that it desires. > > > >> Radia >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From dwfedyk at nortel.com Mon Mar 30 06:52:40 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Mon, 30 Mar 2009 09:52:40 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49CE5402.5070202@sun.com> References: <49CA6285.9000402@sun.com><1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com><1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com><18891.58693.864527.360755@gargle.gargle.HOWL><1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com><4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> <49CE5402.5070202@sun.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4192C1BEE@zrtphxm2.corp.nortel.com> Hi Radia I'm having trouble understanding if this really fixes the problem or just handles one case of IS-IS adjacency failure due to small MTU. What happens after point e) when the adjacency drops? What is the forwarding behavior of the RBridges that realizes they cannot form an adjacency? I think what I'm hearing is the forwarding behavior/treatment of an interface when there is an RBridge that knows they cannot form an adjacency is different than when RBridges do not know any adjacency exists and that seems problematic to me. Regards, Don > So to summarize what I think we should do: > a) say Hellos MUST NOT be padded > b) add a flag for "I support the MTU discovery protocol" to the Hello > c) add a TLV in the LSP for "I think the campus-wide minimum MTU size > for a link is x" > d) specify a simple MTU discovery protocol which would be a > message that > is never forwarded by an RBridge, and which is padded to the > size you want > to test, and includes the size in the data, and an RBridge R2 > that receives > such a message from neighbor R1 (whether the message was unicast by R1 > to R2, or multicast by R1 on the link) acknowledges with the > size in the > message: > "I received your MTU discovery message with size q" > e) if R1 doesn't receive an ack from R2 after sufficiently many MTU > discovery > messages, R1 drops the adjacency to R2. > > Radia > > > > Anoop Ghanwani wrote: > > Just responding to the thread in general and not > > any specific post... > > > > I think it makes sense to use the non-padded > > Hellos just because it is critical that they > > be seen. If they are not seen, what could > > result is a loop which is very bad. > > > > As a result of not padding the Hellos, we would > > lose the MTU discovery/validation benefit of > > L3 IS-IS. For that, we can probably define > > a new message. > > > > If we continue to pad messages, we could > > get loops as observed by Jim. We could define > > a new message/protocol specifically to detect > > such scenarios, but I personally think it is > > safer to prevent such a scenario by having it > > built into the core of the protocol. > > > > Anoop > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Tue Mar 31 03:25:13 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 31 Mar 2009 03:25:13 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4192C1BEE@zrtphxm2.corp.nortel.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> <18891.58693.864527.360755@gargle.gargle.HOWL> <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> <49CE5402.5070202@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4192C1BEE@zrtphxm2.corp.nortel.com> Message-ID: <49D1EF89.3070801@sun.com> I may have the terminology wrong -- but when I say "R1 drops the adjacency to R2" what I mean is: a) In R1's Hellos, R1 no longer lists R2 as a neighbor b) In R1's LSP, R1 no longer lists a link to R2 c) If it's a pseudonode that connects R1 and R2, then as a consequence of R2 not appearing in R1's Hellos, R2 does not report a link to the pseudnode in R2's LSP. d) Because the LSPs do not indicate a link between R1 and R2, no paths will be computed by any RBridges that go through R1-R2. Radia Don Fedyk wrote: > Hi Radia > > I'm having trouble understanding if this really fixes the problem or > just handles one case of IS-IS adjacency failure due to small MTU. > What happens after point e) when the adjacency drops? What is the > forwarding behavior of the RBridges that realizes they cannot form an > adjacency? > > I think what I'm hearing is the forwarding behavior/treatment of an > interface when there is an RBridge that knows they cannot form an > adjacency is different than when RBridges do not know any adjacency > exists and that seems problematic to me. > > Regards, > Don > > > >> So to summarize what I think we should do: >> a) say Hellos MUST NOT be padded >> b) add a flag for "I support the MTU discovery protocol" to the Hello >> c) add a TLV in the LSP for "I think the campus-wide minimum MTU size >> for a link is x" >> d) specify a simple MTU discovery protocol which would be a >> message that >> is never forwarded by an RBridge, and which is padded to the >> size you want >> to test, and includes the size in the data, and an RBridge R2 >> that receives >> such a message from neighbor R1 (whether the message was unicast by R1 >> to R2, or multicast by R1 on the link) acknowledges with the >> size in the >> message: >> "I received your MTU discovery message with size q" >> e) if R1 doesn't receive an ack from R2 after sufficiently many MTU >> discovery >> messages, R1 drops the adjacency to R2. >> >> Radia >> >> >> >> Anoop Ghanwani wrote: >> >>> Just responding to the thread in general and not >>> any specific post... >>> >>> I think it makes sense to use the non-padded >>> Hellos just because it is critical that they >>> be seen. If they are not seen, what could >>> result is a loop which is very bad. >>> >>> As a result of not padding the Hellos, we would >>> lose the MTU discovery/validation benefit of >>> L3 IS-IS. For that, we can probably define >>> a new message. >>> >>> If we continue to pad messages, we could >>> get loops as observed by Jim. We could define >>> a new message/protocol specifically to detect >>> such scenarios, but I personally think it is >>> safer to prevent such a scenario by having it >>> built into the core of the protocol. >>> >>> Anoop >>> >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From mshand at cisco.com Tue Mar 31 05:32:02 2009 From: mshand at cisco.com (mike shand) Date: Tue, 31 Mar 2009 13:32:02 +0100 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D1EF89.3070801@sun.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> <18891.58693.864527.360755@gargle.gargle.HOWL> <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> <49CE5402.5070202@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4192C1BEE@zrtphxm2.corp.nortel.com> <49D1EF89.3070801@sun.com> Message-ID: <49D20D42.5040009@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090331/97cdcefb/attachment.html From Radia.Perlman at sun.com Tue Mar 31 08:45:32 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 31 Mar 2009 08:45:32 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D20D42.5040009@cisco.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> <18891.58693.864527.360755@gargle.gargle.HOWL> <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> <49CE5402.5070202@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4192C1BEE@zrtphxm2.corp.nortel.com> <49D1EF89.3070801@sun.com> <49D20D42.5040009@cisco.com> Message-ID: <49D23A9C.5040904@sun.com> I *do* mean that R2 defers to R1 for DRB even if R1 doesn't list R2 in its Hello. This is the same behavior that has to work in TRILL if, for instance, R2 cannot communicate on the Designated VLAN. If R2 can hear R1, and R1 has a better priority for being DRB, then R2 does not attempt to become DRB even if R1 is refusing to acknowledge R2's existence, and therefore they don't form an adjacency. I'd be somewhat surprised if (layer 3) IS-IS behaves differently. If R2 hears R1's Hellos, and R1 is most qualified as DRB, but for whatever reason does not list R2 in R1's Hellos, I assume that R2 does not attempt to become a separate DRB. But even if that's how IS-IS has evolved since DECnet (that was the behavior I always assumed in that case), for TRILL it has to behave the way that I said. It is dangerous to have two DRBs on a link, so if R2 knows that R1 is "more qualified" to be DRB, then R2 has to defer to R1, even if it does not have "an adjacency" to R1. Radia mike shand wrote: > Radia, > I really don't see how this works. When R1 no longer lists R2 as a > neighbor, then the adjacency goes down. But if the adjacency goes down > the DRB election doesn't happen and we are back to the loop. So you > must somehow mean that the adjacency stays UP as far as DRB election > is concerned and DOWN as far as advertising in the LSPs is concerned. > > So are you proposing changing the DRB election procedure so that it > doesn't require an adjacency? > i.e you elect it from among the hellos that you see on the LAN even if > they don't report mutual connectivity? > > I really don't understand how these dual adjacency types are supposed > to work. > > Mike > > > Radia Perlman wrote: >> I may have the terminology wrong -- but when I say "R1 drops the >> adjacency to R2" what I >> mean is: >> >> a) In R1's Hellos, R1 no longer lists R2 as a neighbor >> b) In R1's LSP, R1 no longer lists a link to R2 >> c) If it's a pseudonode that connects R1 and R2, then as a consequence >> of R2 not appearing in >> R1's Hellos, R2 does not report a link to the pseudnode in R2's LSP. >> d) Because the LSPs do not indicate a link between R1 and R2, no paths >> will be computed >> by any RBridges that go through R1-R2. >> >> Radia >> >> >> >> Don Fedyk wrote: >> >>> Hi Radia >>> >>> I'm having trouble understanding if this really fixes the problem or >>> just handles one case of IS-IS adjacency failure due to small MTU. >>> What happens after point e) when the adjacency drops? What is the >>> forwarding behavior of the RBridges that realizes they cannot form an >>> adjacency? >>> >>> I think what I'm hearing is the forwarding behavior/treatment of an >>> interface when there is an RBridge that knows they cannot form an >>> adjacency is different than when RBridges do not know any adjacency >>> exists and that seems problematic to me. >>> >>> Regards, >>> Don >>> >>> >>> >>> >>>> So to summarize what I think we should do: >>>> a) say Hellos MUST NOT be padded >>>> b) add a flag for "I support the MTU discovery protocol" to the Hello >>>> c) add a TLV in the LSP for "I think the campus-wide minimum MTU size >>>> for a link is x" >>>> d) specify a simple MTU discovery protocol which would be a >>>> message that >>>> is never forwarded by an RBridge, and which is padded to the >>>> size you want >>>> to test, and includes the size in the data, and an RBridge R2 >>>> that receives >>>> such a message from neighbor R1 (whether the message was unicast by R1 >>>> to R2, or multicast by R1 on the link) acknowledges with the >>>> size in the >>>> message: >>>> "I received your MTU discovery message with size q" >>>> e) if R1 doesn't receive an ack from R2 after sufficiently many MTU >>>> discovery >>>> messages, R1 drops the adjacency to R2. >>>> >>>> Radia >>>> >>>> >>>> >>>> Anoop Ghanwani wrote: >>>> >>>> >>>>> Just responding to the thread in general and not >>>>> any specific post... >>>>> >>>>> I think it makes sense to use the non-padded >>>>> Hellos just because it is critical that they >>>>> be seen. If they are not seen, what could >>>>> result is a loop which is very bad. >>>>> >>>>> As a result of not padding the Hellos, we would >>>>> lose the MTU discovery/validation benefit of >>>>> L3 IS-IS. For that, we can probably define >>>>> a new message. >>>>> >>>>> If we continue to pad messages, we could >>>>> get loops as observed by Jim. We could define >>>>> a new message/protocol specifically to detect >>>>> such scenarios, but I personally think it is >>>>> safer to prevent such a scenario by having it >>>>> built into the core of the protocol. >>>>> >>>>> Anoop >>>>> >>>>> >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge at postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From d3e3e3 at gmail.com Tue Mar 31 13:27:17 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 31 Mar 2009 16:27:17 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D20D42.5040009@cisco.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> <18891.58693.864527.360755@gargle.gargle.HOWL> <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> <49CE5402.5070202@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4192C1BEE@zrtphxm2.corp.nortel.com> <49D1EF89.3070801@sun.com> <49D20D42.5040009@cisco.com> Message-ID: <1028365c0903311327x248221e3t8ca1afc90c977691@mail.gmail.com> See below... 2009/3/31 mike shand : > Radia, > ??? I really don't see how this works. When R1 no longer lists R2 as a > neighbor, then the adjacency goes down. But if the adjacency goes down the > DRB election doesn't happen and we are back to the loop. So you must somehow > mean that the adjacency stays UP as far as DRB election is concerned and > DOWN as far as advertising in the LSPs is concerned. > > So are you proposing changing the DRB election procedure so that it doesn't > require an adjacency? Why do you believe the DRB (aka DIS) election has anything to do with whether or not an adjacency has been established? The "DRB election procedure" is, logically, just that each RB keeps around the headers of the LAN Hellos it has received from each other RB on the link, compares fields in those headers, decides for itself whether or not it is DRB, and acts accordingly. I don't see how this has anything to do with whether or not IS-IS Neighbor TLVs were in those Hellos or whether those Neighbor TLVs were been filled-in and exchanged in such a way as to establish an adjacency. Thanks, Donald > i.e you elect it from among the hellos that you see on the LAN even if they > don't report mutual connectivity? > > I really don't understand how these dual adjacency types are supposed to > work. > > ??? Mike > > > Radia Perlman wrote: > > I may have the terminology wrong -- but when I say "R1 drops the > adjacency to R2" what I > mean is: > > a) In R1's Hellos, R1 no longer lists R2 as a neighbor > b) In R1's LSP, R1 no longer lists a link to R2 > c) If it's a pseudonode that connects R1 and R2, then as a consequence > of R2 not appearing in > R1's Hellos, R2 does not report a link to the pseudnode in R2's LSP. > d) Because the LSPs do not indicate a link between R1 and R2, no paths > will be computed > by any RBridges that go through R1-R2. > > Radia > > > > Don Fedyk wrote: > > > Hi Radia > > I'm having trouble understanding if this really fixes the problem or > just handles one case of IS-IS adjacency failure due to small MTU. > What happens after point e) when the adjacency drops? What is the > forwarding behavior of the RBridges that realizes they cannot form an > adjacency? > > I think what I'm hearing is the forwarding behavior/treatment of an > interface when there is an RBridge that knows they cannot form an > adjacency is different than when RBridges do not know any adjacency > exists and that seems problematic to me. > > Regards, > Don > > > > > > So to summarize what I think we should do: > a) say Hellos MUST NOT be padded > b) add a flag for "I support the MTU discovery protocol" to the Hello > c) add a TLV in the LSP for "I think the campus-wide minimum MTU size > for a link is x" > d) specify a simple MTU discovery protocol which would be a > message that > is never forwarded by an RBridge, and which is padded to the > size you want > to test, and includes the size in the data, and an RBridge R2 > that receives > such a message from neighbor R1 (whether the message was unicast by R1 > to R2, or multicast by R1 on the link) acknowledges with the > size in the > message: > "I received your MTU discovery message with size q" > e) if R1 doesn't receive an ack from R2 after sufficiently many MTU > discovery > messages, R1 drops the adjacency to R2. > > Radia > > > > Anoop Ghanwani wrote: > > > > Just responding to the thread in general and not > any specific post... > > I think it makes sense to use the non-padded > Hellos just because it is critical that they > be seen. If they are not seen, what could > result is a loop which is very bad. > > As a result of not padding the Hellos, we would > lose the MTU discovery/validation benefit of > L3 IS-IS. For that, we can probably define > a new message. > > If we continue to pad messages, we could > get loops as observed by Jim. We could define > a new message/protocol specifically to detect > such scenarios, but I personally think it is > safer to prevent such a scenario by having it > built into the core of the protocol. > > Anoop > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From trill at punk.co.nz Tue Mar 31 16:09:11 2009 From: trill at punk.co.nz (Kris Price) Date: Wed, 01 Apr 2009 12:09:11 +1300 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D1EF89.3070801@sun.com> References: <49CA6285.9000402@sun.com> <1028365c0903251842q6b6128c9o470fde9b20abd27b@mail.gmail.com> <1028365c0903261006m177b5965l9d30323745d86cc1@mail.gmail.com> <18891.58693.864527.360755@gargle.gargle.HOWL> <1028365c0903270847g7a72be9y2b533861ed8c4073@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E02BD24D5@HQ-EXCH-5.corp.brocade.com> <49CE5402.5070202@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4192C1BEE@zrtphxm2.corp.nortel.com> <49D1EF89.3070801@sun.com> Message-ID: <49D2A297.3090500@punk.co.nz> Radia, > I may have the terminology wrong -- but when I say "R1 drops the > adjacency to R2" what I > mean is: > > a) In R1's Hellos, R1 no longer lists R2 as a neighbor > b) In R1's LSP, R1 no longer lists a link to R2 > c) If it's a pseudonode that connects R1 and R2, then as a consequence > of R2 not appearing in > R1's Hellos, R2 does not report a link to the pseudnode in R2's LSP. So in this case the network could partition? It considers itself not to have an adjacency and so therefore won't flood LSPs. This link won't be used to forward data frames either. If I have intuited right an RBridge discovers the MTUs on its links, and reports the smallest in a new TLV. When an RBridge recieves one of these TLVs with a smaller MTU than it was using for its originated LSPs, it adopts this new smaller MTU. And this is to allow the network to heal any partitions. Is this what you mean? If this isn't the case, or an RBridge gives up on forming an adjacency, networks may find themselves partitioned by these small MTU links. If a network is partitioned because of this, is that detected and reported? And if we're not using the MTU discovery to ensure the network heals and partitions don't occur (as I thought I understood it), then why use it at all, and not simplify things. Better to fail explicitly and all that. Also.. do things end up being a bit shakey until the network has settled down to this minimum MTU..? LSPs dropped, not acknowledged, etc. Regards Kris > > Don Fedyk wrote: >> Hi Radia >> >> I'm having trouble understanding if this really fixes the problem or >> just handles one case of IS-IS adjacency failure due to small MTU. >> What happens after point e) when the adjacency drops? What is the >> forwarding behavior of the RBridges that realizes they cannot form an >> adjacency? >> >> I think what I'm hearing is the forwarding behavior/treatment of an >> interface when there is an RBridge that knows they cannot form an >> adjacency is different than when RBridges do not know any adjacency >> exists and that seems problematic to me. >> >> Regards, >> Don >> >> >> >>> So to summarize what I think we should do: >>> a) say Hellos MUST NOT be padded >>> b) add a flag for "I support the MTU discovery protocol" to the Hello >>> c) add a TLV in the LSP for "I think the campus-wide minimum MTU size >>> for a link is x" >>> d) specify a simple MTU discovery protocol which would be a >>> message that >>> is never forwarded by an RBridge, and which is padded to the >>> size you want >>> to test, and includes the size in the data, and an RBridge R2 >>> that receives >>> such a message from neighbor R1 (whether the message was unicast by R1 >>> to R2, or multicast by R1 on the link) acknowledges with the >>> size in the >>> message: >>> "I received your MTU discovery message with size q" >>> e) if R1 doesn't receive an ack from R2 after sufficiently many MTU >>> discovery >>> messages, R1 drops the adjacency to R2. >>> >>> Radia >>> >>> >>> >>> Anoop Ghanwani wrote: >>> >>>> Just responding to the thread in general and not >>>> any specific post... >>>> >>>> I think it makes sense to use the non-padded >>>> Hellos just because it is critical that they >>>> be seen. If they are not seen, what could >>>> result is a loop which is very bad. >>>> >>>> As a result of not padding the Hellos, we would >>>> lose the MTU discovery/validation benefit of >>>> L3 IS-IS. For that, we can probably define >>>> a new message. >>>> >>>> If we continue to pad messages, we could >>>> get loops as observed by Jim. We could define >>>> a new message/protocol specifically to detect >>>> such scenarios, but I personally think it is >>>> safer to prevent such a scenario by having it >>>> built into the core of the protocol. >>>> >>>> Anoop >>>> >>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >