From mshand at cisco.com Wed Apr 1 00:09:15 2009 From: mshand at cisco.com (mike shand) Date: Wed, 01 Apr 2009 08:09:15 +0100 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D23A9C.5040904@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> <49D20D42.5040009@cisco.com> <49D23A9C.5040904@sun.com> Message-ID: <49D3131B.4080607@cisco.com> Radia Perlman wrote: > 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. From ISO/IEC 10589 V2 clause 8.4.5 The set of Intermediate systems to be considered includes the local Intermediate system, together with all Intermediate systems of the appropriate type as follows. d) For the LAN Level 1 Designated Intermediate System, it is the set of Intermediate systems from which LAN Level 1 IIH PDUs are received and to which Level 1 adjacencies exist in adjacencyState ?Up?. and from 8.4.2.5.1 The IS shall set the adjacencyState of the adjacency to ?initialising?, until it is known that the communication between this system and the source of the PDU (R) is two-way. However R shall be included in future Level n LAN IIH PDUs transmitted by this system. When R reports the local system?s SNPA address in its Level n LAN IIH PDUs, the IS shall d) set the adjacency?s adjacencyState to ?Up?, and Mike > > > 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 mshand at cisco.com Wed Apr 1 01:36:15 2009 From: mshand at cisco.com (mike shand) Date: Wed, 01 Apr 2009 09:36:15 +0100 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D23A9C.5040904@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> <49D20D42.5040009@cisco.com> <49D23A9C.5040904@sun.com> Message-ID: <49D3277F.6060007@cisco.com> Radia Perlman wrote: > 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 > Radia, Does this proviso help to avoid the problem? Or is it something else which would need to be changed to ensure that a lone Rbridge DOES get elected DRB? ISO/IEC 10589 v2 clause 8.4.5 (penultimate para) "An Intermediate system shall not declare itself to be a LAN Designated Intermediate system of any type until it has at least one ?Up? End system (not including manual adjacencies) or Intermediate system adjacency on the circuit. (This prevents an Intermediate System which has a defective receiver and is incapable of receiving any PDUs from erroneously electing itself LAN Designated Intermediate System.)" From Radia.Perlman at sun.com Wed Apr 1 04:05:10 2009 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Wed, 01 Apr 2009 12:05:10 +0100 Subject: [rbridge] Proposed compromise for short/long hellos Message-ID: <5f4fcb067142.49d35876@sunlabs.com> Mike, The text you quoted does imply different behavior than TRILL has to have. I don't know if the behavior I'd assumed for IS-IS got lost in translation from DECnet, or perhaps actually specified that way for DECnet, but at any rate, even though the behavior isn't what I remembered it as being, that behavior is OK for layer 3 IS-IS, where having multiple DRBs on a link is not fatal. But it is *not* OK for TRILL. Even with the extra phrase (clause 8.4.5) you quoted, that would still be fatal behavior for TRILL. It could be that R1 has highest (numerically lowest?) priority for being DRB, but R2 and R3 can't handle the MTU, or don't communicate on R1's designated VLAN, or whatever, and then R2 and R3 could still have an 'adjacency' to each other, so R2 might decide it, too, is DRB. There might be an R4 that R1 does have an 'adjacency' to, so both R1 and R2 would decide to be DRBs. And even if there is no other 'up' adjacency, and there's only a single RBridge, say R1, on a link, R1 has to become the designated forwarder, and act like the DRB on that link, except it doesnt' have to send CSNPs of forward LSPs (no RBridge neighbors). So regardless of the terminology of what it means to 'have an adjacency' or 'be DRB', TRILL IS-IS has to behave like I said in the previous emails -- regardless of whether R1 (the DRB) can hear you, for whatever reason it might not be able to hear you (VLAN mismatch, MTU mismatch, one-way connectivity due to bizarre hardware), you MUST NOT try to also become DRB. For TRILL, we have to be super conservative to make sure that multiple RBridges are not attempting to become Designated Forwarder on the same link. So if R2 can hear R1, and R1's hellos indicate it would win the DRB election, R2 MUST defer to R1. Radia From Radia.Perlman at sun.com Wed Apr 1 04:16:15 2009 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Wed, 01 Apr 2009 12:16:15 +0100 Subject: [rbridge] Proposed compromise for short/long hellos Message-ID: <5f5166953ffc.49d35b0f@sunlabs.com> Not sure exactly what you're saying, but I think you're assuming different behavior. At any rate, if a link does not support the minimum size, it would not be used for forwarding LSPs or for data traffic, and sure, the campus might partition. As for 'reporting the MTU size in a TLV'. The one place that would be useful is in the LSP of the one RBridge with highest priority, to inform all the other RBridges what the campus-wide minimum MTU size for a link is. Any links smaller than that would not get used. Again, yeah...this might cause partitions. As for discovering the MTU size: this would be done with a new, simple, but as yet unspecified protocol which I described in a previous email. Radia From mshand at cisco.com Wed Apr 1 04:48:07 2009 From: mshand at cisco.com (mike shand) Date: Wed, 01 Apr 2009 12:48:07 +0100 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <5f4fcb067142.49d35876@sunlabs.com> References: <5f4fcb067142.49d35876@sunlabs.com> Message-ID: <49D35477.5040302@cisco.com> Radia, So would it make more sense to leave the hellos, adjacency establishment rules, DIS election exactly as it is for IS-IS and use THAT for the IS-IS related stuff like generating pseudonodes, running the LAN reliable update process and advertising connectivity, and then have a new small TRILL hello which behaved the way you described and use that for electing the DRB from the point of view of determining who does the forwarding? Mike Radia.Perlman at sun.com wrote: > Mike, > > The text you quoted does imply different behavior than TRILL has to have. > I don't know if the behavior I'd assumed for IS-IS got lost in translation from DECnet, or perhaps > actually specified that way for DECnet, but at any rate, even though the behavior isn't what > I remembered it as being, > that behavior is OK for layer 3 IS-IS, where having multiple DRBs on a link is not fatal. > > But it is *not* OK for TRILL. > > Even with the extra phrase (clause 8.4.5) you quoted, that would still be fatal > behavior for TRILL. It could be that R1 has highest (numerically lowest?) priority > for being DRB, but R2 and R3 can't handle the MTU, or don't communicate on > R1's designated VLAN, or whatever, and then R2 and R3 could still have > an 'adjacency' to each other, so R2 might decide it, too, is DRB. There might be > an R4 that R1 does have an 'adjacency' to, so both R1 and R2 would decide > to be DRBs. > > And even if there is no other 'up' adjacency, and there's only a single RBridge, say R1, > on a link, R1 has to become the designated forwarder, and act like the DRB on > that link, except it doesnt' have to send CSNPs of forward LSPs (no RBridge neighbors). > > So regardless of the terminology of what it means to 'have an adjacency' or > 'be DRB', TRILL IS-IS has to behave like I said in the previous emails -- regardless > of whether R1 (the DRB) can hear you, for whatever reason it might not be able to > hear you (VLAN mismatch, MTU mismatch, one-way connectivity due to bizarre hardware), > you MUST NOT try to also become DRB. > > For TRILL, we have to be super conservative to make sure that multiple RBridges are not > attempting to become Designated Forwarder on the same link. So if R2 can hear R1, and > R1's hellos indicate it would win the DRB election, R2 MUST defer to R1. > > Radia > > > > From Radia.Perlman at sun.com Wed Apr 1 05:01:37 2009 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Wed, 01 Apr 2009 13:01:37 +0100 Subject: [rbridge] Proposed compromise for short/long hellos Message-ID: <5fc07485440.49d365b1@sunlabs.com> Mike Shand said: So would it make more sense to leave the hellos, adjacency establishment rules, DIS election exactly as it is for IS-IS and use THAT for the IS-IS related stuff like generating pseudonodes, running the LAN reliable update process and advertising connectivity, and then have a new small TRILL hello which behaved the way you described and use that for electing the DRB from the point of view of determining who does the forwarding? Mike **************************************** I don't think so. It's basically the same thing, with some different rules. If we did the TRILL Hellos and DRB election, we wouldn't need the other one also. So I think we should just modify the rules for TRILL. It's possible we should even rewrite the spec for exactly how TRILL IS-IS should work. There isn't any other IETF protocol that doesn't get updated every few years with new versions. Radia From dwfedyk at nortel.com Wed Apr 1 05:32:49 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 1 Apr 2009 08:32:49 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D3277F.6060007@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><49D23A9C.5040904@sun.com> <49D3277F.6060007@cisco.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41935C5BD@zrtphxm2.corp.nortel.com> Hi Mike, Radia RBridge has a quirk due to its "low configuration nature". It must be a DRB when it is the only RBridge (otherwise it partitions the network.) And it must cease doing this whenever there is a high priority RBridge attached to the same LAN. RBridges are dependent on IS-IS for detecting other RBridges. So if IS-IS every get "confused" about adjacencies RBridges may get confused about what mode they are operating in. Several have pointed out that is the way IGPs(IS-IS and OSPF) work in L3. But I don't think so. In L3 the knowledge of a Router that you can't form an adjacency with, does not affect your forwarding to those Routers/LANs you do know about. For non adjacent L3 routers that are tunneled over some encapsulation if the adjacency fails to form then the tunnel is simply not used. You don't change the behavior of your direct L3 links nor do you change the behavior of your L2 links. If you can't form an adjacency over a LAN you just don't use that link. (This is in line with Mike's point below.) The key difference here is RBridge cares about he total number of RBridges connected to the LAN (potential adjacencies) and at the same time the total number of RBridges that are truly adjacent on the LAN. There is no locally determined fall back position. a)If the connected number is 1 you have one behavior. (No adjacencies or IS-IS not even getting Hellos through.) b)If the connected number is 2 or more you have another behavior and must do election (Delivered IS-IS Hellos regardless of whether IS-IS forms a proper adjacency or not.) c)If you form one or more adjacencies you may be the appointed forwarder even if you are not the DRB. (2 or more functioning IS-IS adjacencies). I'm not sure we have covered all the corner cases for this behavior. And the operating behavior is determined by each RBridge locally. Regards, Don > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of mike shand > Sent: Wednesday, April 01, 2009 4:36 AM > To: Radia Perlman > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Radia Perlman wrote: > > 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 > > > Radia, > > Does this proviso help to avoid the problem? Or is it something else > which would need to be changed to ensure that a lone Rbridge DOES get > elected DRB? > > ISO/IEC 10589 v2 clause 8.4.5 (penultimate para) > > "An Intermediate system shall not declare itself to be a LAN > Designated > Intermediate system of any type until it has at least one "Up" End > system (not including manual adjacencies) or Intermediate system > adjacency on the circuit. (This prevents an Intermediate System which > has a defective receiver and is incapable of receiving any PDUs from > erroneously electing itself LAN Designated Intermediate System.)" > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From harih at cisco.com Wed Apr 1 09:42:15 2009 From: harih at cisco.com (Hari Balasubramanian (harih)) Date: Wed, 1 Apr 2009 09:42:15 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <5f4fcb067142.49d35876@sunlabs.com> References: <5f4fcb067142.49d35876@sunlabs.com> Message-ID: <1CCF0A858F9B194FABEA71E9B65EA88B08EB3F74@xmb-sjc-214.amer.cisco.com> > that behavior is OK for layer 3 IS-IS, where having multiple DRBs on a link > is not fatal. Radia, I am not sure if I understand why having multiple DRBs on a link for Layer 3 is ok ( or "not fatal")? Can you explain a bit? Thanks, Hari > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com > Sent: Wednesday, April 01, 2009 4:05 AM > To: Mike Shand (mshand) > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Mike, > > The text you quoted does imply different behavior than TRILL > has to have. > I don't know if the behavior I'd assumed for IS-IS got lost > in translation from DECnet, or perhaps actually specified > that way for DECnet, but at any rate, even though the > behavior isn't what I remembered it as being, that behavior > is OK for layer 3 IS-IS, where having multiple DRBs on a link > is not fatal. > > But it is *not* OK for TRILL. > > Even with the extra phrase (clause 8.4.5) you quoted, that > would still be fatal behavior for TRILL. It could be that R1 > has highest (numerically lowest?) priority for being DRB, but > R2 and R3 can't handle the MTU, or don't communicate on R1's > designated VLAN, or whatever, and then R2 and R3 could still > have an 'adjacency' to each other, so R2 might decide it, > too, is DRB. There might be an R4 that R1 does have an > 'adjacency' to, so both R1 and R2 would decide to be DRBs. > > And even if there is no other 'up' adjacency, and there's > only a single RBridge, say R1, on a link, R1 has to become > the designated forwarder, and act like the DRB on that link, > except it doesnt' have to send CSNPs of forward LSPs (no > RBridge neighbors). > > So regardless of the terminology of what it means to 'have an > adjacency' or 'be DRB', TRILL IS-IS has to behave like I said > in the previous emails -- regardless of whether R1 (the DRB) > can hear you, for whatever reason it might not be able to > hear you (VLAN mismatch, MTU mismatch, one-way connectivity > due to bizarre hardware), you MUST NOT try to also become DRB. > > For TRILL, we have to be super conservative to make sure that > multiple RBridges are not attempting to become Designated > Forwarder on the same link. So if R2 can hear R1, and R1's > hellos indicate it would win the DRB election, R2 MUST defer to R1. > > Radia > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From erik.nordmark at sun.com Wed Apr 1 13:01:23 2009 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 01 Apr 2009 13:01:23 -0700 Subject: [rbridge] Updated goals and milestones Message-ID: <49D3C813.6010400@sun.com> At the San Francisco IETF we discussed the WG goals and milestones. We will drop the architecture document. Rich Groves has volunteered to start looking at the MIBs to we can add a goal for at least an initial draft. The updated goals and milestones are: April 2009 Submit base protocol specification to IEEE/IETF expert review Aug 2009 First draft showing what is needed for MIB May 2009 Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC July 2010 Re-charter or shut down the WG Comments? Erik From Radia.Perlman at sun.com Wed Apr 1 17:33:31 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 01 Apr 2009 17:33:31 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <1CCF0A858F9B194FABEA71E9B65EA88B08EB3F74@xmb-sjc-214.amer.cisco.com> References: <5f4fcb067142.49d35876@sunlabs.com> <1CCF0A858F9B194FABEA71E9B65EA88B08EB3F74@xmb-sjc-214.amer.cisco.com> Message-ID: <49D407DB.70208@sun.com> Hari Balasubramanian (harih) wrote: > > Radia, I am not sure if I understand why having multiple DRBs on a link > for Layer 3 is ok ( or "not fatal")? Can you explain a bit? > > Thanks, Hari > > Suppose there is a link with 4 routers: R1, R2, R3, and R4, and for whatever reason, R1 and R2 have 2-way connectivity with each other, and R3 and R4 have 2-way connectivity with each other. It would be OK for R1 and R3 to both become DRBs, create a pseudonode for the link, and to routers distant from the link, based on LSPs, it would look like 2 links; one that connects R1 and R2, and one that connects R3 and R4. The two cliques ({R1, R2}, and {R3, R4}) would pretty much ignore each other. Both R1 and R3 would be sending CSNPs. I don't see any harm from this behavior. Even if, say, R5 were part of both cliques (but R5 is not DRB in either clique), I don't see a problem. I presume (I'd have to read, or be pointed to, the exact wording of the IS-IS spec) that R5, in this case would either a) choose to be part of one clique and ignore the other one, or b) claim to be connected to both "R1.x" and "R3.y". Mike? Do you know which thing would happen? But at any rate, I don't see any problem caused by either of those cases (on the other hand, I'm in an airport lounge having just flown transatlanticly, and not slept recently, so there might be a problem with it). But I definitely know that with TRILL it would be a big problem. Radia From d3e3e3 at gmail.com Wed Apr 1 18:10:32 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 1 Apr 2009 21:10:32 -0400 Subject: [rbridge] multiple nicknames in an LSP? In-Reply-To: <49CFBE44.4010404@sun.com> References: <49CFBE44.4010404@sun.com> Message-ID: <1028365c0904011810m2ccd31cdxe830114bd993845c@mail.gmail.com> There seem to be a number of complexities in this idea but no big advantages obvious to me over just using multiple trees with different roots. Complexities include the question of whether these multiple nicknames for the same RBridge have different or similar priorities (priorities for the RBridge to hold that nickname). Note that one of the nicknames could collide and have to be changes while the other might not... Then there is the need to have a different tie breaker, otherwise you don't get different trees. So how is this new and different tie breaker going to work? Tie breaking can be thought of as comparing the value of a function of various parameters related to the links between which the choice is being made. The current function is the identity function of the system ID at the other end of the link. So what's the new function? MD5 ( SystemID, root nickname )? And why are we doing all this instead of just having more trees rooted at other RBridges? Donald See also comment below. On Sun, Mar 29, 2009 at 2:30 PM, Radia Perlman wrote: > 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. Hi Ayan, I don't understand what you are saying above. It makes no difference with the current tie breaker what the root of a tree is called. If the tree is calculated in the same way, it will use the identical links. The only way I can see to make the trees different through different root RBridge nicknames is to make the tie breaker decisions depend in some complex way on a function which takes as one of its inputs the root RBridge nickname. >>> Radia >> _______________________________________________ >> 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 Radia.Perlman at sun.com Thu Apr 2 00:31:20 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 02 Apr 2009 00:31:20 -0700 Subject: [rbridge] multiple nicknames in an LSP? In-Reply-To: <1028365c0904011810m2ccd31cdxe830114bd993845c@mail.gmail.com> References: <49CFBE44.4010404@sun.com> <1028365c0904011810m2ccd31cdxe830114bd993845c@mail.gmail.com> Message-ID: <49D469C8.5040201@sun.com> Donald Eastlake wrote: > > And why are we doing all this instead of just having more trees rooted > at other RBridges? > > Donald > On the theory that you want multiple shortest path trees from R1. If you calculate a tree from a different root, the paths from R1 might not be so great. If you really just want to load split traffic emanating from R1, you'd want shortest paths from R1 -- that's the theory, but as you point out, we need some sort of tie breaker that is different for each nickname, either using the nickname itself as a salt for tie breaking, or an explicit salt, or something else (like the order in which the nicknames are listed in R1's LSP). And as you point out, there are other issues, like whether there is a separate priority for each nickname, or whatever... Radia From mshand at cisco.com Thu Apr 2 01:25:57 2009 From: mshand at cisco.com (mike shand) Date: Thu, 02 Apr 2009 09:25:57 +0100 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D407DB.70208@sun.com> References: <5f4fcb067142.49d35876@sunlabs.com> <1CCF0A858F9B194FABEA71E9B65EA88B08EB3F74@xmb-sjc-214.amer.cisco.com> <49D407DB.70208@sun.com> Message-ID: <49D47695.6030703@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090402/c12b7f26/attachment.html From mshand at cisco.com Thu Apr 2 05:48:04 2009 From: mshand at cisco.com (mike shand) Date: Thu, 02 Apr 2009 13:48:04 +0100 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <5fc07485440.49d365b1@sunlabs.com> References: <5fc07485440.49d365b1@sunlabs.com> Message-ID: <49D4B404.5000805@cisco.com> Radia, Re-reading draft-ietf-trill-rbridge-protocol-12, isn't the combination of adjacency hellos and protection hellos essentially the same as what I proposed below? So why are you proposing that it should be reversed to have non-padded IS-IS hellos (which would also have to have the IS-IS rules changed with respect to not using only UP adjacencies and still electing even when there are no other adjacencies) and (optional?) MTU discovery hellos, which interact in some yet to be completely specified way with the adjacency formation rules. Why is that better than what seems to be the natural approach of keeping the IS-IS stuff unchanged and adding something which has the required TRILL semantics for the identification of the forwarders. It seems to have traded two hellos, one of which was identical to the existing IS-IS mechanisms, for two hellos, neither of which are the same as IS-IS. Mike Radia.Perlman at sun.com wrote: > Mike Shand said: > > So would it make more sense to leave the hellos, adjacency > establishment rules, DIS election exactly as it is for IS-IS and use > THAT for the IS-IS related stuff like generating pseudonodes, running > the LAN reliable update process and advertising connectivity, and then > have a new small TRILL hello which behaved the way you described and use > that for electing the DRB from the point of view of determining who does > the forwarding? > > Mike > > **************************************** > > I don't think so. It's basically the same thing, with some different rules. > If we did the TRILL Hellos and DRB election, we wouldn't need the other > one also. So I think we should just modify the rules for TRILL. > > It's possible we should even rewrite the spec for exactly how TRILL IS-IS should work. > There isn't any other IETF protocol that doesn't get updated every few years with new versions. > > Radia > > > From Radia.Perlman at sun.com Thu Apr 2 09:49:36 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 02 Apr 2009 09:49:36 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D4B404.5000805@cisco.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> Message-ID: <49D4ECA0.2060407@sun.com> Mike, Personally, I would have been OK with what was in the latest version of the spec (I think I might even have been the one that suggested that solution on the mailing list), but it did not get a warm reception at the WG meeting in San Fransisco. Two types of hellos, padded and unpadded, being sent on different VLANs -- it seemed unnecessarily complicated, and indeed I kind of tripped over my words as I was trying to describe it. People were saying that Hellos should be for finding neighbors, not also for MTU discovery. After hearing people's concerns and suggestions, I described what I thought would go over better, and actually, I like it much better. a) Hellos just as we'd specified it before Jim Carlson noticed the problem with padded hellos, but adding to the spec that TRILL Hellos MUST NOT be padded. b) Having a separate protocol, that actually works better I think, for MTU discovery, where to allow it to be optional, we add a flag to the Hello saying "I support MTU discovery", and then having an MTU discovery protocol where R1 sends a padded message of some size, and other RBridges on the link that hear that message reply with an ack to R1. Radia mike shand wrote: > Radia, > Re-reading draft-ietf-trill-rbridge-protocol-12, isn't the > combination of adjacency hellos and protection hellos essentially the > same as what I proposed below? So why are you proposing that it should > be reversed to have non-padded IS-IS hellos (which would also have to > have the IS-IS rules changed with respect to not using only UP > adjacencies and still electing even when there are no other > adjacencies) and (optional?) MTU discovery hellos, which interact in > some yet to be completely specified way with the adjacency formation > rules. Why is that better than what seems to be the natural approach > of keeping the IS-IS stuff unchanged and adding something which has > the required TRILL semantics for the identification of the > forwarders. It seems to have traded two hellos, one of which was > identical to the existing IS-IS mechanisms, for two hellos, neither of > which are the same as IS-IS. > > Mike > From d3e3e3 at gmail.com Thu Apr 2 11:06:58 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 2 Apr 2009 14:06:58 -0400 Subject: [rbridge] San Francisco TRILL WG Meeting Minutes posted Message-ID: <1028365c0904021106o4331328hfaec0e0e2bcc5c14@mail.gmail.com> Hi, The draft minutes from meeting of the TRILL WG in San Francisco have been uploaded to the meeting materials page: https://datatracker.ietf.org/meeting/74/materials.html Corrections welcome. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Thu Apr 2 12:37:55 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 2 Apr 2009 15:37:55 -0400 Subject: [rbridge] 3 Week WG Last Call on draft-ietf-trill-rbridge-vlan-mapping-00.txt Message-ID: <1028365c0904021237g1a605813g3f08f2fb54318ed4@mail.gmail.com> Hi, This message initiates a three week TRILL working group Last Call on draft-ietf-trill-rbridge-vlan-mapping-00.txt, RBridge VLAN Mapping, as discussed in San Francisco. Donald and Erik (co-chairs) ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Thu Apr 2 16:04:07 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 2 Apr 2009 19:04:07 -0400 Subject: [rbridge] San Francisco TRILL WG Meeting Minutes posted In-Reply-To: <1028365c0904021106o4331328hfaec0e0e2bcc5c14@mail.gmail.com> References: <1028365c0904021106o4331328hfaec0e0e2bcc5c14@mail.gmail.com> Message-ID: <1028365c0904021604s442d2f6ai509a019dc25fb6d3@mail.gmail.com> Updated minutes have been uploaded with minor changes to the section concerning IEEE 802.1 comments on the protocol specification. Donald On Thu, Apr 2, 2009 at 2:06 PM, Donald Eastlake wrote: > Hi, > > The draft minutes from meeting of the TRILL WG in San Francisco have > been uploaded to the meeting materials page: > https://datatracker.ietf.org/meeting/74/materials.html > > Corrections welcome. > > 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 From eric.gray at ericsson.com Fri Apr 3 04:03:46 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 3 Apr 2009 06:03:46 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D4ECA0.2060407@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> Radia, I liked the wording of the second part of this better in your previous posting - i.e. - where the mechanism used for MTU discovery is clearly to be specified separately. As I mentioned during the meeting, there are capabilties at the L2 level that can be used to determine the L2 MTU size. Since this is clearly a general problem for L2 networks, defining a solution for it in the IETF - particularly one that is very specific to a single application - is probably not appropriate. -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Thursday, April 02, 2009 12:50 PM To: TRILL/RBridge Working Group Subject: Re: [rbridge] Proposed compromise for short/long hellos Mike, Personally, I would have been OK with what was in the latest version of the spec (I think I might even have been the one that suggested that solution on the mailing list), but it did not get a warm reception at the WG meeting in San Fransisco. Two types of hellos, padded and unpadded, being sent on different VLANs -- it seemed unnecessarily complicated, and indeed I kind of tripped over my words as I was trying to describe it. People were saying that Hellos should be for finding neighbors, not also for MTU discovery. After hearing people's concerns and suggestions, I described what I thought would go over better, and actually, I like it much better. a) Hellos just as we'd specified it before Jim Carlson noticed the problem with padded hellos, but adding to the spec that TRILL Hellos MUST NOT be padded. b) Having a separate protocol, that actually works better I think, for MTU discovery, where to allow it to be optional, we add a flag to the Hello saying "I support MTU discovery", and then having an MTU discovery protocol where R1 sends a padded message of some size, and other RBridges on the link that hear that message reply with an ack to R1. Radia mike shand wrote: > Radia, > Re-reading draft-ietf-trill-rbridge-protocol-12, isn't the > combination of adjacency hellos and protection hellos essentially the > same as what I proposed below? So why are you proposing that it should > be reversed to have non-padded IS-IS hellos (which would also have to > have the IS-IS rules changed with respect to not using only UP > adjacencies and still electing even when there are no other > adjacencies) and (optional?) MTU discovery hellos, which interact in > some yet to be completely specified way with the adjacency formation > rules. Why is that better than what seems to be the natural approach > of keeping the IS-IS stuff unchanged and adding something which has > the required TRILL semantics for the identification of the > forwarders. It seems to have traded two hellos, one of which was > identical to the existing IS-IS mechanisms, for two hellos, neither of > which are the same as IS-IS. > > Mike > _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From mshand at cisco.com Fri Apr 3 04:29:28 2009 From: mshand at cisco.com (mike shand) Date: Fri, 03 Apr 2009 12:29:28 +0100 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> Message-ID: <49D5F318.4000600@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090403/299f7997/attachment.html From eric.gray at ericsson.com Fri Apr 3 06:56:29 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 3 Apr 2009 08:56:29 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D5F318.4000600@cisco.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> Mike, Based on the discussion thus far, the ideal solution would be something along the lines of the following: 1) Padding of IS-IS messages would be optional (we could argue what the default would be) - and would be determined either by configuration, or by any method an implementation may choose (for example, an implementation might simply elect to remove padding if a sharp rise in congestion indications is noted - for example, a sudden and continuous stream of buffer overflow indications from forwarding components). 2) RBridge implementations MUST NOT reject a hello message because it is not padded - for whatever reason. 3) RBridge implementations MUST NOT make any assumptions based on the size of a hello PDU (such as guessing that this is the peer's MTU size), unless there is an explicit indication that a specific hello PDU is padded. I would argue that padding of the RBridge IS-IS messages would be done if there is any way for a specific implementation to be certain that the MTU size used in padding is well known. This would be the case if a pair of RBridge implementations has any sort of MTU discovery mechanism that will determine an accurate MTU size, if there is a useful minimum MTU size defined for the technology (useful in that it is large enough to support at least a maximum size un-fragmentable control message), or if the network operator is certain enough of this size to enable padding. I would also argue that - if there is a mechanism capable of being used for MTU discovery - MTU discovery/determination should occur BEFORE the DRB (and/or designated forwarder) determination process begins (and certainly before forwarding begins), and would be repeated periodically after this is done. -- Eric ________________________________ From: mike shand [mailto:mshand at cisco.com] Sent: Friday, April 03, 2009 7:29 AM To: Eric Gray Cc: Radia Perlman; TRILL/RBridge Working Group Subject: Re: [rbridge] Proposed compromise for short/long hellos Importance: High Eric Gray wrote: Radia, I liked the wording of the second part of this better in your previous posting - i.e. - where the mechanism used for MTU discovery is clearly to be specified separately. As I mentioned during the meeting, there are capabilties at the L2 level that can be used to determine the L2 MTU size. Since this is clearly a general problem for L2 networks, defining a solution for it in the IETF - particularly one that is very specific to a single application - is probably not appropriate. But IS-IS requires the enforcement of a minimum MTU size to ensure that its LSPs are correctly delivered and it already has the mechanism to do that (in the padded hellos). Why change that? Mike -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Thursday, April 02, 2009 12:50 PM To: TRILL/RBridge Working Group Subject: Re: [rbridge] Proposed compromise for short/long hellos Mike, Personally, I would have been OK with what was in the latest version of the spec (I think I might even have been the one that suggested that solution on the mailing list), but it did not get a warm reception at the WG meeting in San Fransisco. Two types of hellos, padded and unpadded, being sent on different VLANs -- it seemed unnecessarily complicated, and indeed I kind of tripped over my words as I was trying to describe it. People were saying that Hellos should be for finding neighbors, not also for MTU discovery. After hearing people's concerns and suggestions, I described what I thought would go over better, and actually, I like it much better. a) Hellos just as we'd specified it before Jim Carlson noticed the problem with padded hellos, but adding to the spec that TRILL Hellos MUST NOT be padded. b) Having a separate protocol, that actually works better I think, for MTU discovery, where to allow it to be optional, we add a flag to the Hello saying "I support MTU discovery", and then having an MTU discovery protocol where R1 sends a padded message of some size, and other RBridges on the link that hear that message reply with an ack to R1. Radia mike shand wrote: Radia, Re-reading draft-ietf-trill-rbridge-protocol-12, isn't the combination of adjacency hellos and protection hellos essentially the same as what I proposed below? So why are you proposing that it should be reversed to have non-padded IS-IS hellos (which would also have to have the IS-IS rules changed with respect to not using only UP adjacencies and still electing even when there are no other adjacencies) and (optional?) MTU discovery hellos, which interact in some yet to be completely specified way with the adjacency formation rules. Why is that better than what seems to be the natural approach of keeping the IS-IS stuff unchanged and adding something which has the required TRILL semantics for the identification of the forwarders. It seems to have traded two hellos, one of which was identical to the existing IS-IS mechanisms, for two hellos, neither of which are the same as IS-IS. Mike _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090403/c76f98c2/attachment-0001.html From harih at cisco.com Fri Apr 3 08:26:57 2009 From: harih at cisco.com (Hari Balasubramanian (harih)) Date: Fri, 3 Apr 2009 08:26:57 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D407DB.70208@sun.com> References: <5f4fcb067142.49d35876@sunlabs.com> <1CCF0A858F9B194FABEA71E9B65EA88B08EB3F74@xmb-sjc-214.amer.cisco.com> <49D407DB.70208@sun.com> Message-ID: <1CCF0A858F9B194FABEA71E9B65EA88B08F4334D@xmb-sjc-214.amer.cisco.com> Please see inline.... > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Wednesday, April 01, 2009 5:34 PM > To: Hari Balasubramanian (harih) > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Hari Balasubramanian (harih) wrote: > > > > Radia, I am not sure if I understand why having multiple DRBs on a > > link for Layer 3 is ok ( or "not fatal")? Can you explain a bit? > > > > Thanks, Hari > > > > > > Suppose there is a link with 4 routers: R1, R2, R3, and R4, > and for whatever reason, R1 and R2 have 2-way connectivity > with each other, and R3 and R4 have 2-way connectivity with > each other. > > It would be OK for R1 and R3 to both become DRBs, create a > pseudonode for the link, and to routers distant from the > link, based on LSPs, it would look like 2 links; one that > connects R1 and R2, and one that connects R3 and R4. The two > cliques ({R1, R2}, and {R3, R4}) would pretty much ignore each other. > > Both R1 and R3 would be sending CSNPs. Is there not a possiblity of duplicate packets being sent out (for multicast packets) as both R1 & R3 believe they are the DR for the LAN? Are you suggesting that duplicate packets are ok as long as they don't cause loops (as it would in TRILL under similar conditions, I think)? > > I don't see any harm from this behavior. > > Even if, say, R5 were part of both cliques (but R5 is not DRB > in either clique), I don't see a problem. > I presume (I'd have to read, or be pointed to, the exact > wording of the IS-IS spec) that R5, in this case would either > a) choose to be part of one clique and ignore the other one, or > b) claim to be connected to both "R1.x" and "R3.y". > > Mike? Do you know which thing would happen? > > But at any rate, I don't see any problem caused by either of > those cases (on the other hand, I'm in an airport lounge > having just flown transatlanticly, and not slept recently, so > there might be a problem with it). > > But I definitely know that with TRILL it would be a big problem. > > Radia > From james.d.carlson at Sun.COM Fri Apr 3 08:08:45 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 3 Apr 2009 11:08:45 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> Message-ID: <18902.9853.482320.518395@gargle.gargle.HOWL> Eric Gray writes: > 1) Padding of IS-IS messages would be optional (we could argue what > the default No. We can't do that, because it runs right into the original problem that I described. With "normal" IS-IS used for routing, the padding serves as a protective device: if I can't hear your Hello messages because there's an MTU restriction somewhere between us, then I won't peer with you, and I won't try to route anything through you. The failure mode is only a loss of connectivity. With IS-IS as used for TRILL, the padding is toxic. If I can't hear your Hello messages, then I'll assume that *I* am the DRB, and I'll begin forwarding for all the VLANs I know about. If you can't hear me, you'll do the same. And that potentially results in an L2 forwarding loop for all frames that are of a size less than the MTU restriction: a very *BAD* failure mode. It's the exact opposite of the L3 routing scenario. For Hellos used as a protective device, we *cannot* safely pad out to the locally known MTU. > 2) RBridge implementations MUST NOT reject a hello message because > it is not > 3) RBridge implementations MUST NOT make any assumptions based on > the size If either of those really needs to be specified, then I think we've got much bigger problems to wrestle than just the MTU issue. > I would also argue that - if there is a mechanism capable of being > used for MTU > discovery - MTU discovery/determination should occur BEFORE the DRB > (and/or > designated forwarder) determination process begins (and certainly before > forwarding > begins), and would be repeated periodically after this is done. Yes. DRB selection must be conditional on it, which is why doing it with the Hello messages is quite useful. But we could obviously specify something different. -- 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 Fri Apr 3 08:59:43 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Fri, 3 Apr 2009 11:59:43 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18902.9853.482320.518395@gargle.gargle.HOWL> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> Hi James Please see inline: > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > Sent: Friday, April 03, 2009 11:09 AM > To: Eric Gray > Cc: TRILL/RBridge Working Group; Radia Perlman > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Eric Gray writes: > > 1) Padding of IS-IS messages would be optional (we > could argue what > > the default > > No. We can't do that, because it runs right into the original problem > that I described. > > With "normal" IS-IS used for routing, the padding serves as a > protective device: if I can't hear your Hello messages because there's > an MTU restriction somewhere between us, then I won't peer with you, > and I won't try to route anything through you. The failure mode is > only a loss of connectivity. > > With IS-IS as used for TRILL, the padding is toxic. If I can't hear > your Hello messages, then I'll assume that *I* am the DRB, and I'll > begin forwarding for all the VLANs I know about. If you can't hear > me, you'll do the same. And that potentially results in an L2 > forwarding loop for all frames that are of a size less than the MTU > restriction: a very *BAD* failure mode. It's the exact opposite of > the L3 routing scenario. > People are avioding the real issue here: It is not the padding that is toxic. It is the use of a discovery protocol where the failure/absense of the protocol results in RBridges self electing themselves the DRB. Whether or not you use IS-IS hellos to discover or some new fangled protocol, any failure of the discovery protocol results in this undesirable behavior. Yes IS-IS with padding may be a less robust discovery protocol but it was not designed for this purpose. And repurposing the IS-IS design only reduses the problem it does not eliminate it. Don > For Hellos used as a protective device, we *cannot* safely pad out to > the locally known MTU. > > > 2) RBridge implementations MUST NOT reject a hello > message because > > it is not > > 3) RBridge implementations MUST NOT make any > assumptions based on > > the size > > If either of those really needs to be specified, then I think we've > got much bigger problems to wrestle than just the MTU issue. > > > I would also argue that - if there is a mechanism > capable of being > > used for MTU > > discovery - MTU discovery/determination should occur BEFORE the DRB > > (and/or > > designated forwarder) determination process begins (and > certainly before > > forwarding > > begins), and would be repeated periodically after this is done. > > Yes. DRB selection must be conditional on it, which is why doing it > with the Hello messages is quite useful. But we could obviously > specify something different. > > -- > 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 > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Fri Apr 3 09:02:12 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 3 Apr 2009 11:02:12 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18902.9853.482320.518395@gargle.gargle.HOWL> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> James, You took my message and replied to it in a way that seems to deliberately remove relevant context. If it was as deliberate as it seems, it would be questionable professional behavior. Presumably it was simply accidental. With the original context, you are merely agreeing with what I said, and arguing that padding should not be the default. You should be aware that I have not - precisely - argued that it should be the default. In my opinion, if padding MUST be on by default, then pair-wise MTU discovery MUST occur first. Note that I am saying "MTU discovery", not the pass-fail form of MTU verification that has so far been explicitly suggested in this thread. The reason why the 2nd and third items would need to be specified is that doing so is necessary if you really want to be allowed the option of not doing padding. When people say that we simply would not do the padding, what they have not explicitly added is the bit about "and everything that IS-IS implementations out there in the world might do based on the assumption that padding is used." And I've not really heard a proposal for doing MTU discovery using the hello protocol. At most, what has been proposed is MTU verification, assuming that some value is assumed, or configured, at each peer. Thanks! -- Eric -----Original Message----- From: James Carlson [mailto:james.d.carlson at Sun.COM] Sent: Friday, April 03, 2009 11:09 AM To: Eric Gray Cc: mike shand; TRILL/RBridge Working Group; Radia Perlman Subject: Re: [rbridge] Proposed compromise for short/long hellos Importance: High Eric Gray writes: > 1) Padding of IS-IS messages would be optional (we could argue what > the default No. We can't do that, because it runs right into the original problem that I described. With "normal" IS-IS used for routing, the padding serves as a protective device: if I can't hear your Hello messages because there's an MTU restriction somewhere between us, then I won't peer with you, and I won't try to route anything through you. The failure mode is only a loss of connectivity. With IS-IS as used for TRILL, the padding is toxic. If I can't hear your Hello messages, then I'll assume that *I* am the DRB, and I'll begin forwarding for all the VLANs I know about. If you can't hear me, you'll do the same. And that potentially results in an L2 forwarding loop for all frames that are of a size less than the MTU restriction: a very *BAD* failure mode. It's the exact opposite of the L3 routing scenario. For Hellos used as a protective device, we *cannot* safely pad out to the locally known MTU. > 2) RBridge implementations MUST NOT reject a hello message because > it is not > 3) RBridge implementations MUST NOT make any assumptions based on > the size If either of those really needs to be specified, then I think we've got much bigger problems to wrestle than just the MTU issue. > I would also argue that - if there is a mechanism capable of being > used for MTU > discovery - MTU discovery/determination should occur BEFORE the DRB > (and/or > designated forwarder) determination process begins (and certainly before > forwarding > begins), and would be repeated periodically after this is done. Yes. DRB selection must be conditional on it, which is why doing it with the Hello messages is quite useful. But we could obviously specify something different. -- 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 james.d.carlson at Sun.COM Fri Apr 3 10:29:48 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 3 Apr 2009 13:29:48 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> Message-ID: <18902.18316.963432.341063@gargle.gargle.HOWL> Eric Gray writes: > You took my message and replied to it in a way that seems > to deliberately remove relevant context. If it was as deliberate > as it seems, it would be questionable professional behavior. > > Presumably it was simply accidental. It must have been. I have no clue what you're talking about. > With the original context, you are merely agreeing with > what I said, and arguing that padding should not be the default. No, I'm saying that it _can't_ be optional. It has to be a MUST NOT, and not an option. That's why I was responding to that part of your message. It's required that RBridges be able to "see" each other if they're connected by any other L2 forwarding mechanism, such as a traditional 802 bridge. > You should be aware that I have not - precisely - argued > that it should be the default. In my opinion, if padding MUST > be on by default, then pair-wise MTU discovery MUST occur first. > Note that I am saying "MTU discovery", not the pass-fail form of > MTU verification that has so far been explicitly suggested in > this thread. That's not clear to me. How does this pairwise MTU discovery work? If we make padding a "MUST NOT," and then invent a new mechanism for MTU discovery, then I understand exactly how it works: you exchange MTU-sized messages with all of your neighbors (as seen by Hello), and if any of them fail, then you can handle that as an MTU-failed adjacency. If we do pairwise MTU discovery first, as I think you're suggesting, then I don't see how that can function. How does MTU discovery know what peers must be checked? Does it have its own discovery protocol as well that runs first? > The reason why the 2nd and third items would need to be > specified is that doing so is necessary if you really want to > be allowed the option of not doing padding. When people say > that we simply would not do the padding, what they have not > explicitly added is the bit about "and everything that IS-IS > implementations out there in the world might do based on the > assumption that padding is used." I'm not following. Can you clarify what those other things might be? What other assumptions, besides verifying that the path can handle MTU-sized messages, are implementations making? If you know about some other assumptions, I'd like to hear about them. > And I've not really heard a proposal for doing MTU discovery > using the hello protocol. At most, what has been proposed is MTU > verification, assuming that some value is assumed, or configured, > at each peer. The MTU is verified by the existing Hello protocol simply by having large packets fail to get through any hidden restrictions in the network. Whether you want to call that "discovery" or "verification," I don't quite see how it matters. -- 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 james.d.carlson at Sun.COM Fri Apr 3 10:22:24 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 3 Apr 2009 13:22:24 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> Message-ID: <18902.17872.316711.466008@gargle.gargle.HOWL> Don Fedyk writes: > > With IS-IS as used for TRILL, the padding is toxic. If I can't hear > > your Hello messages, then I'll assume that *I* am the DRB, and I'll > > begin forwarding for all the VLANs I know about. If you can't hear > > me, you'll do the same. And that potentially results in an L2 > > forwarding loop for all frames that are of a size less than the MTU > > restriction: a very *BAD* failure mode. It's the exact opposite of > > the L3 routing scenario. > > > People are avioding the real issue here: > > It is not the padding that is toxic. It is the use of a discovery > protocol where the failure/absense of the protocol results in RBridges > self electing themselves the DRB. The padding leads to non-discovery, and non-discovery leads to forwarding loops. I believe that what you're suggesting is that there's a different place to break this chain. What I don't see is where that place would be. If it's not in eliminating the padding, then where is it? Are you suggesting that nodes that see no other devices on the network should not become DRB on their own? If so, then what forwards on and off of stub networks? > Whether or not you use IS-IS hellos > to discover or some new fangled protocol, any failure of the discovery > protocol results in this undesirable behavior. Correct. This is just one way to cause the problem. > Yes IS-IS with padding > may be a less robust discovery protocol but it was not designed for this > purpose. And repurposing the IS-IS design only reduses the problem it > does not eliminate it. I'm unsure what you're suggesting as an alternative. Could you clarify? -- 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 eric.gray at ericsson.com Fri Apr 3 11:28:30 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 3 Apr 2009 13:28:30 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18902.18316.963432.341063@gargle.gargle.HOWL> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> <18902.18316.963432.341063@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> James, So, that being the case, I have to disagree with you. Also, I strongly suspect you'll find a large number of other people will as well. The problem you saw was simply the result of faulty network equipment. You can argue about my use of the term "faulty" in this case, but - in my lexicon - any device that purports to be an Ethernet device is required to support forwarding of a frames of a certain size and any such device that does not do so is faulty. But set that aside for a minute. It's clear that - faulty or not - it creates a very serious problem if there is a mismatch of configured and real MTU sizes. But there are really good reasons why IS-IS does what it does. Hence there are reasons to avoid changing how IS-IS operates arbitrarily. If you want to change IS-IS in some critical ways, you're better off choosing another protocol. In this case, provided you meet the conditions I stated, then it is absolutely okay to pad IS-IS messages just as is being done in IS-IS today. Now, before you reply, re-read what I said previously (of course, those conditions appear to have been omitted below, so I am reinserting them here): > I would also argue that - if there is a mechanism capable of being > used for MTU discovery - MTU discovery/determination should occur > BEFORE the DRB (and/or designated forwarder) determination process > begins (and certainly before forwarding begins), and would be > repeated periodically after this is done. If you read this carefully, what I am saying is that - if it's possible for a pair of RBridge peers to know exactly what the real MTU size is between them - then padding of IS-IS hello messages is okay. In fact, it's more than okay because - implicit in what I said - particularly in the context in which I said it (a reply to Mike Shand in which I am trying to state an ideal solution given all of the preceding discussion), padding is actually preferred. What you're doing is conflating the MTU discovery process and the use of IS-IS hello messages. There are other mechanisms that can be used and - since this is a general problem that applies to L2 network generally - it is likely that people already have solutions of this type in play. Where ANY other solution may already exist, your proposal to modify IS-IS is unnacceptable. A far cleaner approach is to simply state something along the lines of "unless a mechanism is in place to ascertain that a padded IS-IS hello message will be delivered to all connected RBridges, IS-IS hello padding is disabled." If you want to propose modifying an IS-IS hello message in some way, as a means for doing this, that's fine - but do it on your own nickle. I don't think we need it, and - unless it does more than a simple "yes/no" verification of a configured MTU size - I don't think it's particularly useful. -- Eric -----Original Message----- From: James Carlson [mailto:james.d.carlson at Sun.COM] Sent: Friday, April 03, 2009 1:30 PM To: Eric Gray Cc: mike shand; TRILL/RBridge Working Group; Radia Perlman Subject: RE: [rbridge] Proposed compromise for short/long hellos Importance: High Eric Gray writes: > You took my message and replied to it in a way that seems > to deliberately remove relevant context. If it was as deliberate > as it seems, it would be questionable professional behavior. > > Presumably it was simply accidental. It must have been. I have no clue what you're talking about. > With the original context, you are merely agreeing with > what I said, and arguing that padding should not be the default. No, I'm saying that it _can't_ be optional. It has to be a MUST NOT, and not an option. That's why I was responding to that part of your message. It's required that RBridges be able to "see" each other if they're connected by any other L2 forwarding mechanism, such as a traditional 802 bridge. > You should be aware that I have not - precisely - argued > that it should be the default. In my opinion, if padding MUST > be on by default, then pair-wise MTU discovery MUST occur first. > Note that I am saying "MTU discovery", not the pass-fail form of > MTU verification that has so far been explicitly suggested in > this thread. That's not clear to me. How does this pairwise MTU discovery work? If we make padding a "MUST NOT," and then invent a new mechanism for MTU discovery, then I understand exactly how it works: you exchange MTU-sized messages with all of your neighbors (as seen by Hello), and if any of them fail, then you can handle that as an MTU-failed adjacency. If we do pairwise MTU discovery first, as I think you're suggesting, then I don't see how that can function. How does MTU discovery know what peers must be checked? Does it have its own discovery protocol as well that runs first? > The reason why the 2nd and third items would need to be > specified is that doing so is necessary if you really want to > be allowed the option of not doing padding. When people say > that we simply would not do the padding, what they have not > explicitly added is the bit about "and everything that IS-IS > implementations out there in the world might do based on the > assumption that padding is used." I'm not following. Can you clarify what those other things might be? What other assumptions, besides verifying that the path can handle MTU-sized messages, are implementations making? If you know about some other assumptions, I'd like to hear about them. > And I've not really heard a proposal for doing MTU discovery > using the hello protocol. At most, what has been proposed is MTU > verification, assuming that some value is assumed, or configured, > at each peer. The MTU is verified by the existing Hello protocol simply by having large packets fail to get through any hidden restrictions in the network. Whether you want to call that "discovery" or "verification," I don't quite see how it matters. -- 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 james.d.carlson at Sun.COM Fri Apr 3 12:24:26 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 3 Apr 2009 15:24:26 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> <18902.18316.963432.341063@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> Message-ID: <18902.25194.624818.417591@gargle.gargle.HOWL> Eric Gray writes: > So, that being the case, I have to disagree with you. Also, > I strongly suspect you'll find a large number of other people will > as well. I'm not sure if you're referring to this list or some other list (or just "people" in general). If it's this list, I don't think that's true, based on the feedback so far. But it'd certainly be good to check for rough consensus here before going forward. > The problem you saw was simply the result of faulty network > equipment. You can argue about my use of the term "faulty" in this > case, but - in my lexicon - any device that purports to be an > Ethernet device is required to support forwarding of a frames of a > certain size and any such device that does not do so is faulty. I understand what you're saying, but whether the equipment is "faulty" or not seems immaterial to me. The issue here is about protection against these known failure modes, and not trying to rule existing equipment out as not just "bad" but "will melt your network." In this particular case, the fault is fairly insidious. Users likely don't know that they have the problem *UNTIL* they try to deploy RBridges, and the extra overhead required now becomes an issue. From a user's (deployer's) point of view, the network worked fine until he tried to add an RBridge: thus, the RBridge is a bad thing, and he won't want to repeat the experience. It can be pretty hard to tell users that their existing equipment, which appears to work just fine today, fails some technical purity test and thus will cause actual failures when new nodes are deployed. > But set that aside for a minute. It's clear that - faulty or > not - it creates a very serious problem if there is a mismatch of > configured and real MTU sizes. But there are really good reasons > why IS-IS does what it does. The "really good reason" that I know about is because of bogus FDDI/Ethernet bridges deployed long ago. If you were FDDI-attached at both apparent ends, but had an Ethernet bridge in the middle, you could have an invisible MTU restriction. The padded Hello checks for this cleanly. Is there some other reason that you know about? Is there some other reason that we should not consider changing this one aspect of IS-IS to suit our needs? If so, please relate it to us. I'd certainly like to know about it. > Hence there are reasons to avoid > changing how IS-IS operates arbitrarily. If you want to change IS-IS > in some critical ways, you're better off choosing another protocol. I don't think what Radia has proposed here is in any way "arbitrary." I don't see how that characterization of this change is fair. It solves a specific problem. > In this case, provided you meet the conditions I stated, then > it is absolutely okay to pad IS-IS messages just as is being done in > IS-IS today. Now, before you reply, re-read what I said previously > (of course, those conditions appear to have been omitted below, so I > am reinserting them here): And, in the interest of not bloating the reply, I'll snip them again. Yes, of course, if you can somehow guarantee that the MTU is not restricted in the L2 path, then padding is harmless. That's perfectly well understood. It's the "somehow" part that's unclear. It's unclear how you're proposing that we should do that prior to the Hello exchange. > If you read this carefully, what I am saying is that - if it's > possible for a pair of RBridge peers to know exactly what the real > MTU size is between them - then padding of IS-IS hello messages is > okay. In fact, it's more than okay because - implicit in what I said > - particularly in the context in which I said it (a reply to Mike > Shand in which I am trying to state an ideal solution given all of > the preceding discussion), padding is actually preferred. OK, then, how? How exactly do we get the peers to agree on MTU *before* exchanging Hello messages? What mechanism will do that? How do we even find the other peers? (I asked that previously, but you've declined to answer.) Radia has suggested a mechanism that will solve this problem, and will work. If you're going to say that it's unacceptable, then I think it's reasonable to ask for a hint of what the preferred alternative might be. > What you're doing is conflating the MTU discovery process and > the use of IS-IS hello messages. Can you explain what other possible purpose the padding might have? > There are other mechanisms that > can be used and - since this is a general problem that applies to L2 > network generally - it is likely that people already have solutions > of this type in play. I agree that it's a general L2 problem. I disagree that it's likely that others have other solutions. If so, please clarify. (Maybe you're thinking of LLDP. We'd probably have to bring this up as a separate thread if the alternative is to force reliance on LLDP for MTU information. I'm not even sure it works, as the solution "assumes" that all of the nodes actually implement LLDP.) > Where ANY other solution may already exist, your proposal to > modify IS-IS is unnacceptable. I disagree most vehemently with that. First of all, it's worth noting that the proposal was Radia's. I happen to agree with it, so if you call it "your proposal," then that's just flattery. ;-} More importantly, though, IS-IS is already highly modified in order to operate with TRILL. We have already: - Changed the MAC address in use. - Changed the Area Addresses. - Changed the supported NLPID operation. - Changed Hello operation to send special Hellos on different VLANs. - Added special bits to the Hello messages that trigger new actions in the recipients. (AF conflict resolution) That's among other interesting changes. If it helps, we'll pick a new name for this, and just call it the "TRILL signaling protocol." The fact that it happens to look a whole lot like IS-IS and reuses some of its algorithms becomes merely an implementation detail. > A far cleaner approach is to simply > state something along the lines of "unless a mechanism is in place > to ascertain that a padded IS-IS hello message will be delivered to > all connected RBridges, IS-IS hello padding is disabled." If you > want to propose modifying an IS-IS hello message in some way, as a > means for doing this, that's fine - but do it on your own nickle. If you're able to determine that a padded Hello message will be delivered to all connected RBridges, then I contend that there *IS NO* reason to pad at all. In other words, the solution you're proposing still devolves down to just "MUST NOT pad Hello." Also, I don't know what you mean by referring to my nickles. You'll need to clarify that. We're talking about TRILL/RBridges here, not Jim's toys. -- 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 Radia.Perlman at sun.com Fri Apr 3 12:56:33 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 03 Apr 2009 12:56:33 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> <18902.18316.963432.341063@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> Message-ID: <49D669F1.7040101@sun.com> This thread is getting too long. Let's not take forever arguing about philosophical things like whether by making a change in IS-IS such as saying that padding Hellos in TRILL IS-IS is a MUST NOT, that it's now a totally different protocol. There will be differences between TRILL IS-IS and layer 3 IS-IS. It's nice to do as much as possible to make it easy for a layer 3 IS-IS implementation to be modified to become TRILL IS-IS, but we have to come up with a simple, practical plan for how to make TRILL work. 1) As multiple people have pointed out, it's safe for IS-IS to pad Hellos. It is *not* safe for TRILL to pad Hellos. (see movie Marathon Man, or Hitchhiker's Guide, for discussion of "safe"). If there are both padded and unpadded Hellos, they serve different purposes (testing MTU size in one case, and finding neighbor RBridges in the other case). I think it's cleaner to call the messages solving the different purposes "different messages", and design each for the purpose it is solving. 2) MTU discovery is also important, but the most important thing is for RBridges on the same layer 2 cloud NOT to be hidden from each other due to things like VLAN configurations, or MTU differences. I think we can and should solve both problems, but it would be OK with me if the MTU discovery protocol was SHOULD rather than MUST. (Though I think I prefer MUST). If, as Eric Gray pointed out, there is already a rock-solid protocol defined in layer 2 for determining MTU size on Ethernet links, and therefore we (TRILL) don't need to solve this problem, then that would be great. So if there is, can someone explain to the mailing list exactly how that protocol works? We need a complete protocol. As James Carlson discovered, the spec as it is has to change, so that we are defensive against differing MTU sizes, or intermediate components adding tags. So, let me see if I can reiterate all the details in one place, since when I do it from memory in a hurry, I tend to miss some little detail. a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than some size. We should pick a conservative maximum size for a Hello, so that it is guaranteed not to be dropped because of being too big, even with extra tags that might be added by intermediate components. So perhaps 1400 bytes? (feel free to suggest a different number). The purpose of the Hello is to ensure that neighbors see each other. It does not test for MTU size. b) The Hello contains a flag "I support the MTU discovery protocol". c) The LSP contains an optional TLV "I think the campus-wide MTU size is x". d) This MTU-size TLV is ignored in all LSPs except the LSP of the highest priority RBridge, R1, in the campus. If R1 does not include this MTU-size TLV in its LSP, then each RBridge R2 decides for itself what the MTU size should be, and does not report links to an RBridge neighbor R3, if the R2-R3 link cannot support R2's assumption of MTU. If R1 *does* include the MTU-size TLV, then R2 uses that size for a criteria for reporting links. Note that if R2 cannot support R1's MTU size, then R2 will continue attempting to be DRB, etc., but will not report any of its links in LSPs. e) We define an "MTU discovery probe" packet, which is padded to some size, say s, and included inside the data is the "s". These can be unicast to a neighbor, or multicast to the all-RBridges layer 2 address. f) If R2 receives an MTU discovery packet from R3, R2 replies to R3 with an "MTU ack", including "s". g) If R2 does not get acks from R3 for its MTU discovery probes, (say, after sending 3 of them), then R2 does not report R3 in its Hellos, R3 will not report connectivity to the pseudonode, and if it's a pt-to-pt link, neither R2 nor R3 will report the R2-R3 link in their LSP. However, if R3 has not set the "I support the MTU discovery protocol", then R2 MUST NOT drop the adjacency to R3 because of nonreceipt of acks to its MTU discovery probes. Have I left anything out? Radia From dwfedyk at nortel.com Fri Apr 3 13:30:31 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Fri, 3 Apr 2009 16:30:31 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18902.17872.316711.466008@gargle.gargle.HOWL> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> Hi James >Don Fedyk writes: > >> > With IS-IS as used for TRILL, the padding is toxic. If >> > I can't hear your Hello messages, then I'll assume that >> > *I* am the DRB, and I'll begin forwarding for all the >> > VLANs I know about. If you can't hear me, you'll do the >> > same. And that potentially results in an L2 forwarding >> > loop for all frames that are of a size less than the MTU >> > restriction: a very *BAD* failure mode. It's the exact >> > opposite of the L3 routing scenario. >> > >> People are avioding the real issue here: >> >> It is not the padding that is toxic. It is the use of a >> discovery protocol where the failure/absense of the >> protocol results in RBridges self electing themselves the >> DRB. > >The padding leads to non-discovery, and non-discovery leads >to forwarding loops. > >I believe that what you're suggesting is that there's a >different place to break this chain. What I don't see is >where that place would be. If it's not in eliminating the >padding, then where is it? > >Are you suggesting that nodes that see no other devices on >the network should not become DRB on their own? If so, then >what forwards on and off of stub networks? I'm suggesting that is the crux of the issue. > >> Whether or not you use IS-IS hellos to discover or some >> new fangled protocol, any failure of the discovery >> protocol results in this undesirable behavior. > >Correct. This is just one way to cause the problem. > >> Yes IS-IS with padding may be a less robust discovery >> protocol but it was not designed for this purpose. And >> repurposing the IS-IS design only reduses the problem it >> does not eliminate it. > >I'm unsure what you're suggesting as an alternative. Could >you clarify? I already suggested the alternative: Interwork with STP (actually you suggested it first). You either make the RBridges smart enough to talk STP or you do something where STP(RSTP) will block you. STP won't form loops if it is told the right information. I'm sure it can be done. Don > >-- >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 eric.gray at ericsson.com Fri Apr 3 13:30:45 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 3 Apr 2009 15:30:45 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18902.25194.624818.417591@gargle.gargle.HOWL> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se><18902.18316.963432.341063@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> <18902.25194.624818.417591@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EC1D23@eusrcmw721.eamcs.ericsson.se> I did a quick check on this thread. It seems to be fairly split into 3 groups: 1) those who think some variation of what you propose is a good enough solution. Note that there is not a firm agreement as to which of the similar approaches would be adopted. 2) those who object to one or another of the specific proposals. 3) those who are still trying to understand the issues and what the implications are. Some people are not clearly in one group or the other, so I would count them twice. I, for instance, would count myself in both group 1 and group 2 because I agree with the basics of what Radia has proposed, but don't agree with the way that you interpret it. To be fair, I should probably count you in both the first group and in the third, because you apparently still have questions (based on your reply below) - but that would probably be seen as a specious argument, so I count you only in the first group. Given the small number of participants, and the division that seems to exist among them, I think it will be hard to call any particular consensus at this point. Perhaps if the chairs explicitly ask, we may find out otherwise. Of course, a consensus call would need to carefully spell out what exactly we are deciding - and there are more options than Radia includes in her mail. Perhaps what we need to do is list all of the variations and throw as many off the island as we can before we actually try to determine consensus on a way forward from the few (hopefully) that will remain. For example, maybe we could throw STP off of the island? -- Eric -----Original Message----- From: James Carlson [mailto:james.d.carlson at Sun.COM] Sent: Friday, April 03, 2009 3:24 PM To: Eric Gray Cc: mike shand; TRILL/RBridge Working Group; Radia Perlman Subject: RE: [rbridge] Proposed compromise for short/long hellos Importance: High Eric Gray writes: > So, that being the case, I have to disagree with you. Also, > I strongly suspect you'll find a large number of other people will > as well. I'm not sure if you're referring to this list or some other list (or just "people" in general). If it's this list, I don't think that's true, based on the feedback so far. But it'd certainly be good to check for rough consensus here before going forward. > The problem you saw was simply the result of faulty network > equipment. You can argue about my use of the term "faulty" in this > case, but - in my lexicon - any device that purports to be an > Ethernet device is required to support forwarding of a frames of a > certain size and any such device that does not do so is faulty. I understand what you're saying, but whether the equipment is "faulty" or not seems immaterial to me. The issue here is about protection against these known failure modes, and not trying to rule existing equipment out as not just "bad" but "will melt your network." In this particular case, the fault is fairly insidious. Users likely don't know that they have the problem *UNTIL* they try to deploy RBridges, and the extra overhead required now becomes an issue. From a user's (deployer's) point of view, the network worked fine until he tried to add an RBridge: thus, the RBridge is a bad thing, and he won't want to repeat the experience. It can be pretty hard to tell users that their existing equipment, which appears to work just fine today, fails some technical purity test and thus will cause actual failures when new nodes are deployed. > But set that aside for a minute. It's clear that - faulty or > not - it creates a very serious problem if there is a mismatch of > configured and real MTU sizes. But there are really good reasons > why IS-IS does what it does. The "really good reason" that I know about is because of bogus FDDI/Ethernet bridges deployed long ago. If you were FDDI-attached at both apparent ends, but had an Ethernet bridge in the middle, you could have an invisible MTU restriction. The padded Hello checks for this cleanly. Is there some other reason that you know about? Is there some other reason that we should not consider changing this one aspect of IS-IS to suit our needs? If so, please relate it to us. I'd certainly like to know about it. > Hence there are reasons to avoid > changing how IS-IS operates arbitrarily. If you want to change IS-IS > in some critical ways, you're better off choosing another protocol. I don't think what Radia has proposed here is in any way "arbitrary." I don't see how that characterization of this change is fair. It solves a specific problem. > In this case, provided you meet the conditions I stated, then > it is absolutely okay to pad IS-IS messages just as is being done in > IS-IS today. Now, before you reply, re-read what I said previously > (of course, those conditions appear to have been omitted below, so I > am reinserting them here): And, in the interest of not bloating the reply, I'll snip them again. Yes, of course, if you can somehow guarantee that the MTU is not restricted in the L2 path, then padding is harmless. That's perfectly well understood. It's the "somehow" part that's unclear. It's unclear how you're proposing that we should do that prior to the Hello exchange. > If you read this carefully, what I am saying is that - if it's > possible for a pair of RBridge peers to know exactly what the real > MTU size is between them - then padding of IS-IS hello messages is > okay. In fact, it's more than okay because - implicit in what I said > - particularly in the context in which I said it (a reply to Mike > Shand in which I am trying to state an ideal solution given all of > the preceding discussion), padding is actually preferred. OK, then, how? How exactly do we get the peers to agree on MTU *before* exchanging Hello messages? What mechanism will do that? How do we even find the other peers? (I asked that previously, but you've declined to answer.) Radia has suggested a mechanism that will solve this problem, and will work. If you're going to say that it's unacceptable, then I think it's reasonable to ask for a hint of what the preferred alternative might be. > What you're doing is conflating the MTU discovery process and > the use of IS-IS hello messages. Can you explain what other possible purpose the padding might have? > There are other mechanisms that > can be used and - since this is a general problem that applies to L2 > network generally - it is likely that people already have solutions > of this type in play. I agree that it's a general L2 problem. I disagree that it's likely that others have other solutions. If so, please clarify. (Maybe you're thinking of LLDP. We'd probably have to bring this up as a separate thread if the alternative is to force reliance on LLDP for MTU information. I'm not even sure it works, as the solution "assumes" that all of the nodes actually implement LLDP.) > Where ANY other solution may already exist, your proposal to > modify IS-IS is unnacceptable. I disagree most vehemently with that. First of all, it's worth noting that the proposal was Radia's. I happen to agree with it, so if you call it "your proposal," then that's just flattery. ;-} More importantly, though, IS-IS is already highly modified in order to operate with TRILL. We have already: - Changed the MAC address in use. - Changed the Area Addresses. - Changed the supported NLPID operation. - Changed Hello operation to send special Hellos on different VLANs. - Added special bits to the Hello messages that trigger new actions in the recipients. (AF conflict resolution) That's among other interesting changes. If it helps, we'll pick a new name for this, and just call it the "TRILL signaling protocol." The fact that it happens to look a whole lot like IS-IS and reuses some of its algorithms becomes merely an implementation detail. > A far cleaner approach is to simply > state something along the lines of "unless a mechanism is in place > to ascertain that a padded IS-IS hello message will be delivered to > all connected RBridges, IS-IS hello padding is disabled." If you > want to propose modifying an IS-IS hello message in some way, as a > means for doing this, that's fine - but do it on your own nickle. If you're able to determine that a padded Hello message will be delivered to all connected RBridges, then I contend that there *IS NO* reason to pad at all. In other words, the solution you're proposing still devolves down to just "MUST NOT pad Hello." Also, I don't know what you mean by referring to my nickles. You'll need to clarify that. We're talking about TRILL/RBridges here, not Jim's toys. -- 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 james.d.carlson at Sun.COM Fri Apr 3 13:45:39 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 3 Apr 2009 16:45:39 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EC1D23@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> <18902.18316.963432.341063@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> <18902.25194.624818.417591@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1D23@eusrcmw721.eamcs.ericsson.se> Message-ID: <18902.30067.803316.472497@gargle.gargle.HOWL> Eric Gray writes: > 3) those who are still trying to understand the issues and what > the implications are. [...] > To be fair, I should probably count you in both the first group > and in the third, because you apparently still have questions > (based on your reply below) - but that would probably be seen > as a specious argument, so I count you only in the first group. Wow. That ends the thread for me. For purposes of consensus, everyone else can count me as a supporter of Radia's existing proposal. -- 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 Fri Apr 3 14:22:16 2009 From: Jim.Burrows at stellarswitches.com (Jim Burrows) Date: Fri, 3 Apr 2009 17:22:16 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D669F1.7040101@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> <18902.18316.963432.341063@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> <49D669F1.7040101@sun.com> Message-ID: <3867A421-0231-46CA-9BD0-D743221AA2D2@stellarswitches.com> On Apr 3, 2009, at 3:56 PM, Radia Perlman wrote: > This thread is getting too long.... > So, let me see if I can reiterate all the details in one place, > since when I do it from memory in a hurry, I tend to miss some > little detail.... Bless you! > Have I left anything out? I don't think so. While a bit long, your message summarized what I believe I have been reading here as concisely and completely as possible. I will admit to being something of a newbie to both the list and TRILL, but given the few weeks of experience I have with it, I believe I understand the issues and your summary corresponds to that understanding very well. I'm left slightly uncertain what the proper value for "s" is, and what criteria R1 (and its ilk) should have used in determining what it assert the campus MTU size is--should it be based solely on the MTU probing protocol or other mechanisms--but it is not clear to me that either of these *have* to be specified. If we can agree on your outlined points a-g, then these "implementation details" can probably be worked out. The big "if", of course, getting consensus on a-g. I for one, haven't seen concrete reasons to disagree with your summary, beyond the more philosophical and unspecific notions that have floated around in prior emails. Thank you, JimB. From james.d.carlson at Sun.COM Fri Apr 3 13:42:06 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 3 Apr 2009 16:42:06 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> Message-ID: <18902.29854.271129.115146@gargle.gargle.HOWL> Don Fedyk writes: > >Don Fedyk writes: > >Are you suggesting that nodes that see no other devices on > >the network should not become DRB on their own? If so, then > >what forwards on and off of stub networks? > > I'm suggesting that is the crux of the issue. OK. > >I'm unsure what you're suggesting as an alternative. Could > >you clarify? > > I already suggested the alternative: Interwork with STP (actually you > suggested it first). You either make the RBridges smart enough to talk > STP or you do something where STP(RSTP) will block you. STP won't form > loops if it is told the right information. I'm sure it can be done. The BPDUs at least have the benefit of not being MTU-padded by default. ;-} This is the path we went down on my initial message and then abandoned. It ultimately forces you to run a giant STP instance over the entire bridged network -- TRILL nodes included -- and the wg consensus was that this would not be a good answer. I think there are two possible behaviors that TRILL could have with respect to STP, corresponding to having one protocol logically "on top" of the other: 1. TRILL nodes look like end stations to STP. Regular bridges are invisible to TRILL; they just make it look like there's a multidrop link present. 2. An entire TRILL cloud looks like a single STP-speaking bridge to the regular bridges attached anywhere in the network. TRILL DRBs are responsible for running a fraction of STP and somehow coordinating with other DRBs. We've intentionally chosen (1), and I think you're suggesting we switch to (2). I think we'd need a solution for how you run STP in a cloud in order to do that, plus a substantial change in the existing consensus. (I don't remember anyone else clamoring for having giant STP networks ...) -- 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 Fri Apr 3 14:38:48 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Fri, 3 Apr 2009 17:38:48 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18902.29854.271129.115146@gargle.gargle.HOWL> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com><18902.17872.316711.466008@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> Hi James > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at Sun.COM] > Sent: Friday, April 03, 2009 4:42 PM > To: Fedyk, Don (BL60:1A00) > Cc: Eric Gray; TRILL/RBridge Working Group; Radia Perlman > Subject: RE: [rbridge] Proposed compromise for short/long hellos > > Don Fedyk writes: > > >Don Fedyk writes: > > >Are you suggesting that nodes that see no other devices on > > >the network should not become DRB on their own? If so, then > > >what forwards on and off of stub networks? > > > > I'm suggesting that is the crux of the issue. > > OK. > > > >I'm unsure what you're suggesting as an alternative. Could > > >you clarify? > > > > I already suggested the alternative: Interwork with STP > (actually you > > suggested it first). You either make the RBridges smart > enough to talk > > STP or you do something where STP(RSTP) will block you. > STP won't form > > loops if it is told the right information. I'm sure it can > be done. > > The BPDUs at least have the benefit of not being MTU-padded by > default. ;-} > > This is the path we went down on my initial message and then > abandoned. It ultimately forces you to run a giant STP instance over > the entire bridged network -- TRILL nodes included -- and the wg > consensus was that this would not be a good answer. > > I think there are two possible behaviors that TRILL could have with > respect to STP, corresponding to having one protocol logically "on > top" of the other: > > 1. TRILL nodes look like end stations to STP. Regular bridges are > invisible to TRILL; they just make it look like there's a > multidrop link present. > > 2. An entire TRILL cloud looks like a single STP-speaking bridge to > the regular bridges attached anywhere in the network. TRILL DRBs > are responsible for running a fraction of STP and somehow > coordinating with other DRBs. > > We've intentionally chosen (1), and I think you're suggesting we > switch to (2). Not exactly I'm suggesting you make the RBridge attachment such that the LAN running STP decides two or more RBridges cannot be tolerated. STP will block the ports until you can fix things. Rather than running STP in a cloud you run enough of an STP stub locally on your RBridge to break loops in the rare event your discovery protocol fails. Remember your only counting on STP iff the discovery protocol breaks. And then IS-IS can be your discovery protocol. Don > > I think we'd need a solution for how you run STP in a cloud in order > to do that, plus a substantial change in the existing consensus. (I > don't remember anyone else clamoring for having giant STP > networks ...) > > -- > 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 james.d.carlson at Sun.COM Fri Apr 3 14:38:09 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 3 Apr 2009 17:38:09 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D669F1.7040101@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> <18902.18316.963432.341063@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> <49D669F1.7040101@sun.com> Message-ID: <18902.33217.945022.519845@gargle.gargle.HOWL> Radia Perlman writes: > So, let me see if I can reiterate all the details in one place, since > when I do it from memory in a hurry, I tend to miss > some little detail. I agree with this mostly, but I think there's a simplification possible: > b) The Hello contains a flag "I support the MTU discovery protocol". If we make it so that RBridges MUST respond to the MTU probe, but only MAY (or possibly SHOULD) send probes of their own, then the need for this extra flag goes away. This allows us to satisfy the folks who don't believe that MTU checks are necessary (they're free to avoid sending probes if they want), while allowing those who want to check for MTU flaws to do so whenever needed. > d) This MTU-size TLV is ignored in all LSPs except the LSP of the > highest priority RBridge, R1, in the campus. I've been thinking about this part of a while. I don't know whether choosing the highest priority RBridge to set the MTU value is right, but I can't actually think of a cleaner answer. In general, you might have some links with a higher possible MTU (going to waste, I suppose), and ones with a lower MTU (being rendered unusable). We could choose the smallest value (rather than the value from the highest priority RBridge), to make sure that all links are always included, but then adding a new RBridge to a campus becomes a more risky proposition. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ddutt at cisco.com Fri Apr 3 14:57:04 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Fri, 03 Apr 2009 14:57:04 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <3867A421-0231-46CA-9BD0-D743221AA2D2@stellarswitches.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se> <18902.18316.963432.341063@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> <49D669F1.7040101@sun.com> <3867A421-0231-46CA-9BD0-D743221AA2D2@stellarswitches.com> Message-ID: <49D68630.1060606@cisco.com> Agreed, Dinesh Jim Burrows wrote: > The big "if", of course, getting consensus on a-g. I for one, haven't > seen concrete reasons to disagree with your summary, beyond the more > philosophical and unspecific notions that have floated around in prior > emails. > > Thank you, > JimB. > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From james.d.carlson at sun.com Fri Apr 3 14:48:42 2009 From: james.d.carlson at sun.com (James Carlson) Date: Fri, 3 Apr 2009 17:48:42 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> Message-ID: <18902.33850.290558.736101@gargle.gargle.HOWL> Don Fedyk writes: > > 2. An entire TRILL cloud looks like a single STP-speaking bridge to > > the regular bridges attached anywhere in the network. TRILL DRBs > > are responsible for running a fraction of STP and somehow > > coordinating with other DRBs. > > > > We've intentionally chosen (1), and I think you're suggesting we > > switch to (2). > > Not exactly I'm suggesting you make the RBridge attachment such that the > LAN running STP decides two or more RBridges cannot be tolerated. STP > will block the ports until you can fix things. Rather than running STP > in a cloud you run enough of an STP stub locally on your RBridge to > break loops in the rare event your discovery protocol fails. Remember > your only counting on STP iff the discovery protocol breaks. And then > IS-IS can be your discovery protocol. I'm unaware of a good way to do that. I know how to make links in the middle of the STP topology snap apart unpredictably (reporting the same root bridge from each RBridge ought to be enough), but I don't offhand know how to cause STP to break off the attachment right at the "duplicate" node. If you've got a concrete suggestion on how to do that, I'd be interested. (I still doubt we can get consensus on going that way, particularly because it'd hard to keep it from interfering with the AF delegation behavior, but it'd be interesting nonetheless.) -- 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 Sat Apr 4 04:43:10 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Sat, 4 Apr 2009 07:43:10 -0400 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <18902.33850.290558.736101@gargle.gargle.HOWL> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com><18902.17872.316711.466008@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com><18902.29854.271129.115146@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> Hi James >Don Fedyk writes: > >> > 2. An entire TRILL cloud looks like a single >> > STP-speaking bridge to the regular bridges attached >> > anywhere in the network. TRILL DRBs are responsible >> > for running a fraction of STP and somehow coordinating >> > with other DRBs. >> > >> > We've intentionally chosen (1), and I think you're >> > suggesting we switch to (2). >> >> Not exactly I'm suggesting you make the RBridge attachment >> such that the LAN running STP decides two or more RBridges >> cannot be tolerated. STP will block the ports until you >> can fix things. Rather than running STP in a cloud you >> run enough of an STP stub locally on your RBridge to break >> loops in the rare event your discovery protocol fails. >> Remember your only counting on STP iff the discovery >> protocol breaks. And then IS-IS can be your discovery >> protocol. > >I'm unaware of a good way to do that. I know how to make >links in the middle of the STP topology snap apart >unpredictably (reporting the same root bridge from each >RBridge ought to be enough), but I don't offhand know how to >cause STP to break off the attachment right at the >"duplicate" node. > >If you've got a concrete suggestion on how to do that, I'd >be interested. (I still doubt we can get consensus on going >that way, particularly because it'd hard to keep it from >interfering with the AF delegation behavior, but it'd be >interesting nonetheless.) > What if every RBridge reported it was connected to a well known low priority "pseudo" bridge. If ever two RBridges were connected to the same LAN and tried to do this STP would require one of the RBridge break the connection to the "pseudo node". The RBridges would know implicitly there were two RBridges connect to the LAN and one of then would go into listen mostly mode (by removing the low priority pseudo node from the BPDUs). The RBridge could still send locally to this LAN sending Hellos etc but it would not bridge to the LAN. (It would see the pseudo bridge already in the LAN.) It seems to me this would be a condition before you became an appointed forwarder. Unfortunately I'm not an STP expert to say defacto this would work but it seems you want to inject some harmless information using STP that would allow RBridges to detect RBridges. You still have the issue that the condition to become appointed forwarder or DRB is dependent on you not hearing something. Regards, Don From eric.gray at ericsson.com Sat Apr 4 08:19:21 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Sat, 4 Apr 2009 10:19:21 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D669F1.7040101@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF04EC1831@eusrcmw721.eamcs.ericsson.se><18902.18316.963432.341063@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF04EC1B04@eusrcmw721.eamcs.ericsson.se> <49D669F1.7040101@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EE99CA@eusrcmw721.eamcs.ericsson.se> -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Friday, April 03, 2009 3:57 PM To: TRILL/RBridge Working Group Subject: Re: [rbridge] Proposed compromise for short/long hellos This thread is getting too long. ---[SNIP]--- If, as Eric Gray pointed out, there is already a rock-solid protocol defined in layer 2 for determining MTU size on Ethernet links, ... EG> I never said this. What I said was that there are mechanisms which EG> have been, or are being, defined in IEEE 802 (.1 Interworking in EG> particular) that can be used to solve this problem. Since this is EG> a problem specific to L2 technologies, and has broader applicability EG> then TRILL, this problem may be solved in a larger context. If it EG> solved, then any TRILL specific solution will likely become obsolete. ... and therefore we (TRILL) don't need to solve this problem, then that would be great. EG> Never said that either. What I said is that we should not - in the EG> Base protocol specification - describe an MTU discovery protocol. EG> I am amenable to proposing what you have been suggesting as a proof EG> of concept example (in the base protocol specification) that such a EG> protocol can be defined, but I do not find this proposal to be very EG> useful (as I have said) because it is basically a pass-fail MTU EG> validation (nothing particularly "discovery" about it), and I do EG> not believe this will be the long-term approach for a number of EG> reasons. So if there is, can someone explain to the mailing list exactly how that protocol works? EG> You ask quite a lot. I participate in several of the activities in EG> IEEE 802.1, and there are a few that have some impact on this issue. EG> EG> As the IETF liaison to IEEE 802.1, I occasionally produce meeting EG> summaries of work (I know of) in IEEE that is related to (what I EG> know of) work in the IETF. As far as I know, nobody expects me to EG> produce summaries of the actual specifications (and that's a good EG> thing, as it would be impossible for me to do so). EG> EG> At a high level, however, there are a number of specifications that EG> may impact on this issue - and particularly - on the applicablility EG> of (or need for) a TRILL-defined MTU discovery mechanism. EG> EG> For instance, there is Connectivity Fault Management (CFM - and EG> particularly Data-Driven CFM, or DDCFM) which can be used to find EG> an exact MTU size between any two bridges. EG> EG> Although it is to be presumed that operators would want to configure EG> security parameters correctly, a quick look at the security work in EG> IEEE indicates that it may be possible to mis-configure security in EG> such a way that one RBridge does not discover another (for instance, EG> by being rejected as invalid by a lower layer entity). I imagine we EG> really need someone from the IEEE Security task group to let us know EG> if that is an issue. If it is, are we going to attempt to fix this EG> in TRILL as well? EG> EG> Then there is Logical Link Discovery Protocol (LLDP - P802.1AB) that EG> has been around a while and may have some impact on whether or not EG> an (additional) MTU discovery mechanism is required. EG> EG> Spanning tree itself can be used to determine if there intermediate EG> bridges (where insertion of additional TAGs may occur). EG> EG> And these do not include the possibility of new work, potentially EG> inspired by this discussion and potentially inspired by others. EG> The relevant point is that we should not specify a _required_ MTU EG> discovery protocol as part of the base protocol specification in EG> TRILL. EG> EG> All of this is essentially part of what the TRILL WG should be EG> considering in reference to the IEEE liaison response that Donald EG> mentioned at the last meeting - i.e. - in particular, references EG> to the need to be clear about the scope of TRILL and the potential EG> for TRILL to have future conflicts with the work in IEEE 802.1. We need a complete protocol. As James Carlson discovered, the spec as it is has to change, so that we are defensive against differing MTU sizes, or intermediate components adding tags. EG> The presence of intermediate components may be a detectable phenom. EG> If it is, and there are none, is MTU discovery required? Are hello EG> messages allowed to be padded in this case? So, let me see if I can reiterate all the details in one place, since when I do it from memory in a hurry, I tend to miss some little detail. a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than some size. We should pick a conservative maximum size for a Hello, so that it is guaranteed not to be dropped because of being too big, even with extra tags that might be added by intermediate components. So perhaps 1400 bytes? EG> The problems I see with this approach is several: EG> A) any number greater than the smallest MTU size we will ever EG> find will need to be configurable to a lower number. And, EG> given that we didn't want to do that for the initial case, EG> it seems likely that we're saying we won't want to do it EG> then either. Clearly we cannot know the smallest size we EG> will ever see. EG> B) If we pick a number today, and find out that it is too big EG> for some implementation/deployment, will we then change the EG> protocol solution to use this lower value as the new MAX? EG> C) what do you do when the hello messages must be larger than EG> whatever we've decided will be the maximum - even when that EG> maximum clearly doesn't apply in some particular deployment EG> scenario? EG> D) Does this apply when two adjacent RBrdiges are connected by EG> a point to point link and this link is configured not to EG> require a DRB? EG> E> Would this apply for an RBridge that is not capable of being EG> a DRB? (feel free to suggest a different number). The purpose of the Hello is to ensure that neighbors see each other. It does not test for MTU size. b) The Hello contains a flag "I support the MTU discovery protocol". EG> I suggest "... the TRILL MTU discovery protocol ..." simply as a EG> clarification, because there are others. You might argue that it EG> should be understood because it is a flag in a TRILL protocol PDU, EG> but the simple truth is that customers are going to call it what EG> ever we call it and I'd like to avoid injecting more confuion into EG> the situation. c) The LSP contains an optional TLV "I think the campus-wide MTU size is x". d) This MTU-size TLV is ignored in all LSPs except the LSP of the highest priority RBridge, R1, in the campus. If R1 does not include this MTU-size TLV in its LSP, then each RBridge R2 decides for itself what the MTU size should be, and does not report links to an RBridge neighbor R3, if the R2-R3 link cannot support R2's assumption of MTU. If R1 *does* include the MTU-size TLV, then R2 uses that size for a criteria for reporting links. Note that if R2 cannot support R1's MTU size, then R2 will continue attempting to be DRB, etc., but will not report any of its links in LSPs. EG> I am not sure I understand this at all, given that it seems EG> like you're using campus to mean "shared link", since the EG> RBridge R2 appears to need to support at least as great an EG> MTU as the highest priority RBridge - even though they may EG> may not be attached to a shared link (and would not therefore EG> be competing DRB candidates), or you are assuming it will not EG> become the DRB for the shared link. EG> EG> If that is indeed what you mean, then what happens if there EG> are no RBridges connected to the same shared link as R2 that EG> are capable of supporting the MTU asserted by the highest EG> priority RBridge? EG> EG> Also, I think you are forgetting at least one thing. The EG> highest priority RBridge would need to change the MTU it EG> asserts to the value determined as the minimum of all MTU EG> size assertions if the intent is to make sure that all EG> RBridges can handle a frame of that size. EG> EG> And, instead of determining the campus-wide MTU, the MTU EG> assertions could be scoped by VLAN - avoiding the scenario EG> in which every link is treated as if it has the worst case EG> MTU, even if none of the taffic that traverses that link EG> will ever traverse the link(s) that require this worst case EG> MTU. e) We define an "MTU discovery probe" packet, which is padded to some size, say s, and included inside the data is the "s". These can be unicast to a neighbor, or multicast to the all-RBridges layer 2 address. f) If R2 receives an MTU discovery packet from R3, R2 replies to R3 with an "MTU ack", including "s". g) If R2 does not get acks from R3 for its MTU discovery probes, (say, after sending 3 of them), then R2 does not report R3 in its Hellos, R3 will not report connectivity to the pseudonode, and if it's a pt-to-pt link, neither R2 nor R3 will report the R2-R3 link in their LSP. However, if R3 has not set the "I support the MTU discovery protocol", then R2 MUST NOT drop the adjacency to R3 because of nonreceipt of acks to its MTU discovery probes. EG> Alternatively, R2 could decide to reduce the size of subsequent EG> discovery probes, until it does receive an ACK. Have I left anything out? Radia _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Sat Apr 4 15:52:59 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sat, 04 Apr 2009 15:52:59 -0700 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> Message-ID: <49D7E4CB.6020804@sun.com> Hi Don, You're basically suggesting something that was in the spec in an earlier version, and that I liked, but it got shot down. The rule was that RBridges would participate in the STP on each link, with priority configured so that RBridges would have priority over regular bridges for becoming spanning tree root. And then an RBridge would become DRB if and only if it was elected root in the STP. As I said, I liked this approach, but it got shot down, I'm not sure I remember all the reasons, but I think it had to do with "which version of the spanning tree would RBridges have to run?", and "what if bridges are also configured to have highest priority"? But given that it was discussed in the WG, and given that for whatever reason it was overruled, we shouldn't try to go back to that. There were a bunch of things I wish had gone a different way, like the clever TRILL header encoding that Don (I think) proposed where the VLAN and DA were brought into the TRILL header. But we'll never finish this if we keep regretting decisions we made. Radia Don Fedyk wrote: > Hi James > > >> Don Fedyk writes: >> >> >>>> 2. An entire TRILL cloud looks like a single >>>> STP-speaking bridge to the regular bridges attached >>>> anywhere in the network. TRILL DRBs are responsible >>>> for running a fraction of STP and somehow coordinating >>>> with other DRBs. >>>> >>>> We've intentionally chosen (1), and I think you're >>>> suggesting we switch to (2). >>>> >>> Not exactly I'm suggesting you make the RBridge attachment >>> such that the LAN running STP decides two or more RBridges >>> cannot be tolerated. STP will block the ports until you >>> can fix things. Rather than running STP in a cloud you >>> run enough of an STP stub locally on your RBridge to break >>> loops in the rare event your discovery protocol fails. >>> Remember your only counting on STP iff the discovery >>> protocol breaks. And then IS-IS can be your discovery >>> protocol. >>> >> I'm unaware of a good way to do that. I know how to make >> links in the middle of the STP topology snap apart >> unpredictably (reporting the same root bridge from each >> RBridge ought to be enough), but I don't offhand know how to >> cause STP to break off the attachment right at the >> "duplicate" node. >> >> If you've got a concrete suggestion on how to do that, I'd >> be interested. (I still doubt we can get consensus on going >> that way, particularly because it'd hard to keep it from >> interfering with the AF delegation behavior, but it'd be >> interesting nonetheless.) >> >> > > What if every RBridge reported it was connected to a well known low > priority "pseudo" bridge. If ever two RBridges were connected to the > same LAN and tried to do this STP would require one of the RBridge break > the connection to the "pseudo node". The RBridges would know implicitly > there were two RBridges connect to the LAN and one of then would go into > listen mostly mode (by removing the low priority pseudo node from the > BPDUs). The RBridge could still send locally to this LAN sending Hellos > etc but it would not bridge to the LAN. (It would see the pseudo bridge > already in the LAN.) It seems to me this would be a condition before > you became an appointed forwarder. Unfortunately I'm not an STP expert > to say defacto this would work but it seems you want to inject some > harmless information using STP that would allow RBridges to detect > RBridges. You still have the issue that the condition to become > appointed forwarder or DRB is dependent on you not hearing something. > > Regards, > Don > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Sat Apr 4 17:16:16 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Sat, 4 Apr 2009 19:16:16 -0500 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <49D7E4CB.6020804@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com><18902.17872.316711.466008@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com><18902.29854.271129.115146@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com><18902.33850.290558.736101@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EE9B6F@eusrcmw721.eamcs.ericsson.se> Radia, This is an interesting argument. For many reasons, some of which we don't remember, an earlier proposal similar to Don's was thrown out. So we shouldn't go back to that proposal - or consider a similar one - because we will only discover again what the reasons were for shooting the similar proposal down earlier. A highly analogous situation exists with the IS-IS padding of hello messages. You won't find anyone to bet against if you want to bet that a suggestion was made once or twice in specifying IS-IS to do away with the padding of hello messages. But it was shot down, apparently, because it's still there. I suspect the reason why using STP in the manner you suggest was shot down was in part because people said their customers didn't want to hear the word "STP" being talked about in connection with their network. But it really doesn't matter - in the final analysis - why an earlier proposal was shot down, if the proposal that was accepted in its place was thereafter the basis for all subsequent work. We've moved on quite a bit since we made the decision not to use STP in precisely the way that you suggest, and that decision is now ingrained in most of the work we've done since. Unfortunately, I am concerned that people may have lost sight of the fact that this same reasoning may very well apply to revisiting the early decision in IS-IS to pad hello messages. In one sense, I definitely feel that Don is onto something. Perhaps there needs to be an RBridge discovery protocol that is BPDU-based, even if it is not STP. Nothing else would have to change - either in TRILL, or in IS-IS - though the use of the discovery aspect of IS-IS is bound to be a bit anti-climactic (but this is already true if we've had to configure a lot of information about neighbors anyway). This approach would eliminate any concerns about not discovering an adjacent Rbridge, and it would decouple the content of IS-IS Hello messages from concerns about MTU size. RBridges would already know who they should be seeing IS-IS Hello messages from and could take appropriate actions if they don't see them. -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Saturday, April 04, 2009 6:53 PM To: Don Fedyk Cc: TRILL/RBridge Working Group Subject: Re: [rbridge] Proposed compromise for short/long hellos Hi Don, You're basically suggesting something that was in the spec in an earlier version, and that I liked, but it got shot down. The rule was that RBridges would participate in the STP on each link, with priority configured so that RBridges would have priority over regular bridges for becoming spanning tree root. And then an RBridge would become DRB if and only if it was elected root in the STP. As I said, I liked this approach, but it got shot down, I'm not sure I remember all the reasons, but I think it had to do with "which version of the spanning tree would RBridges have to run?", and "what if bridges are also configured to have highest priority"? But given that it was discussed in the WG, and given that for whatever reason it was overruled, we shouldn't try to go back to that. There were a bunch of things I wish had gone a different way, like the clever TRILL header encoding that Don (I think) proposed where the VLAN and DA were brought into the TRILL header. But we'll never finish this if we keep regretting decisions we made. Radia Don Fedyk wrote: > Hi James > > >> Don Fedyk writes: >> >> >>>> 2. An entire TRILL cloud looks like a single >>>> STP-speaking bridge to the regular bridges attached >>>> anywhere in the network. TRILL DRBs are responsible >>>> for running a fraction of STP and somehow coordinating >>>> with other DRBs. >>>> >>>> We've intentionally chosen (1), and I think you're >>>> suggesting we switch to (2). >>>> >>> Not exactly I'm suggesting you make the RBridge attachment >>> such that the LAN running STP decides two or more RBridges >>> cannot be tolerated. STP will block the ports until you >>> can fix things. Rather than running STP in a cloud you >>> run enough of an STP stub locally on your RBridge to break >>> loops in the rare event your discovery protocol fails. >>> Remember your only counting on STP iff the discovery >>> protocol breaks. And then IS-IS can be your discovery >>> protocol. >>> >> I'm unaware of a good way to do that. I know how to make >> links in the middle of the STP topology snap apart >> unpredictably (reporting the same root bridge from each >> RBridge ought to be enough), but I don't offhand know how to >> cause STP to break off the attachment right at the >> "duplicate" node. >> >> If you've got a concrete suggestion on how to do that, I'd >> be interested. (I still doubt we can get consensus on going >> that way, particularly because it'd hard to keep it from >> interfering with the AF delegation behavior, but it'd be >> interesting nonetheless.) >> >> > > What if every RBridge reported it was connected to a well known low > priority "pseudo" bridge. If ever two RBridges were connected to the > same LAN and tried to do this STP would require one of the RBridge break > the connection to the "pseudo node". The RBridges would know implicitly > there were two RBridges connect to the LAN and one of then would go into > listen mostly mode (by removing the low priority pseudo node from the > BPDUs). The RBridge could still send locally to this LAN sending Hellos > etc but it would not bridge to the LAN. (It would see the pseudo bridge > already in the LAN.) It seems to me this would be a condition before > you became an appointed forwarder. Unfortunately I'm not an STP expert > to say defacto this would work but it seems you want to inject some > harmless information using STP that would allow RBridges to detect > RBridges. You still have the issue that the condition to become > appointed forwarder or DRB is dependent on you not hearing something. > > Regards, > Don > > > > _______________________________________________ > 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 trill at punk.co.nz Sat Apr 4 22:00:23 2009 From: trill at punk.co.nz (Kris Price) Date: Sun, 05 Apr 2009 17:00:23 +1200 Subject: [rbridge] Proposed compromise for short/long hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EE9B6F@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com><18902.17872.316711.466008@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com><18902.29854.271129.115146@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com><18902.33850.290558.736101@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EE9B6F@eusrcmw721.eamcs.ericsson.se> Message-ID: <49D83AE7.7080300@punk.co.nz> Eric Gray wrote: [snip] > In one sense, I definitely feel that Don is onto something. > Perhaps > there needs to be an RBridge discovery protocol that is BPDU-based, even > if it is not STP. Nothing else would have to change - either in TRILL, > or > in IS-IS - though the use of the discovery aspect of IS-IS is bound to > be > a bit anti-climactic (but this is already true if we've had to configure > a > lot of information about neighbors anyway). > > This approach would eliminate any concerns about not discovering > an > adjacent Rbridge, and it would decouple the content of IS-IS Hello > messages > from concerns about MTU size. RBridges would already know who they > should > be seeing IS-IS Hello messages from and could take appropriate actions > if > they don't see them. [snip] I thought this approach was more ideal (if the TRILL cloud acting as a bridge approach wasn't a goer) as it meant no modification to IS-IS. I assumed an entirely new discovery protocol, becuase I couldn't quickly think up a nice way to use BPDUs/STP, but if that is possible I'd quite like to hear thoughts on how it'd be done (just to satiate my curiosity on the subject). If you have a new protocol, and you discover other RBridges are on the link via this new protocol, you can either not transmit or recieve from the link if there is a discrepency between IS-IS and this new protocol. Otherwise you still need to elect the DRB somehow, and handle VLANs, so the discovery protocol needs to incorporate that behavior... then it starts looking like the current behaviour that's been designed into IS-IS... And if you follow that path maybe eventually maybe you've just created an all new TRILL specific Hello protocol... and perhaps remove some of the TRILL additions from IS-IS... or you say the opposite, and why have a separate protocl when a modified IS-IS will do. In the end, I am mostly uncomfortable with this arbitrary maximum hello size (1400 bytes?) at which above things are ok, or below which the result may be bad. When picking that maximum I expected it needed to be something much smaller, like <600 bytes... to make sure they always gets through... or maybe needs to be the same as what STP would cope with, or something less arbitrary. Probably speaking before properly engaging brain: I still don't *feel* there is enough value in adapting to different MTU sizes though to warrant it, it may be "we can, so why not?" to many, but I just have this automatic dislike for finding features in things that are rarely used but add complexity. What is the reason for adapting to small MTUs? Because some customers don't want to be told that they can't use this strange configuration? Who are these people? In the first 5 years will the people deploying TRILL be the ones with these environments? Or more realistically those with money that can afford to overcome such problems (which are problems in most networks anyway when the MTU <1500) when they deploy TRILL? And when TRILL trickles down to the kinds of people who can't, will they really still have this problem at that point in the future? If it doesn't adapt automatically, what is going to be the default MTU? I can think of some networks I know that would have this MTU problem, but only because of poor planning, and those people shouldn't be running TRILL anyway, they should be (and are) routing IP. Of course, it presumably came up for a reason. The safety aspect of the Hellos is clearly very important, too risky to ignore, but I (in my limited/humble experience) don't buy the MTU adaptation part so much. But alright, some people have MTU cripled links, want to run TRILL over them, and will be offended if told to upgrade. In summary: 1. If MTU adaptation for LSPs etc. is something IS-IS needs to do, wouldn't it be better to design it as a proposed enhancement to IS-IS, because surely it has non-TRILL uses in that case too...doesn't it? And surely it also goes both ways, increasing as well as decreasing the MTU size? 2. If not a separate protocol, of course shorten Hellos for safety, but if a link doesn't support the IS-IS MTU, I would've thought leave it at that. The IS-IS MTU size stays for all LSPs/etc. and it's only Hellos that are modified... 3. If there are really customers that want to run TRILL over small links and the minimum supported size settled on the WG is something quite large like 1400, then why not just adopt it as the new one size fits all standard for TRILL's version of IS-IS. It would be just like IS-IS, but with one field in the spec changed from 1492 to 1400. [/ignorable humble opinion] From dwfedyk at nortel.com Sun Apr 5 06:14:54 2009 From: dwfedyk at nortel.com (Don Fedyk) Date: Sun, 5 Apr 2009 09:14:54 -0400 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49D7E4CB.6020804@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> Hi Radia OK I hear what you are saying but there is also some subtle conclusions I can draw. On the Problems to solve list/ Desires list (not sorted): 1) Trill Discovery Protocol Robustness 2) Padded IS-IS Hellos take too much bandwidth 3) Staying clear of legacy STP etc 4) IS-IS Adjacency robustness On the solutions on the table/discussed about: a) IS-IS short/long Hellos b) Smaller IS-IS MTU (ReceiveLSPBufferSize reduced from 1492 or whatever) c) Solving the discovery with STP on RBridge >From the direction of the solutions mapped to the set of problems if you told me that 2) was your most important problem and 1) was secondary I'd understand where the direction is headed on a). (maybe everybody knew this but me). Also a) addresses 2) primarily. A simple solution is b) for 1) but does zero for 2). And the implementation of a) must be correct to ensure no impacts on 4). For the record 3) limits the ability to better address 1) with c) but c) admittedly has additional burden and does not address 2) other than the fact that the frequency of Hellos could drop if c) was implemented. So I would buy that a) primarily addresses 2) and improves 1)(when MTU is a factor) and that may be all the WG is willing to do, Regards, Don > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Subject: Re: [rbridge] Proposed compromise for short/long hellos > > Hi Don, > > You're basically suggesting something that was in the spec in > an earlier > version, and that I liked, but it got shot down. > The rule was that RBridges would participate in the STP on each link, > with priority configured so that RBridges would > have priority over regular bridges for becoming spanning tree > root. And > then an RBridge would become DRB if and only > if it was elected root in the STP. > > As I said, I liked this approach, but it got shot down, I'm > not sure I > remember all the reasons, but I think it had to > do with "which version of the spanning tree would RBridges have to > run?", and "what if bridges are also configured to > have highest priority"? > > But given that it was discussed in the WG, and given that for > whatever > reason it was overruled, we shouldn't try to > go back to that. There were a bunch of things I wish had gone a > different way, like the clever TRILL header encoding > that Don (I think) proposed where the VLAN and DA were > brought into the > TRILL header. But we'll never finish > this if we keep regretting decisions we made. > > Radia > > > Don Fedyk wrote: > > Hi James > > > > > >> Don Fedyk writes: > >> > >> > >>>> 2. An entire TRILL cloud looks like a single > >>>> STP-speaking bridge to the regular bridges attached > >>>> anywhere in the network. TRILL DRBs are responsible > >>>> for running a fraction of STP and somehow coordinating > >>>> with other DRBs. > >>>> > >>>> We've intentionally chosen (1), and I think you're > >>>> suggesting we switch to (2). > >>>> > >>> Not exactly I'm suggesting you make the RBridge attachment > >>> such that the LAN running STP decides two or more RBridges > >>> cannot be tolerated. STP will block the ports until you > >>> can fix things. Rather than running STP in a cloud you > >>> run enough of an STP stub locally on your RBridge to break > >>> loops in the rare event your discovery protocol fails. > >>> Remember your only counting on STP iff the discovery > >>> protocol breaks. And then IS-IS can be your discovery > >>> protocol. > >>> > >> I'm unaware of a good way to do that. I know how to make > >> links in the middle of the STP topology snap apart > >> unpredictably (reporting the same root bridge from each > >> RBridge ought to be enough), but I don't offhand know how to > >> cause STP to break off the attachment right at the > >> "duplicate" node. > >> > >> If you've got a concrete suggestion on how to do that, I'd > >> be interested. (I still doubt we can get consensus on going > >> that way, particularly because it'd hard to keep it from > >> interfering with the AF delegation behavior, but it'd be > >> interesting nonetheless.) > >> > >> > > > > What if every RBridge reported it was connected to a well known low > > priority "pseudo" bridge. If ever two RBridges were > connected to the > > same LAN and tried to do this STP would require one of the > RBridge break > > the connection to the "pseudo node". The RBridges would > know implicitly > > there were two RBridges connect to the LAN and one of then > would go into > > listen mostly mode (by removing the low priority pseudo > node from the > > BPDUs). The RBridge could still send locally to this LAN > sending Hellos > > etc but it would not bridge to the LAN. (It would see the > pseudo bridge > > already in the LAN.) It seems to me this would be a > condition before > > you became an appointed forwarder. Unfortunately I'm not > an STP expert > > to say defacto this would work but it seems you want to inject some > > harmless information using STP that would allow RBridges to detect > > RBridges. You still have the issue that the condition to become > > appointed forwarder or DRB is dependent on you not hearing > something. > > > > Regards, > > Don > > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > From Radia.Perlman at sun.com Sun Apr 5 12:07:57 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 05 Apr 2009 12:07:57 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> Message-ID: <49D9018D.7010303@sun.com> Don: (just a nit on your email) The problem with large hellos isn't wasted bandwidth...it's that they might not actually get received. Which causes loops with TRILL even though (as we pointed out in earlier messages) it might cause weird stuff with layer 3, but nothing fatal. Kris: "no modification to IS-IS" is not an issue. TRILL requires modifications to IS-IS. Not padding Hellos, and separating RBridge neighbor discovery from MTU discovery is no more of a change than any of the other things we've needed to do. It's always good to see if a change is gratuitous or necessary. In this case it is necessary. Eric: Yes we definitely should come up with a new name. I never liked "MTU". It's almost as baffling even when it is expanded. And "MTU discovery protocol", as you pointed out, is already taken, so perhaps we could call it "link size test protocol" or something. Jim: If we make ability to handle link size test protocol probes mandatory, we have to define *now*, the format of a probe. Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello message, so that we don't have to use a new packet type? All that needs to be in it is the size being tested, "s", and whether it is a probe or an ack. The probe would be padded to size s. The ack would not, but it would include "s", the size in the probe packet being ack'ed. This shouldn't be a big deal, let's try to agree quickly. So, to reiterate the design, this time making handling of a probe mandatory and part of the spec: a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than some size. Let's pick 1400 bytes, because that really is big enough to handle all reasonable sized Hellos. The only thing that could make it bigger is very weird assignments of Designated Forwarders, and the 1400 byte limit would just limit the DRB's creativity in handing out forwarding assignments. b) The LSP contains an optional TLV "I think the campus-wide MTU size is x". c) This MTU-size TLV is ignored in all LSPs except the LSP of the highest priority RBridge, R1, in the campus. If R1 does not include this MTU-size TLV in its LSP, then each RBridge R2 decides for itself what the MTU size should be, and does not report links to an RBridge neighbor R3, if the R2-R3 link cannot support R2's assumption of MTU. If R1 *does* include the MTU-size TLV, then R2 uses that size for a criteria for reporting links. Note that if R2 cannot support R1's MTU size, then R2 will continue attempting to be DRB, etc., but will not report any of its links in LSPs. d) We define a "link size probe" packet, which is padded to some size, say s, and included inside the data is the "s". These can be unicast to a neighbor, or multicast to the all-RBridges layer 2 address. Likewise there is a "link size probe ack", which contains "s", the size stated inside the probe packet being ack'd. The ack would be unicast to the sender of the probe. I'd recommend some variant on a Hello packet, just so we don't need a new packet type. But as I've said before, I tend to be overly disinterested in encoding. e) If R2 does not get acks from R3 for its link size probes, (say, after sending 3 of them), then R2 does not report R3 in its Hellos, R3 will not report connectivity to the pseudonode, and if it's a pt-to-pt link, neither R2 nor R3 will report the R2-R3 link in their LSP. From Radia.Perlman at sun.com Sun Apr 5 12:32:40 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 05 Apr 2009 12:32:40 -0700 Subject: [rbridge] Fancier tie-breaking in trees for more load-splitting, plus multiple nicknames In-Reply-To: <49CFBE44.4010404@sun.com> References: <49CFBE44.4010404@sun.com> Message-ID: <49D90758.4090002@sun.com> After thinking about this some more, I do like the idea of having different tiebreakers for different roots. Without doing simulations, etc., I don't know what the real gains are, but intuition says that if the parent with lowest ID is always chosen in a tie-breaker, that nodes with lower IDs will have more children, and traffic won't be spread as well. So...the questions are: a) whether we use the nickname number as the salt (the thing that will influence the tie-breaker differently in different trees) b) have explicit salt, c) allow acquisition of multiple nicknames Having explicit salt changes the packet format, and since we do have the ability to configure nicknames, I think we should just use the nickname number. Allowing multiple nicknames seems harmless, and might be useful. So I'd suggest that we say: a) the nickname TLV can have multiple nicknames, and the number of them is determined based on the "L". b) the tie-breaker is, that when calculating a particular tree from root nicknamed "R": if node N has k particular parents, then you sort the IDs of the parents, and take the Nth one, mod k. If we are going to do this, it has to be now, because otherwise we'd never be able to interwork if some RBridges are calculating trees differently. Radia From touch at ISI.EDU Mon Apr 6 08:28:48 2009 From: touch at ISI.EDU (Joe Touch) Date: Mon, 06 Apr 2009 08:28:48 -0700 Subject: [rbridge] Fancier tie-breaking in trees for more load-splitting, plus multiple nicknames In-Reply-To: <49D90758.4090002@sun.com> References: <49CFBE44.4010404@sun.com> <49D90758.4090002@sun.com> Message-ID: <49DA1FB0.3090402@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Radia, et al., Any mechanism for tiebreaking necessarily needs to use a single identifier, whether that's a single namespace or the concatenation of namespaces. Regardless of the names used, low-named parents will have more children. There's no way around that. Using configurable values for tie-breaking is dangerous due to the impact of misconfiguration, e.g., when values are duplicated. If such names are used as *part* of the tiebreaking, a more conventional value (e.g., the ID) should be used to "tie-break the tiebreaker" in the case of duplicates. However, as per my second note above, it's not clear why this is a win. Joe Radia Perlman wrote: > After thinking about this some more, I do like the idea of having > different tiebreakers for different roots. > Without doing simulations, etc., I don't know what the real gains are, > but intuition says that if > the parent with lowest ID is always chosen in a tie-breaker, that nodes > with lower IDs will have more children, > and traffic won't be spread as well. > > So...the questions are: > a) whether we use the nickname number as the salt (the thing that will > influence the tie-breaker > differently in different trees) > b) have explicit salt, > c) allow acquisition of multiple nicknames > > Having explicit salt changes the packet format, and since we do have the > ability to configure nicknames, I think > we should just use the nickname number. > > Allowing multiple nicknames seems harmless, and might be useful. > > So I'd suggest that we say: > a) the nickname TLV can have multiple nicknames, and the number of them is > determined based on the "L". > b) the tie-breaker is, that when calculating a particular tree from root > nicknamed > "R": if node N has k particular parents, then you sort the IDs of the > parents, and > take the Nth one, mod k. > > If we are going to do this, it has to be now, because otherwise we'd > never be > able to interwork if some RBridges are calculating trees differently. > > Radia > > _______________________________________________ > 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 iEYEARECAAYFAknaH7AACgkQE5f5cImnZrs+xwCbByCVp1lLiSvPlhiBh8PVOzJL SzcAoMWliDN0vZzyVkhueR2TF45y22Fa =F1NZ -----END PGP SIGNATURE----- From d3e3e3 at gmail.com Mon Apr 6 09:02:30 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 6 Apr 2009 12:02:30 -0400 Subject: [rbridge] Fancier tie-breaking in trees for more load-splitting, plus multiple nicknames In-Reply-To: <49DA1FB0.3090402@isi.edu> References: <49CFBE44.4010404@sun.com> <49D90758.4090002@sun.com> <49DA1FB0.3090402@isi.edu> Message-ID: <1028365c0904060902m41708feesdf60e57a1e23bb7@mail.gmail.com> Hi Joe, To be a bit more particular and precise, if you are building a tree rooted at the RBridge with nickname N and in the process come across an RBridge with k equal cost parents with System IDs ID0, ID1, ID2, ..., ID(k-1), you sort those potential system IDs as unsigned integers, then you divide N by k and use the remainder to select from the ordered list. Assuming there were multiple trees whose construction encountered RBridges with that same set of potential equal cost parents, the selections for the different trees will be at least somewhat randomly distributed over the ID0...ID(k-1) set, including trees for different nicknames that were might be given to the same distribution tree root RBridge. Donald On Mon, Apr 6, 2009 at 11:28 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Radia, et al., > > Any mechanism for tiebreaking necessarily needs to use a single > identifier, whether that's a single namespace or the concatenation of > namespaces. > > Regardless of the names used, low-named parents will have more children. > There's no way around that. > > Using configurable values for tie-breaking is dangerous due to the > impact of misconfiguration, e.g., when values are duplicated. If such > names are used as *part* of the tiebreaking, a more conventional value > (e.g., the ID) should be used to "tie-break the tiebreaker" in the case > of duplicates. However, as per my second note above, it's not clear why > this is a win. > > Joe > > Radia Perlman wrote: >> After thinking about this some more, I do like the idea of having >> different tiebreakers for different roots. >> Without doing simulations, etc., I don't know what the real gains are, >> but intuition says that if >> the parent with lowest ID is always chosen in a tie-breaker, that nodes >> with lower IDs will have more children, >> and traffic won't be spread as well. >> >> So...the questions are: >> a) whether we use the nickname number as the salt (the thing that will >> influence the tie-breaker >> differently in different trees) >> b) have explicit salt, >> c) allow acquisition of multiple nicknames >> >> Having explicit salt changes the packet format, and since we do have the >> ability to configure nicknames, I think >> we should just use the nickname number. >> >> Allowing multiple nicknames seems harmless, and might be useful. >> >> So I'd suggest that we say: >> a) the nickname TLV can have multiple nicknames, and the number of them is >> determined based on the "L". >> b) the tie-breaker is, that when calculating a particular tree from root >> nicknamed >> "R": if node N has k particular parents, then you sort the IDs of the >> parents, and >> take the Nth one, mod k. >> >> If we are going to do this, it has to be now, because otherwise we'd >> never be >> able to interwork if some RBridges are calculating trees differently. >> >> Radia >> >> _______________________________________________ >> 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 > > iEYEARECAAYFAknaH7AACgkQE5f5cImnZrs+xwCbByCVp1lLiSvPlhiBh8PVOzJL > SzcAoMWliDN0vZzyVkhueR2TF45y22Fa > =F1NZ > -----END PGP SIGNATURE----- > _______________________________________________ > 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 eric.gray at ericsson.com Mon Apr 6 09:26:03 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Mon, 6 Apr 2009 11:26:03 -0500 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49D9018D.7010303@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com><18902.17872.316711.466008@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com><18902.29854.271129.115146@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com><18902.33850.290558.736101@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com><49D7E4CB.6020804@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> <49D9018D.7010303@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EEA19E@eusrcmw721.eamcs.ericsson.se> Radia, Re-iterating my prior question, what does "c)" mean? I think an important piece is still missing. If I try to analyze "c)" a piece at a time, this is what I get: 1) RBridges throughout the campus are looking to be told what the common MTU is by the highest priority RBridge (apparently for the entire campus) in an MTU size TLV. 2) I assume you're intent is to make support for this mandatory (based on your comment to Jim) and - if that is so - the highest priority RBridge would (presumably) necessarily have this TLV. If this is correct, why include the (confusing/ambiguous) text about what the rest of the campus-wide RBridges would do if the highest priority RBridge does not include it. 3) Any RBridge that does not support this MTU size can contend to be DRB but cannot advertise any of its links in RBridge IS-IS. If that RBridge cannot advertise its links, what would be the effect of its being elected DRB for some set of end-stations, if it is not allowed to advertise associated links? If there are no RBridges associated with any set of end-stations that support the MTU advertised by the highest-priority bridge, then how will those end-stations be attached to the campus? I suspect the missing piece is how the highest priority RBridge determines what MTU to assert. And - if we were going to adopt this scheme - that would need to be deterministic as we probably don't want to have an arbitrarily complex shuffling of RBridges as a result of changing the higest priority RBridge. -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Sunday, April 05, 2009 3:08 PM To: TRILL/RBridge Working Group Subject: Re: [rbridge] Recap short long hello problem statement Don: (just a nit on your email) The problem with large hellos isn't wasted bandwidth...it's that they might not actually get received. Which causes loops with TRILL even though (as we pointed out in earlier messages) it might cause weird stuff with layer 3, but nothing fatal. Kris: "no modification to IS-IS" is not an issue. TRILL requires modifications to IS-IS. Not padding Hellos, and separating RBridge neighbor discovery from MTU discovery is no more of a change than any of the other things we've needed to do. It's always good to see if a change is gratuitous or necessary. In this case it is necessary. Eric: Yes we definitely should come up with a new name. I never liked "MTU". It's almost as baffling even when it is expanded. And "MTU discovery protocol", as you pointed out, is already taken, so perhaps we could call it "link size test protocol" or something. Jim: If we make ability to handle link size test protocol probes mandatory, we have to define *now*, the format of a probe. Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello message, so that we don't have to use a new packet type? All that needs to be in it is the size being tested, "s", and whether it is a probe or an ack. The probe would be padded to size s. The ack would not, but it would include "s", the size in the probe packet being ack'ed. This shouldn't be a big deal, let's try to agree quickly. So, to reiterate the design, this time making handling of a probe mandatory and part of the spec: a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than some size. Let's pick 1400 bytes, because that really is big enough to handle all reasonable sized Hellos. The only thing that could make it bigger is very weird assignments of Designated Forwarders, and the 1400 byte limit would just limit the DRB's creativity in handing out forwarding assignments. b) The LSP contains an optional TLV "I think the campus-wide MTU size is x". c) This MTU-size TLV is ignored in all LSPs except the LSP of the highest priority RBridge, R1, in the campus. If R1 does not include this MTU-size TLV in its LSP, then each RBridge R2 decides for itself what the MTU size should be, and does not report links to an RBridge neighbor R3, if the R2-R3 link cannot support R2's assumption of MTU. If R1 *does* include the MTU-size TLV, then R2 uses that size for a criteria for reporting links. Note that if R2 cannot support R1's MTU size, then R2 will continue attempting to be DRB, etc., but will not report any of its links in LSPs. d) We define a "link size probe" packet, which is padded to some size, say s, and included inside the data is the "s". These can be unicast to a neighbor, or multicast to the all-RBridges layer 2 address. Likewise there is a "link size probe ack", which contains "s", the size stated inside the probe packet being ack'd. The ack would be unicast to the sender of the probe. I'd recommend some variant on a Hello packet, just so we don't need a new packet type. But as I've said before, I tend to be overly disinterested in encoding. e) If R2 does not get acks from R3 for its link size probes, (say, after sending 3 of them), then R2 does not report R3 in its Hellos, R3 will not report connectivity to the pseudonode, and if it's a pt-to-pt link, neither R2 nor R3 will report the R2-R3 link in their LSP. _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From ddutt at cisco.com Mon Apr 6 10:48:55 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 06 Apr 2009 10:48:55 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49D9018D.7010303@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> <49D9018D.7010303@sun.com> Message-ID: <49DA4087.40901@cisco.com> The imperative problem to solve is to avoid two Rbridges from becoming DRBs on a single link and creating a loop. The optional problem, to me at least, is the MTU discovery. From this perspective, doing what Radia is suggesting i.e. not padding Hellos is what I support. If we chose to solve the MTU discovery problem, I'm not in favor of mandating every node to support it. On the separate problem of setting a campus-wide MTU for the sake of not sending LSP's larger than a lowest common denominator value, how does L3 IS-IS solve this ? So from Radia's email, I like (a), (d)/(e) should be optional and I'm not sure about the use of (b) and (c). Dinesh Radia Perlman wrote: > Don: (just a nit on your > email) The problem with large hellos isn't wasted bandwidth...it's that > they might not actually get received. Which causes loops with TRILL > even though (as we pointed out in earlier messages) it might cause weird > stuff with layer 3, but nothing fatal. > > Kris: "no modification to IS-IS" is not an issue. TRILL requires > modifications to IS-IS. Not padding Hellos, and separating > RBridge neighbor discovery from MTU discovery is no more of a change > than any of the other things we've needed to do. > It's always good to see if a change is gratuitous or necessary. In this > case it is necessary. > > Eric: Yes we definitely should come up with a new name. I never liked > "MTU". It's almost as baffling even when it is > expanded. And "MTU discovery protocol", as you pointed out, is already > taken, so perhaps we could call it > "link size test protocol" or something. > > Jim: If we make ability to handle link size test protocol probes > mandatory, we have to define *now*, the format of a probe. > Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello > message, so that we don't have to use a new packet type? > All that needs to be in it is the size being tested, "s", and whether it > is a probe or an ack. The probe would be > padded to size s. The ack would not, but it would include "s", the size > in the probe packet being ack'ed. > > This shouldn't be a big deal, let's try to agree quickly. > > So, to reiterate the design, this time making handling of a probe > mandatory and part of the spec: > > a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than > some size. Let's pick > 1400 bytes, because that really is big enough to handle all reasonable sized Hellos. > The only thing that could make it bigger is very weird assignments of Designated Forwarders, > and the 1400 byte limit would just limit the DRB's creativity in handing out forwarding > assignments. > > b) The LSP contains an optional TLV "I think the campus-wide MTU size is x". > > c) This MTU-size TLV is ignored in all LSPs except the LSP of the > highest priority RBridge, R1, in the campus. > If R1 does not include this MTU-size TLV in its LSP, then each RBridge > R2 decides for itself what the MTU size should > be, and does not report links to an RBridge neighbor R3, if the R2-R3 > link cannot support R2's assumption of MTU. > If R1 *does* include the MTU-size TLV, then R2 uses that size for a > criteria for reporting links. Note that > if R2 cannot support R1's MTU size, then R2 will continue attempting to > be DRB, etc., but will not report any > of its links in LSPs. > > d) We define a "link size probe" packet, which is padded to some > size, say s, and included inside the data > is the "s". These can be unicast to a neighbor, or multicast to the > all-RBridges layer 2 address. Likewise there is a "link size probe ack", which > contains "s", the size stated inside the probe packet being ack'd. The ack would > be unicast to the sender of the probe. I'd recommend some variant on a Hello > packet, just so we don't need a new packet type. But as I've said before, > I tend to be overly disinterested in encoding. > > e) If R2 does not get acks from R3 for its link size probes, (say, > after sending 3 of them), then R2 does not > report R3 in its Hellos, R3 will not report connectivity to the > pseudonode, and if it's a pt-to-pt link, neither R2 nor > R3 will report the R2-R3 link in their LSP. > > > > > _______________________________________________ > 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 ddutt at cisco.com Mon Apr 6 10:54:57 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 06 Apr 2009 10:54:57 -0700 Subject: [rbridge] Fancier tie-breaking in trees for more load-splitting, plus multiple nicknames In-Reply-To: <49D90758.4090002@sun.com> References: <49CFBE44.4010404@sun.com> <49D90758.4090002@sun.com> Message-ID: <49DA41F1.6030906@cisco.com> Radia, Radia Perlman wrote: > So...the questions are: > a) whether we use the nickname number as the salt (the thing that will > influence the tie-breaker > differently in different trees) > b) have explicit salt, > c) allow acquisition of multiple nicknames > I'm in favor of (a) and (c). Explicit salt or some other implicit scheme is OK with me, though explicit salt seems superior. The main reason we need (a) is as you point out, for multi-destination frames, we don't get utilization of all links in the network. Two trees, associated with two different switches, could both choose the same set of links largely negating the advantage of multiple trees. The reason I want (c) too is because I'm aware of networks where the number of optimal roots is small enough that it results in many nodes not using all their links for multi-destination frames. Choosing a different set of roots results in an unscalable number of trees. Having the optimal roots pick multiple nicknames solves the problem. Dinesh -- 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 Mon Apr 6 11:53:39 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Mon, 6 Apr 2009 13:53:39 -0500 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49DA4087.40901@cisco.com> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com><49D9018D.7010303@sun.com> <49DA4087.40901@cisco.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EEA4E1@eusrcmw721.eamcs.ericsson.se> Dinesh, The MTU (common, or least common) size problem is not solved by routing at L3. It is solved - for IP at least - by setting the "don't fragment" bit at sending hsosts and handling the resulting ICMP error messages. If it was handled by routers, the routers would have to handle IP fragmentation - which most router vendors would rather not do... -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt Sent: Monday, April 06, 2009 1:49 PM To: Radia Perlman Cc: TRILL/RBridge Working Group Subject: Re: [rbridge] Recap short long hello problem statement The imperative problem to solve is to avoid two Rbridges from becoming DRBs on a single link and creating a loop. The optional problem, to me at least, is the MTU discovery. From this perspective, doing what Radia is suggesting i.e. not padding Hellos is what I support. If we chose to solve the MTU discovery problem, I'm not in favor of mandating every node to support it. On the separate problem of setting a campus-wide MTU for the sake of not sending LSP's larger than a lowest common denominator value, how does L3 IS-IS solve this ? So from Radia's email, I like (a), (d)/(e) should be optional and I'm not sure about the use of (b) and (c). Dinesh Radia Perlman wrote: > Don: (just a nit on your > email) The problem with large hellos isn't wasted bandwidth...it's that > they might not actually get received. Which causes loops with TRILL > even though (as we pointed out in earlier messages) it might cause weird > stuff with layer 3, but nothing fatal. > > Kris: "no modification to IS-IS" is not an issue. TRILL requires > modifications to IS-IS. Not padding Hellos, and separating > RBridge neighbor discovery from MTU discovery is no more of a change > than any of the other things we've needed to do. > It's always good to see if a change is gratuitous or necessary. In this > case it is necessary. > > Eric: Yes we definitely should come up with a new name. I never liked > "MTU". It's almost as baffling even when it is > expanded. And "MTU discovery protocol", as you pointed out, is already > taken, so perhaps we could call it > "link size test protocol" or something. > > Jim: If we make ability to handle link size test protocol probes > mandatory, we have to define *now*, the format of a probe. > Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello > message, so that we don't have to use a new packet type? > All that needs to be in it is the size being tested, "s", and whether it > is a probe or an ack. The probe would be > padded to size s. The ack would not, but it would include "s", the size > in the probe packet being ack'ed. > > This shouldn't be a big deal, let's try to agree quickly. > > So, to reiterate the design, this time making handling of a probe > mandatory and part of the spec: > > a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than > some size. Let's pick > 1400 bytes, because that really is big enough to handle all reasonable sized Hellos. > The only thing that could make it bigger is very weird assignments of Designated Forwarders, > and the 1400 byte limit would just limit the DRB's creativity in handing out forwarding > assignments. > > b) The LSP contains an optional TLV "I think the campus-wide MTU size is x". > > c) This MTU-size TLV is ignored in all LSPs except the LSP of the > highest priority RBridge, R1, in the campus. > If R1 does not include this MTU-size TLV in its LSP, then each RBridge > R2 decides for itself what the MTU size should > be, and does not report links to an RBridge neighbor R3, if the R2-R3 > link cannot support R2's assumption of MTU. > If R1 *does* include the MTU-size TLV, then R2 uses that size for a > criteria for reporting links. Note that > if R2 cannot support R1's MTU size, then R2 will continue attempting to > be DRB, etc., but will not report any > of its links in LSPs. > > d) We define a "link size probe" packet, which is padded to some > size, say s, and included inside the data > is the "s". These can be unicast to a neighbor, or multicast to the > all-RBridges layer 2 address. Likewise there is a "link size probe ack", which > contains "s", the size stated inside the probe packet being ack'd. The ack would > be unicast to the sender of the probe. I'd recommend some variant on a Hello > packet, just so we don't need a new packet type. But as I've said before, > I tend to be overly disinterested in encoding. > > e) If R2 does not get acks from R3 for its link size probes, (say, > after sending 3 of them), then R2 does not > report R3 in its Hellos, R3 will not report connectivity to the > pseudonode, and if it's a pt-to-pt link, neither R2 nor > R3 will report the R2-R3 link in their LSP. > > > > > _______________________________________________ > 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 _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From ddutt at cisco.com Mon Apr 6 12:08:27 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 06 Apr 2009 12:08:27 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EEA4E1@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com><49D9018D.7010303@sun.com> <49DA4087.40901@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EEA4E1@eusrcmw721.eamcs.ericsson.se> Message-ID: <49DA532B.1030900@cisco.com> My question was related to not breaking down LSP fragments sent by Rbridges who have a larger-than-thou MTU. I was told that in IS-IS, LSP's of other Rbridges cannot be chopped up into smaller pieces for transmission on lower sized MTU links. Therefore, Radia was proposing the campus-wide MTU TLV. Dinesh Eric Gray wrote: > Dinesh, > > The MTU (common, or least common) size problem is not solved by > routing at L3. It is solved - for IP at least - by setting the "don't > fragment" bit at sending hsosts and handling the resulting ICMP error > messages. > > If it was handled by routers, the routers would have to handle > IP fragmentation - which most router vendors would rather not do... > > -- > Eric > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Monday, April 06, 2009 1:49 PM > To: Radia Perlman > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Recap short long hello problem statement > > The imperative problem to solve is to avoid two Rbridges from becoming > DRBs on a single link and creating a loop. The optional problem, to me > at least, is the MTU discovery. > > From this perspective, doing what Radia is suggesting i.e. not padding > Hellos is what I support. If we chose to solve the MTU discovery > problem, I'm not in favor of mandating every node to support it. > > On the separate problem of setting a campus-wide MTU for the sake of not > > sending LSP's larger than a lowest common denominator value, how does > L3 IS-IS solve this ? > > So from Radia's email, I like (a), (d)/(e) should be optional and I'm > not sure about the use of (b) and (c). > > Dinesh > Radia Perlman wrote: > >> Don: (just a nit on your >> email) The problem with large hellos isn't wasted bandwidth...it's >> > that > >> they might not actually get received. Which causes loops with TRILL >> even though (as we pointed out in earlier messages) it might cause >> > weird > >> stuff with layer 3, but nothing fatal. >> >> Kris: "no modification to IS-IS" is not an issue. TRILL requires >> modifications to IS-IS. Not padding Hellos, and separating >> RBridge neighbor discovery from MTU discovery is no more of a change >> than any of the other things we've needed to do. >> It's always good to see if a change is gratuitous or necessary. In >> > this > >> case it is necessary. >> >> Eric: Yes we definitely should come up with a new name. I never liked >> "MTU". It's almost as baffling even when it is >> expanded. And "MTU discovery protocol", as you pointed out, is >> > already > >> taken, so perhaps we could call it >> "link size test protocol" or something. >> >> Jim: If we make ability to handle link size test protocol probes >> mandatory, we have to define *now*, the format of a probe. >> Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello >> message, so that we don't have to use a new packet type? >> All that needs to be in it is the size being tested, "s", and whether >> > it > >> is a probe or an ack. The probe would be >> padded to size s. The ack would not, but it would include "s", the >> > size > >> in the probe packet being ack'ed. >> >> This shouldn't be a big deal, let's try to agree quickly. >> >> So, to reiterate the design, this time making handling of a probe >> mandatory and part of the spec: >> >> a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than >> some size. Let's pick >> 1400 bytes, because that really is big enough to handle all reasonable >> > sized Hellos. > >> The only thing that could make it bigger is very weird assignments of >> > Designated Forwarders, > >> and the 1400 byte limit would just limit the DRB's creativity in >> > handing out forwarding > >> assignments. >> >> b) The LSP contains an optional TLV "I think the campus-wide MTU size >> > is x". > >> c) This MTU-size TLV is ignored in all LSPs except the LSP of the >> highest priority RBridge, R1, in the campus. >> If R1 does not include this MTU-size TLV in its LSP, then each RBridge >> > > >> R2 decides for itself what the MTU size should >> be, and does not report links to an RBridge neighbor R3, if the R2-R3 >> link cannot support R2's assumption of MTU. >> If R1 *does* include the MTU-size TLV, then R2 uses that size for a >> criteria for reporting links. Note that >> if R2 cannot support R1's MTU size, then R2 will continue attempting >> > to > >> be DRB, etc., but will not report any >> of its links in LSPs. >> >> d) We define a "link size probe" packet, which is padded to some >> size, say s, and included inside the data >> is the "s". These can be unicast to a neighbor, or multicast to the >> all-RBridges layer 2 address. Likewise there is a "link size probe >> > ack", which > >> contains "s", the size stated inside the probe packet being ack'd. The >> > ack would > >> be unicast to the sender of the probe. I'd recommend some variant on a >> > Hello > >> packet, just so we don't need a new packet type. But as I've said >> > before, > >> I tend to be overly disinterested in encoding. >> >> e) If R2 does not get acks from R3 for its link size probes, (say, >> after sending 3 of them), then R2 does not >> report R3 in its Hellos, R3 will not report connectivity to the >> pseudonode, and if it's a pt-to-pt link, neither R2 nor >> R3 will report the R2-R3 link in their LSP. >> >> >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Radia.Perlman at sun.com Mon Apr 6 12:09:43 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 06 Apr 2009 12:09:43 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04EEA4E1@eusrcmw721.eamcs.ericsson.se> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> <49D9018D.7010303@sun.com> <49DA4087.40901@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EEA4E1@eusrcmw721.eamcs.ericsson.se> Message-ID: <49DA5377.4080807@sun.com> In that case -- if L3 IS-IS doesn't worry about network-wide MTU size, then it seems like we could probably live with the extremely simple fix to TRILL of: "Don't pad Hellos". End of story. I'd like that. Radia Eric Gray wrote: > Dinesh, > > The MTU (common, or least common) size problem is not solved by > routing at L3. It is solved - for IP at least - by setting the "don't > fragment" bit at sending hsosts and handling the resulting ICMP error > messages. > > If it was handled by routers, the routers would have to handle > IP fragmentation - which most router vendors would rather not do... > > -- > Eric > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Monday, April 06, 2009 1:49 PM > To: Radia Perlman > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Recap short long hello problem statement > > The imperative problem to solve is to avoid two Rbridges from becoming > DRBs on a single link and creating a loop. The optional problem, to me > at least, is the MTU discovery. > > From this perspective, doing what Radia is suggesting i.e. not padding > Hellos is what I support. If we chose to solve the MTU discovery > problem, I'm not in favor of mandating every node to support it. > > On the separate problem of setting a campus-wide MTU for the sake of not > > sending LSP's larger than a lowest common denominator value, how does > L3 IS-IS solve this ? > > So from Radia's email, I like (a), (d)/(e) should be optional and I'm > not sure about the use of (b) and (c). > > Dinesh > Radia Perlman wrote: > >> Don: (just a nit on your >> email) The problem with large hellos isn't wasted bandwidth...it's >> > that > >> they might not actually get received. Which causes loops with TRILL >> even though (as we pointed out in earlier messages) it might cause >> > weird > >> stuff with layer 3, but nothing fatal. >> >> Kris: "no modification to IS-IS" is not an issue. TRILL requires >> modifications to IS-IS. Not padding Hellos, and separating >> RBridge neighbor discovery from MTU discovery is no more of a change >> than any of the other things we've needed to do. >> It's always good to see if a change is gratuitous or necessary. In >> > this > >> case it is necessary. >> >> Eric: Yes we definitely should come up with a new name. I never liked >> "MTU". It's almost as baffling even when it is >> expanded. And "MTU discovery protocol", as you pointed out, is >> > already > >> taken, so perhaps we could call it >> "link size test protocol" or something. >> >> Jim: If we make ability to handle link size test protocol probes >> mandatory, we have to define *now*, the format of a probe. >> Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello >> message, so that we don't have to use a new packet type? >> All that needs to be in it is the size being tested, "s", and whether >> > it > >> is a probe or an ack. The probe would be >> padded to size s. The ack would not, but it would include "s", the >> > size > >> in the probe packet being ack'ed. >> >> This shouldn't be a big deal, let's try to agree quickly. >> >> So, to reiterate the design, this time making handling of a probe >> mandatory and part of the spec: >> >> a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than >> some size. Let's pick >> 1400 bytes, because that really is big enough to handle all reasonable >> > sized Hellos. > >> The only thing that could make it bigger is very weird assignments of >> > Designated Forwarders, > >> and the 1400 byte limit would just limit the DRB's creativity in >> > handing out forwarding > >> assignments. >> >> b) The LSP contains an optional TLV "I think the campus-wide MTU size >> > is x". > >> c) This MTU-size TLV is ignored in all LSPs except the LSP of the >> highest priority RBridge, R1, in the campus. >> If R1 does not include this MTU-size TLV in its LSP, then each RBridge >> > > >> R2 decides for itself what the MTU size should >> be, and does not report links to an RBridge neighbor R3, if the R2-R3 >> link cannot support R2's assumption of MTU. >> If R1 *does* include the MTU-size TLV, then R2 uses that size for a >> criteria for reporting links. Note that >> if R2 cannot support R1's MTU size, then R2 will continue attempting >> > to > >> be DRB, etc., but will not report any >> of its links in LSPs. >> >> d) We define a "link size probe" packet, which is padded to some >> size, say s, and included inside the data >> is the "s". These can be unicast to a neighbor, or multicast to the >> all-RBridges layer 2 address. Likewise there is a "link size probe >> > ack", which > >> contains "s", the size stated inside the probe packet being ack'd. The >> > ack would > >> be unicast to the sender of the probe. I'd recommend some variant on a >> > Hello > >> packet, just so we don't need a new packet type. But as I've said >> > before, > >> I tend to be overly disinterested in encoding. >> >> e) If R2 does not get acks from R3 for its link size probes, (say, >> after sending 3 of them), then R2 does not >> report R3 in its Hellos, R3 will not report connectivity to the >> pseudonode, and if it's a pt-to-pt link, neither R2 nor >> R3 will report the R2-R3 link in their LSP. >> >> >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> > > From eric.gray at ericsson.com Mon Apr 6 12:12:33 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Mon, 6 Apr 2009 14:12:33 -0500 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49DA532B.1030900@cisco.com> References: <5fc07485440.49d365b1@sunlabs.com><49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com><49D9018D.7010303@sun.com> <49DA4087.40901@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EEA4E1@eusrcmw721.eamcs.ericsson.se> <49DA532B.1030900@cisco.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04EEA559@eusrcmw721.eamcs.ericsson.se> Dinesh, Aha. Radia's proposal is for IS-IS control plane use only. That's something I hadn't picked up on. Thanks! -- Eric -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Monday, April 06, 2009 3:08 PM To: Eric Gray Cc: Radia Perlman; TRILL/RBridge Working Group Subject: Re: [rbridge] Recap short long hello problem statement Importance: High My question was related to not breaking down LSP fragments sent by Rbridges who have a larger-than-thou MTU. I was told that in IS-IS, LSP's of other Rbridges cannot be chopped up into smaller pieces for transmission on lower sized MTU links. Therefore, Radia was proposing the campus-wide MTU TLV. Dinesh Eric Gray wrote: > Dinesh, > > The MTU (common, or least common) size problem is not solved by > routing at L3. It is solved - for IP at least - by setting the "don't > fragment" bit at sending hsosts and handling the resulting ICMP error > messages. > > If it was handled by routers, the routers would have to handle > IP fragmentation - which most router vendors would rather not do... > > -- > Eric > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Monday, April 06, 2009 1:49 PM > To: Radia Perlman > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Recap short long hello problem statement > > The imperative problem to solve is to avoid two Rbridges from becoming > DRBs on a single link and creating a loop. The optional problem, to me > at least, is the MTU discovery. > > From this perspective, doing what Radia is suggesting i.e. not padding > Hellos is what I support. If we chose to solve the MTU discovery > problem, I'm not in favor of mandating every node to support it. > > On the separate problem of setting a campus-wide MTU for the sake of not > > sending LSP's larger than a lowest common denominator value, how does > L3 IS-IS solve this ? > > So from Radia's email, I like (a), (d)/(e) should be optional and I'm > not sure about the use of (b) and (c). > > Dinesh > Radia Perlman wrote: > >> Don: (just a nit on your >> email) The problem with large hellos isn't wasted bandwidth...it's >> > that > >> they might not actually get received. Which causes loops with TRILL >> even though (as we pointed out in earlier messages) it might cause >> > weird > >> stuff with layer 3, but nothing fatal. >> >> Kris: "no modification to IS-IS" is not an issue. TRILL requires >> modifications to IS-IS. Not padding Hellos, and separating >> RBridge neighbor discovery from MTU discovery is no more of a change >> than any of the other things we've needed to do. >> It's always good to see if a change is gratuitous or necessary. In >> > this > >> case it is necessary. >> >> Eric: Yes we definitely should come up with a new name. I never liked >> "MTU". It's almost as baffling even when it is >> expanded. And "MTU discovery protocol", as you pointed out, is >> > already > >> taken, so perhaps we could call it >> "link size test protocol" or something. >> >> Jim: If we make ability to handle link size test protocol probes >> mandatory, we have to define *now*, the format of a probe. >> Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello >> message, so that we don't have to use a new packet type? >> All that needs to be in it is the size being tested, "s", and whether >> > it > >> is a probe or an ack. The probe would be >> padded to size s. The ack would not, but it would include "s", the >> > size > >> in the probe packet being ack'ed. >> >> This shouldn't be a big deal, let's try to agree quickly. >> >> So, to reiterate the design, this time making handling of a probe >> mandatory and part of the spec: >> >> a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than >> some size. Let's pick >> 1400 bytes, because that really is big enough to handle all reasonable >> > sized Hellos. > >> The only thing that could make it bigger is very weird assignments of >> > Designated Forwarders, > >> and the 1400 byte limit would just limit the DRB's creativity in >> > handing out forwarding > >> assignments. >> >> b) The LSP contains an optional TLV "I think the campus-wide MTU size >> > is x". > >> c) This MTU-size TLV is ignored in all LSPs except the LSP of the >> highest priority RBridge, R1, in the campus. >> If R1 does not include this MTU-size TLV in its LSP, then each RBridge >> > > >> R2 decides for itself what the MTU size should >> be, and does not report links to an RBridge neighbor R3, if the R2-R3 >> link cannot support R2's assumption of MTU. >> If R1 *does* include the MTU-size TLV, then R2 uses that size for a >> criteria for reporting links. Note that >> if R2 cannot support R1's MTU size, then R2 will continue attempting >> > to > >> be DRB, etc., but will not report any >> of its links in LSPs. >> >> d) We define a "link size probe" packet, which is padded to some >> size, say s, and included inside the data >> is the "s". These can be unicast to a neighbor, or multicast to the >> all-RBridges layer 2 address. Likewise there is a "link size probe >> > ack", which > >> contains "s", the size stated inside the probe packet being ack'd. The >> > ack would > >> be unicast to the sender of the probe. I'd recommend some variant on a >> > Hello > >> packet, just so we don't need a new packet type. But as I've said >> > before, > >> I tend to be overly disinterested in encoding. >> >> e) If R2 does not get acks from R3 for its link size probes, (say, >> after sending 3 of them), then R2 does not >> report R3 in its Hellos, R3 will not report connectivity to the >> pseudonode, and if it's a pt-to-pt link, neither R2 nor >> R3 will report the R2-R3 link in their LSP. >> >> >> >> >> _______________________________________________ >> 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 james.d.carlson at Sun.COM Mon Apr 6 12:14:31 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Mon, 6 Apr 2009 15:14:31 -0400 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49DA4087.40901@cisco.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> <49D9018D.7010303@sun.com> <49DA4087.40901@cisco.com> Message-ID: <18906.21655.13037.68088@gargle.gargle.HOWL> Dinesh G Dutt writes: > From this perspective, doing what Radia is suggesting i.e. not padding > Hellos is what I support. If we chose to solve the MTU discovery > problem, I'm not in favor of mandating every node to support it. It depends on what you mean by "support." If you mean forcing every implementation to send probe messages and actively look for restricted MTUs between peer RBridges, then I completely agree. That shouldn't be mandatory. Not everyone agrees that it's necessary in all implementations. If you mean just responding appropriately to the probe message, then I disagree. That response mechanism needs to be mandatory for two reasons: 1. Making it optional makes it effectively impossible for others to build interoperable implementations that *do* implement the feature, because they have to live with the risk of paths that won't respond and won't detect MTU problems. 2. Making it optional also adds more complexity: those nodes that do implement it will need a way to find out whether the non-responding peers are failing to respond because the MTU is restricted or because they're just ornery. That forces the addition of the extra bit in Hello as Radia originally suggested. I suggest keeping it simple: response is trivial to do, represents no burden on those that otherwise lack the feature, and is thus required. Actively sending probes is not simple, but is not required. > On the separate problem of setting a campus-wide MTU for the sake of not > sending LSP's larger than a lowest common denominator value, how does > L3 IS-IS solve this ? Agreed; that really shouldn't be addressed in this thread, because it is a completely separate matter. (But part of the answer is that most L3s can deal with separate subnetworks with differing MTUs. We don't have that luxury because we're forwarding at L2.) -- 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 Mon Apr 6 12:43:44 2009 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 6 Apr 2009 12:43:44 -0700 Subject: [rbridge] Fancier tie-breaking in trees for more load-splitting, plus multiple nicknames In-Reply-To: <49DA41F1.6030906@cisco.com> References: <49CFBE44.4010404@sun.com><49D90758.4090002@sun.com> <49DA41F1.6030906@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E02C6B1C3@HQ-EXCH-5.corp.brocade.com> I don't have a preference for (a) or (b), but (c) definitely seems like a good idea. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt > Sent: Monday, April 06, 2009 10:55 AM > To: Radia Perlman > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Fancier tie-breaking in trees for more > load-splitting, plus multiple nicknames > > Radia, > > Radia Perlman wrote: > > So...the questions are: > > a) whether we use the nickname number as the salt (the > thing that will > > influence the tie-breaker > > differently in different trees) > > b) have explicit salt, > > c) allow acquisition of multiple nicknames > > > I'm in favor of (a) and (c). Explicit salt or some other > implicit scheme > is OK with me, though explicit salt seems superior. > > The main reason we need (a) is as you point out, for > multi-destination > frames, we don't get utilization of all links in the network. > Two trees, > associated with two different switches, could both choose the > same set > of links largely negating the advantage of multiple trees. > > The reason I want (c) too is because I'm aware of networks where the > number of optimal roots is small enough that it results in many nodes > not using all their links for multi-destination frames. Choosing a > different set of roots results in an unscalable number of > trees. Having > the optimal roots pick multiple nicknames solves the problem. > > Dinesh > > -- > We make our world significant by the courage of our questions and by > the depth of our answers. - Carl Sagan > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From iesg-secretary at ietf.org Mon Apr 6 12:56:09 2009 From: iesg-secretary at ietf.org (The IESG) Date: Mon, 6 Apr 2009 12:56:09 -0700 (PDT) Subject: [rbridge] Document Action: 'Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement' to Informational RFC Message-ID: <20090406195609.592B928C1F6@core3.amsl.com> The IESG has approved the following document: - 'Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement ' as an Informational RFC This document is the product of the Transparent Interconnection of Lots of Links Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-06.txt Technical Summary This document discusses the avoidance of some problems in Layer 2 forwarding with the spanning tree protocol through the use of link state routing techniques, possibly with a hop count limit. Desired properties and the applicability of such improved forwarding are also given. Working Group Summary This document was Working Group Last Called twice. There were informal complaints that the first WGLC was improper because the document was not complete at that time. Document Quality This is an informational document intended to describe the problem to which the TRILL working group is addressed and the applicability of solutions. Document quality is good. From smirtora at cisco.com Mon Apr 6 15:09:43 2009 From: smirtora at cisco.com (Sina Mirtorabi (smirtora)) Date: Mon, 6 Apr 2009 15:09:43 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49D9018D.7010303@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com><49D4ECA0.2060407@sun.com><941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se><49D5F318.4000600@cisco.com><941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se><18902.9853.482320.518395@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com><18902.17872.316711.466008@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com><18902.29854.271129.115146@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com><18902.33850.290558.736101@gargle.gargle.HOWL><34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com><49D7E4CB.6020804@sun.com><34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> <49D9018D.7010303@sun.com> Message-ID: Radia, Let's assume, we know that for a given minimum MTU size ( Smin = 1500-X ) all the stupid old devices could handle correctly the packet and whatever overhead that is added to the packet would still not make its size more than 1500 byte. Now if we agree on Smin then most of the below proposal is unnecessary apart from NOT padding Hello (although that could be included as well but just for safety) Note that ISIS spec (ISO 10589:2002) define the following parameters ReceiveLSPBufferSize set to 1492 (by default) originatingLSPBufferSize included in a TLV when generating LSP The assumption is that originatingLSPBufferSize <= ReceiveLSPBufferSize & originatingLSPBufferSize <= MTU for all links For Trill if we set the originatingLSPBufferSize = Smin then we know that all packets will make it through legacy devices. I think a simple conservative calculation by considering worse case overhead could give us the Smin. Of course if there is a "L2 MTU path discovery mechanism" which can tell what is a better value for S when sending packets then such a value could be used otherwise the default has to be set to Smin. Last, defining L2 MTU path discovery mechanism should be outside of the TRILL scope or at least being optional. Thanks Sina > This shouldn't be a big deal, let's try to agree quickly. > > So, to reiterate the design, this time making handling of a probe > mandatory and part of the spec: > > a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than > some size. Let's pick > 1400 bytes, because that really is big enough to handle all reasonable > sized Hellos. > The only thing that could make it bigger is very weird assignments of > Designated Forwarders, > and the 1400 byte limit would just limit the DRB's creativity in > handing out forwarding > assignments. > > b) The LSP contains an optional TLV "I think the campus-wide MTU size > is x". > > c) This MTU-size TLV is ignored in all LSPs except the LSP of the > highest priority RBridge, R1, in the campus. > If R1 does not include this MTU-size TLV in its LSP, then each RBridge > R2 decides for itself what the MTU size should > be, and does not report links to an RBridge neighbor R3, if the R2-R3 > link cannot support R2's assumption of MTU. > If R1 *does* include the MTU-size TLV, then R2 uses that size for a > criteria for reporting links. Note that > if R2 cannot support R1's MTU size, then R2 will continue attempting to > be DRB, etc., but will not report any > of its links in LSPs. > > d) We define a "link size probe" packet, which is padded to some > size, say s, and included inside the data > is the "s". These can be unicast to a neighbor, or multicast to the > all-RBridges layer 2 address. Likewise there is a "link size probe > ack", which > contains "s", the size stated inside the probe packet being ack'd. The > ack would > be unicast to the sender of the probe. I'd recommend some variant on a > Hello > packet, just so we don't need a new packet type. But as I've said > before, > I tend to be overly disinterested in encoding. > > e) If R2 does not get acks from R3 for its link size probes, (say, > after sending 3 of them), then R2 does not > report R3 in its Hellos, R3 will not report connectivity to the > pseudonode, and if it's a pt-to-pt link, neither R2 nor > R3 will report the R2-R3 link in their LSP. > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Mon Apr 6 15:36:20 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 06 Apr 2009 15:36:20 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> <49D9018D.7010303@sun.com> Message-ID: <49DA83E4.8070003@sun.com> Personally, I'm happy to completely get rid of any MTU discovery mechanism, and have the only change to the TRILL spec at this point to say that IS-IS MUST NOT pad hellos. If Hellos don't get through, it could cause loops. If there isn't an agreed-upon campus-wide MTU size, then a) big data packets might not make it through on some links (who cares about data packets :-) ) b) LSPs might not make it through on some links (perhaps could cause some problems, but I'm not sure if this really would be that much of a problem) There were some IS-IS people at the IETF meeting that seemed to be arguing that MTU discovery was important. I'll raise the issue on the IS-IS mailing list, and see if anyone has any arguments about why it would be bad for TRILL not to bother with MTU discovery. *********** So, I think at this point we've agreed upon: TRILL spec should be modified to say Hellos MUST NOT be padded ******** We are undecided about: . whether we need an MTU discovery mechanism, and if we have it, whether it ought to be mandatory or optional, and whether we should have some sort of discovery mechanism for the campus-wide MTU size. Radia Sina Mirtorabi (smirtora) wrote: > Radia, > > Let's assume, we know that for a given minimum MTU size ( Smin = 1500-X > ) all the stupid old devices could handle correctly the packet and > whatever overhead that is added to the packet would still not make its > size more than 1500 byte. Now if we agree on Smin then most of the below > proposal is unnecessary apart from NOT padding Hello (although that > could be included as well but just for safety) > > > Note that ISIS spec (ISO 10589:2002) define the following parameters > > ReceiveLSPBufferSize set to 1492 (by default) > originatingLSPBufferSize included in a TLV when generating LSP > > The assumption is that > > originatingLSPBufferSize <= ReceiveLSPBufferSize > & > originatingLSPBufferSize <= MTU for all links > > > > For Trill if we set the originatingLSPBufferSize = Smin then we know > that all packets will make it through legacy devices. I think a simple > conservative calculation by considering worse case overhead could give > us the Smin. Of course if there is a "L2 MTU path discovery mechanism" > which can tell what is a better value for S when sending packets then > such a value could be used otherwise the default has to be set to Smin. > Last, defining L2 MTU path discovery mechanism should be outside of the > TRILL scope or at least being optional. > > > Thanks > Sina > > >> This shouldn't be a big deal, let's try to agree quickly. >> >> So, to reiterate the design, this time making handling of a probe >> mandatory and part of the spec: >> >> a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than >> some size. Let's pick >> 1400 bytes, because that really is big enough to handle all reasonable >> sized Hellos. >> The only thing that could make it bigger is very weird assignments of >> Designated Forwarders, >> and the 1400 byte limit would just limit the DRB's creativity in >> handing out forwarding >> assignments. >> >> b) The LSP contains an optional TLV "I think the campus-wide MTU size >> is x". >> >> c) This MTU-size TLV is ignored in all LSPs except the LSP of the >> highest priority RBridge, R1, in the campus. >> If R1 does not include this MTU-size TLV in its LSP, then each RBridge >> R2 decides for itself what the MTU size should >> be, and does not report links to an RBridge neighbor R3, if the R2-R3 >> link cannot support R2's assumption of MTU. >> If R1 *does* include the MTU-size TLV, then R2 uses that size for a >> criteria for reporting links. Note that >> if R2 cannot support R1's MTU size, then R2 will continue attempting >> > to > >> be DRB, etc., but will not report any >> of its links in LSPs. >> >> d) We define a "link size probe" packet, which is padded to some >> size, say s, and included inside the data >> is the "s". These can be unicast to a neighbor, or multicast to the >> all-RBridges layer 2 address. Likewise there is a "link size probe >> ack", which >> contains "s", the size stated inside the probe packet being ack'd. The >> ack would >> be unicast to the sender of the probe. I'd recommend some variant on a >> Hello >> packet, just so we don't need a new packet type. But as I've said >> before, >> I tend to be overly disinterested in encoding. >> >> e) If R2 does not get acks from R3 for its link size probes, (say, >> after sending 3 of them), then R2 does not >> report R3 in its Hellos, R3 will not report connectivity to the >> pseudonode, and if it's a pt-to-pt link, neither R2 nor >> R3 will report the R2-R3 link in their LSP. >> >> >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> From smirtora at cisco.com Mon Apr 6 16:15:09 2009 From: smirtora at cisco.com (Sina Mirtorabi (smirtora)) Date: Mon, 6 Apr 2009 16:15:09 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: <49DA83E4.8070003@sun.com> References: <5fc07485440.49d365b1@sunlabs.com> <49D4B404.5000805@cisco.com> <49D4ECA0.2060407@sun.com> <941D5DCD8C42014FAF70FB7424686DCF04EC147C@eusrcmw721.eamcs.ericsson.se> <49D5F318.4000600@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF04EC159E@eusrcmw721.eamcs.ericsson.se> <18902.9853.482320.518395@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F2F30@zrtphxm2.corp.nortel.com> <18902.17872.316711.466008@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F33E5@zrtphxm2.corp.nortel.com> <18902.29854.271129.115146@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F34C5@zrtphxm2.corp.nortel.com> <18902.33850.290558.736101@gargle.gargle.HOWL> <34B3EAA5B3066A42914D28C5ECF5FEA4193F3568@zrtphxm2.corp.nortel.com> <49D7E4CB.6020804@sun.com> <34B3EAA5B3066A42914D28C5ECF5FEA4193F35FA@zrtphxm2.corp.nortel.com> <49D9018D.7010303@sun.com> <49DA83E4.8070003@sun.com> Message-ID: Radia, Supporting a minimum size packet in all links is important and L3 ISIS relies on 1492 byte value. From a control plane perspective, if there is a topology change and as a result the new LSP size cannot make it through some nodes then all nodes may not have the same LSDB and you could have a forwarding loop. From data plane perspective you could end up black holing packet which could be less dramatic. Any how the point I tried to make in my previous e-mail (which you ignored ;-) is that we need to agree on a minimum size packet and in the absence of other intelligent mechanism, such a minimum size value should be used. Thanks Sina > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Monday, April 06, 2009 3:36 PM > To: Sina Mirtorabi (smirtora) > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Recap short long hello problem statement > > Personally, I'm happy to completely get rid of any MTU discovery > mechanism, and have the only change to the TRILL > spec at this point to say that IS-IS MUST NOT pad hellos. If Hellos > don't get through, it could cause loops. If > there isn't an agreed-upon campus-wide MTU size, then > a) big data packets might not make it through on some links (who cares > about data packets :-) ) > b) LSPs might not make it through on some links (perhaps could cause > some problems, but I'm not sure if > this really would be that much of a problem) > > There were some IS-IS people at the IETF meeting that seemed to be > arguing that MTU discovery was important. > I'll raise the issue on the IS-IS mailing list, and see if anyone has > any arguments about why it would be bad for TRILL > not to bother with MTU discovery. > > *********** > So, I think at this point we've agreed upon: > > TRILL spec should be modified to say Hellos MUST NOT be padded > > > ******** > We are undecided about: > > . whether we need an MTU discovery mechanism, and if we have it, > whether it > ought to be mandatory or optional, and whether we should have some sort > of discovery mechanism for the > campus-wide MTU size. > > Radia > > > Sina Mirtorabi (smirtora) wrote: > > Radia, > > > > Let's assume, we know that for a given minimum MTU size ( Smin = > 1500-X > > ) all the stupid old devices could handle correctly the packet and > > whatever overhead that is added to the packet would still not make > its > > size more than 1500 byte. Now if we agree on Smin then most of the > below > > proposal is unnecessary apart from NOT padding Hello (although that > > could be included as well but just for safety) > > > > > > Note that ISIS spec (ISO 10589:2002) define the following parameters > > > > ReceiveLSPBufferSize set to 1492 (by default) > > originatingLSPBufferSize included in a TLV when generating LSP > > > > The assumption is that > > > > originatingLSPBufferSize <= ReceiveLSPBufferSize > > & > > originatingLSPBufferSize <= MTU for all links > > > > > > > > For Trill if we set the originatingLSPBufferSize = Smin then we know > > that all packets will make it through legacy devices. I think a > simple > > conservative calculation by considering worse case overhead could > give > > us the Smin. Of course if there is a "L2 MTU path discovery > mechanism" > > which can tell what is a better value for S when sending packets then > > such a value could be used otherwise the default has to be set to > Smin. > > Last, defining L2 MTU path discovery mechanism should be outside of > the > > TRILL scope or at least being optional. > > > > > > Thanks > > Sina > > > > > >> This shouldn't be a big deal, let's try to agree quickly. > >> > >> So, to reiterate the design, this time making handling of a probe > >> mandatory and part of the spec: > >> > >> a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger > than > >> some size. Let's pick > >> 1400 bytes, because that really is big enough to handle all > reasonable > >> sized Hellos. > >> The only thing that could make it bigger is very weird assignments > of > >> Designated Forwarders, > >> and the 1400 byte limit would just limit the DRB's creativity in > >> handing out forwarding > >> assignments. > >> > >> b) The LSP contains an optional TLV "I think the campus-wide MTU > size > >> is x". > >> > >> c) This MTU-size TLV is ignored in all LSPs except the LSP of the > >> highest priority RBridge, R1, in the campus. > >> If R1 does not include this MTU-size TLV in its LSP, then each > RBridge > >> R2 decides for itself what the MTU size should > >> be, and does not report links to an RBridge neighbor R3, if the R2- > R3 > >> link cannot support R2's assumption of MTU. > >> If R1 *does* include the MTU-size TLV, then R2 uses that size for a > >> criteria for reporting links. Note that > >> if R2 cannot support R1's MTU size, then R2 will continue attempting > >> > > to > > > >> be DRB, etc., but will not report any > >> of its links in LSPs. > >> > >> d) We define a "link size probe" packet, which is padded to some > >> size, say s, and included inside the data > >> is the "s". These can be unicast to a neighbor, or multicast to the > >> all-RBridges layer 2 address. Likewise there is a "link size probe > >> ack", which > >> contains "s", the size stated inside the probe packet being ack'd. > The > >> ack would > >> be unicast to the sender of the probe. I'd recommend some variant on > a > >> Hello > >> packet, just so we don't need a new packet type. But as I've said > >> before, > >> I tend to be overly disinterested in encoding. > >> > >> e) If R2 does not get acks from R3 for its link size probes, (say, > >> after sending 3 of them), then R2 does not > >> report R3 in its Hellos, R3 will not report connectivity to the > >> pseudonode, and if it's a pt-to-pt link, neither R2 nor > >> R3 will report the R2-R3 link in their LSP. > >> > >> > >> > >> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge at postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > >> From smirtora at cisco.com Mon Apr 6 20:45:06 2009 From: smirtora at cisco.com (Sina Mirtorabi (smirtora)) Date: Mon, 6 Apr 2009 20:45:06 -0700 Subject: [rbridge] Recap short long hello problem statement In-Reply-To: References: <49DA83E4.8070003@sun.com> Message-ID: Silvano, I guess we all agree that the Hello must not be padded. The issue really is that if your control and data traffic don't make it through, you may have some other issues such as forwarding loop or black hole traffic. Therefore in the absence of a (simple) mechanism to discover the MTU, we better agree on a minimum size packet where the issue should not occur for that minimum packet size. Thanks Sina > -----Original Message----- > From: Silvano Gai (sgai) > Sent: Monday, April 06, 2009 7:11 PM > To: Radia Perlman; Sina Mirtorabi (smirtora) > Cc: TRILL/RBridge Working Group > Subject: Re: [rbridge] Recap short long hello problem statement > > I support Radia Position " IS-IS MUST NOT pad hellos." > > I don't care of MTU discovery > > -- Silvano > > > On 4/6/09 3:36 PM, "Radia Perlman" wrote: > > > Personally, I'm happy to completely get rid of any MTU discovery > > mechanism, and have the only change to the TRILL > > spec at this point to say that IS-IS MUST NOT pad hellos. If Hellos > > don't get through, it could cause loops. If > > there isn't an agreed-upon campus-wide MTU size, then > > a) big data packets might not make it through on some links (who > cares > > about data packets :-) ) > > b) LSPs might not make it through on some links (perhaps could cause > > some problems, but I'm not sure if > > this really would be that much of a problem) > > > > There were some IS-IS people at the IETF meeting that seemed to be > > arguing that MTU discovery was important. > > I'll raise the issue on the IS-IS mailing list, and see if anyone has > > any arguments about why it would be bad for TRILL > > not to bother with MTU discovery. > > > > *********** > > So, I think at this point we've agreed upon: > > > > TRILL spec should be modified to say Hellos MUST NOT be padded > > > > > > ******** > > We are undecided about: > > > > . whether we need an MTU discovery mechanism, and if we have it, > > whether it > > ought to be mandatory or optional, and whether we should have some > sort > > of discovery mechanism for the > > campus-wide MTU size. > > > > Radia > > > > > > Sina Mirtorabi (smirtora) wrote: > >> Radia, > >> > >> Let's assume, we know that for a given minimum MTU size ( Smin = > 1500-X > >> ) all the stupid old devices could handle correctly the packet and > >> whatever overhead that is added to the packet would still not make > its > >> size more than 1500 byte. Now if we agree on Smin then most of the > below > >> proposal is unnecessary apart from NOT padding Hello (although that > >> could be included as well but just for safety) > >> > >> > >> Note that ISIS spec (ISO 10589:2002) define the following parameters > >> > >> ReceiveLSPBufferSize set to 1492 (by default) > >> originatingLSPBufferSize included in a TLV when generating LSP > >> > >> The assumption is that > >> > >> originatingLSPBufferSize <= ReceiveLSPBufferSize > >> & > >> originatingLSPBufferSize <= MTU for all links > >> > >> > >> > >> For Trill if we set the originatingLSPBufferSize = Smin then we know > >> that all packets will make it through legacy devices. I think a > simple > >> conservative calculation by considering worse case overhead could > give > >> us the Smin. Of course if there is a "L2 MTU path discovery > mechanism" > >> which can tell what is a better value for S when sending packets > then > >> such a value could be used otherwise the default has to be set to > Smin. > >> Last, defining L2 MTU path discovery mechanism should be outside of > the > >> TRILL scope or at least being optional. > >> > >> > >> Thanks > >> Sina > >> > >> > >>> This shouldn't be a big deal, let's try to agree quickly. > >>> > >>> So, to reiterate the design, this time making handling of a probe > >>> mandatory and part of the spec: > >>> > >>> a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger > than > >>> some size. Let's pick > >>> 1400 bytes, because that really is big enough to handle all > reasonable > >>> sized Hellos. > >>> The only thing that could make it bigger is very weird assignments > of > >>> Designated Forwarders, > >>> and the 1400 byte limit would just limit the DRB's creativity in > >>> handing out forwarding > >>> assignments. > >>> > >>> b) The LSP contains an optional TLV "I think the campus-wide MTU > size > >>> is x". > >>> > >>> c) This MTU-size TLV is ignored in all LSPs except the LSP of the > >>> highest priority RBridge, R1, in the campus. > >>> If R1 does not include this MTU-size TLV in its LSP, then each > RBridge > >>> R2 decides for itself what the MTU size should > >>> be, and does not report links to an RBridge neighbor R3, if the R2- > R3 > >>> link cannot support R2's assumption of MTU. > >>> If R1 *does* include the MTU-size TLV, then R2 uses that size for a > >>> criteria for reporting links. Note that > >>> if R2 cannot support R1's MTU size, then R2 will continue > attempting > >>> > >> to > >> > >>> be DRB, etc., but will not report any > >>> of its links in LSPs. > >>> > >>> d) We define a "link size probe" packet, which is padded to some > >>> size, say s, and included inside the data > >>> is the "s". These can be unicast to a neighbor, or multicast to the > >>> all-RBridges layer 2 address. Likewise there is a "link size probe > >>> ack", which > >>> contains "s", the size stated inside the probe packet being ack'd. > The > >>> ack would > >>> be unicast to the sender of the probe. I'd recommend some variant > on a > >>> Hello > >>> packet, just so we don't need a new packet type. But as I've said > >>> before, > >>> I tend to be overly disinterested in encoding. > >>> > >>> e) If R2 does not get acks from R3 for its link size probes, (say, > >>> after sending 3 of them), then R2 does not > >>> report R3 in its Hellos, R3 will not report connectivity to the > >>> pseudonode, and if it's a pt-to-pt link, neither R2 nor > >>> R3 will report the R2-R3 link in their LSP. > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 ginsberg at cisco.com Tue Apr 7 02:13:29 2009 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Tue, 7 Apr 2009 02:13:29 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DA8595.4010803@sun.com> References: <49DA8595.4010803@sun.com> Message-ID: Radia - The point of hello padding is not just to "discover the MTU" but to not form adjacencies with neighbors who are incapable of receiving/flooding the max size LSP any router in the area/domain might generate. I haven't caught up on the details of Jim's testing, but if the padded hellos can't get through then similar sized LSPs won't either - and routing is broken - so sending smaller hellos isn't going to help - and in fact is likely to obfuscate things because routing may work at first, but as additional information is added to an LSP it will become too large to be flooded everywhere and things will break w/o any clear indication of why. Les > -----Original Message----- > From: isis-wg-bounces at ietf.org [mailto:isis-wg-bounces at ietf.org] On Behalf > Of Radia Perlman > Sent: Monday, April 06, 2009 3:44 PM > To: isis-wg at ietf.org > Subject: [Isis-wg] Why is MTU discovery important? > > For those of you not monitoring the TRILL mailing list: > > Jim Carlson, in testing his TRILL implementation, noticed that the > padded Hellos caused RBridges not to discover each other. > That's real bad in TRILL, though it's OK in layer 3 IS-IS. > > So, we'd like to just say in TRILL "don't pad Hellos". > > But that eliminates IS-IS's MTU discovery mechanism. We had a proposal > for doing that, but some people said > "why bother"? > > The reasoning is that it's not clear what an RBridge would do if the MTU > isn't what it would expect, and that > it seems like you'd need a campus-wide agreed-upon MTU size in order to > make sure LSPs would get through on > every link. The solutions being proposed involved agreeing upon a > campus-wide MTU size, testing MTU size on > each adjacency through some as-yet-to-be-defined protocol, and not > reporting links that don't meet > that MTU size. > > Obviously ignoring the MTU issue, and just making sure Hellos get > through by not padding Hellos, is a nice simple proposal. > > What would we be giving up if we ignored MTU discovery entirely? > > Radia > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From james.d.carlson at Sun.COM Tue Apr 7 07:56:45 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Tue, 7 Apr 2009 10:56:45 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: References: <49DA8595.4010803@sun.com> Message-ID: <18907.27053.945776.676460@gargle.gargle.HOWL> Les Ginsberg (ginsberg) writes: > The point of hello padding is not just to "discover the MTU" but to not > form adjacencies with neighbors who are incapable of receiving/flooding > the max size LSP any router in the area/domain might generate. I suspect that for practical purposes, those work out to be the same thing. Regardless of how exactly it may happen in a given deployment, there are scenarios in which packets larger than a certain arbitrary size cannot make it through, and that problem must be detected. The problem in this case is that with TRILL, failing to detect an actual adjacency that exists on the wire means that (unlike IS-IS for L3 networks), you will begin forwarding on *both* (or "all") nodes, and inadvertently create L2 forwarding loops for all packets with size less than that restriction. With L3 routing, having Hello fail between connected nodes is safe and obvious enough. The peers are not considered adjacent, and no traffic flows. With L2 TRILL bridging, forwarding becomes enabled on both, having the Hello fail is toxic and potentially fatal for all involved. > I haven't caught up on the details of Jim's testing, but if the padded > hellos can't get through then similar sized LSPs won't either - and > routing is broken - so sending smaller hellos isn't going to help - and > in fact is likely to obfuscate things because routing may work at first, > but as additional information is added to an LSP it will become too > large to be flooded everywhere and things will break w/o any clear > indication of why. The proposal is actually two-fold: - Smaller Hellos to make sure that actual adjacencies are detected and L2 loops do not form. - Some other simple protocol (such as an echo request/response using MTU-padded messages) to validate MTU between known peers. The first part fixes the forwarding path danger. The second part fixes the LSP size concerns. -- 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 Radia.Perlman at sun.com Tue Apr 7 13:10:26 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 07 Apr 2009 13:10:26 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: References: Message-ID: <49DBB332.6080003@sun.com> OK. It's clear we should NOT pad Hellos. It also seems like enough people would feel uncomfortable with not doing MTU discovery that we should make sure there is a mechanism for that also. So can we focus for a minute on the following question, "whether to make MTU size a forever constant, or configurable in a campus", as described below. The simplest option is to pick some minimum size, say 1450 bytes, put that in the spec now, and forever say that TRILL Hellos and LSPs cannot be bigger than that. MTU discovery would be done to ensure that every link can handle 1450 bytes, and not use (not report in LSPs) links that can't handle that. However, my preference is to have an optional TLV in the LSP that says "campus-wide MTU size". This TLV would only be relevant if: a) it is larger than 1450, and b) it is in the LSP of the highest priority RBridge in the campus. If we put that in, then we would be enabling TRILL campuses that support jumbo frames. The rule is that if the highest priority RBridge says MTU size should be 10000 bytes, then all RBridges would adjust their buffer sizes, and test their adjacencies to ensure they could handle 10000 bytes, and if they don't then stop reporting those links (just like they would with the simpler proposal if the links couldn't support 1450). From ddutt at cisco.com Tue Apr 7 14:29:54 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 07 Apr 2009 14:29:54 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DBB332.6080003@sun.com> References: <49DBB332.6080003@sun.com> Message-ID: <49DBC5D2.5050703@cisco.com> Radia, What I don't understand is how L3 IS-IS solves this problem. Consider a trivial topology where three routers are connected thus: R1 --- R2 --- R3 Let's say the link between R1 and R2 has an MTU, M1, and the link between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded Hellos, how is the problem of R1 sending an LSP that exceeds M2 (but not M1) handled ? Dinesh Radia Perlman wrote: > OK. It's clear we should NOT pad Hellos. > > It also seems like enough people would feel uncomfortable with not doing > MTU discovery that we should make > sure there is a mechanism for that also. > > So can we focus for a minute on the following question, "whether to make > MTU size a forever constant, > or configurable in a campus", as described below. > > The simplest option is to pick some minimum size, say 1450 bytes, put > that in the spec now, and forever > say that TRILL Hellos and LSPs cannot be bigger than that. > MTU discovery would be done to ensure that > every link can handle 1450 bytes, and not use (not report in LSPs) links > that can't handle that. > > However, my preference is to have an optional TLV in the LSP that says > "campus-wide MTU size". This TLV > would only be relevant if: > a) it is larger than 1450, and > b) it is in the LSP of the highest priority RBridge in the campus. > > If we put that in, then we would be enabling TRILL campuses that support > jumbo frames. > > The rule is that if the highest priority RBridge says MTU size should be > 10000 bytes, then all RBridges would adjust > their buffer sizes, and test their adjacencies to ensure they could > handle 10000 bytes, and if they don't > then stop reporting those links (just like they would with the simpler > proposal if the links > couldn't support 1450). > > > > > _______________________________________________ > 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 smirtora at cisco.com Tue Apr 7 14:57:58 2009 From: smirtora at cisco.com (Sina Mirtorabi (smirtora)) Date: Tue, 7 Apr 2009 14:57:58 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DBB332.6080003@sun.com> References: <49DBB332.6080003@sun.com> Message-ID: Radia, The minimum size packet is what I proposed and I think it is the easiest solution to go forward. We should also allow for higher size packet if there is a mechanism to safely enable that. Now it is not because somebody (the highest priority Rbridge) to tell you what to do that you have to blindly follow, but if everybody announce that jumbo value then you can safely move to that value. So here what we can do: Put an originatingLSPBufferSize in a TLV when generating LSP and (ISO 10589:2002) already recommend that. The default value would be 1450 otherwise it is set to the configured value. An Rbridge can start generating a non-default size X LSP if all the reachable Rbridge has announce at least a value >= X, in other word the non-default size LSP is set to the minimum of all announced LSP size. Note that for a non-default size LSP, we rely on the administrator's configuration and we don't actually check the MTU path. If later there is a mechanism to actually check the MTU of a Rbridge link, then originatingLSPBufferSize could be set to the minimum MTU size of all local Rbridge's link. This will guarantee that the LSP size will always be set to the minimum MTU size of any link. Thanks Sina > > OK. It's clear we should NOT pad Hellos. > > It also seems like enough people would feel uncomfortable with not > doing > MTU discovery that we should make > sure there is a mechanism for that also. > > So can we focus for a minute on the following question, "whether to > make > MTU size a forever constant, > or configurable in a campus", as described below. > > The simplest option is to pick some minimum size, say 1450 bytes, put > that in the spec now, and forever > say that TRILL Hellos and LSPs cannot be bigger than that. > MTU discovery would be done to ensure that > every link can handle 1450 bytes, and not use (not report in LSPs) > links > that can't handle that. > > However, my preference is to have an optional TLV in the LSP that says > "campus-wide MTU size". This TLV > would only be relevant if: > a) it is larger than 1450, and > b) it is in the LSP of the highest priority RBridge in the campus. > > If we put that in, then we would be enabling TRILL campuses that > support > jumbo frames. > > The rule is that if the highest priority RBridge says MTU size should > be > 10000 bytes, then all RBridges would adjust > their buffer sizes, and test their adjacencies to ensure they could > handle 10000 bytes, and if they don't > then stop reporting those links (just like they would with the simpler > proposal if the links > couldn't support 1450). > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From Radia.Perlman at sun.com Tue Apr 7 14:58:59 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 07 Apr 2009 14:58:59 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DBC5D2.5050703@cisco.com> References: <49DBB332.6080003@sun.com> <49DBC5D2.5050703@cisco.com> Message-ID: <49DBCCA3.1010102@sun.com> Dinesh, In IS-IS there is a hard limit MTU size, say 1472 or whatever. MTU discovery through padded Hellos is done to ensure that adjacencies that can't support that size don't get established. If M2 is too small, then R2-R3 would not form an adjacency, and as a result data, LSPs, etc., would not be sent over the link. So, likewise, in TRILL we'll enforce a minimum link size, and the question I was asking was whether it should be a constant forever (say 1450 types), or whether we can allow a TRILL campus to be configured to require all the links to have some higher-than-1450 link size? Radia Dinesh G Dutt wrote: > Radia, > > What I don't understand is how L3 IS-IS solves this problem. Consider > a trivial topology where three routers are connected thus: > R1 --- R2 --- R3 > > Let's say the link between R1 and R2 has an MTU, M1, and the link > between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded > Hellos, how is the problem of R1 sending an LSP that exceeds M2 (but > not M1) handled ? > > Dinesh > Radia Perlman wrote: >> OK. It's clear we should NOT pad Hellos. >> >> It also seems like enough people would feel uncomfortable with not >> doing MTU discovery that we should make >> sure there is a mechanism for that also. >> >> So can we focus for a minute on the following question, "whether to >> make MTU size a forever constant, >> or configurable in a campus", as described below. >> >> The simplest option is to pick some minimum size, say 1450 bytes, put >> that in the spec now, and forever >> say that TRILL Hellos and LSPs cannot be bigger than that. >> MTU discovery would be done to ensure that >> every link can handle 1450 bytes, and not use (not report in LSPs) >> links that can't handle that. >> >> However, my preference is to have an optional TLV in the LSP that >> says "campus-wide MTU size". This TLV >> would only be relevant if: >> a) it is larger than 1450, and >> b) it is in the LSP of the highest priority RBridge in the campus. >> >> If we put that in, then we would be enabling TRILL campuses that >> support jumbo frames. >> >> The rule is that if the highest priority RBridge says MTU size should >> be 10000 bytes, then all RBridges would adjust >> their buffer sizes, and test their adjacencies to ensure they could >> handle 10000 bytes, and if they don't >> then stop reporting those links (just like they would with the >> simpler proposal if the links >> couldn't support 1450). >> >> >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > From d3e3e3 at gmail.com Tue Apr 7 15:01:17 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 7 Apr 2009 18:01:17 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DBC5D2.5050703@cisco.com> References: <49DBB332.6080003@sun.com> <49DBC5D2.5050703@cisco.com> Message-ID: <1028365c0904071501s10949268mae2cdbd7b840dd7e@mail.gmail.com> Keep in mind that all IS-IS messages are LSAP encoded so they are limited to the classic Ethernet MTU, possibly plus VLAN and/or other tags. So if, for example, you wanted to be sure you could correctly handle Fiber Channel over Ethernet frames, which are bigger than that, there is no way for padded Hellos to help, since they can't be padded up to FCoE frame size. Donald On Tue, Apr 7, 2009 at 5:29 PM, Dinesh G Dutt wrote: > Radia, > > What I don't understand is how L3 IS-IS solves this problem. Consider a > trivial topology where three routers are connected thus: > ? ? ? ? ? ? R1 --- R2 --- R3 > > Let's say the link between R1 and R2 has an MTU, M1, and the link > between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded Hellos, > how is the problem of R1 sending an LSP that exceeds M2 (but not M1) > handled ? > > Dinesh > Radia Perlman wrote: >> OK. It's clear we should NOT pad Hellos. >> >> It also seems like enough people would feel uncomfortable with not doing >> MTU discovery that we should make >> sure there is a mechanism for that also. >> >> So can we focus for a minute on the following question, "whether to make >> MTU size a forever constant, >> or configurable in a campus", as described below. >> >> The simplest option is to pick some minimum size, say 1450 bytes, put >> that in the spec now, and forever >> say that TRILL Hellos and LSPs cannot be bigger than that. >> MTU discovery would be done to ensure that >> every link can handle 1450 bytes, and not use (not report in LSPs) links >> that can't handle that. >> >> However, my preference is to have an optional TLV in the LSP that says >> "campus-wide MTU size". This TLV >> would only be relevant if: >> a) it is larger than 1450, and >> b) it is in the LSP of the highest priority RBridge in the campus. >> >> If we put that in, then we would be enabling TRILL campuses that support >> jumbo frames. >> >> The rule is that if the highest priority RBridge says MTU size should be >> 10000 bytes, then all RBridges would adjust >> their buffer sizes, and test their adjacencies to ensure they could >> handle 10000 bytes, and if they don't >> then stop reporting those links (just like they would with the simpler >> proposal if the links >> couldn't support 1450). >> >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 ginsberg at cisco.com Tue Apr 7 15:48:26 2009 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Tue, 7 Apr 2009 15:48:26 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DBC5D2.5050703@cisco.com> References: <49DBB332.6080003@sun.com> <49DBC5D2.5050703@cisco.com> Message-ID: Dinesh - This problem has been addressed in ISO 10589:2002 - though admittedly the solution is not commonly implemented. The solution involves the advertisement of originatingL1LSPBufferSize/ originatingL2LSPBufferSize in LSP #0. Each system can then compare the received value to its locally configured value and detect mismatches. The TLV codepoint for this is: LSPBufferSize 14. There is a good discussion of the issues about this - as well as hello padding - RFC 3719 Sections 5 and 6. Les > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt (ddutt) > Sent: Tuesday, April 07, 2009 2:30 PM > To: Radia Perlman > Cc: TRILL/RBridge Working Group; isis-wg at ietf.org > Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important? > > Radia, > > What I don't understand is how L3 IS-IS solves this problem. Consider a > trivial topology where three routers are connected thus: > R1 --- R2 --- R3 > > Let's say the link between R1 and R2 has an MTU, M1, and the link > between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded Hellos, > how is the problem of R1 sending an LSP that exceeds M2 (but not M1) > handled ? > > Dinesh > Radia Perlman wrote: > > OK. It's clear we should NOT pad Hellos. > > > > It also seems like enough people would feel uncomfortable with not doing > > MTU discovery that we should make > > sure there is a mechanism for that also. > > > > So can we focus for a minute on the following question, "whether to make > > MTU size a forever constant, > > or configurable in a campus", as described below. > > > > The simplest option is to pick some minimum size, say 1450 bytes, put > > that in the spec now, and forever > > say that TRILL Hellos and LSPs cannot be bigger than that. > > MTU discovery would be done to ensure that > > every link can handle 1450 bytes, and not use (not report in LSPs) links > > that can't handle that. > > > > However, my preference is to have an optional TLV in the LSP that says > > "campus-wide MTU size". This TLV > > would only be relevant if: > > a) it is larger than 1450, and > > b) it is in the LSP of the highest priority RBridge in the campus. > > > > If we put that in, then we would be enabling TRILL campuses that support > > jumbo frames. > > > > The rule is that if the highest priority RBridge says MTU size should be > > 10000 bytes, then all RBridges would adjust > > their buffer sizes, and test their adjacencies to ensure they could > > handle 10000 bytes, and if they don't > > then stop reporting those links (just like they would with the simpler > > proposal if the links > > couldn't support 1450). > > > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From d3e3e3 at gmail.com Tue Apr 7 17:45:26 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 7 Apr 2009 20:45:26 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: References: <1028365c0904071501s10949268mae2cdbd7b840dd7e@mail.gmail.com> Message-ID: <1028365c0904071745l5386c491wd226857861bef590@mail.gmail.com> My point was that if you are using a network heavily for some protocol where an MTU of X is the most efficient, if there was, say, one link with MTU Y, Y wrote: > FCoE has its own MTU protection. > > -- Silvano > > > On 4/7/09 3:01 PM, "Donald Eastlake" wrote: > >> Keep in mind that all IS-IS messages are LSAP encoded so they are >> limited to the classic Ethernet MTU, possibly plus VLAN and/or other >> tags. So if, for example, you wanted to be sure you could correctly >> handle Fiber Channel over Ethernet frames, which are bigger than that, >> there is no way for padded Hellos to help, since they can't be padded >> up to FCoE frame size. >> >> Donald >> >> On Tue, Apr 7, 2009 at 5:29 PM, Dinesh G Dutt wrote: >>> Radia, >>> >>> What I don't understand is how L3 IS-IS solves this problem. Consider a >>> trivial topology where three routers are connected thus: >>> ? ? ? ? ? ? R1 --- R2 --- R3 >>> >>> Let's say the link between R1 and R2 has an MTU, M1, and the link >>> between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded Hellos, >>> how is the problem of R1 sending an LSP that exceeds M2 (but not M1) >>> handled ? >>> >>> Dinesh >>> Radia Perlman wrote: >>>> OK. It's clear we should NOT pad Hellos. >>>> >>>> It also seems like enough people would feel uncomfortable with not doing >>>> MTU discovery that we should make >>>> sure there is a mechanism for that also. >>>> >>>> So can we focus for a minute on the following question, "whether to make >>>> MTU size a forever constant, >>>> or configurable in a campus", as described below. >>>> >>>> The simplest option is to pick some minimum size, say 1450 bytes, put >>>> that in the spec now, and forever >>>> say that TRILL Hellos and LSPs cannot be bigger than that. >>>> MTU discovery would be done to ensure that >>>> every link can handle 1450 bytes, and not use (not report in LSPs) links >>>> that can't handle that. >>>> >>>> However, my preference is to have an optional TLV in the LSP that says >>>> "campus-wide MTU size". This TLV >>>> would only be relevant if: >>>> a) it is larger than 1450, and >>>> b) it is in the LSP of the highest priority RBridge in the campus. >>>> >>>> If we put that in, then we would be enabling TRILL campuses that support >>>> jumbo frames. >>>> >>>> The rule is that if the highest priority RBridge says MTU size should be >>>> 10000 bytes, then all RBridges would adjust >>>> their buffer sizes, and test their adjacencies to ensure they could >>>> handle 10000 bytes, and if they don't >>>> then stop reporting those links (just like they would with the simpler >>>> proposal if the links >>>> couldn't support 1450). >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 touch at ISI.EDU Tue Apr 7 17:46:08 2009 From: touch at ISI.EDU (Joe Touch) Date: Tue, 07 Apr 2009 17:46:08 -0700 Subject: [rbridge] [Fwd: Document Action: 'Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement' to Informational RFC] Message-ID: <49DBF3D0.4000109@isi.edu> -------------- next part -------------- An embedded message was scrubbed... From: The IESG Subject: [rbridge] Document Action: 'Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement' to Informational RFC Date: Mon, 6 Apr 2009 12:56:09 -0700 (PDT) Size: 3333 Url: http://mailman.postel.org/pipermail/rbridge/attachments/20090407/15fb7ce3/toInformationalRFC.eml -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20090407/15fb7ce3/signature.bin From dward at cisco.com Wed Apr 8 10:09:38 2009 From: dward at cisco.com (David Ward) Date: Wed, 8 Apr 2009 12:09:38 -0500 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DBB332.6080003@sun.com> References: <49DBB332.6080003@sun.com> Message-ID: <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> All - This discussion is rapidly defining !IS-IS as a solution given the changes to the protocol. At least enough of the protocol is being changed that we need to consider a new version designator as the direction is fundamentally changing adj formation, DIS election, LSP size, etc and compatibility with current ISIS doesn't seem a goal. I'd like to push the brakes just a bit to try and get us into better sync. There are proposals that the Hellos should NOT be padded to eliminate a cause of multiple rbridges on the same LAN "not seeing each other" and electing multiple forwarders. However, the idea in the discussion is to remove the required MTU checking and it is proposed (which I don't understand) to introduce another "MTU discovery" protocol to restore this awareness. As we know, IS-IS requires that the DIS is elected from among the routers that have adjacencies (that report the existence of each other in the IIHs, and it requires that the IIHs are padded to the maximum of the link MTU and the originating L1LSPBufferSize - in the case of L1). This ensures both that the link is capable of transferring data packets of link MTU size, and more that it is capable of transferring LSPs of the appropriate network wide size. If this were not the case, then it is possible that a DIS could get elected which was not capable of operating the reliable update process, and could cause certain LSPs to fail to be propagated across the LAN. The DRB is the TRILL equivalent of the DIS. This is elected from among the routers connected to the LAN and is responsible for: a) generating a pseudonode LSP, which claims connectivity to all the other routers it sees on the LAN. (and in the OSI case reports the ESs on the LAN) b) running the LAN reliable update process (i.e. periodically sending CSNPs etc) So the padding is required in order to ensure that IS-IS operates correctly. The problem is that the roll of the DIS (aka DRB) is defined in terms of adjacency formation, and I don't understand how the two distinct roles for the DRB can be combined into a single DRB. Again, I've followed and read the TRILL and ISIS but, I am not seeing a way to combine the functions into a single DIS/DRB at this point. My view (which others have stated earlier) is that the L2ISIS desired functionality should not mess with the existing IS-IS DIS election mechanisms, but should have another set of "hellos" which can be used for the TRILL specific DRB elections, and have the appropriate rules for that. Or, we at least need to write down the rules and explore how to combine them. There appears only one way out of this: - TRILL WG should write down the specific requirements and functionality are and what the "rules" should be for them. We may find ISIS is suited to meet them or not. Thanks -DWard Note that if the requirement is that TRILL needs to operate in environments with different or "variable" (though static) MTUs, we should not hack an easy solution but, create a generalized solution On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: > OK. It's clear we should NOT pad Hellos. > > It also seems like enough people would feel uncomfortable with not > doing MTU discovery that we should make > sure there is a mechanism for that also. > > So can we focus for a minute on the following question, "whether to > make MTU size a forever constant, > or configurable in a campus", as described below. > > The simplest option is to pick some minimum size, say 1450 bytes, > put that in the spec now, and forever > say that TRILL Hellos and LSPs cannot be bigger than that. > MTU discovery would be done to ensure that > every link can handle 1450 bytes, and not use (not report in LSPs) > links that can't handle that. > > However, my preference is to have an optional TLV in the LSP that > says "campus-wide MTU size". This TLV > would only be relevant if: > a) it is larger than 1450, and > b) it is in the LSP of the highest priority RBridge in the campus. > > If we put that in, then we would be enabling TRILL campuses that > support jumbo frames. > > The rule is that if the highest priority RBridge says MTU size > should be 10000 bytes, then all RBridges would adjust > their buffer sizes, and test their adjacencies to ensure they could > handle 10000 bytes, and if they don't > then stop reporting those links (just like they would with the > simpler proposal if the links > couldn't support 1450). > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From Radia.Perlman at sun.com Wed Apr 8 11:36:09 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 08 Apr 2009 11:36:09 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> Message-ID: <49DCEE99.5070802@sun.com> Dave, I think a lot of the controversy is due to overloaded terminology, and using words that people have preconceived notions for. One term that seems to be confusing people is the term "Forming adjacency". "Forming adjacency" is a term that implies a bunch of steps to layer 3 IS-IS people that the TRILL people (including me) are not implying all the steps of. So it's possible that TRILL people should not use the term "forming adjacency" in emails describing protocols, or perhaps the layer 3 IS-IS people could try not to read too much into that phrase and instead just follow through all the described steps in the protocol being proposed. "Designated DRB" is two functions in TRILL, where it's only the second function in layer 3 IS-IS: a) the one that serves specific TRILL purposes: deciding who should be the Designated Forwarder for each VLAN so there are no loops, deciding on Designated VLAN for inter-RBridge communication, etc. b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs In TRILL it is *essential* to get the first thing robust, i.e., never having multiple forwarders. In layer 3 IS-IS, it's OK to have multiple DRs. In TRILL it is *fatal*. So the first thing TRILL has to do is to get that right. The solution, fortunately, is easy : . Unpadded Hellos. . Choosing DRB regardless of 2-way connectivity, MTU, etc. This is (and *must* be) different from the way layer 3 IS-IS happens to work. Regardless of philosophical discussions that we could carry on forever about whether this makes TRILL a different protocol, different version of the protocol, whatever....it is clear that is what TRILL needs to do. I have no objection to no longer calling the TRILL routing protocol "IS-IS" if that is considered "too big a change" from layer 3 IS-IS. But we have to do the obvious correct technical thing for TRILL. The other thing that seems to be confusing people is the term "Hello protocol". The Hellos in layer 3 IS-IS have two purposes: a) checking MTU size b) finding neighbors, choosing DR TRILL is just separating the two functions (choosing DRB, and testing MTU size), and calling it two different protocols; the "Hello" and the "MTU probe protocol". Layer 3 people could just think of it as a terminology change. It seems cleaner to call it two different protocols, since they are serving two very different functions. Having one protoocol that does both, the way it is today in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to think about the two problems individually, and make sure we get them both right. If you like, we can call the MTU probe protocol "padded Hellos", but let's first make sure we are getting both protocols correct. Even if we call the MTU probe protocol "padded Hellos", the padded Hello protocol MUST NOT have any influence on the "choosing a Designated DRB" (the thingy in TRILL that ensures there is only a single Designated Forwarder per VLAN on the link). The technical issues (ignoring terminology) that are being discussed for variants of the "MTU probe protocol" are: a) whether to ignore MTU probing entirely, because it's simpler to just ignore it, and just ensure that there is only one DRB on the link: and live with occasionally LSPs, CSNPs, data packets, not getting through on some link (which in TRILL is FAR less serious than having multiple forwarders) b) whether to make MTU probing just test that the link meets the criteria of the permanent fixed minimum size of 1450, or whatever, or whether to allow campuses to have a different campus-wide minimum link size S, and have RBridges test that their links can handle size "S" in the probing protocol, rather than "1450". Regardless of what the size is, and how that size is determined, it's clear what should happen if a link doesn't meet size S. The link should not be considered part of the topology -- routes should not be computed that traverse such a link. Radia David Ward wrote: > > > All - > > This discussion is rapidly defining !IS-IS as a solution given the > changes to the protocol. At least enough of the protocol is being > changed that we need to consider a new version designator as the > direction is fundamentally changing adj formation, DIS election, LSP > size, etc and compatibility with current ISIS doesn't seem a goal. > I'd like to push the brakes just a bit to try and get us into better > sync. > > There are proposals that the Hellos should NOT be padded to eliminate > a cause of multiple rbridges on the same LAN "not seeing each other" > and electing multiple forwarders. However, the idea in the discussion > is to remove the required MTU checking and it is proposed (which I > don't understand) to introduce another "MTU discovery" protocol to > restore this awareness. > > As we know, IS-IS requires that the DIS is elected from among the > routers that have adjacencies (that report the existence of each > other in the IIHs, and it requires that the IIHs are padded to the > maximum of the link MTU and the originating L1LSPBufferSize - in the > case of L1). This ensures both that the link is capable of > transferring data packets of link MTU size, and more that it is > capable of transferring LSPs of the appropriate network wide size. If > this were not the case, then it is possible that a DIS could get > elected which was not capable of operating the reliable update > process, and could cause certain LSPs to fail to be propagated across > the LAN. > > The DRB is the TRILL equivalent of the DIS. This is elected from among > the routers connected to the LAN and is responsible for: > a) generating a pseudonode LSP, which claims connectivity to all > the other routers it sees on the LAN. (and in the OSI case reports the > ESs on the LAN) > b) running the LAN reliable update process (i.e. periodically > sending CSNPs etc) > > So the padding is required in order to ensure that IS-IS operates > correctly. The problem is that the roll of the DIS (aka DRB) is > defined in terms of adjacency formation, and I don't understand how > the two distinct roles for the DRB can be combined into a single DRB. > Again, I've followed and read the TRILL and ISIS but, I am not seeing > a way to combine the functions into a single DIS/DRB at this point. > > My view (which others have stated earlier) is that the L2ISIS desired > functionality should not mess with the existing IS-IS DIS election > mechanisms, but should have another set of "hellos" which can be used > for the TRILL specific DRB elections, and have the appropriate rules > for that. Or, we at least need to write down the rules and explore how > to combine them. > > There appears only one way out of this: > > - TRILL WG should write down the specific requirements and > functionality are and what the "rules" should be for them. We may find > ISIS is suited to meet them or not. > > Thanks > > -DWard > > Note that if the requirement is that TRILL needs to operate in > environments with different or "variable" (though static) MTUs, we > should not hack an easy solution but, create a generalized solution > > On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: > >> OK. It's clear we should NOT pad Hellos. >> >> It also seems like enough people would feel uncomfortable with not >> doing MTU discovery that we should make >> sure there is a mechanism for that also. >> >> So can we focus for a minute on the following question, "whether to >> make MTU size a forever constant, >> or configurable in a campus", as described below. >> >> The simplest option is to pick some minimum size, say 1450 bytes, put >> that in the spec now, and forever >> say that TRILL Hellos and LSPs cannot be bigger than that. >> MTU discovery would be done to ensure that >> every link can handle 1450 bytes, and not use (not report in LSPs) >> links that can't handle that. >> >> However, my preference is to have an optional TLV in the LSP that >> says "campus-wide MTU size". This TLV >> would only be relevant if: >> a) it is larger than 1450, and >> b) it is in the LSP of the highest priority RBridge in the campus. >> >> If we put that in, then we would be enabling TRILL campuses that >> support jumbo frames. >> >> The rule is that if the highest priority RBridge says MTU size should >> be 10000 bytes, then all RBridges would adjust >> their buffer sizes, and test their adjacencies to ensure they could >> handle 10000 bytes, and if they don't >> then stop reporting those links (just like they would with the >> simpler proposal if the links >> couldn't support 1450). >> >> >> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From d3e3e3 at gmail.com Wed Apr 8 19:22:43 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 8 Apr 2009 22:22:43 -0400 Subject: [rbridge] IEEE 802.1 Comments on the protocol specification draft In-Reply-To: <1028365c0904080816s421a40a1l9ef9cf56b9ba4712@mail.gmail.com> References: <1028365c0904050823nd29e325uea76f08fb375a2be@mail.gmail.com> <1028365c0904080816s421a40a1l9ef9cf56b9ba4712@mail.gmail.com> Message-ID: <1028365c0904081922u45add420kb6f4b7d6edf1cdb5@mail.gmail.com> Hi, As suggested at the TRILL WG meeting in San Francisco, we are treating the IEEE 802.1 comments as if they had been posted to this mailing list: On Sun, Apr 5, 2009 at 11:23 AM, Donald Eastlake wrote: > ?To TRILL WG co-chairs and IEEE-IETF liaisons: > From: IEEE 802.1 > > Thank you for your query of November 6, 2008, reproduced below so that > it is clear what question is being answered: > > "As you know, the IETF TRILL Working Group has been developing a > protocol for devices called RBridges (Routing Bridges). > > We believe that the draft specification of the TRILL protocol > (the > protocol that is implemented by RBridges) has reached a stage of > maturity where, as required by the TRILL WG Charter, it would be > appropriate to request IEEE 802.1 to comment on the draft, > particularly from the point of view of its effect on the Ethernet > Service model." > > A number of the members of IEEE 802.1 have read the draft-ietf-TRILL- > rbridge-protocol-10.txt, draft-ietf-TRILL-rbridge-protocol-11.txt > and the recent draft-ietf-TRILL-rbridge-protocol-12.txt. > > While we don't plan to comment on the details of the TRILL design there > are statements in these revisions of the document with respect to IEEE > 802.1 we would appreciate being revised. ?It was our understanding at > the outset of TRILL the design was planned to be link-layer agnostic > however the current design only refers to IEEE 802.1. Further there are (Probably meant to say 802.3 in the line above.) > errors or inaccuracies in descriptions about IEEE 802.1 equipment used > in conjunctions with Trill. There may be such "errors or inaccuracies" but this message from IEEE 802.1 fails to point out any of them. > IEEE 802.1 does not have an Ethernet Service model per se but we have > an architecture that governs the design of 802.1 bridged networks and > maintains compatibility among new and legacy IEEE 802.1 bridged > networks. > > TRILL, as currently defined, depends upon a subset of 802.1Q. It is > designed to integrate into a flat C-VLAN network and provide a > different forwarding and control model from that specified in 802.1Q. That is correct if you mean the 802.1Q with all currently completed amendments. The RBridge base protocol specification defines "802.1Q", as referenced in that specification, to be only 802.1Q-2005. An attempt is made in the specification, in each instance, to explicitly refer to any subsequent amendment part of which is referenced (possibly the only such things are drop eligibility from 802.1ad and MVRP from 802.1Qak). The RBridge base protocol specification also states that it provides only customer bridging. Such statements start in the Abstract where it says: "RBridges are compatible with previous IEEE 802.1 customer bridges". However, the draft can certainly be modified to make all this clearer. > By inserting RBridges into a C-VLAN network a network structure is > created that is incompatible with current 802.1Q S-VLAN and B-VLAN > network architecture. ?This incompatibility in network architecture may It is the case that an RBridge conformant to the specification would not know about and could not cooperate with "S-VLAN and B-VLAN network architecture". But Provider Bridging (802.1ad) and Provider Backbone Bridging (802.1ah) are designed, in general, to be transparent to customer LAN traffic including, for example, TRILL encapsulated traffic. > create a complex network structure which, if not actually broken, will > be difficult to administer and evolve. > > For example: > 802.1Q includes: > ? > Services based on Provider Bridges (Clause 16 IEEE 802.1Q) and > Provider Backbone Bridges (Clause 25 IEEE 802.1Q) are not > accounted for in TRILL. As explained above, the current RBridge protocol specification concerns itself only with customer bridging, Further I believe RBridges could be extended to handle Provider Bridging. > ? > OAM functions IEEE 802.1 Connectivity Fault Management (Clause 22 > IEEE 802.1Q) that are not accounted for in TRILL. TRILL weakens > the applicability of CFM. Indeed, the feeling in the TRILL WG seems to be that OAM additions of some sort will be required for TRILL. > ? > 802.1Q Bridge protocols provide a low probability of frame > misordering, including during topology changes. New protocols > such as Fibre channel over Ethernet depend on this behavior. > > 802.1Q will include: > ? > Shortest Path Bridging. IEEE 802.1aq provides an example of how > to conform to the architecture and include shortest path tree > forwarding. TRILL provides shortest path bridging without the scaling constraints of 802.1aq. > Our analysis was not complete and there are other aspects of IEEE 802.1 > that are changing behavior even on C-VLAN bridges (such as AV Bridging, > Congestion management) that may not be compatible with TRILL RBridges > in the future. > > Furthermore, it is impossible for 802.1 to effectively ensure any > ongoing compatibility between 802.1 bridged network architecture and > TRILL. ?In consequence it is our opinion that the "effect on the > Ethernet Service model" as we understand it could be severe and > deleterious. > > Where the TRILL document refers to replacing IEEE 802.1Q Bridges, it > would be more accurate to state that it supports only a limited subset > of IEEE Std 802.1Q (including its approved amendments), and what that > subset is. The document should also make it clear that there is no > assurance of compatibility with future versions of IEEE Std 802.1Q, > even within the limited subset identified. As stated above, the RBridge protocol specification refers to replacing IEEE 802.1Q-2005 Bridges, not IEEE 802.1Q + 802.1ad + 802.1ag + 802.1ak + 802.1ah + ... Bridges. This can be clarified in the draft. > ... Thanks, Donald ============================= ?Donald E. Eastlake 3rd ? +1-508-634-2066 (home) ?155 Beaver Street ?Milford, MA 01757 USA ?d3e3e3 at gmail.com From dward at cisco.com Thu Apr 9 08:53:46 2009 From: dward at cisco.com (David Ward) Date: Thu, 9 Apr 2009 10:53:46 -0500 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DCEE99.5070802@sun.com> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> Message-ID: Radia - Thanks for the note. It's best that we capture these requirements in more than the email thread and with a bit more detail and put it in some doc or another. What would be helpful is if there is a bit of state machine diagramming on how adj are formed, DRB election, finding neighbors, PSNP optimizations, LSP size/fragmentation, etc. Note that it is moderately interesting that 802.1.aq isn't asking for this functionality. Given the ISIS WG can be considered the stuckkey between the two technologies; we'll have to sort this all out. My goal is for one solution for carrying L2 in IS-IS *if* IS-IS can meet the requirements. -DWard On Apr 8, 2009, at 1:36 PM, Radia Perlman wrote: > Dave, > > I think a lot of the controversy is due to overloaded terminology, > and using words that people have preconceived notions for. > One term that seems to be confusing people is the term "Forming > adjacency". > > "Forming adjacency" is a term that implies a bunch of steps to > layer 3 IS-IS people that the TRILL people (including me) are > not implying all the steps of. > So it's possible that TRILL people should not use the term "forming > adjacency" > in emails describing protocols, or perhaps the layer 3 IS-IS people > could > try not to read too much into that phrase and instead just follow > through all the described steps in the > protocol being proposed. > > "Designated DRB" is two functions in TRILL, where it's only the > second function in layer 3 IS-IS: > > a) the one that serves specific TRILL purposes: deciding who should > be the Designated Forwarder for each VLAN > so there are no loops, deciding on Designated VLAN for inter-RBridge > communication, etc. > b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs > > In TRILL it is *essential* to get the first thing robust, i.e., > never having multiple forwarders. In layer 3 IS-IS, it's > OK to have multiple DRs. In TRILL it is *fatal*. > So the first thing TRILL has to do is to get that right. The solution, > fortunately, is easy : > > . Unpadded Hellos. > . Choosing DRB regardless of 2-way connectivity, MTU, etc. > > This is (and *must* be) different from the way layer 3 IS-IS happens > to work. > Regardless of philosophical discussions that we could carry on > forever about whether this makes TRILL a > different protocol, different version of the protocol, > whatever....it is clear that is what TRILL needs to do. > I have no objection to no longer calling the TRILL routing protocol > "IS-IS" if that is considered "too big > a change" from layer 3 IS-IS. But we have to do the obvious correct > technical thing for TRILL. > > The other thing that seems to be confusing people is the term "Hello > protocol". > The Hellos in layer 3 IS-IS have two purposes: > a) checking MTU size > b) finding neighbors, choosing DR > > TRILL is just separating the two functions (choosing DRB, and > testing MTU size), and calling it > two different protocols; the "Hello" and the "MTU probe protocol". > Layer 3 people could just think of > it as a terminology change. It seems cleaner to call it two > different protocols, since they are > serving two very different functions. Having one protoocol that does > both, the way it is today > in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to > think about > the two problems individually, and make sure we get them both right. > If you like, we can > call the MTU probe protocol "padded Hellos", but let's first make > sure we are getting > both protocols correct. Even if we call the MTU probe protocol > "padded Hellos", the > padded Hello protocol MUST NOT have any influence on the "choosing a > Designated > DRB" (the thingy in TRILL that ensures there is only a single > Designated Forwarder > per VLAN on the link). > > The technical issues (ignoring terminology) that are being discussed > for variants of the "MTU probe > protocol" are: > a) whether to ignore MTU probing entirely, because it's simpler to > just ignore it, and just ensure that > there is only one DRB on the link: and live with occasionally LSPs, > CSNPs, data packets, not > getting through on some link (which in TRILL is FAR less serious > than having multiple forwarders) > b) whether to make MTU probing just test that the link meets the > criteria of the permanent > fixed minimum size of 1450, or whatever, or whether to allow > campuses to have a different > campus-wide minimum link size S, and have RBridges test that their > links can handle size "S" > in the probing protocol, rather than "1450". Regardless of what the > size is, and how that > size is determined, it's clear what should happen if a link doesn't > meet size S. The link > should not be considered part of the topology -- routes should not > be computed that > traverse such a link. > > Radia > > > > > > > David Ward wrote: >> >> >> All - >> >> This discussion is rapidly defining !IS-IS as a solution given the >> changes to the protocol. At least enough of the protocol is being >> changed that we need to consider a new version designator as the >> direction is fundamentally changing adj formation, DIS election, >> LSP size, etc and compatibility with current ISIS doesn't seem a >> goal. I'd like to push the brakes just a bit to try and get us >> into better sync. >> >> There are proposals that the Hellos should NOT be padded to >> eliminate a cause of multiple rbridges on the same LAN "not seeing >> each other" and electing multiple forwarders. However, the idea in >> the discussion is to remove the required MTU checking and it is >> proposed (which I don't understand) to introduce another "MTU >> discovery" protocol to restore this awareness. >> >> As we know, IS-IS requires that the DIS is elected from among the >> routers that have adjacencies (that report the existence of each >> other in the IIHs, and it requires that the IIHs are padded to the >> maximum of the link MTU and the originating L1LSPBufferSize - in >> the case of L1). This ensures both that the link is capable of >> transferring data packets of link MTU size, and more that it is >> capable of transferring LSPs of the appropriate network wide size. >> If this were not the case, then it is possible that a DIS could get >> elected which was not capable of operating the reliable update >> process, and could cause certain LSPs to fail to be propagated >> across the LAN. >> >> The DRB is the TRILL equivalent of the DIS. This is elected from >> among the routers connected to the LAN and is responsible for: >> a) generating a pseudonode LSP, which claims connectivity to >> all the other routers it sees on the LAN. (and in the OSI case >> reports the ESs on the LAN) >> b) running the LAN reliable update process (i.e. periodically >> sending CSNPs etc) >> >> So the padding is required in order to ensure that IS-IS operates >> correctly. The problem is that the roll of the DIS (aka DRB) is >> defined in terms of adjacency formation, and I don't understand how >> the two distinct roles for the DRB can be combined into a single >> DRB. Again, I've followed and read the TRILL and ISIS but, I am >> not seeing a way to combine the functions into a single DIS/DRB at >> this point. >> >> My view (which others have stated earlier) is that the L2ISIS >> desired functionality should not mess with the existing IS-IS DIS >> election mechanisms, but should have another set of "hellos" which >> can be used for the TRILL specific DRB elections, and have the >> appropriate rules for that. Or, we at least need to write down the >> rules and explore how to combine them. >> >> There appears only one way out of this: >> >> - TRILL WG should write down the specific requirements and >> functionality are and what the "rules" should be for them. We may >> find ISIS is suited to meet them or not. >> >> Thanks >> >> -DWard >> >> Note that if the requirement is that TRILL needs to operate in >> environments with different or "variable" (though static) MTUs, we >> should not hack an easy solution but, create a generalized solution >> >> On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: >> >>> OK. It's clear we should NOT pad Hellos. >>> >>> It also seems like enough people would feel uncomfortable with not >>> doing MTU discovery that we should make >>> sure there is a mechanism for that also. >>> >>> So can we focus for a minute on the following question, "whether >>> to make MTU size a forever constant, >>> or configurable in a campus", as described below. >>> >>> The simplest option is to pick some minimum size, say 1450 bytes, >>> put that in the spec now, and forever >>> say that TRILL Hellos and LSPs cannot be bigger than that. >>> MTU discovery would be done to ensure that >>> every link can handle 1450 bytes, and not use (not report in LSPs) >>> links that can't handle that. >>> >>> However, my preference is to have an optional TLV in the LSP that >>> says "campus-wide MTU size". This TLV >>> would only be relevant if: >>> a) it is larger than 1450, and >>> b) it is in the LSP of the highest priority RBridge in the campus. >>> >>> If we put that in, then we would be enabling TRILL campuses that >>> support jumbo frames. >>> >>> The rule is that if the highest priority RBridge says MTU size >>> should be 10000 bytes, then all RBridges would adjust >>> their buffer sizes, and test their adjacencies to ensure they >>> could handle 10000 bytes, and if they don't >>> then stop reporting those links (just like they would with the >>> simpler proposal if the links >>> couldn't support 1450). >>> >>> >>> >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg > From ddutt at cisco.com Thu Apr 9 15:40:38 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 09 Apr 2009 15:40:38 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DCEE99.5070802@sun.com> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> Message-ID: <49DE7966.1080609@cisco.com> Radia, I'd like to reiterate that all we ought to really care about is non-padded Hellos. That fixes our problem of creating loops otherwise. Everything else is optional and nice-to-have. David, if we restrict our request to just this, would it be more palatable to the IS-IS WG ? Dinesh Radia Perlman wrote: > Dave, > > I think a lot of the controversy is due to overloaded terminology, and > using words that people have preconceived notions for. > One term that seems to be confusing people is the term "Forming adjacency". > > "Forming adjacency" is a term that implies a bunch of steps to > layer 3 IS-IS people that the TRILL people (including me) are > not implying all the steps of. > So it's possible that TRILL people should not use the term "forming > adjacency" > in emails describing protocols, or perhaps the layer 3 IS-IS people could > try not to read too much into that phrase and instead just follow > through all the described steps in the > protocol being proposed. > > "Designated DRB" is two functions in TRILL, where it's only the second > function in layer 3 IS-IS: > > a) the one that serves specific TRILL purposes: deciding who should be > the Designated Forwarder for each VLAN > so there are no loops, deciding on Designated VLAN for inter-RBridge > communication, etc. > b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs > > In TRILL it is *essential* to get the first thing robust, i.e., never > having multiple forwarders. In layer 3 IS-IS, it's > OK to have multiple DRs. In TRILL it is *fatal*. > So the first thing TRILL has to do is to get that right. The solution, > fortunately, is easy : > > . Unpadded Hellos. > . Choosing DRB regardless of 2-way connectivity, MTU, etc. > > This is (and *must* be) different from the way layer 3 IS-IS happens to > work. > Regardless of philosophical discussions that we could carry on forever > about whether this makes TRILL a > different protocol, different version of the protocol, whatever....it is > clear that is what TRILL needs to do. > I have no objection to no longer calling the TRILL routing protocol > "IS-IS" if that is considered "too big > a change" from layer 3 IS-IS. But we have to do the obvious correct > technical thing for TRILL. > > The other thing that seems to be confusing people is the term "Hello > protocol". > The Hellos in layer 3 IS-IS have two purposes: > a) checking MTU size > b) finding neighbors, choosing DR > > TRILL is just separating the two functions (choosing DRB, and testing > MTU size), and calling it > two different protocols; the "Hello" and the "MTU probe protocol". Layer > 3 people could just think of > it as a terminology change. It seems cleaner to call it two different > protocols, since they are > serving two very different functions. Having one protoocol that does > both, the way it is today > in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to > think about > the two problems individually, and make sure we get them both right. If > you like, we can > call the MTU probe protocol "padded Hellos", but let's first make sure > we are getting > both protocols correct. Even if we call the MTU probe protocol "padded > Hellos", the > padded Hello protocol MUST NOT have any influence on the "choosing a > Designated > DRB" (the thingy in TRILL that ensures there is only a single Designated > Forwarder > per VLAN on the link). > > The technical issues (ignoring terminology) that are being discussed for > variants of the "MTU probe > protocol" are: > a) whether to ignore MTU probing entirely, because it's simpler to > just ignore it, and just ensure that > there is only one DRB on the link: and live with occasionally LSPs, > CSNPs, data packets, not > getting through on some link (which in TRILL is FAR less serious than > having multiple forwarders) > b) whether to make MTU probing just test that the link meets the > criteria of the permanent > fixed minimum size of 1450, or whatever, or whether to allow campuses to > have a different > campus-wide minimum link size S, and have RBridges test that their links > can handle size "S" > in the probing protocol, rather than "1450". Regardless of what the size > is, and how that > size is determined, it's clear what should happen if a link doesn't meet > size S. The link > should not be considered part of the topology -- routes should not be > computed that > traverse such a link. > > Radia > > > > > > > David Ward wrote: > >> All - >> >> This discussion is rapidly defining !IS-IS as a solution given the >> changes to the protocol. At least enough of the protocol is being >> changed that we need to consider a new version designator as the >> direction is fundamentally changing adj formation, DIS election, LSP >> size, etc and compatibility with current ISIS doesn't seem a goal. >> I'd like to push the brakes just a bit to try and get us into better >> sync. >> >> There are proposals that the Hellos should NOT be padded to eliminate >> a cause of multiple rbridges on the same LAN "not seeing each other" >> and electing multiple forwarders. However, the idea in the discussion >> is to remove the required MTU checking and it is proposed (which I >> don't understand) to introduce another "MTU discovery" protocol to >> restore this awareness. >> >> As we know, IS-IS requires that the DIS is elected from among the >> routers that have adjacencies (that report the existence of each >> other in the IIHs, and it requires that the IIHs are padded to the >> maximum of the link MTU and the originating L1LSPBufferSize - in the >> case of L1). This ensures both that the link is capable of >> transferring data packets of link MTU size, and more that it is >> capable of transferring LSPs of the appropriate network wide size. If >> this were not the case, then it is possible that a DIS could get >> elected which was not capable of operating the reliable update >> process, and could cause certain LSPs to fail to be propagated across >> the LAN. >> >> The DRB is the TRILL equivalent of the DIS. This is elected from among >> the routers connected to the LAN and is responsible for: >> a) generating a pseudonode LSP, which claims connectivity to all >> the other routers it sees on the LAN. (and in the OSI case reports the >> ESs on the LAN) >> b) running the LAN reliable update process (i.e. periodically >> sending CSNPs etc) >> >> So the padding is required in order to ensure that IS-IS operates >> correctly. The problem is that the roll of the DIS (aka DRB) is >> defined in terms of adjacency formation, and I don't understand how >> the two distinct roles for the DRB can be combined into a single DRB. >> Again, I've followed and read the TRILL and ISIS but, I am not seeing >> a way to combine the functions into a single DIS/DRB at this point. >> >> My view (which others have stated earlier) is that the L2ISIS desired >> functionality should not mess with the existing IS-IS DIS election >> mechanisms, but should have another set of "hellos" which can be used >> for the TRILL specific DRB elections, and have the appropriate rules >> for that. Or, we at least need to write down the rules and explore how >> to combine them. >> >> There appears only one way out of this: >> >> - TRILL WG should write down the specific requirements and >> functionality are and what the "rules" should be for them. We may find >> ISIS is suited to meet them or not. >> >> Thanks >> >> -DWard >> >> Note that if the requirement is that TRILL needs to operate in >> environments with different or "variable" (though static) MTUs, we >> should not hack an easy solution but, create a generalized solution >> >> On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: >> >> >>> OK. It's clear we should NOT pad Hellos. >>> >>> It also seems like enough people would feel uncomfortable with not >>> doing MTU discovery that we should make >>> sure there is a mechanism for that also. >>> >>> So can we focus for a minute on the following question, "whether to >>> make MTU size a forever constant, >>> or configurable in a campus", as described below. >>> >>> The simplest option is to pick some minimum size, say 1450 bytes, put >>> that in the spec now, and forever >>> say that TRILL Hellos and LSPs cannot be bigger than that. >>> MTU discovery would be done to ensure that >>> every link can handle 1450 bytes, and not use (not report in LSPs) >>> links that can't handle that. >>> >>> However, my preference is to have an optional TLV in the LSP that >>> says "campus-wide MTU size". This TLV >>> would only be relevant if: >>> a) it is larger than 1450, and >>> b) it is in the LSP of the highest priority RBridge in the campus. >>> >>> If we put that in, then we would be enabling TRILL campuses that >>> support jumbo frames. >>> >>> The rule is that if the highest priority RBridge says MTU size should >>> be 10000 bytes, then all RBridges would adjust >>> their buffer sizes, and test their adjacencies to ensure they could >>> handle 10000 bytes, and if they don't >>> then stop reporting those links (just like they would with the >>> simpler proposal if the links >>> couldn't support 1450). >>> >>> >>> >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Radia.Perlman at sun.com Thu Apr 9 16:49:39 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 09 Apr 2009 16:49:39 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DE7966.1080609@cisco.com> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> Message-ID: <49DE8993.70401@sun.com> Yes, Dinesh, I agree. All we need to do is say that in TRILL Hellos MUST NOT be padded. Radia Dinesh G Dutt wrote: > Radia, > > I'd like to reiterate that all we ought to really care about is > non-padded Hellos. That fixes our problem of creating loops otherwise. > Everything else is optional and nice-to-have. > > David, if we restrict our request to just this, would it be more > palatable to the IS-IS WG ? > > Dinesh > Radia Perlman wrote: > >> Dave, >> >> I think a lot of the controversy is due to overloaded terminology, and >> using words that people have preconceived notions for. >> One term that seems to be confusing people is the term "Forming adjacency". >> >> "Forming adjacency" is a term that implies a bunch of steps to >> layer 3 IS-IS people that the TRILL people (including me) are >> not implying all the steps of. >> So it's possible that TRILL people should not use the term "forming >> adjacency" >> in emails describing protocols, or perhaps the layer 3 IS-IS people could >> try not to read too much into that phrase and instead just follow >> through all the described steps in the >> protocol being proposed. >> >> "Designated DRB" is two functions in TRILL, where it's only the second >> function in layer 3 IS-IS: >> >> a) the one that serves specific TRILL purposes: deciding who should be >> the Designated Forwarder for each VLAN >> so there are no loops, deciding on Designated VLAN for inter-RBridge >> communication, etc. >> b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs >> >> In TRILL it is *essential* to get the first thing robust, i.e., never >> having multiple forwarders. In layer 3 IS-IS, it's >> OK to have multiple DRs. In TRILL it is *fatal*. >> So the first thing TRILL has to do is to get that right. The solution, >> fortunately, is easy : >> >> . Unpadded Hellos. >> . Choosing DRB regardless of 2-way connectivity, MTU, etc. >> >> This is (and *must* be) different from the way layer 3 IS-IS happens to >> work. >> Regardless of philosophical discussions that we could carry on forever >> about whether this makes TRILL a >> different protocol, different version of the protocol, whatever....it is >> clear that is what TRILL needs to do. >> I have no objection to no longer calling the TRILL routing protocol >> "IS-IS" if that is considered "too big >> a change" from layer 3 IS-IS. But we have to do the obvious correct >> technical thing for TRILL. >> >> The other thing that seems to be confusing people is the term "Hello >> protocol". >> The Hellos in layer 3 IS-IS have two purposes: >> a) checking MTU size >> b) finding neighbors, choosing DR >> >> TRILL is just separating the two functions (choosing DRB, and testing >> MTU size), and calling it >> two different protocols; the "Hello" and the "MTU probe protocol". Layer >> 3 people could just think of >> it as a terminology change. It seems cleaner to call it two different >> protocols, since they are >> serving two very different functions. Having one protoocol that does >> both, the way it is today >> in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to >> think about >> the two problems individually, and make sure we get them both right. If >> you like, we can >> call the MTU probe protocol "padded Hellos", but let's first make sure >> we are getting >> both protocols correct. Even if we call the MTU probe protocol "padded >> Hellos", the >> padded Hello protocol MUST NOT have any influence on the "choosing a >> Designated >> DRB" (the thingy in TRILL that ensures there is only a single Designated >> Forwarder >> per VLAN on the link). >> >> The technical issues (ignoring terminology) that are being discussed for >> variants of the "MTU probe >> protocol" are: >> a) whether to ignore MTU probing entirely, because it's simpler to >> just ignore it, and just ensure that >> there is only one DRB on the link: and live with occasionally LSPs, >> CSNPs, data packets, not >> getting through on some link (which in TRILL is FAR less serious than >> having multiple forwarders) >> b) whether to make MTU probing just test that the link meets the >> criteria of the permanent >> fixed minimum size of 1450, or whatever, or whether to allow campuses to >> have a different >> campus-wide minimum link size S, and have RBridges test that their links >> can handle size "S" >> in the probing protocol, rather than "1450". Regardless of what the size >> is, and how that >> size is determined, it's clear what should happen if a link doesn't meet >> size S. The link >> should not be considered part of the topology -- routes should not be >> computed that >> traverse such a link. >> >> Radia >> >> >> >> >> >> >> David Ward wrote: >> >> >>> All - >>> >>> This discussion is rapidly defining !IS-IS as a solution given the >>> changes to the protocol. At least enough of the protocol is being >>> changed that we need to consider a new version designator as the >>> direction is fundamentally changing adj formation, DIS election, LSP >>> size, etc and compatibility with current ISIS doesn't seem a goal. >>> I'd like to push the brakes just a bit to try and get us into better >>> sync. >>> >>> There are proposals that the Hellos should NOT be padded to eliminate >>> a cause of multiple rbridges on the same LAN "not seeing each other" >>> and electing multiple forwarders. However, the idea in the discussion >>> is to remove the required MTU checking and it is proposed (which I >>> don't understand) to introduce another "MTU discovery" protocol to >>> restore this awareness. >>> >>> As we know, IS-IS requires that the DIS is elected from among the >>> routers that have adjacencies (that report the existence of each >>> other in the IIHs, and it requires that the IIHs are padded to the >>> maximum of the link MTU and the originating L1LSPBufferSize - in the >>> case of L1). This ensures both that the link is capable of >>> transferring data packets of link MTU size, and more that it is >>> capable of transferring LSPs of the appropriate network wide size. If >>> this were not the case, then it is possible that a DIS could get >>> elected which was not capable of operating the reliable update >>> process, and could cause certain LSPs to fail to be propagated across >>> the LAN. >>> >>> The DRB is the TRILL equivalent of the DIS. This is elected from among >>> the routers connected to the LAN and is responsible for: >>> a) generating a pseudonode LSP, which claims connectivity to all >>> the other routers it sees on the LAN. (and in the OSI case reports the >>> ESs on the LAN) >>> b) running the LAN reliable update process (i.e. periodically >>> sending CSNPs etc) >>> >>> So the padding is required in order to ensure that IS-IS operates >>> correctly. The problem is that the roll of the DIS (aka DRB) is >>> defined in terms of adjacency formation, and I don't understand how >>> the two distinct roles for the DRB can be combined into a single DRB. >>> Again, I've followed and read the TRILL and ISIS but, I am not seeing >>> a way to combine the functions into a single DIS/DRB at this point. >>> >>> My view (which others have stated earlier) is that the L2ISIS desired >>> functionality should not mess with the existing IS-IS DIS election >>> mechanisms, but should have another set of "hellos" which can be used >>> for the TRILL specific DRB elections, and have the appropriate rules >>> for that. Or, we at least need to write down the rules and explore how >>> to combine them. >>> >>> There appears only one way out of this: >>> >>> - TRILL WG should write down the specific requirements and >>> functionality are and what the "rules" should be for them. We may find >>> ISIS is suited to meet them or not. >>> >>> Thanks >>> >>> -DWard >>> >>> Note that if the requirement is that TRILL needs to operate in >>> environments with different or "variable" (though static) MTUs, we >>> should not hack an easy solution but, create a generalized solution >>> >>> On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: >>> >>> >>> >>>> OK. It's clear we should NOT pad Hellos. >>>> >>>> It also seems like enough people would feel uncomfortable with not >>>> doing MTU discovery that we should make >>>> sure there is a mechanism for that also. >>>> >>>> So can we focus for a minute on the following question, "whether to >>>> make MTU size a forever constant, >>>> or configurable in a campus", as described below. >>>> >>>> The simplest option is to pick some minimum size, say 1450 bytes, put >>>> that in the spec now, and forever >>>> say that TRILL Hellos and LSPs cannot be bigger than that. >>>> MTU discovery would be done to ensure that >>>> every link can handle 1450 bytes, and not use (not report in LSPs) >>>> links that can't handle that. >>>> >>>> However, my preference is to have an optional TLV in the LSP that >>>> says "campus-wide MTU size". This TLV >>>> would only be relevant if: >>>> a) it is larger than 1450, and >>>> b) it is in the LSP of the highest priority RBridge in the campus. >>>> >>>> If we put that in, then we would be enabling TRILL campuses that >>>> support jumbo frames. >>>> >>>> The rule is that if the highest priority RBridge says MTU size should >>>> be 10000 bytes, then all RBridges would adjust >>>> their buffer sizes, and test their adjacencies to ensure they could >>>> handle 10000 bytes, and if they don't >>>> then stop reporting those links (just like they would with the >>>> simpler proposal if the links >>>> couldn't support 1450). >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg at ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>> >>>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> > > From d3e3e3 at gmail.com Thu Apr 9 17:05:04 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 9 Apr 2009 20:05:04 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DE8993.70401@sun.com> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> <49DE8993.70401@sun.com> Message-ID: <1028365c0904091705x5c9e4f3bre0eb9f2b4faeb812@mail.gmail.com> This seems reasonable. What TRILL needs is for Hellos to be reasonably short, that is, MUST NOT padded. In the interests of converging, I see no problem in deferring any decisions as to what else to do about MTU. Thanks, Donald On Thu, Apr 9, 2009 at 7:49 PM, Radia Perlman wrote: > Yes, Dinesh, I agree. All we need to do is say that in TRILL Hellos MUST NOT > be padded. > > Radia > > Dinesh G Dutt wrote: >> >> Radia, >> >> I'd like to reiterate that all we ought to really care about is non-padded >> Hellos. That fixes our problem of creating loops otherwise. Everything else >> is optional and nice-to-have. >> >> David, if we restrict our request to just this, would it be more palatable >> to the IS-IS WG ? >> >> Dinesh >> Radia Perlman wrote: >> >>> >>> Dave, >>> >>> I think a lot of the controversy is due to overloaded terminology, and >>> using words that people have preconceived notions for. >>> One term that seems to be confusing people is the term "Forming >>> adjacency". >>> >>> "Forming adjacency" is a term that implies a bunch of steps to >>> layer 3 IS-IS people that the TRILL people (including me) are >>> not implying all the steps of. >>> So it's possible that TRILL people should not use the term "forming >>> adjacency" >>> in emails describing protocols, or perhaps the layer 3 IS-IS people could >>> try not to read too much into that phrase and instead just follow through >>> all the described steps in the >>> protocol being proposed. >>> >>> "Designated DRB" is two functions in TRILL, where it's only the second >>> function in layer 3 IS-IS: >>> >>> a) the one that serves specific TRILL purposes: deciding who should be >>> the Designated Forwarder for each VLAN >>> so there are no loops, deciding on Designated VLAN for inter-RBridge >>> communication, etc. >>> b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs >>> >>> In TRILL it is *essential* to get the first thing robust, i.e., never >>> having multiple forwarders. In layer 3 IS-IS, it's >>> OK to have multiple DRs. In TRILL it is *fatal*. >>> So the first thing TRILL has to do is to get that right. The solution, >>> fortunately, is easy : >>> >>> . Unpadded Hellos. >>> . Choosing DRB regardless of 2-way connectivity, MTU, etc. >>> >>> This is (and *must* be) different from the way layer 3 IS-IS happens to >>> work. >>> Regardless of philosophical discussions that we could carry on forever >>> about whether this makes TRILL a >>> different protocol, different version of the protocol, whatever....it is >>> clear that is what TRILL needs to do. >>> I have no objection to no longer calling the TRILL routing protocol >>> "IS-IS" if that is considered "too big >>> a change" from layer 3 IS-IS. But we have to do the obvious correct >>> technical thing for TRILL. >>> >>> The other thing that seems to be confusing people is the term "Hello >>> protocol". >>> The Hellos in layer 3 IS-IS have two purposes: >>> a) checking MTU size >>> b) finding neighbors, choosing DR >>> >>> TRILL is just separating the two functions (choosing DRB, and testing MTU >>> size), and calling it >>> two different protocols; the "Hello" and the "MTU probe protocol". Layer >>> 3 people could just think of >>> it as a terminology change. It seems cleaner to call it two different >>> protocols, since they are >>> serving two very different functions. Having one protoocol that does >>> both, the way it is today >>> in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to think >>> about >>> the two problems individually, and make sure we get them both right. If >>> you like, we can >>> call the MTU probe protocol "padded Hellos", but let's first make sure we >>> are getting >>> both protocols correct. Even if we call the MTU probe protocol "padded >>> Hellos", the >>> padded Hello protocol MUST NOT have any influence on the "choosing a >>> Designated >>> DRB" (the thingy in TRILL that ensures there is only a single Designated >>> Forwarder >>> per VLAN on the link). >>> >>> The technical issues (ignoring terminology) that are being discussed for >>> variants of the "MTU probe >>> protocol" are: >>> a) whether to ignore MTU probing entirely, because it's simpler to >>> just ignore it, and just ensure that >>> there is only one DRB on the link: and live with occasionally LSPs, >>> CSNPs, data packets, not >>> getting through on some link (which in TRILL is FAR less serious than >>> having multiple forwarders) >>> b) whether to make MTU probing just test that the link meets the criteria >>> of the permanent >>> fixed minimum size of 1450, or whatever, or whether to allow campuses to >>> have a different >>> campus-wide minimum link size S, and have RBridges test that their links >>> can handle size "S" >>> in the probing protocol, rather than "1450". Regardless of what the size >>> is, and how that >>> size is determined, it's clear what should happen if a link doesn't meet >>> size S. The link >>> should not be considered part of the topology -- routes should not be >>> computed that >>> traverse such a link. >>> >>> Radia >>> >>> >>> >>> >>> >>> >>> David Ward wrote: >>> >>>> >>>> All - >>>> >>>> This discussion is rapidly defining !IS-IS as a solution given the >>>> changes to the protocol. At least enough of the protocol is being changed >>>> that we need to consider a new version designator as the direction is >>>> fundamentally changing adj formation, DIS election, LSP size, etc and >>>> compatibility with current ISIS doesn't seem a goal. ?I'd like to push the >>>> brakes just a bit to try and get us into better sync. >>>> >>>> There are proposals that the Hellos should NOT be padded to ?eliminate a >>>> cause of multiple rbridges on the same LAN "not seeing each other" and >>>> electing multiple forwarders. However, the idea in the discussion is to >>>> remove the required MTU checking and it is proposed (which I don't >>>> understand) to introduce another "MTU discovery" protocol ?to restore this >>>> awareness. >>>> >>>> As we know, ?IS-IS requires that the DIS is elected from among the >>>> routers that have adjacencies ?(that report the existence of each other in >>>> the IIHs, and it requires that the IIHs are padded to the maximum of the >>>> link MTU and the originating L1LSPBufferSize - in the case of L1). This >>>> ensures both that the link is capable of transferring data packets of link >>>> MTU size, and more ?that it is capable of transferring LSPs of the >>>> appropriate network wide size. If this were not the case, then it is >>>> possible that a DIS could get elected which was not capable of operating the >>>> reliable update process, and could cause certain LSPs to fail to be >>>> propagated across the LAN. >>>> >>>> The DRB is the TRILL equivalent of the DIS. This is elected from among >>>> the routers connected to the LAN and is responsible for: >>>> ? ? ?a) generating a pseudonode LSP, which claims connectivity to all >>>> the other routers it sees on the LAN. (and in the OSI case reports the ESs >>>> on the LAN) >>>> ? ? ?b) running the LAN reliable update process (i.e. periodically >>>> sending CSNPs etc) >>>> >>>> So the padding is required in order to ensure that IS-IS operates >>>> correctly. The problem is that the roll of the DIS (aka DRB) is defined in >>>> terms of adjacency formation, and I don't understand how the two distinct >>>> roles for the DRB ?can be combined into a single DRB. Again, I've followed >>>> and read the TRILL and ISIS ?but, I am not seeing a way to combine the >>>> functions into a single DIS/DRB at this point. >>>> >>>> My view (which others have stated earlier) is that the L2ISIS desired >>>> functionality ?should not mess with the existing IS-IS DIS election >>>> mechanisms, but should have another set of "hellos" which can be used for >>>> the TRILL specific DRB elections, and have the appropriate rules for that. >>>> Or, we at least need to write down the rules and explore how to combine >>>> them. >>>> >>>> There appears only one way out of this: >>>> >>>> - TRILL WG should write down the specific requirements and functionality >>>> are and what the "rules" should be for them. We may find ISIS is suited to >>>> meet them or not. >>>> >>>> Thanks >>>> >>>> -DWard >>>> >>>> Note that if the requirement is that TRILL needs to operate in >>>> environments with different or "variable" (though static) MTUs, we should >>>> not hack an easy solution but, create a generalized solution >>>> >>>> On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: >>>> >>>> >>>>> >>>>> OK. It's clear we should NOT pad Hellos. >>>>> >>>>> It also seems like enough people would feel uncomfortable with not >>>>> doing MTU discovery that we should make >>>>> sure there is a mechanism for that also. >>>>> >>>>> So can we focus for a minute on the following question, "whether to >>>>> make MTU size a forever constant, >>>>> or configurable in a campus", as described below. >>>>> >>>>> The simplest option is to pick some minimum size, say 1450 bytes, put >>>>> that in the spec now, and forever >>>>> say that TRILL Hellos and LSPs cannot be bigger than that. >>>>> MTU discovery would be done to ensure that >>>>> every link can handle 1450 bytes, and not use (not report in LSPs) >>>>> links that can't handle that. >>>>> >>>>> However, my preference is to have an optional TLV in the LSP that says >>>>> "campus-wide MTU size". This TLV >>>>> would only be relevant if: >>>>> a) it is larger than 1450, and >>>>> b) it is in the LSP of the highest priority RBridge in the campus. >>>>> >>>>> If we put that in, then we would be enabling TRILL campuses that >>>>> support jumbo frames. >>>>> >>>>> The rule is that if the highest priority RBridge says MTU size should >>>>> be 10000 bytes, then all RBridges would adjust >>>>> their buffer sizes, and test their adjacencies to ensure they could >>>>> handle 10000 bytes, and if they don't >>>>> then stop reporting those links (just like they would with the simpler >>>>> proposal if the links >>>>> couldn't support 1450). >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg at ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>> >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg at ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>> >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> >> > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From mrthom at essex.ac.uk Fri Apr 10 02:15:43 2009 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Fri, 10 Apr 2009 10:15:43 +0100 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> <49DE8993.70401@sun.com> <1028365c0904091705x5c9e4f3bre0eb9f2b4faeb812@mail.gmail.com> <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661DA753C7@sernt14.essex.ac.uk> +1 I am actually easy either way, If we do change the election process we (L2) really NEED to do the state diagrams Dave Ward wanted. Matthew Thomas ________________________________ From: isis-wg-bounces at ietf.org on behalf of Don Fedyk Sent: Fri 10/04/2009 01:31 To: Donald Eastlake Cc: TRILL/RBridge Working Group; Radia Perlman; isis-wg at ietf.org; Dinesh G Dutt Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important? I have a different interpretation. I think you just broke an IS-IS safeguard by not padding Hellos. The simplest thing you could do is fix the Maximum IS-IS Frame size at some lower value and continue to PAD Hellos. Don On Thu, Apr 9, 2009 at 8:05 PM, Donald Eastlake wrote: This seems reasonable. What TRILL needs is for Hellos to be reasonably short, that is, MUST NOT padded. In the interests of converging, I see no problem in deferring any decisions as to what else to do about MTU. Thanks, Donald On Thu, Apr 9, 2009 at 7:49 PM, Radia Perlman wrote: > Yes, Dinesh, I agree. All we need to do is say that in TRILL Hellos MUST NOT > be padded. > > Radia > > Dinesh G Dutt wrote: >> >> Radia, >> >> I'd like to reiterate that all we ought to really care about is non-padded >> Hellos. That fixes our problem of creating loops otherwise. Everything else >> is optional and nice-to-have. >> >> David, if we restrict our request to just this, would it be more palatable >> to the IS-IS WG ? >> >> Dinesh >> Radia Perlman wrote: >> >>> >>> Dave, >>> >>> I think a lot of the controversy is due to overloaded terminology, and >>> using words that people have preconceived notions for. >>> One term that seems to be confusing people is the term "Forming >>> adjacency". >>> >>> "Forming adjacency" is a term that implies a bunch of steps to >>> layer 3 IS-IS people that the TRILL people (including me) are >>> not implying all the steps of. >>> So it's possible that TRILL people should not use the term "forming >>> adjacency" >>> in emails describing protocols, or perhaps the layer 3 IS-IS people could >>> try not to read too much into that phrase and instead just follow through >>> all the described steps in the >>> protocol being proposed. >>> >>> "Designated DRB" is two functions in TRILL, where it's only the second >>> function in layer 3 IS-IS: >>> >>> a) the one that serves specific TRILL purposes: deciding who should be >>> the Designated Forwarder for each VLAN >>> so there are no loops, deciding on Designated VLAN for inter-RBridge >>> communication, etc. >>> b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs >>> >>> In TRILL it is *essential* to get the first thing robust, i.e., never >>> having multiple forwarders. In layer 3 IS-IS, it's >>> OK to have multiple DRs. In TRILL it is *fatal*. >>> So the first thing TRILL has to do is to get that right. The solution, >>> fortunately, is easy : >>> >>> . Unpadded Hellos. >>> . Choosing DRB regardless of 2-way connectivity, MTU, etc. >>> >>> This is (and *must* be) different from the way layer 3 IS-IS happens to >>> work. >>> Regardless of philosophical discussions that we could carry on forever >>> about whether this makes TRILL a >>> different protocol, different version of the protocol, whatever....it is >>> clear that is what TRILL needs to do. >>> I have no objection to no longer calling the TRILL routing protocol >>> "IS-IS" if that is considered "too big >>> a change" from layer 3 IS-IS. But we have to do the obvious correct >>> technical thing for TRILL. >>> >>> The other thing that seems to be confusing people is the term "Hello >>> protocol". >>> The Hellos in layer 3 IS-IS have two purposes: >>> a) checking MTU size >>> b) finding neighbors, choosing DR >>> >>> TRILL is just separating the two functions (choosing DRB, and testing MTU >>> size), and calling it >>> two different protocols; the "Hello" and the "MTU probe protocol". Layer >>> 3 people could just think of >>> it as a terminology change. It seems cleaner to call it two different >>> protocols, since they are >>> serving two very different functions. Having one protoocol that does >>> both, the way it is today >>> in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to think >>> about >>> the two problems individually, and make sure we get them both right. If >>> you like, we can >>> call the MTU probe protocol "padded Hellos", but let's first make sure we >>> are getting >>> both protocols correct. Even if we call the MTU probe protocol "padded >>> Hellos", the >>> padded Hello protocol MUST NOT have any influence on the "choosing a >>> Designated >>> DRB" (the thingy in TRILL that ensures there is only a single Designated >>> Forwarder >>> per VLAN on the link). >>> >>> The technical issues (ignoring terminology) that are being discussed for >>> variants of the "MTU probe >>> protocol" are: >>> a) whether to ignore MTU probing entirely, because it's simpler to >>> just ignore it, and just ensure that >>> there is only one DRB on the link: and live with occasionally LSPs, >>> CSNPs, data packets, not >>> getting through on some link (which in TRILL is FAR less serious than >>> having multiple forwarders) >>> b) whether to make MTU probing just test that the link meets the criteria >>> of the permanent >>> fixed minimum size of 1450, or whatever, or whether to allow campuses to >>> have a different >>> campus-wide minimum link size S, and have RBridges test that their links >>> can handle size "S" >>> in the probing protocol, rather than "1450". Regardless of what the size >>> is, and how that >>> size is determined, it's clear what should happen if a link doesn't meet >>> size S. The link >>> should not be considered part of the topology -- routes should not be >>> computed that >>> traverse such a link. >>> >>> Radia >>> >>> >>> >>> >>> >>> >>> David Ward wrote: >>> >>>> >>>> All - >>>> >>>> This discussion is rapidly defining !IS-IS as a solution given the >>>> changes to the protocol. At least enough of the protocol is being changed >>>> that we need to consider a new version designator as the direction is >>>> fundamentally changing adj formation, DIS election, LSP size, etc and >>>> compatibility with current ISIS doesn't seem a goal. I'd like to push the >>>> brakes just a bit to try and get us into better sync. >>>> >>>> There are proposals that the Hellos should NOT be padded to eliminate a >>>> cause of multiple rbridges on the same LAN "not seeing each other" and >>>> electing multiple forwarders. However, the idea in the discussion is to >>>> remove the required MTU checking and it is proposed (which I don't >>>> understand) to introduce another "MTU discovery" protocol to restore this >>>> awareness. >>>> >>>> As we know, IS-IS requires that the DIS is elected from among the >>>> routers that have adjacencies (that report the existence of each other in >>>> the IIHs, and it requires that the IIHs are padded to the maximum of the >>>> link MTU and the originating L1LSPBufferSize - in the case of L1). This >>>> ensures both that the link is capable of transferring data packets of link >>>> MTU size, and more that it is capable of transferring LSPs of the >>>> appropriate network wide size. If this were not the case, then it is >>>> possible that a DIS could get elected which was not capable of operating the >>>> reliable update process, and could cause certain LSPs to fail to be >>>> propagated across the LAN. >>>> >>>> The DRB is the TRILL equivalent of the DIS. This is elected from among >>>> the routers connected to the LAN and is responsible for: >>>> a) generating a pseudonode LSP, which claims connectivity to all >>>> the other routers it sees on the LAN. (and in the OSI case reports the ESs >>>> on the LAN) >>>> b) running the LAN reliable update process (i.e. periodically >>>> sending CSNPs etc) >>>> >>>> So the padding is required in order to ensure that IS-IS operates >>>> correctly. The problem is that the roll of the DIS (aka DRB) is defined in >>>> terms of adjacency formation, and I don't understand how the two distinct >>>> roles for the DRB can be combined into a single DRB. Again, I've followed >>>> and read the TRILL and ISIS but, I am not seeing a way to combine the >>>> functions into a single DIS/DRB at this point. >>>> >>>> My view (which others have stated earlier) is that the L2ISIS desired >>>> functionality should not mess with the existing IS-IS DIS election >>>> mechanisms, but should have another set of "hellos" which can be used for >>>> the TRILL specific DRB elections, and have the appropriate rules for that. >>>> Or, we at least need to write down the rules and explore how to combine >>>> them. >>>> >>>> There appears only one way out of this: >>>> >>>> - TRILL WG should write down the specific requirements and functionality >>>> are and what the "rules" should be for them. We may find ISIS is suited to >>>> meet them or not. >>>> >>>> Thanks >>>> >>>> -DWard >>>> >>>> Note that if the requirement is that TRILL needs to operate in >>>> environments with different or "variable" (though static) MTUs, we should >>>> not hack an easy solution but, create a generalized solution >>>> >>>> On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: >>>> >>>> >>>>> >>>>> OK. It's clear we should NOT pad Hellos. >>>>> >>>>> It also seems like enough people would feel uncomfortable with not >>>>> doing MTU discovery that we should make >>>>> sure there is a mechanism for that also. >>>>> >>>>> So can we focus for a minute on the following question, "whether to >>>>> make MTU size a forever constant, >>>>> or configurable in a campus", as described below. >>>>> >>>>> The simplest option is to pick some minimum size, say 1450 bytes, put >>>>> that in the spec now, and forever >>>>> say that TRILL Hellos and LSPs cannot be bigger than that. >>>>> MTU discovery would be done to ensure that >>>>> every link can handle 1450 bytes, and not use (not report in LSPs) >>>>> links that can't handle that. >>>>> >>>>> However, my preference is to have an optional TLV in the LSP that says >>>>> "campus-wide MTU size". This TLV >>>>> would only be relevant if: >>>>> a) it is larger than 1450, and >>>>> b) it is in the LSP of the highest priority RBridge in the campus. >>>>> >>>>> If we put that in, then we would be enabling TRILL campuses that >>>>> support jumbo frames. >>>>> >>>>> The rule is that if the highest priority RBridge says MTU size should >>>>> be 10000 bytes, then all RBridges would adjust >>>>> their buffer sizes, and test their adjacencies to ensure they could >>>>> handle 10000 bytes, and if they don't >>>>> then stop reporting those links (just like they would with the simpler >>>>> proposal if the links >>>>> couldn't support 1450). >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg at ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>> >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg at ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>> >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> >> > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com _______________________________________________ Isis-wg mailing list Isis-wg at ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From jeffpick at broadcom.com Fri Apr 10 05:46:07 2009 From: jeffpick at broadcom.com (Jeff Pickering) Date: Fri, 10 Apr 2009 05:46:07 -0700 Subject: [rbridge] parallel links Message-ID: <9793EC0A42D76D4EB2A8F94D77E213885C654ED286@SJEXCHCCR02.corp.ad.broadcom.com> New to the list and was looking at a couple of threads related to parallel links. If I missed something in another thread that addressed this, I apologize in advance.. For the case where R1,R2 have parallel links, it seems there is agreement that a third device R3 need not be concerned. Ie, R3 need only know whether or not the shotest path transits R1/R2. So it seems to me there is no need to suppress links in R1 or R2's LSPs and no need to worry about unequal costs reported on those links. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090410/f8b608e3/attachment.html From james.d.carlson at sun.com Fri Apr 10 06:38:43 2009 From: james.d.carlson at sun.com (James Carlson) Date: Fri, 10 Apr 2009 09:38:43 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> <49DE8993.70401@sun.com> <1028365c0904091705x5c9e4f3bre0eb9f2b4faeb812@mail.gmail.com> <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> Message-ID: <18911.19427.534592.94884@gargle.gargle.HOWL> Don Fedyk writes: > I have a different interpretation. I think you just broke an IS-IS > safeguard by not padding Hellos. > > The simplest thing you could do is fix the Maximum IS-IS Frame size at some > lower value and continue to PAD Hellos. I disagree. In the context of TRILL, it's *not* a safeguard at all. It is in fact a problem. Failing to get Hello messages through (because the "safeguard" can stop them when there's a restriction) means that your entire network goes down. This is the crucial difference. I realize that the padded Hello is protecting against an inability to get LSPs through between peers. However, the TRILL failure mode we're talking about is far worse, and destroys everything in its path, including innocent bystanders. To simplify, let's consider two cases: 1. This new, smaller padded Hello is always small enough to fit on all of the networks anyone ever uses. 2. The new smaller padded Hello fails to get through on some network. In case (1), everything works fine, but it's also true that unpadded Hellos would work fine as well. It's a no-op. In case (2), the "protection" offered by the padded Hello has now made two RBridges invisible to each other. They will both become DRBs. They will both begin forwarding L2 frames. The network now has an L2 forwarding loop, and it goes down hard. Unless we make this new padding requirement absurdly low (say, 64 octets), such that it's not really useful in any sense but also just never does any harm, I think we're making a mistake. -- 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 dward at cisco.com Fri Apr 10 08:58:27 2009 From: dward at cisco.com (David Ward) Date: Fri, 10 Apr 2009 10:58:27 -0500 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DE7966.1080609@cisco.com> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> Message-ID: Dinesh - This is a much better place to start and gives us something concrete to work on. Let's consider this as the only work item. -DWard On Apr 9, 2009, at 5:40 PM, Dinesh G Dutt wrote: > Radia, > > I'd like to reiterate that all we ought to really care about is non- > padded Hellos. That fixes our problem of creating loops otherwise. > Everything else is optional and nice-to-have. > > David, if we restrict our request to just this, would it be more > palatable to the IS-IS WG ? > > Dinesh > Radia Perlman wrote: >> Dave, >> >> I think a lot of the controversy is due to overloaded terminology, >> and using words that people have preconceived notions for. >> One term that seems to be confusing people is the term "Forming >> adjacency". >> >> "Forming adjacency" is a term that implies a bunch of steps to >> layer 3 IS-IS people that the TRILL people (including me) are >> not implying all the steps of. >> So it's possible that TRILL people should not use the term "forming >> adjacency" >> in emails describing protocols, or perhaps the layer 3 IS-IS people >> could >> try not to read too much into that phrase and instead just follow >> through all the described steps in the >> protocol being proposed. >> >> "Designated DRB" is two functions in TRILL, where it's only the >> second function in layer 3 IS-IS: >> >> a) the one that serves specific TRILL purposes: deciding who should >> be the Designated Forwarder for each VLAN >> so there are no loops, deciding on Designated VLAN for inter- >> RBridge communication, etc. >> b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs >> >> In TRILL it is *essential* to get the first thing robust, i.e., >> never having multiple forwarders. In layer 3 IS-IS, it's >> OK to have multiple DRs. In TRILL it is *fatal*. >> So the first thing TRILL has to do is to get that right. The >> solution, >> fortunately, is easy : >> >> . Unpadded Hellos. >> . Choosing DRB regardless of 2-way connectivity, MTU, etc. >> >> This is (and *must* be) different from the way layer 3 IS-IS >> happens to work. >> Regardless of philosophical discussions that we could carry on >> forever about whether this makes TRILL a >> different protocol, different version of the protocol, >> whatever....it is clear that is what TRILL needs to do. >> I have no objection to no longer calling the TRILL routing protocol >> "IS-IS" if that is considered "too big >> a change" from layer 3 IS-IS. But we have to do the obvious correct >> technical thing for TRILL. >> >> The other thing that seems to be confusing people is the term >> "Hello protocol". >> The Hellos in layer 3 IS-IS have two purposes: >> a) checking MTU size >> b) finding neighbors, choosing DR >> >> TRILL is just separating the two functions (choosing DRB, and >> testing MTU size), and calling it >> two different protocols; the "Hello" and the "MTU probe protocol". >> Layer 3 people could just think of >> it as a terminology change. It seems cleaner to call it two >> different protocols, since they are >> serving two very different functions. Having one protoocol that >> does both, the way it is today >> in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to >> think about >> the two problems individually, and make sure we get them both >> right. If you like, we can >> call the MTU probe protocol "padded Hellos", but let's first make >> sure we are getting >> both protocols correct. Even if we call the MTU probe protocol >> "padded Hellos", the >> padded Hello protocol MUST NOT have any influence on the "choosing >> a Designated >> DRB" (the thingy in TRILL that ensures there is only a single >> Designated Forwarder >> per VLAN on the link). >> >> The technical issues (ignoring terminology) that are being >> discussed for variants of the "MTU probe >> protocol" are: >> a) whether to ignore MTU probing entirely, because it's simpler to >> just ignore it, and just ensure that >> there is only one DRB on the link: and live with occasionally LSPs, >> CSNPs, data packets, not >> getting through on some link (which in TRILL is FAR less serious >> than having multiple forwarders) >> b) whether to make MTU probing just test that the link meets the >> criteria of the permanent >> fixed minimum size of 1450, or whatever, or whether to allow >> campuses to have a different >> campus-wide minimum link size S, and have RBridges test that their >> links can handle size "S" >> in the probing protocol, rather than "1450". Regardless of what the >> size is, and how that >> size is determined, it's clear what should happen if a link doesn't >> meet size S. The link >> should not be considered part of the topology -- routes should not >> be computed that >> traverse such a link. >> >> Radia >> >> >> >> >> >> >> David Ward wrote: >> >>> All - >>> >>> This discussion is rapidly defining !IS-IS as a solution given the >>> changes to the protocol. At least enough of the protocol is being >>> changed that we need to consider a new version designator as the >>> direction is fundamentally changing adj formation, DIS election, >>> LSP size, etc and compatibility with current ISIS doesn't seem a >>> goal. I'd like to push the brakes just a bit to try and get us >>> into better sync. >>> >>> There are proposals that the Hellos should NOT be padded to >>> eliminate a cause of multiple rbridges on the same LAN "not seeing >>> each other" and electing multiple forwarders. However, the idea in >>> the discussion is to remove the required MTU checking and it is >>> proposed (which I don't understand) to introduce another "MTU >>> discovery" protocol to restore this awareness. >>> >>> As we know, IS-IS requires that the DIS is elected from among the >>> routers that have adjacencies (that report the existence of each >>> other in the IIHs, and it requires that the IIHs are padded to the >>> maximum of the link MTU and the originating L1LSPBufferSize - in >>> the case of L1). This ensures both that the link is capable of >>> transferring data packets of link MTU size, and more that it is >>> capable of transferring LSPs of the appropriate network wide size. >>> If this were not the case, then it is possible that a DIS could >>> get elected which was not capable of operating the reliable update >>> process, and could cause certain LSPs to fail to be propagated >>> across the LAN. >>> >>> The DRB is the TRILL equivalent of the DIS. This is elected from >>> among the routers connected to the LAN and is responsible for: >>> a) generating a pseudonode LSP, which claims connectivity to >>> all the other routers it sees on the LAN. (and in the OSI case >>> reports the ESs on the LAN) >>> b) running the LAN reliable update process (i.e. periodically >>> sending CSNPs etc) >>> >>> So the padding is required in order to ensure that IS-IS operates >>> correctly. The problem is that the roll of the DIS (aka DRB) is >>> defined in terms of adjacency formation, and I don't understand >>> how the two distinct roles for the DRB can be combined into a >>> single DRB. Again, I've followed and read the TRILL and ISIS but, >>> I am not seeing a way to combine the functions into a single DIS/ >>> DRB at this point. >>> >>> My view (which others have stated earlier) is that the L2ISIS >>> desired functionality should not mess with the existing IS-IS DIS >>> election mechanisms, but should have another set of "hellos" which >>> can be used for the TRILL specific DRB elections, and have the >>> appropriate rules for that. Or, we at least need to write down the >>> rules and explore how to combine them. >>> >>> There appears only one way out of this: >>> >>> - TRILL WG should write down the specific requirements and >>> functionality are and what the "rules" should be for them. We may >>> find ISIS is suited to meet them or not. >>> >>> Thanks >>> >>> -DWard >>> >>> Note that if the requirement is that TRILL needs to operate in >>> environments with different or "variable" (though static) MTUs, we >>> should not hack an easy solution but, create a generalized solution >>> >>> On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote: >>> >>> >>>> OK. It's clear we should NOT pad Hellos. >>>> >>>> It also seems like enough people would feel uncomfortable with >>>> not doing MTU discovery that we should make >>>> sure there is a mechanism for that also. >>>> >>>> So can we focus for a minute on the following question, "whether >>>> to make MTU size a forever constant, >>>> or configurable in a campus", as described below. >>>> >>>> The simplest option is to pick some minimum size, say 1450 bytes, >>>> put that in the spec now, and forever >>>> say that TRILL Hellos and LSPs cannot be bigger than that. >>>> MTU discovery would be done to ensure that >>>> every link can handle 1450 bytes, and not use (not report in >>>> LSPs) links that can't handle that. >>>> >>>> However, my preference is to have an optional TLV in the LSP that >>>> says "campus-wide MTU size". This TLV >>>> would only be relevant if: >>>> a) it is larger than 1450, and >>>> b) it is in the LSP of the highest priority RBridge in the campus. >>>> >>>> If we put that in, then we would be enabling TRILL campuses that >>>> support jumbo frames. >>>> >>>> The rule is that if the highest priority RBridge says MTU size >>>> should be 10000 bytes, then all RBridges would adjust >>>> their buffer sizes, and test their adjacencies to ensure they >>>> could handle 10000 bytes, and if they don't >>>> then stop reporting those links (just like they would with the >>>> simpler proposal if the links >>>> couldn't support 1450). >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg at ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > > -- > We make our world significant by the courage of our questions and by > the depth of our answers. - Carl Sagan > From Radia.Perlman at sun.com Fri Apr 10 09:16:10 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 10 Apr 2009 09:16:10 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <18911.19427.534592.94884@gargle.gargle.HOWL> References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> <49DE8993.70401@sun.com> <1028365c0904091705x5c9e4f3bre0eb9f2b4faeb812@mail.gmail.com> <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> <18911.19427.534592.94884@gargle.gargle.HOWL> Message-ID: <49DF70CA.3020106@sun.com> Like Jim said, and as numerous people have said in many previous emails on this thread, padded Hellos do not work for TRILL, because it results in two RBridges not seeing each other, and both forwarding to/from the link. Which causes loops not protected by the TTL, and is therefore fatal. Layer 3 is different in this case than layer 2. Again, as explained numerous times before, so it probably won't help for me to explain it once more. Not padding hellos does not "break IS-IS". The only thing it does is not do the extra thing that the IS-IS Hello mechanism is doing at the same time as finding neighbors, which is to test the MTU size. In TRILL, although weird things may happen if the topology includes a link that can't handle the MTU size, it's far less bad than to have two neighbors not see each other. So, repeating for the nth time.... Keeping the Hello mechanism exactly as it is in IS-IS today will not work for TRILL. That should be the end of discussion. Not padding the Hellos obviously works for robustly finding neighbors, and is a trivial change. The only thing that gets lost is MTU discovery. The only feasible choices at this point are: a) only do unpadded Hellos, and live with weirdnesses due to not testing MTU size, deferring MTU discovery to the future b) do unpadded Hellos, and come up with a mechanism for MTU discovery now. It would be easy to do so. I'm happy either way. If we pick a conservative MTU size (and perhaps the value that's already in IS-IS is conservative enough) and say in the spec that LSPs MUST NOT be bigger than that, the probability of weirdness as a result of not testing MTU size will be very small, probably even zero. Radia James Carlson wrote: > Don Fedyk writes: > >> I have a different interpretation. I think you just broke an IS-IS >> safeguard by not padding Hellos. >> >> The simplest thing you could do is fix the Maximum IS-IS Frame size at some >> lower value and continue to PAD Hellos. >> > > I disagree. In the context of TRILL, it's *not* a safeguard at all. > It is in fact a problem. > > Failing to get Hello messages through (because the "safeguard" can > stop them when there's a restriction) means that your entire network > goes down. > > This is the crucial difference. I realize that the padded Hello is > protecting against an inability to get LSPs through between peers. > However, the TRILL failure mode we're talking about is far worse, and > destroys everything in its path, including innocent bystanders. > > To simplify, let's consider two cases: > > 1. This new, smaller padded Hello is always small enough to fit on > all of the networks anyone ever uses. > > 2. The new smaller padded Hello fails to get through on some > network. > > In case (1), everything works fine, but it's also true that unpadded > Hellos would work fine as well. It's a no-op. > > In case (2), the "protection" offered by the padded Hello has now made > two RBridges invisible to each other. They will both become DRBs. > They will both begin forwarding L2 frames. The network now has an L2 > forwarding loop, and it goes down hard. > > Unless we make this new padding requirement absurdly low (say, 64 > octets), such that it's not really useful in any sense but also just > never does any harm, I think we're making a mistake. > > From Radia.Perlman at sun.com Fri Apr 10 09:21:13 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 10 Apr 2009 09:21:13 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: References: <49DBB332.6080003@sun.com> <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> <49DE8993.70401@sun.com> <1028365c0904091705x5c9e4f3bre0eb9f2b4faeb812@mail.gmail.com> <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> <49DED12F.5040704@tony.li> Message-ID: <49DF71F9.30309@sun.com> No, Vishwas -- merely stating the MTU is not sufficient, because there could be components between two RBridges (like, for instance, bridges), that wind up causing a big packet not to get through. So to really test the MTU requires a padded packet, (but it need not be (and MUST NOT be, for TRILL) the same, simultaneous mechanism as finding neighbors, such as layer 3 IS-IS which does not see neighbors that can't be reached using the largest packets.) Radia Vishwas Manral wrote: > Hi, > > Though the MTU padding of Hello's is one way of getting the MTU right in all > the machines, a simpler and more efficient way would be to actually exchange > MTU values in a TLV. > > The reason padding of Hellos was done in a layer 3 network, instead of a TLV > was because if between 2 - Layer 3 peers there was a switched network (not > just a single link), and the MTU in the links somewhere in between was > lesser, there would be no way to figure that out. > > For trying to work IS-IS for layer 2 the reason no longer holds good. > > Thanks, > Vishwas > > -----Original Message----- > From: isis-wg-bounces at ietf.org [mailto:isis-wg-bounces at ietf.org] On Behalf > Of Tony Li > Sent: Thursday, April 09, 2009 9:55 PM > To: Don Fedyk > Cc: TRILL/RBridge Working Group; Radia Perlman; isis-wg at ietf.org; Dinesh G > Dutt > Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important? > > Don Fedyk wrote: > >> I have a different interpretation. I think you just broke an IS-IS >> safeguard by not padding Hellos. >> > > > +1 > > Tony > > > > From d3e3e3 at gmail.com Fri Apr 10 11:31:32 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 10 Apr 2009 14:31:32 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DF83AA.2000705@raszuk.net> References: <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com> <49DE7966.1080609@cisco.com> <49DE8993.70401@sun.com> <1028365c0904091705x5c9e4f3bre0eb9f2b4faeb812@mail.gmail.com> <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> <18911.19427.534592.94884@gargle.gargle.HOWL> <49DF70CA.3020106@sun.com> <49DF83AA.2000705@raszuk.net> Message-ID: <1028365c0904101131j70072e28m12328b71e925cffd@mail.gmail.com> Hi Robert, See below... On Fri, Apr 10, 2009 at 1:36 PM, Robert Raszuk wrote: > Hi Radia, > >> Keeping the Hello mechanism exactly as it is in IS-IS today will not work >> for TRILL. >> That should be the end of discussion. Not padding the Hellos obviously >> works for robustly finding neighbors, and is a trivial change. The >> only thing that gets lost is MTU discovery. >> >> The only feasible choices at this point are: >> a) only do unpadded Hellos, and live with weirdnesses due to not >> testing MTU size, deferring MTU discovery to the future >> b) do unpadded Hellos, and come up with a mechanism for MTU discovery now. >> It would be easy to do so. > > + > >> So to really test the MTU requires a padded packet, >> (but it need not be (and MUST NOT be, for TRILL) the same, simultaneous >> mechanism >> as finding neighbors, such as layer 3 IS-IS which does not see neighbors >> that can't >> be reached using the largest packets.) > > So how about option c) which would leave current L3 ISIS Hellos as is today > and define a new TRILL ISIS Hello mechanism ? Seems to me like quite simple > and trivial solution to accomplish without any compromises. The short message, whatever it is called, has to have most if not all the Hello header information. It also has to have in its body (in some TLV or otherwise) at least the Designated VLAN for link and a copy of the VLAN ID with which it was tagged on transmission as well as a flag indicating whether it thinks it is Appointed Forwarder for that VLAN. Furthermore, the option must be available to authenticate this message, so it sure seems convenient to be able to include the IS-IS Security TLV. Furthermore, it needs to participate in DRB determination in essentially the same way that Hellos need to. By the time you are through with all that (and maybe I missed something else that needs to be added), what is the point of not having this short message be a Hello? Or are you just saying that you favor the two kinds of Hello solution which is in draft-ietf-trill-rbridge-protocol-12.txt? You have studied that draft, haven't you? > Of course if we down the road find that minor changes like this will be > required to other functions of today's ISIS it will be also easier to > separate L3 ISIS from ISIS twicked for TRILL and perhaps even run it fully > independently. > > Cheers, > R. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Fri Apr 10 15:00:26 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 10 Apr 2009 18:00:26 -0400 Subject: [rbridge] parallel links In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E213885C654ED286@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED286@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <1028365c0904101500m52932558w9ea011de64e49ac3@mail.gmail.com> If different RBridges compute shortest paths in different ways, you can get loops. So, given a link state database, there must be a deterministic way of doing this. The current (-12) draft requires that multiple parallel adjacencies be reported as a single adjacency in LSPs and that if, in violation of that requirement, they are reported separately, you just use the lowest cost adjacency (or one of the lowest cost if there are two or more tied). The first requirement could be dropped, given the second provision. But whatever you do, you have to avoid cases where two different RBridges, operating on the link state database, would come up with different costs for the adjacency, such as one using the cost of the least cost adjacency and another assuming that their was some equal cost multi-path going on or the like and assuming that additional parallel adjacencies decrease the cost of the hop. Donald On Fri, Apr 10, 2009 at 8:46 AM, Jeff Pickering wrote: > > New to the list and was looking at a couple of threads related to parallel > links. If I missed something > in another ?thread that addressed this, I apologize in advance.. > > For the case where R1,R2 have parallel links, it seems there is agreement > that?a third device R3 > need not be concerned. Ie, R3 need only know whether or not the shotest path > transits R1/R2. So > it seems to me there is no need to suppress?links?in R1 or R2's LSPs and no > need to worry about > unequal costs reported on those links. > > > Jeff > > _______________________________________________ > 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 sboddapa at yahoo.com Fri Apr 10 15:22:22 2009 From: sboddapa at yahoo.com (Suresh Boddapati) Date: Fri, 10 Apr 2009 15:22:22 -0700 (PDT) Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DF70CA.3020106@sun.com> Message-ID: <508896.66561.qm@web81305.mail.mud.yahoo.com> --- On Fri, 4/10/09, Radia Perlman wrote: > > Not padding hellos does not "break IS-IS". I am not completely sure. Please correct me if I am wrong. Let me see if I can construct an example. 1 A--------B \ / 1 \ / 5 \ C / The numbers are the respective cost on the links. Now suppose A has a smaller MTU such that it can see B's and C's hellos and form adjacencies with them. Now B's LSP that describes the link to A happens to be larger than the MTU that A uses on its links. This LSP does not get through to A from either B or C. Consider that the LSP that B uses to describe the link to C is within the MTU limits and does get through. Since A does not see B's LSP describing the link to A, it will compute a path to B through C. C sees both A's and B's LSPs and determines that the shortest path to B is through A (note A and B have both advertised their link in their respective LSPs, so the bidirectionality check would pass, it's just that A does not have B's LSP, so it cannot compute the path correctly). You have basically prevented A from being able to get to all destinations that can be reached through B and you have a loop of a different kind. This loop will not go away. The fix in IS-IS for this is to use padded hellos. If you pad, adjacencies wont form between A and B and everything will be fine. In TRILL, if you eliminate the padding, you have a TRILL forwarding loop and every frame sent by A to B or anything reachable through B will die in this loop once the hop count reaches zero. I recognize the fact that this is not as bad as the case when RBridges do not see each other, but is this the "weirdness" you say we could live with? IMO, we should make every effort to not have this situation. Debugging this could be real fun. And this is just one example of things going wrong. CSNPs may not get through. Or it is possible they do get through, but the LSPs dont, resulting in constant flooding of those LSPs on those links. > So, repeating for the nth time.... > Keeping the Hello mechanism exactly as it is in IS-IS today > will not > work for TRILL. > That should be the end of discussion. Not padding the > Hellos obviously > works for robustly finding neighbors, and is a trivial > change. The > only thing that gets lost is MTU discovery. > > The only feasible choices at this point are: > a) only do unpadded Hellos, and live with weirdnesses due > to not > testing MTU size, deferring MTU discovery to the future > b) do unpadded Hellos, and come up with a mechanism for MTU > discovery now. > It would be easy to do so. > I would prefer to go with an option that ensures that no LSPs get lost silently due to MTU issues. Thanks, Suresh From Radia.Perlman at sun.com Fri Apr 10 15:52:49 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 10 Apr 2009 15:52:49 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <508896.66561.qm@web81305.mail.mud.yahoo.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> Message-ID: <49DFCDC1.8050100@sun.com> Suresh, I agree that it would be good to solve both problems: a) ensure that RBridges see each other (unpadded Hellos is the the solution that has been proposed), and b) some mechanism to assure there is agreement about what the campus-wide MTU size should be, and assure that the paths computed only include links that meet that MTU size. It would not be difficult (technically) to solve b) but a) is more important, so I can live with deferring b) and shipping the spec. If people would like solve b) now, then fine, I'm sure we can come up with a mechanism to do that. But we have to ensure that that mechanism does not interfere in any way with a). The problem is that discussing both problems at the same time seems to be confusing people. I think we should agree on this thread that we need to do unpadded Hellos to solve problem a), and start a second thread about what to do about problem b), e.g., "ignore it", "defer it until later", or "here's a candidate solution". Radia Suresh Boddapati wrote: > --- On Fri, 4/10/09, Radia Perlman wrote: > > >> Not padding hellos does not "break IS-IS". >> > > I am not completely sure. Please correct me if I am wrong. > Let me see if I can construct an example. > > 1 > A--------B > \ / > 1 \ / 5 > \ C / > > The numbers are the respective cost on the links. > > Now suppose A has a smaller MTU such that it can see B's and C's hellos and form adjacencies with them. Now B's LSP that describes the link to A happens to be larger than the MTU that A uses on its links. This LSP does not get through to A from either B or C. Consider that the LSP that B uses to describe the link to C is within the MTU limits and does get through. > Since A does not see B's LSP describing the link to A, it will compute a path to B through C. > > C sees both A's and B's LSPs and determines that the shortest path to B is through A (note A and B have both advertised their link in their respective LSPs, so the bidirectionality check would pass, it's just that A does not have B's LSP, so it cannot compute the path correctly). You have basically prevented A from being able to get to all destinations that can be reached through B and you have a loop of a different kind. This loop will not go away. The fix in IS-IS for this is to use padded hellos. If you pad, adjacencies wont form between A and B and everything will be fine. > > In TRILL, if you eliminate the padding, you have a TRILL forwarding loop and every frame sent by A to B or anything reachable through B will die in this loop once the hop count reaches zero. I recognize the fact that this is not as bad as the case when RBridges do not see each other, but is this the "weirdness" you say we could live with? IMO, we should make every effort to not have this situation. Debugging this could be real fun. And this is just one example of things going wrong. CSNPs may not get through. Or it is possible they do get through, but the LSPs dont, resulting in constant flooding of those LSPs on those links. > > >> So, repeating for the nth time.... >> Keeping the Hello mechanism exactly as it is in IS-IS today >> will not >> work for TRILL. >> That should be the end of discussion. Not padding the >> Hellos obviously >> works for robustly finding neighbors, and is a trivial >> change. The >> only thing that gets lost is MTU discovery. >> >> The only feasible choices at this point are: >> a) only do unpadded Hellos, and live with weirdnesses due >> to not >> testing MTU size, deferring MTU discovery to the future >> b) do unpadded Hellos, and come up with a mechanism for MTU >> discovery now. >> It would be easy to do so. >> >> > I would prefer to go with an option that ensures that no LSPs get lost silently due to MTU issues. > > Thanks, > > Suresh > From don.fedyk at gmail.com Fri Apr 10 18:51:15 2009 From: don.fedyk at gmail.com (Don Fedyk) Date: Fri, 10 Apr 2009 21:51:15 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DFCDC1.8050100@sun.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> Message-ID: <49DFF793.4090600@gmail.com> Hi Radia b) is a not side issue. Problem b) is characterized by ensuring the minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills LSP up to the minimum MTU as part of its operation. Initially when there is not much information to exchange the frame size is small, but as information gets added the LSPs grows to the minimum MTU size then IS-IS fragments them. So if you are not sure the minimum MTU limit is supported everywhere and continuously monitored then the probability increases there will be missing LSPs. Missing LSPs is a big problem. b) is therefore a problem for proper operation of Trill too. In IS-IS where b) is the problem, padding Hellos is the current solution and it safeguards IS-IS. Missing Hellos take down the adjacency (ie become unaware of any other IS-IS capable systems on the link) if the minimum MTU is not supported (cut off the link to save the rest of the network network). It is also a good thing to have the initial packet you send fail the minimum MTU check if it is going to fail. It makes little sense to exchange messages further for IS-IS operation. Problem a) Is a problem characterized by knowing all RBridges attached to a common LAN for correct operation of the LAN and the RBridges. IS-IS between the RBridges on the LAN does not need to be operational in order to solve this problem. So to summarize: * In IS-IS padded hellos is the current solution to b) * And you are proposing in Trill unpadded hellos is the solution to a) * Both a) and b) must be solved in Trill So we have deadlock. That is why some of us suggested a while ago that another solution to a) outside using IS-IS Hellos is preferable. I know that makes it inconvenient because IS-IS has a really easy way to announce itself over a LAN using Hellos. It is oh so close. It works most of the time. But re-engineering IS-IS hellos to solve a) means you now need a solution for b) where you already had one.. To break the deadlock the solution in a) and b) must be decoupled and I have seen little evidence that IS-IS people are clamoring to change the current solution for b). So the sooner we agree that a) should be solved outside of IS-IS Hellos (and I'm not saying how just why), then I think we could make progress. Regards, Don Radia Perlman wrote: > Suresh, > > I agree that it would be good to solve both problems: > > a) ensure that RBridges see each other (unpadded Hellos is the the > solution > that has been proposed), and > > b) some mechanism to assure there is agreement about what the > campus-wide MTU size should be, > and assure that the paths computed only include links that meet that > MTU size. > > It would not be difficult (technically) to solve b) but a) is more > important, so I can live with > deferring b) and shipping the spec. > > If people would like solve b) now, then fine, I'm sure we can come up > with > a mechanism to do that. But we have to ensure that that mechanism does > not interfere in > any way with a). > > The problem is that discussing both problems at the same time seems to > be confusing people. > > I think we should agree on this thread that we need to do unpadded > Hellos to solve problem a), and > start a second thread about what to do about problem b), e.g., "ignore > it", "defer it until > later", or "here's a candidate solution". > > Radia > > > > > > > > Suresh Boddapati wrote: >> --- On Fri, 4/10/09, Radia Perlman wrote: >> >> >>> Not padding hellos does not "break IS-IS". >> >> I am not completely sure. Please correct me if I am wrong. >> Let me see if I can construct an example. >> 1 >> A--------B >> \ / >> 1 \ / 5 >> \ C / >> >> The numbers are the respective cost on the links. >> >> Now suppose A has a smaller MTU such that it can see B's and C's >> hellos and form adjacencies with them. Now B's LSP that describes the >> link to A happens to be larger than the MTU that A uses on its links. >> This LSP does not get through to A from either B or C. Consider that >> the LSP that B uses to describe the link to C is within the MTU >> limits and does get through. >> Since A does not see B's LSP describing the link to A, it will >> compute a path to B through C. >> >> C sees both A's and B's LSPs and determines that the shortest path to >> B is through A (note A and B have both advertised their link in their >> respective LSPs, so the bidirectionality check would pass, it's just >> that A does not have B's LSP, so it cannot compute the path >> correctly). You have basically prevented A from being able to get to >> all destinations that can be reached through B and you have a loop of >> a different kind. This loop will not go away. The fix in IS-IS for >> this is to use padded hellos. If you pad, adjacencies wont form >> between A and B and everything will be fine. >> In TRILL, if you eliminate the padding, you have a TRILL forwarding >> loop and every frame sent by A to B or anything reachable through B >> will die in this loop once the hop count reaches zero. I recognize >> the fact that this is not as bad as the case when RBridges do not see >> each other, but is this the "weirdness" you say we could live with? >> IMO, we should make every effort to not have this situation. >> Debugging this could be real fun. And this is just one example of >> things going wrong. CSNPs may not get through. Or it is possible they >> do get through, but the LSPs dont, resulting in constant flooding of >> those LSPs on those links. >> >> >>> So, repeating for the nth time.... >>> Keeping the Hello mechanism exactly as it is in IS-IS today >>> will not work for TRILL. >>> That should be the end of discussion. Not padding the >>> Hellos obviously >>> works for robustly finding neighbors, and is a trivial >>> change. The >>> only thing that gets lost is MTU discovery. >>> >>> The only feasible choices at this point are: >>> a) only do unpadded Hellos, and live with weirdnesses due >>> to not >>> testing MTU size, deferring MTU discovery to the future >>> b) do unpadded Hellos, and come up with a mechanism for MTU >>> discovery now. >>> It would be easy to do so. >>> >>> >> I would prefer to go with an option that ensures that no LSPs get >> lost silently due to MTU issues. >> Thanks, >> >> Suresh >> > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > From d3e3e3 at gmail.com Fri Apr 10 19:43:29 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 10 Apr 2009 22:43:29 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49DFF793.4090600@gmail.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> Message-ID: <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> Hi Don, The way I would characterize the problem is as follows: There have to be two different messages. (Actually, it's at least two, since you can always come up with even more complex schemes.) Consider the follows two possible pairs of messages: (1) Use padded Hellos for MTU. Now you have to add a short message for safety. Unfortunately, this short message has to be a fairly complex short message with many fields that are the same as a Hello and has to participate in various Hello mechanisms. (2) Use unpadded Hellos for safety. Now you have to add a padded message for MTU but MTU message can be a simple ping like message. Alternative 1 sure sounds more complex to me. Donald On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk wrote: > Hi Radia > > b) is a not side issue. ? ?Problem b) is characterized by ensuring the > minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills > LSP up to the minimum MTU as part of its operation. ?Initially when there is > not much information to exchange the frame size is small, but as information > gets added the LSPs grows to the minimum MTU size then IS-IS fragments them. > ?So if you are not sure the minimum MTU limit is supported everywhere and > continuously monitored then the probability increases there will be missing > LSPs. ?Missing LSPs is a big problem. ?b) is therefore a problem for proper > operation of Trill too. > > In IS-IS where b) is the problem, ?padding Hellos is the current solution > and it safeguards IS-IS. ?Missing Hellos take down the adjacency (ie become > unaware of any other IS-IS capable systems on the link) ?if the minimum MTU > is not supported (cut off the link to save the rest of the network network). > ? It is also a good thing to have the initial packet you send fail the > minimum MTU check if it is going to fail. It makes little sense to exchange > messages further for IS-IS operation. > > Problem a) Is a problem characterized by knowing all RBridges attached to a > common LAN for correct operation of ?the LAN and the RBridges. ?IS-IS > between the RBridges on the LAN does not need to be operational in order to > solve this ?problem. > > So to summarize: > > ? * In IS-IS padded hellos is the current solution to b) ? * And you are > proposing in Trill ?unpadded hellos is the solution to a) > ? * Both a) and b) must be solved in Trill > > So we have deadlock. > > That is why some of us suggested a while ago that another solution to a) > ?outside using IS-IS Hellos is preferable. ? I know that makes it > inconvenient because IS-IS has a really easy way to announce itself over a > LAN using Hellos. It is oh so close. It works most of the time. ?But > re-engineering IS-IS hellos to solve a) means you now need a solution for b) > where you already had one.. > > To break the deadlock the solution in a) and b) must be decoupled and I have > seen little evidence that IS-IS people are clamoring to change the current > solution for b). ?So the sooner we agree that a) should be solved outside of > IS-IS Hellos (and I'm not saying how just why), then I think we could make > progress. > > Regards, > Don > > Radia Perlman wrote: >> >> Suresh, >> >> I agree that it would be good to solve both problems: >> >> a) ensure that RBridges see each other (unpadded Hellos is the the >> solution >> that has been proposed), and >> >> b) some mechanism to assure there is agreement about what the campus-wide >> MTU size should be, >> and assure that the paths computed only include links that meet that MTU >> size. >> >> It would not be difficult (technically) to solve b) but a) is more >> important, so I can live with >> deferring b) and shipping the spec. >> >> If people would like solve b) now, then fine, I'm sure we can come up with >> a mechanism to do that. But we have to ensure that that mechanism does not >> interfere in >> any way with a). >> >> The problem is that discussing both problems at the same time seems to be >> confusing people. >> >> I think we should agree on this thread that we need to do unpadded Hellos >> to solve problem a), and >> start a second thread about what to do about problem b), e.g., "ignore >> it", "defer it until >> later", or "here's a candidate solution". >> >> Radia >> >> >> >> >> >> >> >> Suresh Boddapati wrote: >>> >>> --- On Fri, 4/10/09, Radia Perlman wrote: >>> >>> >>>> >>>> Not padding hellos does not "break IS-IS". >>> >>> I am not completely sure. Please correct me if I am wrong. >>> Let me see if I can construct an example. >>> ? ? ? ? 1 >>> ?A--------B >>> ?\ ? ? ? / >>> 1 \ ? ? / 5 >>> ? \ C / >>> >>> The numbers are the respective cost on the links. >>> >>> Now suppose A has a smaller MTU such that it can see B's and C's hellos >>> and form adjacencies with them. Now B's LSP that describes the link to A >>> happens to be larger than the MTU that A uses on its links. This LSP does >>> not get through to A from either B or C. Consider that the LSP that B uses >>> to describe the link to C is within the MTU limits and does get through. >>> Since A does not see B's LSP describing the link to A, it will compute a >>> path to B through C. >>> >>> C sees both A's and B's LSPs and determines that the shortest path to B >>> is through A (note A and B have both advertised their link in their >>> respective LSPs, so the bidirectionality check would pass, it's just that A >>> does not have B's LSP, so it cannot compute the path correctly). You have >>> basically prevented A from being able to get to all destinations that can be >>> reached through B and you have a loop of a different kind. This loop will >>> not go away. The fix in IS-IS for this is to use padded hellos. If you pad, >>> adjacencies wont form between A and B and everything will be fine. >>> In TRILL, if you eliminate the padding, you have a TRILL forwarding loop >>> and every frame sent by A to B or anything reachable through B will die in >>> this loop once the hop count reaches zero. I recognize the fact that this is >>> not as bad as the case when RBridges do not see each other, but is this the >>> "weirdness" you say we could live with? IMO, we should make every effort to >>> not have this situation. Debugging this could be real fun. And this is just >>> one example of things going wrong. CSNPs may not get through. Or it is >>> possible they do get through, but the LSPs dont, resulting in constant >>> flooding of those LSPs on those links. >>> >>> >>>> >>>> So, repeating for the nth time.... >>>> Keeping the Hello mechanism exactly as it is in IS-IS today >>>> will not work for TRILL. >>>> That should be the end of discussion. Not padding the >>>> Hellos obviously >>>> works for robustly finding neighbors, and is a trivial >>>> change. The >>>> only thing that gets lost is MTU discovery. >>>> >>>> The only feasible choices at this point are: >>>> a) only do unpadded Hellos, and live with weirdnesses due >>>> to not >>>> testing MTU size, deferring MTU discovery to the future >>>> b) do unpadded Hellos, and come up with a mechanism for MTU >>>> discovery now. >>>> It would be easy to do so. >>>> >>>> >>> >>> I would prefer to go with an option that ensures that no LSPs get lost >>> silently due to MTU issues. >>> Thanks, >>> >>> Suresh >>> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> > > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > -- ============================= 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 Fri Apr 10 22:23:01 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 10 Apr 2009 22:23:01 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> Message-ID: <49E02935.5000805@sun.com> Yes, what Donald Eastlake said is right. I think there are several things confusing people: a) the subject line of this thread, which is a discussion having little to do with the subject line b) calling both "neighbor discovery" messages and "MTU probes" "Hellos". Frankly, "Hello" is not a particularly descriptive name for either thing, and it was probably my fault for calling it that 30 years ago. I suggest we call neither one of them "Hello"s. c) discussing both mechanisms (neighbor discovery, and MTU probing) in the same thread. Layer 3 IS-IS happened to solve both problems (nbr discovery and MTU discovery) with the same message type, and one mechanism that somehow did them both. We've established that TRILL can't get away with that. So we need one protocol for neighbor discovery and one for MTU discovery. As I said, using the nondescriptive term "Hello" is confusing people, so I suggest we use the terms "neighbor discovery message" and "MTU probe/ack" for the message names. Nobody has claimed that unpadded Hellos does not safely and simply accomplish neighbor discovery. I think we should put "neighbor discovery" to bed at this point, perhaps renaming the message in the spec from "Hello" to "neighbor discovery message", which would be bit-wise identical to the thing we were calling an "unpadded Hello" or a "protective Hello". And start up a new thread for MTU discovery. I suspect people really are not happy with "ignore the problem" or even "defer the problem". If the chairs think that is not necessarily true, and the WG might prefer "ignore" or "defer" MTU discovery, I suggest we have a different thread with a subject line "should we bother doing MTU discovery". Assuming the WG does want to solve MTU discovery, we should do so. It will not be technically difficult. It will involve some simple pinging thing with padded messages. I propose we not call those messages "padded Hellos", but instead call them "MTU probe". Radia Donald Eastlake wrote: > Hi Don, > > The way I would characterize the problem is as follows: > There have to be two different messages. (Actually, it's at least > two, since you can always come up with even more complex schemes.) > Consider the follows two possible pairs of messages: > (1) Use padded Hellos for MTU. Now you have to add a short > message for safety. Unfortunately, this short message has to be a > fairly complex short message with many fields that are the same as a > Hello and has to participate in various Hello mechanisms. > (2) Use unpadded Hellos for safety. Now you have to add a padded > message for MTU but MTU message can be a simple ping like message. > > Alternative 1 sure sounds more complex to me. > > Donald > > On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk wrote: > >> Hi Radia >> >> b) is a not side issue. Problem b) is characterized by ensuring the >> minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills >> LSP up to the minimum MTU as part of its operation. Initially when there is >> not much information to exchange the frame size is small, but as information >> gets added the LSPs grows to the minimum MTU size then IS-IS fragments them. >> So if you are not sure the minimum MTU limit is supported everywhere and >> continuously monitored then the probability increases there will be missing >> LSPs. Missing LSPs is a big problem. b) is therefore a problem for proper >> operation of Trill too. >> >> In IS-IS where b) is the problem, padding Hellos is the current solution >> and it safeguards IS-IS. Missing Hellos take down the adjacency (ie become >> unaware of any other IS-IS capable systems on the link) if the minimum MTU >> is not supported (cut off the link to save the rest of the network network). >> It is also a good thing to have the initial packet you send fail the >> minimum MTU check if it is going to fail. It makes little sense to exchange >> messages further for IS-IS operation. >> >> Problem a) Is a problem characterized by knowing all RBridges attached to a >> common LAN for correct operation of the LAN and the RBridges. IS-IS >> between the RBridges on the LAN does not need to be operational in order to >> solve this problem. >> >> So to summarize: >> >> * In IS-IS padded hellos is the current solution to b) * And you are >> proposing in Trill unpadded hellos is the solution to a) >> * Both a) and b) must be solved in Trill >> >> So we have deadlock. >> >> That is why some of us suggested a while ago that another solution to a) >> outside using IS-IS Hellos is preferable. I know that makes it >> inconvenient because IS-IS has a really easy way to announce itself over a >> LAN using Hellos. It is oh so close. It works most of the time. But >> re-engineering IS-IS hellos to solve a) means you now need a solution for b) >> where you already had one.. >> >> To break the deadlock the solution in a) and b) must be decoupled and I have >> seen little evidence that IS-IS people are clamoring to change the current >> solution for b). So the sooner we agree that a) should be solved outside of >> IS-IS Hellos (and I'm not saying how just why), then I think we could make >> progress. >> >> Regards, >> Don >> >> Radia Perlman wrote: >> >>> Suresh, >>> >>> I agree that it would be good to solve both problems: >>> >>> a) ensure that RBridges see each other (unpadded Hellos is the the >>> solution >>> that has been proposed), and >>> >>> b) some mechanism to assure there is agreement about what the campus-wide >>> MTU size should be, >>> and assure that the paths computed only include links that meet that MTU >>> size. >>> >>> It would not be difficult (technically) to solve b) but a) is more >>> important, so I can live with >>> deferring b) and shipping the spec. >>> >>> If people would like solve b) now, then fine, I'm sure we can come up with >>> a mechanism to do that. But we have to ensure that that mechanism does not >>> interfere in >>> any way with a). >>> >>> The problem is that discussing both problems at the same time seems to be >>> confusing people. >>> >>> I think we should agree on this thread that we need to do unpadded Hellos >>> to solve problem a), and >>> start a second thread about what to do about problem b), e.g., "ignore >>> it", "defer it until >>> later", or "here's a candidate solution". >>> >>> Radia >>> >>> >>> >>> >>> >>> >>> >>> Suresh Boddapati wrote: >>> >>>> --- On Fri, 4/10/09, Radia Perlman wrote: >>>> >>>> >>>> >>>>> Not padding hellos does not "break IS-IS". >>>>> >>>> I am not completely sure. Please correct me if I am wrong. >>>> Let me see if I can construct an example. >>>> 1 >>>> A--------B >>>> \ / >>>> 1 \ / 5 >>>> \ C / >>>> >>>> The numbers are the respective cost on the links. >>>> >>>> Now suppose A has a smaller MTU such that it can see B's and C's hellos >>>> and form adjacencies with them. Now B's LSP that describes the link to A >>>> happens to be larger than the MTU that A uses on its links. This LSP does >>>> not get through to A from either B or C. Consider that the LSP that B uses >>>> to describe the link to C is within the MTU limits and does get through. >>>> Since A does not see B's LSP describing the link to A, it will compute a >>>> path to B through C. >>>> >>>> C sees both A's and B's LSPs and determines that the shortest path to B >>>> is through A (note A and B have both advertised their link in their >>>> respective LSPs, so the bidirectionality check would pass, it's just that A >>>> does not have B's LSP, so it cannot compute the path correctly). You have >>>> basically prevented A from being able to get to all destinations that can be >>>> reached through B and you have a loop of a different kind. This loop will >>>> not go away. The fix in IS-IS for this is to use padded hellos. If you pad, >>>> adjacencies wont form between A and B and everything will be fine. >>>> In TRILL, if you eliminate the padding, you have a TRILL forwarding loop >>>> and every frame sent by A to B or anything reachable through B will die in >>>> this loop once the hop count reaches zero. I recognize the fact that this is >>>> not as bad as the case when RBridges do not see each other, but is this the >>>> "weirdness" you say we could live with? IMO, we should make every effort to >>>> not have this situation. Debugging this could be real fun. And this is just >>>> one example of things going wrong. CSNPs may not get through. Or it is >>>> possible they do get through, but the LSPs dont, resulting in constant >>>> flooding of those LSPs on those links. >>>> >>>> >>>> >>>>> So, repeating for the nth time.... >>>>> Keeping the Hello mechanism exactly as it is in IS-IS today >>>>> will not work for TRILL. >>>>> That should be the end of discussion. Not padding the >>>>> Hellos obviously >>>>> works for robustly finding neighbors, and is a trivial >>>>> change. The >>>>> only thing that gets lost is MTU discovery. >>>>> >>>>> The only feasible choices at this point are: >>>>> a) only do unpadded Hellos, and live with weirdnesses due >>>>> to not >>>>> testing MTU size, deferring MTU discovery to the future >>>>> b) do unpadded Hellos, and come up with a mechanism for MTU >>>>> discovery now. >>>>> It would be easy to do so. >>>>> >>>>> >>>>> >>>> I would prefer to go with an option that ensures that no LSPs get lost >>>> silently due to MTU issues. >>>> Thanks, >>>> >>>> Suresh >>>> >>>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> > > > > From eric.gray at ericsson.com Sat Apr 11 00:06:46 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Sat, 11 Apr 2009 02:06:46 -0500 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com><49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04F6486A@eusrcmw721.eamcs.ericsson.se> Donald, First of all, you're not characterizing the problem; you're characterizing possible solution choices to the problem. And, I don't think you've characterized the choice correctly, or perhaps it is more accurate to say that you've chosen a specific characterization that is not necessarily the most appropriate one in light of the many aspects of the current discussion. I would characterize the choices as follows: 1) Use padded Hellos for consistency with currently specified IS-IS. With this choice, you also need to add a short message for loop (and duplicate delivery) protection. This short message might be fairly complex (with many fields the same as a hello PDU, and the need to process this message consistent with hello processing) or as simple as a message that says "I am a version 1 TRILL Rbridge." In the latter case, the protocol specification needs to describe how DRB election takes place if a device is detected that says it is a version 1 RBridge but no hello messages are received. 2) Use unpadded Hello messages for safety. Now you might add a simple padded message for MTU, provided that you can do so and still end up with the protection for control plane message relaying that has previously been afforded IS-IS via padding of hello PDUs. This could and up being as complex as re-invention of IS-IS protocol. In this characterization, it is signficantly less clear that choice 1 is the more complex choice. Yet, if you think it through, you should realize that this is a more accurate characterization of the choices. -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake Sent: Friday, April 10, 2009 10:43 PM To: Don Fedyk Cc: TRILL/RBridge Working Group; Radia Perlman; isis-wg at ietf.org Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important? Hi Don, The way I would characterize the problem is as follows: There have to be two different messages. (Actually, it's at least two, since you can always come up with even more complex schemes.) Consider the follows two possible pairs of messages: (1) Use padded Hellos for MTU. Now you have to add a short message for safety. Unfortunately, this short message has to be a fairly complex short message with many fields that are the same as a Hello and has to participate in various Hello mechanisms. (2) Use unpadded Hellos for safety. Now you have to add a padded message for MTU but MTU message can be a simple ping like message. Alternative 1 sure sounds more complex to me. Donald On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk wrote: > Hi Radia > > b) is a not side issue. ? ?Problem b) is characterized by ensuring the > minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills > LSP up to the minimum MTU as part of its operation. ?Initially when there is > not much information to exchange the frame size is small, but as information > gets added the LSPs grows to the minimum MTU size then IS-IS fragments them. > ?So if you are not sure the minimum MTU limit is supported everywhere and > continuously monitored then the probability increases there will be missing > LSPs. ?Missing LSPs is a big problem. ?b) is therefore a problem for proper > operation of Trill too. > > In IS-IS where b) is the problem, ?padding Hellos is the current solution > and it safeguards IS-IS. ?Missing Hellos take down the adjacency (ie become > unaware of any other IS-IS capable systems on the link) ?if the minimum MTU > is not supported (cut off the link to save the rest of the network network). > ? It is also a good thing to have the initial packet you send fail the > minimum MTU check if it is going to fail. It makes little sense to exchange > messages further for IS-IS operation. > > Problem a) Is a problem characterized by knowing all RBridges attached to a > common LAN for correct operation of ?the LAN and the RBridges. ?IS-IS > between the RBridges on the LAN does not need to be operational in order to > solve this ?problem. > > So to summarize: > > ? * In IS-IS padded hellos is the current solution to b) ? * And you are > proposing in Trill ?unpadded hellos is the solution to a) > ? * Both a) and b) must be solved in Trill > > So we have deadlock. > > That is why some of us suggested a while ago that another solution to a) > ?outside using IS-IS Hellos is preferable. ? I know that makes it > inconvenient because IS-IS has a really easy way to announce itself over a > LAN using Hellos. It is oh so close. It works most of the time. ?But > re-engineering IS-IS hellos to solve a) means you now need a solution for b) > where you already had one.. > > To break the deadlock the solution in a) and b) must be decoupled and I have > seen little evidence that IS-IS people are clamoring to change the current > solution for b). ?So the sooner we agree that a) should be solved outside of > IS-IS Hellos (and I'm not saying how just why), then I think we could make > progress. > > Regards, > Don > > Radia Perlman wrote: >> >> Suresh, >> >> I agree that it would be good to solve both problems: >> >> a) ensure that RBridges see each other (unpadded Hellos is the the >> solution >> that has been proposed), and >> >> b) some mechanism to assure there is agreement about what the campus-wide >> MTU size should be, >> and assure that the paths computed only include links that meet that MTU >> size. >> >> It would not be difficult (technically) to solve b) but a) is more >> important, so I can live with >> deferring b) and shipping the spec. >> >> If people would like solve b) now, then fine, I'm sure we can come up with >> a mechanism to do that. But we have to ensure that that mechanism does not >> interfere in >> any way with a). >> >> The problem is that discussing both problems at the same time seems to be >> confusing people. >> >> I think we should agree on this thread that we need to do unpadded Hellos >> to solve problem a), and >> start a second thread about what to do about problem b), e.g., "ignore >> it", "defer it until >> later", or "here's a candidate solution". >> >> Radia >> >> >> >> >> >> >> >> Suresh Boddapati wrote: >>> >>> --- On Fri, 4/10/09, Radia Perlman wrote: >>> >>> >>>> >>>> Not padding hellos does not "break IS-IS". >>> >>> I am not completely sure. Please correct me if I am wrong. >>> Let me see if I can construct an example. >>> ? ? ? ? 1 >>> ?A--------B >>> ?\ ? ? ? / >>> 1 \ ? ? / 5 >>> ? \ C / >>> >>> The numbers are the respective cost on the links. >>> >>> Now suppose A has a smaller MTU such that it can see B's and C's hellos >>> and form adjacencies with them. Now B's LSP that describes the link to A >>> happens to be larger than the MTU that A uses on its links. This LSP does >>> not get through to A from either B or C. Consider that the LSP that B uses >>> to describe the link to C is within the MTU limits and does get through. >>> Since A does not see B's LSP describing the link to A, it will compute a >>> path to B through C. >>> >>> C sees both A's and B's LSPs and determines that the shortest path to B >>> is through A (note A and B have both advertised their link in their >>> respective LSPs, so the bidirectionality check would pass, it's just that A >>> does not have B's LSP, so it cannot compute the path correctly). You have >>> basically prevented A from being able to get to all destinations that can be >>> reached through B and you have a loop of a different kind. This loop will >>> not go away. The fix in IS-IS for this is to use padded hellos. If you pad, >>> adjacencies wont form between A and B and everything will be fine. >>> In TRILL, if you eliminate the padding, you have a TRILL forwarding loop >>> and every frame sent by A to B or anything reachable through B will die in >>> this loop once the hop count reaches zero. I recognize the fact that this is >>> not as bad as the case when RBridges do not see each other, but is this the >>> "weirdness" you say we could live with? IMO, we should make every effort to >>> not have this situation. Debugging this could be real fun. And this is just >>> one example of things going wrong. CSNPs may not get through. Or it is >>> possible they do get through, but the LSPs dont, resulting in constant >>> flooding of those LSPs on those links. >>> >>> >>>> >>>> So, repeating for the nth time.... >>>> Keeping the Hello mechanism exactly as it is in IS-IS today >>>> will not work for TRILL. >>>> That should be the end of discussion. Not padding the >>>> Hellos obviously >>>> works for robustly finding neighbors, and is a trivial >>>> change. The >>>> only thing that gets lost is MTU discovery. >>>> >>>> The only feasible choices at this point are: >>>> a) only do unpadded Hellos, and live with weirdnesses due >>>> to not >>>> testing MTU size, deferring MTU discovery to the future >>>> b) do unpadded Hellos, and come up with a mechanism for MTU >>>> discovery now. >>>> It would be easy to do so. >>>> >>>> >>> >>> I would prefer to go with an option that ensures that no LSPs get lost >>> silently due to MTU issues. >>> Thanks, >>> >>> Suresh >>> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> > > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From eric.gray at ericsson.com Sat Apr 11 00:11:34 2009 From: eric.gray at ericsson.com (Eric Gray) Date: Sat, 11 Apr 2009 02:11:34 -0500 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E02935.5000805@sun.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com><49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com><1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04F6486D@eusrcmw721.eamcs.ericsson.se> Radia, No, what Donald Eastlake said is not "right"; it is one possible view of the choices for dealing with the problem, but that does not make it necessarily the "right" view. -- Eric -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Saturday, April 11, 2009 1:23 AM To: Donald Eastlake Cc: TRILL/RBridge Working Group; isis-wg at ietf.org Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important? Yes, what Donald Eastlake said is right. I think there are several things confusing people: a) the subject line of this thread, which is a discussion having little to do with the subject line b) calling both "neighbor discovery" messages and "MTU probes" "Hellos". Frankly, "Hello" is not a particularly descriptive name for either thing, and it was probably my fault for calling it that 30 years ago. I suggest we call neither one of them "Hello"s. c) discussing both mechanisms (neighbor discovery, and MTU probing) in the same thread. Layer 3 IS-IS happened to solve both problems (nbr discovery and MTU discovery) with the same message type, and one mechanism that somehow did them both. We've established that TRILL can't get away with that. So we need one protocol for neighbor discovery and one for MTU discovery. As I said, using the nondescriptive term "Hello" is confusing people, so I suggest we use the terms "neighbor discovery message" and "MTU probe/ack" for the message names. Nobody has claimed that unpadded Hellos does not safely and simply accomplish neighbor discovery. I think we should put "neighbor discovery" to bed at this point, perhaps renaming the message in the spec from "Hello" to "neighbor discovery message", which would be bit-wise identical to the thing we were calling an "unpadded Hello" or a "protective Hello". And start up a new thread for MTU discovery. I suspect people really are not happy with "ignore the problem" or even "defer the problem". If the chairs think that is not necessarily true, and the WG might prefer "ignore" or "defer" MTU discovery, I suggest we have a different thread with a subject line "should we bother doing MTU discovery". Assuming the WG does want to solve MTU discovery, we should do so. It will not be technically difficult. It will involve some simple pinging thing with padded messages. I propose we not call those messages "padded Hellos", but instead call them "MTU probe". Radia Donald Eastlake wrote: > Hi Don, > > The way I would characterize the problem is as follows: > There have to be two different messages. (Actually, it's at least > two, since you can always come up with even more complex schemes.) > Consider the follows two possible pairs of messages: > (1) Use padded Hellos for MTU. Now you have to add a short > message for safety. Unfortunately, this short message has to be a > fairly complex short message with many fields that are the same as a > Hello and has to participate in various Hello mechanisms. > (2) Use unpadded Hellos for safety. Now you have to add a padded > message for MTU but MTU message can be a simple ping like message. > > Alternative 1 sure sounds more complex to me. > > Donald > > On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk wrote: > >> Hi Radia >> >> b) is a not side issue. Problem b) is characterized by ensuring the >> minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills >> LSP up to the minimum MTU as part of its operation. Initially when there is >> not much information to exchange the frame size is small, but as information >> gets added the LSPs grows to the minimum MTU size then IS-IS fragments them. >> So if you are not sure the minimum MTU limit is supported everywhere and >> continuously monitored then the probability increases there will be missing >> LSPs. Missing LSPs is a big problem. b) is therefore a problem for proper >> operation of Trill too. >> >> In IS-IS where b) is the problem, padding Hellos is the current solution >> and it safeguards IS-IS. Missing Hellos take down the adjacency (ie become >> unaware of any other IS-IS capable systems on the link) if the minimum MTU >> is not supported (cut off the link to save the rest of the network network). >> It is also a good thing to have the initial packet you send fail the >> minimum MTU check if it is going to fail. It makes little sense to exchange >> messages further for IS-IS operation. >> >> Problem a) Is a problem characterized by knowing all RBridges attached to a >> common LAN for correct operation of the LAN and the RBridges. IS-IS >> between the RBridges on the LAN does not need to be operational in order to >> solve this problem. >> >> So to summarize: >> >> * In IS-IS padded hellos is the current solution to b) * And you are >> proposing in Trill unpadded hellos is the solution to a) >> * Both a) and b) must be solved in Trill >> >> So we have deadlock. >> >> That is why some of us suggested a while ago that another solution to a) >> outside using IS-IS Hellos is preferable. I know that makes it >> inconvenient because IS-IS has a really easy way to announce itself over a >> LAN using Hellos. It is oh so close. It works most of the time. But >> re-engineering IS-IS hellos to solve a) means you now need a solution for b) >> where you already had one.. >> >> To break the deadlock the solution in a) and b) must be decoupled and I have >> seen little evidence that IS-IS people are clamoring to change the current >> solution for b). So the sooner we agree that a) should be solved outside of >> IS-IS Hellos (and I'm not saying how just why), then I think we could make >> progress. >> >> Regards, >> Don >> >> Radia Perlman wrote: >> >>> Suresh, >>> >>> I agree that it would be good to solve both problems: >>> >>> a) ensure that RBridges see each other (unpadded Hellos is the the >>> solution >>> that has been proposed), and >>> >>> b) some mechanism to assure there is agreement about what the campus-wide >>> MTU size should be, >>> and assure that the paths computed only include links that meet that MTU >>> size. >>> >>> It would not be difficult (technically) to solve b) but a) is more >>> important, so I can live with >>> deferring b) and shipping the spec. >>> >>> If people would like solve b) now, then fine, I'm sure we can come up with >>> a mechanism to do that. But we have to ensure that that mechanism does not >>> interfere in >>> any way with a). >>> >>> The problem is that discussing both problems at the same time seems to be >>> confusing people. >>> >>> I think we should agree on this thread that we need to do unpadded Hellos >>> to solve problem a), and >>> start a second thread about what to do about problem b), e.g., "ignore >>> it", "defer it until >>> later", or "here's a candidate solution". >>> >>> Radia >>> >>> >>> >>> >>> >>> >>> >>> Suresh Boddapati wrote: >>> >>>> --- On Fri, 4/10/09, Radia Perlman wrote: >>>> >>>> >>>> >>>>> Not padding hellos does not "break IS-IS". >>>>> >>>> I am not completely sure. Please correct me if I am wrong. >>>> Let me see if I can construct an example. >>>> 1 >>>> A--------B >>>> \ / >>>> 1 \ / 5 >>>> \ C / >>>> >>>> The numbers are the respective cost on the links. >>>> >>>> Now suppose A has a smaller MTU such that it can see B's and C's hellos >>>> and form adjacencies with them. Now B's LSP that describes the link to A >>>> happens to be larger than the MTU that A uses on its links. This LSP does >>>> not get through to A from either B or C. Consider that the LSP that B uses >>>> to describe the link to C is within the MTU limits and does get through. >>>> Since A does not see B's LSP describing the link to A, it will compute a >>>> path to B through C. >>>> >>>> C sees both A's and B's LSPs and determines that the shortest path to B >>>> is through A (note A and B have both advertised their link in their >>>> respective LSPs, so the bidirectionality check would pass, it's just that A >>>> does not have B's LSP, so it cannot compute the path correctly). You have >>>> basically prevented A from being able to get to all destinations that can be >>>> reached through B and you have a loop of a different kind. This loop will >>>> not go away. The fix in IS-IS for this is to use padded hellos. If you pad, >>>> adjacencies wont form between A and B and everything will be fine. >>>> In TRILL, if you eliminate the padding, you have a TRILL forwarding loop >>>> and every frame sent by A to B or anything reachable through B will die in >>>> this loop once the hop count reaches zero. I recognize the fact that this is >>>> not as bad as the case when RBridges do not see each other, but is this the >>>> "weirdness" you say we could live with? IMO, we should make every effort to >>>> not have this situation. Debugging this could be real fun. And this is just >>>> one example of things going wrong. CSNPs may not get through. Or it is >>>> possible they do get through, but the LSPs dont, resulting in constant >>>> flooding of those LSPs on those links. >>>> >>>> >>>> >>>>> So, repeating for the nth time.... >>>>> Keeping the Hello mechanism exactly as it is in IS-IS today >>>>> will not work for TRILL. >>>>> That should be the end of discussion. Not padding the >>>>> Hellos obviously >>>>> works for robustly finding neighbors, and is a trivial >>>>> change. The >>>>> only thing that gets lost is MTU discovery. >>>>> >>>>> The only feasible choices at this point are: >>>>> a) only do unpadded Hellos, and live with weirdnesses due >>>>> to not >>>>> testing MTU size, deferring MTU discovery to the future >>>>> b) do unpadded Hellos, and come up with a mechanism for MTU >>>>> discovery now. >>>>> It would be easy to do so. >>>>> >>>>> >>>>> >>>> I would prefer to go with an option that ensures that no LSPs get lost >>>> silently due to MTU issues. >>>> Thanks, >>>> >>>> Suresh >>>> >>>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> > > > > _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From mrthom at essex.ac.uk Sat Apr 11 01:59:07 2009 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Sat, 11 Apr 2009 09:59:07 +0100 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? References: <508896.66561.qm@web81305.mail.mud.yahoo.com><49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com><1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661DA753C9@sernt14.essex.ac.uk> Radia, Like I said, we need some state diagrams. ISIS has specific states and actions that move the 'neighbor, adjacency, foo from one state to another. These actions are also quite specific; like receiving a valid hello, missing various messages etc. Is an invalid hello even considered a hello? The states are well defined and inter-connected. Adjacency and neighbor are specific terms and as you point out in this thread we have probably not used them consistently and from some of the comments I expect we might not have used them accurately? With each new 'packet' / 'mechanism' there may be changes to these mechanisms and states. I think we need to display an understanding of the existing mechanisms, and the condition they leave the router in in each case. Each change to this system is considered a large change. MT ________________________________ From: isis-wg-bounces at ietf.org on behalf of Radia Perlman Sent: Sat 11/04/2009 06:23 To: Donald Eastlake Cc: TRILL/RBridge Working Group; isis-wg at ietf.org Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important? Yes, what Donald Eastlake said is right. I think there are several things confusing people: a) the subject line of this thread, which is a discussion having little to do with the subject line b) calling both "neighbor discovery" messages and "MTU probes" "Hellos". Frankly, "Hello" is not a particularly descriptive name for either thing, and it was probably my fault for calling it that 30 years ago. I suggest we call neither one of them "Hello"s. c) discussing both mechanisms (neighbor discovery, and MTU probing) in the same thread. Layer 3 IS-IS happened to solve both problems (nbr discovery and MTU discovery) with the same message type, and one mechanism that somehow did them both. We've established that TRILL can't get away with that. So we need one protocol for neighbor discovery and one for MTU discovery. As I said, using the nondescriptive term "Hello" is confusing people, so I suggest we use the terms "neighbor discovery message" and "MTU probe/ack" for the message names. Nobody has claimed that unpadded Hellos does not safely and simply accomplish neighbor discovery. I think we should put "neighbor discovery" to bed at this point, perhaps renaming the message in the spec from "Hello" to "neighbor discovery message", which would be bit-wise identical to the thing we were calling an "unpadded Hello" or a "protective Hello". And start up a new thread for MTU discovery. I suspect people really are not happy with "ignore the problem" or even "defer the problem". If the chairs think that is not necessarily true, and the WG might prefer "ignore" or "defer" MTU discovery, I suggest we have a different thread with a subject line "should we bother doing MTU discovery". Assuming the WG does want to solve MTU discovery, we should do so. It will not be technically difficult. It will involve some simple pinging thing with padded messages. I propose we not call those messages "padded Hellos", but instead call them "MTU probe". Radia Donald Eastlake wrote: > Hi Don, > > The way I would characterize the problem is as follows: > There have to be two different messages. (Actually, it's at least > two, since you can always come up with even more complex schemes.) > Consider the follows two possible pairs of messages: > (1) Use padded Hellos for MTU. Now you have to add a short > message for safety. Unfortunately, this short message has to be a > fairly complex short message with many fields that are the same as a > Hello and has to participate in various Hello mechanisms. > (2) Use unpadded Hellos for safety. Now you have to add a padded > message for MTU but MTU message can be a simple ping like message. > > Alternative 1 sure sounds more complex to me. > > Donald > > On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk wrote: > >> Hi Radia >> >> b) is a not side issue. Problem b) is characterized by ensuring the >> minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills >> LSP up to the minimum MTU as part of its operation. Initially when there is >> not much information to exchange the frame size is small, but as information >> gets added the LSPs grows to the minimum MTU size then IS-IS fragments them. >> So if you are not sure the minimum MTU limit is supported everywhere and >> continuously monitored then the probability increases there will be missing >> LSPs. Missing LSPs is a big problem. b) is therefore a problem for proper >> operation of Trill too. >> >> In IS-IS where b) is the problem, padding Hellos is the current solution >> and it safeguards IS-IS. Missing Hellos take down the adjacency (ie become >> unaware of any other IS-IS capable systems on the link) if the minimum MTU >> is not supported (cut off the link to save the rest of the network network). >> It is also a good thing to have the initial packet you send fail the >> minimum MTU check if it is going to fail. It makes little sense to exchange >> messages further for IS-IS operation. >> >> Problem a) Is a problem characterized by knowing all RBridges attached to a >> common LAN for correct operation of the LAN and the RBridges. IS-IS >> between the RBridges on the LAN does not need to be operational in order to >> solve this problem. >> >> So to summarize: >> >> * In IS-IS padded hellos is the current solution to b) * And you are >> proposing in Trill unpadded hellos is the solution to a) >> * Both a) and b) must be solved in Trill >> >> So we have deadlock. >> >> That is why some of us suggested a while ago that another solution to a) >> outside using IS-IS Hellos is preferable. I know that makes it >> inconvenient because IS-IS has a really easy way to announce itself over a >> LAN using Hellos. It is oh so close. It works most of the time. But >> re-engineering IS-IS hellos to solve a) means you now need a solution for b) >> where you already had one.. >> >> To break the deadlock the solution in a) and b) must be decoupled and I have >> seen little evidence that IS-IS people are clamoring to change the current >> solution for b). So the sooner we agree that a) should be solved outside of >> IS-IS Hellos (and I'm not saying how just why), then I think we could make >> progress. >> >> Regards, >> Don >> >> Radia Perlman wrote: >> >>> Suresh, >>> >>> I agree that it would be good to solve both problems: >>> >>> a) ensure that RBridges see each other (unpadded Hellos is the the >>> solution >>> that has been proposed), and >>> >>> b) some mechanism to assure there is agreement about what the campus-wide >>> MTU size should be, >>> and assure that the paths computed only include links that meet that MTU >>> size. >>> >>> It would not be difficult (technically) to solve b) but a) is more >>> important, so I can live with >>> deferring b) and shipping the spec. >>> >>> If people would like solve b) now, then fine, I'm sure we can come up with >>> a mechanism to do that. But we have to ensure that that mechanism does not >>> interfere in >>> any way with a). >>> >>> The problem is that discussing both problems at the same time seems to be >>> confusing people. >>> >>> I think we should agree on this thread that we need to do unpadded Hellos >>> to solve problem a), and >>> start a second thread about what to do about problem b), e.g., "ignore >>> it", "defer it until >>> later", or "here's a candidate solution". >>> >>> Radia >>> >>> >>> >>> >>> >>> >>> >>> Suresh Boddapati wrote: >>> >>>> --- On Fri, 4/10/09, Radia Perlman wrote: >>>> >>>> >>>> >>>>> Not padding hellos does not "break IS-IS". >>>>> >>>> I am not completely sure. Please correct me if I am wrong. >>>> Let me see if I can construct an example. >>>> 1 >>>> A--------B >>>> \ / >>>> 1 \ / 5 >>>> \ C / >>>> >>>> The numbers are the respective cost on the links. >>>> >>>> Now suppose A has a smaller MTU such that it can see B's and C's hellos >>>> and form adjacencies with them. Now B's LSP that describes the link to A >>>> happens to be larger than the MTU that A uses on its links. This LSP does >>>> not get through to A from either B or C. Consider that the LSP that B uses >>>> to describe the link to C is within the MTU limits and does get through. >>>> Since A does not see B's LSP describing the link to A, it will compute a >>>> path to B through C. >>>> >>>> C sees both A's and B's LSPs and determines that the shortest path to B >>>> is through A (note A and B have both advertised their link in their >>>> respective LSPs, so the bidirectionality check would pass, it's just that A >>>> does not have B's LSP, so it cannot compute the path correctly). You have >>>> basically prevented A from being able to get to all destinations that can be >>>> reached through B and you have a loop of a different kind. This loop will >>>> not go away. The fix in IS-IS for this is to use padded hellos. If you pad, >>>> adjacencies wont form between A and B and everything will be fine. >>>> In TRILL, if you eliminate the padding, you have a TRILL forwarding loop >>>> and every frame sent by A to B or anything reachable through B will die in >>>> this loop once the hop count reaches zero. I recognize the fact that this is >>>> not as bad as the case when RBridges do not see each other, but is this the >>>> "weirdness" you say we could live with? IMO, we should make every effort to >>>> not have this situation. Debugging this could be real fun. And this is just >>>> one example of things going wrong. CSNPs may not get through. Or it is >>>> possible they do get through, but the LSPs dont, resulting in constant >>>> flooding of those LSPs on those links. >>>> >>>> >>>> >>>>> So, repeating for the nth time.... >>>>> Keeping the Hello mechanism exactly as it is in IS-IS today >>>>> will not work for TRILL. >>>>> That should be the end of discussion. Not padding the >>>>> Hellos obviously >>>>> works for robustly finding neighbors, and is a trivial >>>>> change. The >>>>> only thing that gets lost is MTU discovery. >>>>> >>>>> The only feasible choices at this point are: >>>>> a) only do unpadded Hellos, and live with weirdnesses due >>>>> to not >>>>> testing MTU size, deferring MTU discovery to the future >>>>> b) do unpadded Hellos, and come up with a mechanism for MTU >>>>> discovery now. >>>>> It would be easy to do so. >>>>> >>>>> >>>>> >>>> I would prefer to go with an option that ensures that no LSPs get lost >>>> silently due to MTU issues. >>>> Thanks, >>>> >>>> Suresh >>>> >>>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> > > > > _______________________________________________ Isis-wg mailing list Isis-wg at ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From don.fedyk at gmail.com Sat Apr 11 08:01:07 2009 From: don.fedyk at gmail.com (Don Fedyk) Date: Sat, 11 Apr 2009 11:01:07 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E02935.5000805@sun.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> Message-ID: <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> Hi Radia Well you are correct that some of the terminology is imprecise. I don't agree with some of the characterization. I would agree we should use more precise terminology. I was actually being very precise my last couple of emails. (I hope people are still reading them.) We are dealing with two worlds here. Sorry it is not a level playing field: 1. IS-IS design and working system. 2. Trill proposals which leverage 1. In my books 1. current operation takes precedence because it is both problem and solution. It is deployed and working. So we can't just go in and change things and expect it to work with out careful analysis. But accurately describing what it is doing is a good idea. For 2. we have a problem that needs to be described. Let stick to the problem description. Define an "ideal" solution mechanism outside of IS-IS mecjhanisms and describe it with the same accuracy. Only then can we look at 1. and see what portions are applicable if any. Terms we need to agree on: "minimum MTU" or "The too small MTU Problem for IS-IS" "Neighbor Discovery" "IS-IS Adjacency" "RBridge Adjacency" "Number of RBridges that attached on a LAN" <- There is no equivalent for this in IS-IS "IS-IS Hello" "minimum MTU probing" "MTU discovery" <- Should not be used. IP does MTU discovery. IS-IS does not. Unfortunately _is_ the title of this thread! Regards, Don On Sat, Apr 11, 2009 at 1:23 AM, Radia Perlman wrote: > Yes, what Donald Eastlake said is right. > > I think there are several things confusing people: > > a) the subject line of this thread, which is a discussion having little to > do with the subject line > > b) calling both "neighbor discovery" messages and "MTU probes" "Hellos". > Frankly, "Hello" is not a particularly descriptive name for either thing, > and it was probably my fault for > calling it that 30 years ago. I suggest we call neither one of them > "Hello"s. > > c) discussing both mechanisms (neighbor discovery, and MTU probing) in the > same thread. > Layer 3 IS-IS happened to solve both problems (nbr discovery > and MTU discovery) with the same message type, and one > mechanism that somehow did them both. We've established that TRILL can't > get away with that. So we need one protocol for neighbor discovery and one > for MTU discovery. > As I said, using the nondescriptive term "Hello" is confusing people, so I > suggest we > use the terms "neighbor discovery message" and "MTU probe/ack" for the > message names. > > Nobody has claimed that unpadded Hellos does not safely and simply > accomplish neighbor > discovery. I think we should put "neighbor discovery" to bed at this point, > perhaps renaming > the message in the spec from "Hello" to "neighbor discovery message", which > would > be bit-wise identical to the thing we were calling an "unpadded Hello" or a > "protective Hello". > > And start up a new thread for MTU discovery. I suspect people really are > not happy with > "ignore the problem" or even "defer the problem". If the chairs think that > is not necessarily > true, and the WG might prefer "ignore" or "defer" MTU discovery, I suggest > we > have a different thread with a subject line "should we bother doing MTU > discovery". > > Assuming the WG does want to solve MTU discovery, we should do so. > It will not be technically difficult. > It will involve some simple pinging thing with padded messages. I propose > we > not call those messages "padded Hellos", but instead call them "MTU probe". > > Radia > > > > > > > > Donald Eastlake wrote: > >> Hi Don, >> >> The way I would characterize the problem is as follows: >> There have to be two different messages. (Actually, it's at least >> two, since you can always come up with even more complex schemes.) >> Consider the follows two possible pairs of messages: >> (1) Use padded Hellos for MTU. Now you have to add a short >> message for safety. Unfortunately, this short message has to be a >> fairly complex short message with many fields that are the same as a >> Hello and has to participate in various Hello mechanisms. >> (2) Use unpadded Hellos for safety. Now you have to add a padded >> message for MTU but MTU message can be a simple ping like message. >> >> Alternative 1 sure sounds more complex to me. >> >> Donald >> >> On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk wrote: >> >> >>> Hi Radia >>> >>> b) is a not side issue. Problem b) is characterized by ensuring the >>> minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills >>> LSP up to the minimum MTU as part of its operation. Initially when there >>> is >>> not much information to exchange the frame size is small, but as >>> information >>> gets added the LSPs grows to the minimum MTU size then IS-IS fragments >>> them. >>> So if you are not sure the minimum MTU limit is supported everywhere and >>> continuously monitored then the probability increases there will be >>> missing >>> LSPs. Missing LSPs is a big problem. b) is therefore a problem for >>> proper >>> operation of Trill too. >>> >>> In IS-IS where b) is the problem, padding Hellos is the current solution >>> and it safeguards IS-IS. Missing Hellos take down the adjacency (ie >>> become >>> unaware of any other IS-IS capable systems on the link) if the minimum >>> MTU >>> is not supported (cut off the link to save the rest of the network >>> network). >>> It is also a good thing to have the initial packet you send fail the >>> minimum MTU check if it is going to fail. It makes little sense to >>> exchange >>> messages further for IS-IS operation. >>> >>> Problem a) Is a problem characterized by knowing all RBridges attached to >>> a >>> common LAN for correct operation of the LAN and the RBridges. IS-IS >>> between the RBridges on the LAN does not need to be operational in order >>> to >>> solve this problem. >>> >>> So to summarize: >>> >>> * In IS-IS padded hellos is the current solution to b) * And you are >>> proposing in Trill unpadded hellos is the solution to a) >>> * Both a) and b) must be solved in Trill >>> >>> So we have deadlock. >>> >>> That is why some of us suggested a while ago that another solution to a) >>> outside using IS-IS Hellos is preferable. I know that makes it >>> inconvenient because IS-IS has a really easy way to announce itself over >>> a >>> LAN using Hellos. It is oh so close. It works most of the time. But >>> re-engineering IS-IS hellos to solve a) means you now need a solution for >>> b) >>> where you already had one.. >>> >>> To break the deadlock the solution in a) and b) must be decoupled and I >>> have >>> seen little evidence that IS-IS people are clamoring to change the >>> current >>> solution for b). So the sooner we agree that a) should be solved outside >>> of >>> IS-IS Hellos (and I'm not saying how just why), then I think we could >>> make >>> progress. >>> >>> Regards, >>> Don >>> >>> Radia Perlman wrote: >>> >>> >>>> Suresh, >>>> >>>> I agree that it would be good to solve both problems: >>>> >>>> a) ensure that RBridges see each other (unpadded Hellos is the the >>>> solution >>>> that has been proposed), and >>>> >>>> b) some mechanism to assure there is agreement about what the >>>> campus-wide >>>> MTU size should be, >>>> and assure that the paths computed only include links that meet that MTU >>>> size. >>>> >>>> It would not be difficult (technically) to solve b) but a) is more >>>> important, so I can live with >>>> deferring b) and shipping the spec. >>>> >>>> If people would like solve b) now, then fine, I'm sure we can come up >>>> with >>>> a mechanism to do that. But we have to ensure that that mechanism does >>>> not >>>> interfere in >>>> any way with a). >>>> >>>> The problem is that discussing both problems at the same time seems to >>>> be >>>> confusing people. >>>> >>>> I think we should agree on this thread that we need to do unpadded >>>> Hellos >>>> to solve problem a), and >>>> start a second thread about what to do about problem b), e.g., "ignore >>>> it", "defer it until >>>> later", or "here's a candidate solution". >>>> >>>> Radia >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Suresh Boddapati wrote: >>>> >>>> >>>>> --- On Fri, 4/10/09, Radia Perlman wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Not padding hellos does not "break IS-IS". >>>>>> >>>>>> >>>>> I am not completely sure. Please correct me if I am wrong. >>>>> Let me see if I can construct an example. >>>>> 1 >>>>> A--------B >>>>> \ / >>>>> 1 \ / 5 >>>>> \ C / >>>>> >>>>> The numbers are the respective cost on the links. >>>>> >>>>> Now suppose A has a smaller MTU such that it can see B's and C's hellos >>>>> and form adjacencies with them. Now B's LSP that describes the link to >>>>> A >>>>> happens to be larger than the MTU that A uses on its links. This LSP >>>>> does >>>>> not get through to A from either B or C. Consider that the LSP that B >>>>> uses >>>>> to describe the link to C is within the MTU limits and does get >>>>> through. >>>>> Since A does not see B's LSP describing the link to A, it will compute >>>>> a >>>>> path to B through C. >>>>> >>>>> C sees both A's and B's LSPs and determines that the shortest path to B >>>>> is through A (note A and B have both advertised their link in their >>>>> respective LSPs, so the bidirectionality check would pass, it's just >>>>> that A >>>>> does not have B's LSP, so it cannot compute the path correctly). You >>>>> have >>>>> basically prevented A from being able to get to all destinations that >>>>> can be >>>>> reached through B and you have a loop of a different kind. This loop >>>>> will >>>>> not go away. The fix in IS-IS for this is to use padded hellos. If you >>>>> pad, >>>>> adjacencies wont form between A and B and everything will be fine. >>>>> In TRILL, if you eliminate the padding, you have a TRILL forwarding >>>>> loop >>>>> and every frame sent by A to B or anything reachable through B will die >>>>> in >>>>> this loop once the hop count reaches zero. I recognize the fact that >>>>> this is >>>>> not as bad as the case when RBridges do not see each other, but is this >>>>> the >>>>> "weirdness" you say we could live with? IMO, we should make every >>>>> effort to >>>>> not have this situation. Debugging this could be real fun. And this is >>>>> just >>>>> one example of things going wrong. CSNPs may not get through. Or it is >>>>> possible they do get through, but the LSPs dont, resulting in constant >>>>> flooding of those LSPs on those links. >>>>> >>>>> >>>>> >>>>> >>>>>> So, repeating for the nth time.... >>>>>> Keeping the Hello mechanism exactly as it is in IS-IS today >>>>>> will not work for TRILL. >>>>>> That should be the end of discussion. Not padding the >>>>>> Hellos obviously >>>>>> works for robustly finding neighbors, and is a trivial >>>>>> change. The >>>>>> only thing that gets lost is MTU discovery. >>>>>> >>>>>> The only feasible choices at this point are: >>>>>> a) only do unpadded Hellos, and live with weirdnesses due >>>>>> to not >>>>>> testing MTU size, deferring MTU discovery to the future >>>>>> b) do unpadded Hellos, and come up with a mechanism for MTU >>>>>> discovery now. >>>>>> It would be easy to do so. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I would prefer to go with an option that ensures that no LSPs get lost >>>>> silently due to MTU issues. >>>>> Thanks, >>>>> >>>>> Suresh >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg at ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>> >>>> >>>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg at ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> >>> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090411/1ab8d8c1/attachment-0001.html From dward at cisco.com Sat Apr 11 14:39:11 2009 From: dward at cisco.com (David Ward) Date: Sat, 11 Apr 2009 16:39:11 -0500 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <0E0D366B-0EBD-4093-85D3-78EB4EA08297@juniper.net> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <0E0D366B-0EBD-4093-85D3-78EB4EA08297@juniper.net> Message-ID: Dave - At this point the primary extensions for TRILL are: - a new mcast PDU - a separate Hello on a new demux (at worst) These fit into the definition that you describe below. The other functions were agreed to be dropped and I hope that it remains the case or a new NLPID seems in order. I also prefer to keep this functionality as close to "IS-IS" as possible. -DWard On Apr 11, 2009, at 11:56 AM, Dave Katz wrote: > As someone who as been designing and coding this stuff since before > most of our current crop of engineers were born, I'll throw in some > practicalities: > > 1) The thing we call "IS-IS" that has a NLPID of 0x83 (IIRC) can > only be changed in an upward-compatible manner. So any proposal to > change anything in the existing L3 IS-IS beyond the addition of a > new PDU type is a non-starter (and even that is likely to break some > dubious implementations, which may or may not be a bad thing). > > 2) If TRILL ends up as a distinct protocol (by NLPID or some other > mechanism) it can do things any which way it pleases. It is best > from an implementation perspective to keep it as close to IS-IS as > possible so that a single implementation with a few checks here and > there can do both. This has the added advantage that foolish > implementors will cut-and-paste the code and create themselves > maintenance problems and allow Darwinian selection to occur, like > back in the NLSP days. ;-) But it is entirely possible to share > 99% of the code while maintaining protocol "distinctness." And > having it distinct from IS-IS avoids having to be forced to make > compromises to avoid breaking IS-IS (at the cost of less common code). > > Just my 112 ZMK. > > --Dave > > On Apr 11, 2009, at 10:01 AM, Don Fedyk wrote: > >> Hi Radia >> >> Well you are correct that some of the terminology is imprecise. I >> don't agree with some of the characterization. I would agree we >> should use more precise terminology. I was actually being very >> precise my last couple of emails. (I hope people are still reading >> them.) >> >> We are dealing with two worlds here. Sorry it is not a level >> playing field: >> IS-IS design and working system. >> Trill proposals which leverage 1. >> In my books 1. current operation takes precedence because it is >> both problem and solution. It is deployed and working. So we can't >> just go in and change things and expect it to work with out careful >> analysis. But accurately describing what it is doing is a good idea. >> >> For 2. we have a problem that needs to be described. Let stick to >> the problem description. Define an "ideal" solution mechanism >> outside of IS-IS mecjhanisms and describe it with the same >> accuracy. Only then can we look at 1. and see what portions are >> applicable if any. >> >> Terms we need to agree on: >> "minimum MTU" or "The too small MTU Problem for IS-IS" >> "Neighbor Discovery" >> "IS-IS Adjacency" >> "RBridge Adjacency" >> "Number of RBridges that attached on a LAN" <- There is no >> equivalent for this in IS-IS >> "IS-IS Hello" >> "minimum MTU probing" >> "MTU discovery" <- Should not be used. IP does MTU discovery. IS- >> IS does not. Unfortunately _is_ the title of this thread! >> >> Regards, >> Don >> >> On Sat, Apr 11, 2009 at 1:23 AM, Radia Perlman >> wrote: >> Yes, what Donald Eastlake said is right. >> >> I think there are several things confusing people: >> >> a) the subject line of this thread, which is a discussion having >> little to do with the subject line >> >> b) calling both "neighbor discovery" messages and "MTU probes" >> "Hellos". >> Frankly, "Hello" is not a particularly descriptive name for either >> thing, and it was probably my fault for >> calling it that 30 years ago. I suggest we call neither one of them >> "Hello"s. >> >> c) discussing both mechanisms (neighbor discovery, and MTU probing) >> in the same thread. >> Layer 3 IS-IS happened to solve both problems (nbr discovery >> and MTU discovery) with the same message type, and one >> mechanism that somehow did them both. We've established that TRILL >> can't >> get away with that. So we need one protocol for neighbor discovery >> and one for MTU discovery. >> As I said, using the nondescriptive term "Hello" is confusing >> people, so I suggest we >> use the terms "neighbor discovery message" and "MTU probe/ack" for >> the message names. >> >> Nobody has claimed that unpadded Hellos does not safely and simply >> accomplish neighbor >> discovery. I think we should put "neighbor discovery" to bed at >> this point, perhaps renaming >> the message in the spec from "Hello" to "neighbor discovery >> message", which would >> be bit-wise identical to the thing we were calling an "unpadded >> Hello" or a "protective Hello". >> >> And start up a new thread for MTU discovery. I suspect people >> really are not happy with >> "ignore the problem" or even "defer the problem". If the chairs >> think that is not necessarily >> true, and the WG might prefer "ignore" or "defer" MTU discovery, I >> suggest we >> have a different thread with a subject line "should we bother doing >> MTU discovery". >> >> Assuming the WG does want to solve MTU discovery, we should do so. >> It will not be technically difficult. >> It will involve some simple pinging thing with padded messages. I >> propose we >> not call those messages "padded Hellos", but instead call them "MTU >> probe". >> >> Radia >> >> >> >> >> >> >> >> Donald Eastlake wrote: >> Hi Don, >> >> The way I would characterize the problem is as follows: >> There have to be two different messages. (Actually, it's at least >> two, since you can always come up with even more complex schemes.) >> Consider the follows two possible pairs of messages: >> (1) Use padded Hellos for MTU. Now you have to add a short >> message for safety. Unfortunately, this short message has to be a >> fairly complex short message with many fields that are the same as a >> Hello and has to participate in various Hello mechanisms. >> (2) Use unpadded Hellos for safety. Now you have to add a padded >> message for MTU but MTU message can be a simple ping like message. >> >> Alternative 1 sure sounds more complex to me. >> >> Donald >> >> On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk >> wrote: >> >> Hi Radia >> >> b) is a not side issue. Problem b) is characterized by ensuring >> the >> minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS >> fills >> LSP up to the minimum MTU as part of its operation. Initially when >> there is >> not much information to exchange the frame size is small, but as >> information >> gets added the LSPs grows to the minimum MTU size then IS-IS >> fragments them. >> So if you are not sure the minimum MTU limit is supported >> everywhere and >> continuously monitored then the probability increases there will be >> missing >> LSPs. Missing LSPs is a big problem. b) is therefore a problem >> for proper >> operation of Trill too. >> >> In IS-IS where b) is the problem, padding Hellos is the current >> solution >> and it safeguards IS-IS. Missing Hellos take down the adjacency >> (ie become >> unaware of any other IS-IS capable systems on the link) if the >> minimum MTU >> is not supported (cut off the link to save the rest of the network >> network). >> It is also a good thing to have the initial packet you send fail the >> minimum MTU check if it is going to fail. It makes little sense to >> exchange >> messages further for IS-IS operation. >> >> Problem a) Is a problem characterized by knowing all RBridges >> attached to a >> common LAN for correct operation of the LAN and the RBridges. IS-IS >> between the RBridges on the LAN does not need to be operational in >> order to >> solve this problem. >> >> So to summarize: >> >> * In IS-IS padded hellos is the current solution to b) * And you >> are >> proposing in Trill unpadded hellos is the solution to a) >> * Both a) and b) must be solved in Trill >> >> So we have deadlock. >> >> That is why some of us suggested a while ago that another solution >> to a) >> outside using IS-IS Hellos is preferable. I know that makes it >> inconvenient because IS-IS has a really easy way to announce itself >> over a >> LAN using Hellos. It is oh so close. It works most of the time. But >> re-engineering IS-IS hellos to solve a) means you now need a >> solution for b) >> where you already had one.. >> >> To break the deadlock the solution in a) and b) must be decoupled >> and I have >> seen little evidence that IS-IS people are clamoring to change the >> current >> solution for b). So the sooner we agree that a) should be solved >> outside of >> IS-IS Hellos (and I'm not saying how just why), then I think we >> could make >> progress. >> >> Regards, >> Don >> >> Radia Perlman wrote: >> >> Suresh, >> >> I agree that it would be good to solve both problems: >> >> a) ensure that RBridges see each other (unpadded Hellos is the the >> solution >> that has been proposed), and >> >> b) some mechanism to assure there is agreement about what the >> campus-wide >> MTU size should be, >> and assure that the paths computed only include links that meet >> that MTU >> size. >> >> It would not be difficult (technically) to solve b) but a) is more >> important, so I can live with >> deferring b) and shipping the spec. >> >> If people would like solve b) now, then fine, I'm sure we can come >> up with >> a mechanism to do that. But we have to ensure that that mechanism >> does not >> interfere in >> any way with a). >> >> The problem is that discussing both problems at the same time seems >> to be >> confusing people. >> >> I think we should agree on this thread that we need to do unpadded >> Hellos >> to solve problem a), and >> start a second thread about what to do about problem b), e.g., >> "ignore >> it", "defer it until >> later", or "here's a candidate solution". >> >> Radia >> >> >> >> >> >> >> >> Suresh Boddapati wrote: >> >> --- On Fri, 4/10/09, Radia Perlman wrote: >> >> >> >> Not padding hellos does not "break IS-IS". >> >> I am not completely sure. Please correct me if I am wrong. >> Let me see if I can construct an example. >> 1 >> A--------B >> \ / >> 1 \ / 5 >> \ C / >> >> The numbers are the respective cost on the links. >> >> Now suppose A has a smaller MTU such that it can see B's and C's >> hellos >> and form adjacencies with them. Now B's LSP that describes the link >> to A >> happens to be larger than the MTU that A uses on its links. This >> LSP does >> not get through to A from either B or C. Consider that the LSP that >> B uses >> to describe the link to C is within the MTU limits and does get >> through. >> Since A does not see B's LSP describing the link to A, it will >> compute a >> path to B through C. >> >> C sees both A's and B's LSPs and determines that the shortest path >> to B >> is through A (note A and B have both advertised their link in their >> respective LSPs, so the bidirectionality check would pass, it's >> just that A >> does not have B's LSP, so it cannot compute the path correctly). >> You have >> basically prevented A from being able to get to all destinations >> that can be >> reached through B and you have a loop of a different kind. This >> loop will >> not go away. The fix in IS-IS for this is to use padded hellos. If >> you pad, >> adjacencies wont form between A and B and everything will be fine. >> In TRILL, if you eliminate the padding, you have a TRILL forwarding >> loop >> and every frame sent by A to B or anything reachable through B will >> die in >> this loop once the hop count reaches zero. I recognize the fact >> that this is >> not as bad as the case when RBridges do not see each other, but is >> this the >> "weirdness" you say we could live with? IMO, we should make every >> effort to >> not have this situation. Debugging this could be real fun. And this >> is just >> one example of things going wrong. CSNPs may not get through. Or it >> is >> possible they do get through, but the LSPs dont, resulting in >> constant >> flooding of those LSPs on those links. >> >> >> >> So, repeating for the nth time.... >> Keeping the Hello mechanism exactly as it is in IS-IS today >> will not work for TRILL. >> That should be the end of discussion. Not padding the >> Hellos obviously >> works for robustly finding neighbors, and is a trivial >> change. The >> only thing that gets lost is MTU discovery. >> >> The only feasible choices at this point are: >> a) only do unpadded Hellos, and live with weirdnesses due >> to not >> testing MTU size, deferring MTU discovery to the future >> b) do unpadded Hellos, and come up with a mechanism for MTU >> discovery now. >> It would be easy to do so. >> >> >> >> I would prefer to go with an option that ensures that no LSPs get >> lost >> silently due to MTU issues. >> Thanks, >> >> Suresh >> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> >> >> >> >> >> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg at ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090411/be06de50/attachment-0001.html From trill at punk.co.nz Sat Apr 11 21:08:46 2009 From: trill at punk.co.nz (Kris Price) Date: Sun, 12 Apr 2009 16:08:46 +1200 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> Message-ID: <49E1694E.1010708@punk.co.nz> OK. Defining the problem and the general courses of action, and then the eliminating them. In normal layer-3 operation, the failure of IS-IS to discover a neighbouring router is of minor consequence. For TRILL the failure of IS-IS to discover a neighbouring RBridge is a problem. TRILL defines a special RBridge role, known as the designated forwarder, and uses IS-IS to elect which RBridge on each link will perform this role. When an RBridge does not recieve the IS-IS Hellos of its neighbours it will assume it is alone on the link, and therefore elect itself the designated forwarder. The designated forwarder role elevates an RBridge from merely forwarding TRILL data frames between the TRILL speakers in a TRILL cloud, to encapsulating and decapsulating Ethernet frames onto and off of LANs. This is where the danger arises. When more than one RBridge performs this role, a loop forms. There is no bad news in regards to forwarding TRILL data frames. So the *split* comes at this elevation of "bridging" between the TRILL data frames and the Ethernet frames. In elevating a router from being a forwarder of Layer 2.5+ frames, to being an encapsulator/decapsulator from the routed layer into the LAN layer. You could leave IS-IS as is if an RBridge had some other mechanism to know if it should elevate itself into this position. Option 0: Use some kind of involvement in the STP to trick it into breaking loops. But this has been completely rejected by the WG several times, and will never (by the looks) be given a lifeline. So it's not worth considering. Option 1: Could you use a repurposed configuration BPDU or similar to announce your presense as an RBridge onto a link? You wait for a period of X seconds, and if you do not see any announcements, proceed as normal, elevating yourself (or someone else) into the designated forwarder role. Maybe you could have some new TRILL OUI that RBridges map their nicknames and priority into for the Bridge IDs, and then they transmit these. Perhaps it can even carry more useful info in some MST like way. How this is achieved is beyond my current level of STP knowledge, so someone more educated on STP would need to explore that avenue if they found it interesting. Option 2: If you cannot use STP in some way like this, you need a new protocol, but it will not be simple because it becomes constrained by the VLAN topology. It does not see a physical bridged LAN as one link, like a BPDU does, it sees it as many links. So you have solve those problems and to do something similar to what TRILL does with the IS-IS hellos, protection hellos, etc. In that case you might as well move all that protection hellos etc. into this new protocol, and leave IS-IS as untouched as possible. So I think this option is about leave IS-IS as is and create an all new "TRILL Discovery and Election Protocol for All Link Types(tm)," and running the two protocols together. Pros: TRILL doesn't have to modify IS-IS and become responsible for porting IS-IS enhancements, etc. Option 3: Modify IS-IS for TRILL's needs but call it something different, maybe "RB-RB". RB-RB would share 99% of the code with IS-IS, but is customised for TRILL's specific needs. Solve the problems in an appropriate way, as has been suggested, or maybe a variation of. Pros: Already undergone some customisation for TRILL's needs. It seems to be what you would naturally come up with if IS-IS didn't exist, one protocol to rule them all, rather than multiple. Moving forward: 1. Someone who knows STP and BPDUs would need to come up with a working suggestion for Option 1, or it's out the window. Put a timer on it, say a week. 2. It looks like people are split between Option 2 and Option 3. So would the WG even accept moving some existing customisation into an external protocol as per Option 2? 3. If not, those opposed to Option 3 should ask themselves if it is worth pursuing, given it would end up as a split between half of Option 2 and half Option 3. 4. If so, we're still stuck at coming up with two competing protocols, but perhaps, given how key it is, it is worth developing and comparing two proposals in that case. (So long as the effort isn't wasted, see 1, 2, and 3 above.) For me Option 1 is slightly preferable. Otherwise I can go either way on Option 2 or 3. But I wouldn't like to see a split between half an Option 2 and half an Option 3. Hope you all found your chocolate eggs. Cheers Kris From don.fedyk at gmail.com Sun Apr 12 06:01:05 2009 From: don.fedyk at gmail.com (Don Fedyk) Date: Sun, 12 Apr 2009 09:01:05 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E1694E.1010708@punk.co.nz> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> Message-ID: <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> Hi Kris I think you have enumerated a number of options but in general we could summarize most of the them all as: Separating Neighbor discovery out from IS-IS and running vanilla IS-IS. What I would recommend is: Run a protocol that does Neighbor Discovery and handshake (Might look like IS-IS Short Hello frames, and minimum handshake logic but it is not IS-IS) Call it the Trill discovery protocol. If Trill Neighbor discovery aspect only works in one direction for some obscure reason the handshake won't complete but at least it should prevent multiple RBridges assuming they are the DRB. If the handshake completes then this protocol is happy and all it does is trigger vanilla IS-IS (which may use a different NLPID or whatever) and Trill discovery continues in the background. If IS-IS ever restarts, breaks down or looses adjacency the Trill discovery would be there as a safety net continuing the neighbor discovery at a minimum. In this design of a solution: Clear separation of function from IS-IS would satisfy the requirements and allow IS-IS to remain in tact. Yes there is a little duplication of Neighbor discovery and handshaking functions but I think the separation is worth the cost of reusing the IS-IS logic in tact. Cheers, Don (The best I can do in the spirit of the Easter egg hunt [?] ) On Sun, Apr 12, 2009 at 12:08 AM, Kris Price wrote: > OK. Defining the problem and the general courses of action, and then the > eliminating them. > > > > In normal layer-3 operation, the failure of IS-IS to discover a > neighbouring router is of minor consequence. > > For TRILL the failure of IS-IS to discover a neighbouring RBridge is a > problem. TRILL defines a special RBridge role, known as the designated > forwarder, and uses IS-IS to elect which RBridge on each link will perform > this role. > > When an RBridge does not recieve the IS-IS Hellos of its neighbours it will > assume it is alone on the link, and therefore elect itself the designated > forwarder. > > The designated forwarder role elevates an RBridge from merely forwarding > TRILL data frames between the TRILL speakers in a TRILL cloud, to > encapsulating and decapsulating Ethernet frames onto and off of LANs. > > This is where the danger arises. When more than one RBridge performs this > role, a loop forms. There is no bad news in regards to forwarding TRILL data > frames. > > So the *split* comes at this elevation of "bridging" between the TRILL data > frames and the Ethernet frames. In elevating a router from being a forwarder > of Layer 2.5+ frames, to being an encapsulator/decapsulator from the routed > layer into the LAN layer. > > You could leave IS-IS as is if an RBridge had some other mechanism to know > if it should elevate itself into this position. > > > Option 0: > > Use some kind of involvement in the STP to trick it into breaking loops. > But this has been completely rejected by the WG several times, and will > never (by the looks) be given a lifeline. So it's not worth considering. > > > Option 1: > > Could you use a repurposed configuration BPDU or similar to announce your > presense as an RBridge onto a link? You wait for a period of X seconds, and > if you do not see any announcements, proceed as normal, elevating yourself > (or someone else) into the designated forwarder role. > > Maybe you could have some new TRILL OUI that RBridges map their nicknames > and priority into for the Bridge IDs, and then they transmit these. Perhaps > it can even carry more useful info in some MST like way. > > How this is achieved is beyond my current level of STP knowledge, so > someone more educated on STP would need to explore that avenue if they found > it interesting. > > > Option 2: > > If you cannot use STP in some way like this, you need a new protocol, but > it will not be simple because it becomes constrained by the VLAN topology. > It does not see a physical bridged LAN as one link, like a BPDU does, it > sees it as many links. > > So you have solve those problems and to do something similar to what TRILL > does with the IS-IS hellos, protection hellos, etc. In that case you might > as well move all that protection hellos etc. into this new protocol, and > leave IS-IS as untouched as possible. > > So I think this option is about leave IS-IS as is and create an all new > "TRILL Discovery and Election Protocol for All Link Types(tm)," and running > the two protocols together. > > Pros: TRILL doesn't have to modify IS-IS and become responsible for porting > IS-IS enhancements, etc. > > > Option 3: > > Modify IS-IS for TRILL's needs but call it something different, maybe > "RB-RB". RB-RB would share 99% of the code with IS-IS, but is customised for > TRILL's specific needs. Solve the problems in an appropriate way, as has > been suggested, or maybe a variation of. > > Pros: Already undergone some customisation for TRILL's needs. It seems to > be what you would naturally come up with if IS-IS didn't exist, one protocol > to rule them all, rather than multiple. > > > > Moving forward: > > 1. Someone who knows STP and BPDUs would need to come up with a working > suggestion for Option 1, or it's out the window. Put a timer on it, say a > week. > > 2. It looks like people are split between Option 2 and Option 3. So would > the WG even accept moving some existing customisation into an external > protocol as per Option 2? > > 3. If not, those opposed to Option 3 should ask themselves if it is worth > pursuing, given it would end up as a split between half of Option 2 and half > Option 3. > > 4. If so, we're still stuck at coming up with two competing protocols, but > perhaps, given how key it is, it is worth developing and comparing two > proposals in that case. (So long as the effort isn't wasted, see 1, 2, and 3 > above.) > > > > For me Option 1 is slightly preferable. Otherwise I can go either way on > Option 2 or 3. But I wouldn't like to see a split between half an Option 2 > and half an Option 3. > > > > Hope you all found your chocolate eggs. > > Cheers > Kris > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090412/95c07d95/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 96 bytes Desc: not available Url : http://mailman.postel.org/pipermail/rbridge/attachments/20090412/95c07d95/attachment.gif From Radia.Perlman at sun.com Sun Apr 12 16:17:57 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 12 Apr 2009 16:17:57 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> Message-ID: <49E276A5.8090309@sun.com> Another reason I think people are getting confused is the use of the term "use vanilla IS-IS". "Vanilla IS-IS", where MTU discovery is all interlinked with choosing DRs, and where the result can be multiple DRs, will not work, as has been said many times on this thread, and people don't know what "just use vanilla IS-IS" means. So, do not use the phrase "use vanilla IS-IS" as a shorthand for any part of the solution. It only confuses people. Certainly *I* have no idea what anyone means when they use that phrase, especially since it's clear that we can't "just use vanilla IS-IS". Now, to try to get us back on track: There are three problems TRILL needs to solve, (given that it's pretty clear people don't want to defer or ignore the MTU issue), and the discussion should be around how to solve each problem. The three problems that must be solved: a) on a link, choosing one and only one DRB, who will be assigning designated forwarders, dictating which VLAN is the designated VLAN, naming the pseudonode, etc. b) having all RBridges agree on what the campus-wide MTU size should be, say S. c) having all RBridges test, for each link and each neighbor, which ones can handle size S, and removing those that don't from the topology, so routes are not calculated through links that can't handle size S. The solution to a) is what is in the TRILL spec today. It uses unpadded IS-IS Hellos, and has a lot of explanation of what VLANs to send unpadded Hellos on, and unlike IS-IS, has slightly different logic to ensure there are not multiple DRBs in the face of one-way connectivity, MTU mismatches, etc. The solution to b) is with adding a TLV into the LSP, where not including the TLV is the same as specifying "1450", and the TLV, if specified must have S > 1450. There are only three plausible ways of using this TLV, I think: 1) look through all the LSPs in your database, and choose the largest size S any RBridge specifies, as the campus-wide S 2) choose the smallest size S any RBridge specifies as the campus-wide S 3) look at the LSP of the highest priority RBridge in the campus, and use the S specified in its LSP as the campus-wide S. (by the way, I prefer this one -- seems simplest and most stable) The solution to c) (testing MTU size), has to be done with padded packets of some sort. It could certainly be done using the same format as padded IS-IS Hellos, though I'd prefer some clear distinction between the MTU-testing packets and the DRB election/ VLAN specifying, etc., packets so that the logic of solving problems a) and c) don't get intermingled. The MTU-testing packet should include a TLV specifying "S", the size being tested, and should be padded to S. We could have unicast acks to this padded packet, or do the same sort of IS-IS-like two-way connectivity announcements, by having R2, in its S-padded packet, list all RBridge neighbors on the link from which it has (recently enough) received packets of at least size S. It would be nice to have some careful thoughtful discussion on the mailing list about what the best way to solve this would be. (e.g., optional, mandatory, periodic, once and assume things won't change, unicast acks vs listing "I heard size S from this list"). But whatever it is would have nothing to do with choosing a DRB, naming the pseudonode, or any mechanisms usually associated with "Hellos". Radia From trill at punk.co.nz Sun Apr 12 19:52:05 2009 From: trill at punk.co.nz (Kris Price) Date: Mon, 13 Apr 2009 14:52:05 +1200 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E276A5.8090309@sun.com> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> <49E276A5.8090309@sun.com> Message-ID: <49E2A8D5.3040005@punk.co.nz> Radia Perlman wrote: [snip] > Now, to try to get us back on track: > > There are three problems TRILL needs to solve, (given that > it's pretty clear people don't want to defer or ignore the MTU issue), > and the discussion should > be around how to solve each problem. > > The three problems that must be solved: > > a) on a link, choosing one and only one DRB, who will be assigning > designated > forwarders, dictating which VLAN is the designated VLAN, naming the > pseudonode, etc. > > b) having all RBridges agree on what the campus-wide MTU size should be, > say S. Radia, could you please elaborate a little on why this point b) is a problem to be solved so we're all on the same page? I thought I understood but I've forgotten after reading this long thread. Does it cause a loop or any problems other than partitioned networks? Or is it to ease administrative burdon, e.g. configure in one place rather than on all routers (this introduces other problems)? I've been a bit confused (and perhaps others have also) about the purpose of the padding in an IIH. I may still be confused. To clear things up: An IIH is padded up to the maximum of dataLinkBlocksize (MTU) or originatingL1LSPBufferSize. Because each IS may send LSP PDUs up to its originatingL1LSPBufferSize they do this padding to prevent creating an adjacency with a neighbour for which they may not be able to send an LSP to. The purpose of the padding is *only* to prevent an adjacency forming between any pair of ISs which would not be able to exchange LSPs locally with each other. It does nothing to ensure that RecieveLSPBufferSize, or some network wide consistent originatingL1LSPBufferSize is met on all links, and does not ensure that LSPs created by any IS can be sent across all links. When an IS recieves, on one link, an LSP bigger than the dataLinkBlocksize of another link, it cannot flood it, and it reports and error. The spec also includes means for detection of inconsistent originatingL1LSPBufferSize by including a new TLV originatingLSPBufferSize for it. This is what is defined in IS-IS. It is considered an administrative issue by the looks to ensure that (if you want your LSPs to get through) you configure a consistent originatingL1LSPBufferSize on all routers in your network. So it seems (to me) there are three general options for this point: Option 1. Provided there is no danger to LSPs not getting through on some links. Do nothing, leave it as an administrative alert as per existing ISIS. It is the responsibility of the administrator to ensure the originatingL1LSPBufferSize is configured appropriately throughout the network. And in this option, perhaps leave it for the IS-IS group to one day solve. Option 2. Take the approach of automatically healing the network to the smallest MTU to include all links. Option 3. Take the approach of the priority router dictating the MTU size and other routers exclude links which do not meet that MTU. I'd like to understand why Option 3 is better than the other options. Cheers Kris From mrthom at essex.ac.uk Mon Apr 13 02:11:16 2009 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Mon, 13 Apr 2009 10:11:16 +0100 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> <49E276A5.8090309@sun.com> <49E2A8D5.3040005@punk.co.nz> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661DA753CC@sernt14.essex.ac.uk> Radia, Kris, There may be something to salvage here or may not as the case may be. ( This is just my port 8899 ) but in 2007 I callled this idea promiscuous hellos. It was to try to automatically fix encapsulation failure on NBMA networks which seems to be what you are having (via MTU). The IETF fix was P2P network type (not surprisingly) which of couse is manual configuration. This idea here would improve the situation somewhat but not fix fireproof. It is always possible to break pseudonodes if you really try (although they do improve safety somewhat) This would improve the situation somewhat. Imagine R1 and R2 cannot communicate, and they share a media with R3 which R2 can communicate with: Problem identification: R3 sends a hello to R1. R1 sees itself (R1) listed in the hello and so R3 and R1 are generally ok. BUT It also sees R2 listed in the hello from R1. R2 is there in the hello from R3 even though the neighbor relationship between R1 and R2 is broken and the hellos from R2 to R1 never got through. this is because R3 is in communication with R2. R1 is confused. R2 is also confused but clearly something is wrong. As no hello has formally appeared from R2 to R1, R1 would normally not even consider R2 to exist. R2 would be considered a rumour and no neighbor state would exist for R2 in R1. Normally (in my understanding) this would result in R1 and R2 completely ignoring each other and this will lead to problems in general, resulting in duplicate DR's which is bad. FIX in this case: SO... 1.) R1 wonders who R2 is (even though R2 is not officially there in anyway): No hello has been received from R2 and acording to the normal operation of the unfixed protcol no state exists for this router. BUT R2 was listed in a valid hello from R3 and so will now not be ignored. R1 instead puts R2 on a special list and tries to contact R2 with special options. In my ospf-lite R1 reverted to unicast. (you could dynamically drop the MTU here). This fixes: some blind neighbors, not all. This doesnt fix: 2 pairs of incorrectly configured RB's completely blind to each other, and endorsing each other if they (the pairs) miss ALL packets from the other RB's. I couldnt find a fix for this and called it experience. Matthew ________________________________ From: rbridge-bounces at postel.org on behalf of Kris Price Sent: Mon 13/04/2009 03:52 To: TRILL/RBridge Working Group; Radia Perlman Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important? Radia Perlman wrote: [snip] > Now, to try to get us back on track: > > There are three problems TRILL needs to solve, (given that > it's pretty clear people don't want to defer or ignore the MTU issue), > and the discussion should > be around how to solve each problem. > > The three problems that must be solved: > > a) on a link, choosing one and only one DRB, who will be assigning > designated > forwarders, dictating which VLAN is the designated VLAN, naming the > pseudonode, etc. > > b) having all RBridges agree on what the campus-wide MTU size should be, > say S. Radia, could you please elaborate a little on why this point b) is a problem to be solved so we're all on the same page? I thought I understood but I've forgotten after reading this long thread. Does it cause a loop or any problems other than partitioned networks? Or is it to ease administrative burdon, e.g. configure in one place rather than on all routers (this introduces other problems)? I've been a bit confused (and perhaps others have also) about the purpose of the padding in an IIH. I may still be confused. To clear things up: An IIH is padded up to the maximum of dataLinkBlocksize (MTU) or originatingL1LSPBufferSize. Because each IS may send LSP PDUs up to its originatingL1LSPBufferSize they do this padding to prevent creating an adjacency with a neighbour for which they may not be able to send an LSP to. The purpose of the padding is *only* to prevent an adjacency forming between any pair of ISs which would not be able to exchange LSPs locally with each other. It does nothing to ensure that RecieveLSPBufferSize, or some network wide consistent originatingL1LSPBufferSize is met on all links, and does not ensure that LSPs created by any IS can be sent across all links. When an IS recieves, on one link, an LSP bigger than the dataLinkBlocksize of another link, it cannot flood it, and it reports and error. The spec also includes means for detection of inconsistent originatingL1LSPBufferSize by including a new TLV originatingLSPBufferSize for it. This is what is defined in IS-IS. It is considered an administrative issue by the looks to ensure that (if you want your LSPs to get through) you configure a consistent originatingL1LSPBufferSize on all routers in your network. So it seems (to me) there are three general options for this point: Option 1. Provided there is no danger to LSPs not getting through on some links. Do nothing, leave it as an administrative alert as per existing ISIS. It is the responsibility of the administrator to ensure the originatingL1LSPBufferSize is configured appropriately throughout the network. And in this option, perhaps leave it for the IS-IS group to one day solve. Option 2. Take the approach of automatically healing the network to the smallest MTU to include all links. Option 3. Take the approach of the priority router dictating the MTU size and other routers exclude links which do not meet that MTU. I'd like to understand why Option 3 is better than the other options. Cheers Kris _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From mrthom at essex.ac.uk Mon Apr 13 02:29:46 2009 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Mon, 13 Apr 2009 10:29:46 +0100 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> <49E276A5.8090309@sun.com> <49E2A8D5.3040005@punk.co.nz> <7AC902A40BEDD411A3A800D0B7847B661DA753CC@sernt14.essex.ac.uk> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661DA753CD@sernt14.essex.ac.uk> Could we send both types? Padded and unpadded and revert to whichever is responded to? MT ________________________________ From: Thomas, Matthew R Sent: Mon 13/04/2009 10:11 To: Kris Price; radia.perlman at sun.com Cc: rbridge at postel.org Subject: RE: [rbridge] [Isis-wg] Why is MTU discovery important? Radia, Kris, There may be something to salvage here or may not as the case may be. ( This is just my port 8899 ) but in 2007 I callled this idea promiscuous hellos. It was to try to automatically fix encapsulation failure on NBMA networks which seems to be what you are having (via MTU). The IETF fix was P2P network type (not surprisingly) which of couse is manual configuration. This idea here would improve the situation somewhat but not fix fireproof. It is always possible to break pseudonodes if you really try (although they do improve safety somewhat) This would improve the situation somewhat. Imagine R1 and R2 cannot communicate, and they share a media with R3 which R2 can communicate with: Problem identification: R3 sends a hello to R1. R1 sees itself (R1) listed in the hello and so R3 and R1 are generally ok. BUT It also sees R2 listed in the hello from R1. R2 is there in the hello from R3 even though the neighbor relationship between R1 and R2 is broken and the hellos from R2 to R1 never got through. this is because R3 is in communication with R2. R1 is confused. R2 is also confused but clearly something is wrong. As no hello has formally appeared from R2 to R1, R1 would normally not even consider R2 to exist. R2 would be considered a rumour and no neighbor state would exist for R2 in R1. Normally (in my understanding) this would result in R1 and R2 completely ignoring each other and this will lead to problems in general, resulting in duplicate DR's which is bad. FIX in this case: SO... 1.) R1 wonders who R2 is (even though R2 is not officially there in anyway): No hello has been received from R2 and acording to the normal operation of the unfixed protcol no state exists for this router. BUT R2 was listed in a valid hello from R3 and so will now not be ignored. R1 instead puts R2 on a special list and tries to contact R2 with special options. In my ospf-lite R1 reverted to unicast. (you could dynamically drop the MTU here). This fixes: some blind neighbors, not all. This doesnt fix: 2 pairs of incorrectly configured RB's completely blind to each other, and endorsing each other if they (the pairs) miss ALL packets from the other RB's. I couldnt find a fix for this and called it experience. Matthew ________________________________ From: rbridge-bounces at postel.org on behalf of Kris Price Sent: Mon 13/04/2009 03:52 To: TRILL/RBridge Working Group; Radia Perlman Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important? Radia Perlman wrote: [snip] > Now, to try to get us back on track: > > There are three problems TRILL needs to solve, (given that > it's pretty clear people don't want to defer or ignore the MTU issue), > and the discussion should > be around how to solve each problem. > > The three problems that must be solved: > > a) on a link, choosing one and only one DRB, who will be assigning > designated > forwarders, dictating which VLAN is the designated VLAN, naming the > pseudonode, etc. > > b) having all RBridges agree on what the campus-wide MTU size should be, > say S. Radia, could you please elaborate a little on why this point b) is a problem to be solved so we're all on the same page? I thought I understood but I've forgotten after reading this long thread. Does it cause a loop or any problems other than partitioned networks? Or is it to ease administrative burdon, e.g. configure in one place rather than on all routers (this introduces other problems)? I've been a bit confused (and perhaps others have also) about the purpose of the padding in an IIH. I may still be confused. To clear things up: An IIH is padded up to the maximum of dataLinkBlocksize (MTU) or originatingL1LSPBufferSize. Because each IS may send LSP PDUs up to its originatingL1LSPBufferSize they do this padding to prevent creating an adjacency with a neighbour for which they may not be able to send an LSP to. The purpose of the padding is *only* to prevent an adjacency forming between any pair of ISs which would not be able to exchange LSPs locally with each other. It does nothing to ensure that RecieveLSPBufferSize, or some network wide consistent originatingL1LSPBufferSize is met on all links, and does not ensure that LSPs created by any IS can be sent across all links. When an IS recieves, on one link, an LSP bigger than the dataLinkBlocksize of another link, it cannot flood it, and it reports and error. The spec also includes means for detection of inconsistent originatingL1LSPBufferSize by including a new TLV originatingLSPBufferSize for it. This is what is defined in IS-IS. It is considered an administrative issue by the looks to ensure that (if you want your LSPs to get through) you configure a consistent originatingL1LSPBufferSize on all routers in your network. So it seems (to me) there are three general options for this point: Option 1. Provided there is no danger to LSPs not getting through on some links. Do nothing, leave it as an administrative alert as per existing ISIS. It is the responsibility of the administrator to ensure the originatingL1LSPBufferSize is configured appropriately throughout the network. And in this option, perhaps leave it for the IS-IS group to one day solve. Option 2. Take the approach of automatically healing the network to the smallest MTU to include all links. Option 3. Take the approach of the priority router dictating the MTU size and other routers exclude links which do not meet that MTU. I'd like to understand why Option 3 is better than the other options. Cheers Kris _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From james.d.carlson at Sun.COM Mon Apr 13 05:26:18 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Mon, 13 Apr 2009 08:26:18 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E2A8D5.3040005@punk.co.nz> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> <49E276A5.8090309@sun.com> <49E2A8D5.3040005@punk.co.nz> Message-ID: <18915.12138.342382.241724@gargle.gargle.HOWL> Kris Price writes: > Option 3. > > Take the approach of the priority router dictating the MTU size and > other routers exclude links which do not meet that MTU. > > > I'd like to understand why Option 3 is better than the other options. The messages that an RBridge will be forwarding are layer two 802 packets. This means there's no fragmentation possible. The implication of that is that all of the bridges and links connected to a single subnetwork must be configured with exactly the same MTU, not larger and not smaller. -- 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 james.d.carlson at Sun.COM Mon Apr 13 05:44:57 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Mon, 13 Apr 2009 08:44:57 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04F6486A@eusrcmw721.eamcs.ericsson.se> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <941D5DCD8C42014FAF70FB7424686DCF04F6486A@eusrcmw721.eamcs.ericsson.se> Message-ID: <18915.13257.572268.19447@gargle.gargle.HOWL> Eric Gray writes: > 1) Use padded Hellos for consistency with currently specified IS-IS. > With this choice, you also need to add a short message for loop > (and duplicate delivery) protection. This short message might be > fairly complex (with many fields the same as a hello PDU, and the > need to process this message consistent with hello processing) or > as simple as a message that says "I am a version 1 TRILL Rbridge." > In the latter case, the protocol specification needs to describe > how DRB election takes place if a device is detected that says it > is a version 1 RBridge but no hello messages are received. I believe that the DRB election could not take place in that event. If the protective discovery message is simple, and the rest of the Hello information is missing, then the only safe thing left to do is to avoid forwarding on that interface at all, because we know that some nodes are screened from us, but we can't tell what L2 forwarding they might attempt to do or what loops may exist in the topology, and we cannot elect a unique DRB without Hello messages passing through. I suspect this proposal _also_ changes IS-IS. We would have to define what happens if a node receives an IS-IS Hello message without having previously received the loop protection message, and what to do if we stop receiving the protective messages from a node (due to an underlying reconfiguration). The latter means tearing down existing adjacencies when we miss those packets, and disabling all forwarding as above. (Again, the key difference is that this "simple" discovery mechanism lacks the ability to guarantee that we have at most one DRB on the network, which is a requirement of TRILL.) On the other hand, if the message is complex, it's hard to see how we don't just end up with unpadded Hellos. At that point, we've converged on solution (2), and all we're talking about is the complexity of the MTU probing mechanism -- whether it is indeed a padded Hello or a simpler message. (One of the discarded proposals was to send both padded and unpadded Hellos. You would need to receive both to become fully adjacent.) -- 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 Apr 13 06:57:56 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 13 Apr 2009 09:57:56 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <7AC902A40BEDD411A3A800D0B7847B661DA753CD@sernt14.essex.ac.uk> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> <49E276A5.8090309@sun.com> <49E2A8D5.3040005@punk.co.nz> <7AC902A40BEDD411A3A800D0B7847B661DA753CC@sernt14.essex.ac.uk> <7AC902A40BEDD411A3A800D0B7847B661DA753CD@sernt14.essex.ac.uk> Message-ID: <1028365c0904130657n73b1af6xef58e09952f42a88@mail.gmail.com> Sending two types of Hellos is what is in the current RBridge base protocol draft. I haven't heard anyone claim that does not work, just many people say they don't like it. Donald On Mon, Apr 13, 2009 at 5:29 AM, Thomas, Matthew R wrote: > Could we send both types? Padded and unpadded and revert to whichever is responded to? > > MT > > ________________________________ > > From: Thomas, Matthew R > Sent: Mon 13/04/2009 10:11 > To: Kris Price; radia.perlman at sun.com > Cc: rbridge at postel.org > Subject: RE: [rbridge] [Isis-wg] Why is MTU discovery important? > > > Radia, Kris, > > There may be something to salvage here or may not as the case may be. ( This is just my port 8899 ) but in 2007 I callled this idea promiscuous hellos. It was to try to automatically fix encapsulation failure on NBMA networks which seems to be what you are having (via MTU). The IETF fix was P2P network type (not surprisingly) which of couse is manual configuration. This idea here would improve the situation somewhat but not fix fireproof. It is always possible to break pseudonodes if you really try (although they do improve safety somewhat) This would improve the situation somewhat. > > Imagine R1 and R2 cannot communicate, and they share a media with R3 which R2 can communicate with: > > Problem identification: > > R3 sends a hello to R1. R1 sees itself (R1) listed in the hello and so R3 and R1 are generally ok. BUT It also sees R2 listed in the hello from R1. R2 is there in the hello from R3 even though the neighbor relationship between R1 and R2 is broken and the hellos from R2 to R1 never got through. this is because R3 is in communication with R2. R1 is confused. R2 is also confused but clearly something is wrong. As no hello has formally appeared from R2 to R1, R1 would normally not even consider R2 to exist. R2 would be considered a rumour and no neighbor state would exist for R2 in R1. > > Normally (in my understanding) this would result in R1 and R2 completely ignoring each other and this will lead to problems in general, resulting in duplicate DR's which is bad. > > FIX in this case: > > SO... 1.) R1 wonders who R2 is (even though R2 is not officially there in anyway): No hello has been received from R2 and acording to the normal operation of the unfixed protcol no state exists for this router. BUT R2 was listed in a valid hello from R3 and so will now not be ignored. R1 instead puts R2 on a special list and tries to contact R2 with special options. In my ospf-lite R1 reverted to unicast. (you could dynamically drop the MTU here). > > This fixes: some blind neighbors, not all. > > This doesnt fix: 2 pairs of incorrectly configured RB's completely blind to each other, and endorsing each other if they (the pairs) miss ALL packets from the other RB's. I couldnt find a fix for this and called it experience. > > > Matthew > > ________________________________ > > From: rbridge-bounces at postel.org on behalf of Kris Price > Sent: Mon 13/04/2009 03:52 > To: TRILL/RBridge Working Group; Radia Perlman > Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important? > > > > Radia Perlman wrote: > [snip] >> Now, to try to get us back on track: >> >> There are three problems TRILL needs to solve, (given that >> it's pretty clear people don't want to defer or ignore the MTU issue), >> and the discussion should >> be around how to solve each problem. >> >> The three problems that must be solved: >> >> a) on a link, choosing one and only one DRB, who will be assigning >> designated >> forwarders, dictating which VLAN is the designated VLAN, naming the >> pseudonode, etc. >> >> b) having all RBridges agree on what the campus-wide MTU size should be, >> say S. > > Radia, could you please elaborate a little on why this point b) is a > problem to be solved so we're all on the same page? I thought I > understood but I've forgotten after reading this long thread. Does it > cause a loop or any problems other than partitioned networks? Or is it > to ease administrative burdon, e.g. configure in one place rather than > on all routers (this introduces other problems)? > > > > I've been a bit confused (and perhaps others have also) about the > purpose of the padding in an IIH. I may still be confused. To clear > things up: > > An IIH is padded up to the maximum of dataLinkBlocksize (MTU) or > originatingL1LSPBufferSize. > > Because each IS may send LSP PDUs up to its originatingL1LSPBufferSize > they do this padding to prevent creating an adjacency with a neighbour > for which they may not be able to send an LSP to. > > The purpose of the padding is *only* to prevent an adjacency forming > between any pair of ISs which would not be able to exchange LSPs locally > with each other. It does nothing to ensure that RecieveLSPBufferSize, or > some network wide consistent originatingL1LSPBufferSize is met on all > links, and does not ensure that LSPs created by any IS can be sent > across all links. > > When an IS recieves, on one link, an LSP bigger than the > dataLinkBlocksize of another link, it cannot flood it, and it reports > and error. The spec also includes means for detection of inconsistent > originatingL1LSPBufferSize by including a new TLV > originatingLSPBufferSize for it. This is what is defined in IS-IS. It is > considered an administrative issue by the looks to ensure that (if you > want your LSPs to get through) you configure a consistent > originatingL1LSPBufferSize on all routers in your network. > > > > So it seems (to me) there are three general options for this point: > > Option 1. > > Provided there is no danger to LSPs not getting through on some links. > Do nothing, leave it as an administrative alert as per existing ISIS. It > is the responsibility of the administrator to ensure the > originatingL1LSPBufferSize is configured appropriately throughout the > network. > > And in this option, perhaps leave it for the IS-IS group to one day solve. > > Option 2. > > Take the approach of automatically healing the network to the smallest > MTU to include all links. > > Option 3. > > Take the approach of the priority router dictating the MTU size and > other routers exclude links which do not meet that MTU. > > > I'd like to understand why Option 3 is better than the other options. > > > Cheers > Kris > _______________________________________________ > 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 Mon Apr 13 21:28:35 2009 From: trill at punk.co.nz (Kris Price) Date: Tue, 14 Apr 2009 16:28:35 +1200 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <18915.12138.342382.241724@gargle.gargle.HOWL> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> <49E276A5.8090309@sun.com> <49E2A8D5.3040005@punk.co.nz> <18915.12138.342382.241724@gargle.gargle.HOWL> Message-ID: <49E410F3.3060501@punk.co.nz> James Carlson wrote: > Kris Price writes: >> Option 3. >> >> Take the approach of the priority router dictating the MTU size and >> other routers exclude links which do not meet that MTU. >> >> >> I'd like to understand why Option 3 is better than the other options. > > The messages that an RBridge will be forwarding are layer two 802 > packets. This means there's no fragmentation possible. > > The implication of that is that all of the bridges and links connected > to a single subnetwork must be configured with exactly the same MTU, > not larger and not smaller. > Thanks James, I just want to be clear then... This is about preventing data frames from being discarded because they arrive at a link with an MTU that is too small? Just as happens today in Ethernet? It is not about preventing bad (abnormal) things from happening or making sure the control plane is working properly? And it's range is what, from 512 bytes to 9216 bytes? If so, in a way it is really a kind of traffic engineering isn't it? Saying, "I only want you to compute paths that fit this constraint." If it is this (traffic engineering) then I think it should be left to a separate extension to TRILL. Perhaps including other TE-like additions. And it should be separated out from the functionality of the control plane, i.e. the control plane shouldn't form a special new type of adjacency to make this happen. IS-IS or RB-RB or whatever forms all its adjacencies as normal. They all report their TE info in new TLVs as per existing TE extensions, and then each RB computes the constrained paths based on that info. You can still have a priority router or something dictate that TE policy that every router should compute their paths to. Some possible badness with this priority router dictating the MTU: - Priority router goes down. Now what happens? Do they use the new MTU defined by the second priority router? What about the third? Etc. Do they maintain some kind of state about what a higher priority router once said? For how long? What if they all differ? - A higher priority router comes online later in the game and has a higher MTU. Unfortunately it is too late, an older router already was priority for a period and sent out an MTU size, that has caused the network to be partitioned and on this partitioned link there is this new "aware-but-not-adjacent" adjacency because the link didn't meet the MTU. Now one side recieves the new larger MTU, but it can't transmit any LSPs to the other side, so you have a whole new cycle of states that need to transition through for this adjacency. I'm all for healing the network to ensure there are no partitions, i.e. settling down to the lowest MTU to make sure LSPs get through. And then having a separate TE extension to handle neat TE things that TRILL can do (that'd be great). Unless it is there for some non-TE reason...? (which again, I thought I recognised at some point a need for that non-TE reason, but I've lost track of it, and it would be down the track of this healing business...) Cheers Kris From mshand at cisco.com Tue Apr 14 05:41:13 2009 From: mshand at cisco.com (mike shand) Date: Tue, 14 Apr 2009 13:41:13 +0100 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <7AC902A40BEDD411A3A800D0B7847B661DA753C9@sernt14.essex.ac.uk> References: <508896.66561.qm@web81305.mail.mud.yahoo.com><49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com><1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <7AC902A40BEDD411A3A800D0B7847B661DA753C9@sernt14.essex.ac.uk> Message-ID: <49E48469.6090900@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090414/43c2c205/attachment.html From james.d.carlson at Sun.COM Tue Apr 14 06:10:43 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Tue, 14 Apr 2009 09:10:43 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E410F3.3060501@punk.co.nz> References: <508896.66561.qm@web81305.mail.mud.yahoo.com> <49DFCDC1.8050100@sun.com> <49DFF793.4090600@gmail.com> <1028365c0904101943t112e7c65n933bf4db185df110@mail.gmail.com> <49E02935.5000805@sun.com> <6fe277dd0904110801n5553313ao8d1a736cb861b96b@mail.gmail.com> <49E1694E.1010708@punk.co.nz> <6fe277dd0904120601h4f57d2f1k6cfc6b853079fb9e@mail.gmail.com> <49E276A5.8090309@sun.com> <49E2A8D5.3040005@punk.co.nz> <18915.12138.342382.241724@gargle.gargle.HOWL> <49E410F3.3060501@punk.co.nz> Message-ID: <18916.35667.72107.422346@gargle.gargle.HOWL> Kris Price writes: > I just want to be clear then... This is about preventing data frames > from being discarded because they arrive at a link with an MTU that is > too small? Just as happens today in Ethernet? It is not about preventing > bad (abnormal) things from happening or making sure the control plane is > working properly? And it's range is what, from 512 bytes to 9216 bytes? Yes; the single network-wide MTU (and the mechanism for picking and/or enforcing it) are all about that issue. However, that's not really the important issue that we've been talking about in this thread, but rather the padded Hello problem, which is separate. I think we should start a new thread if we're going to discuss the network-wide MTU problem. > If so, in a way it is really a kind of traffic engineering isn't it? > Saying, "I only want you to compute paths that fit this constraint." > > If it is this (traffic engineering) then I think it should be left to a > separate extension to TRILL. Perhaps including other TE-like additions. Possibly. It is inherent, though, in an 802 bridged network, so it'd be nice if there were some thought put into it and not just made optional. > Unless it is there for some non-TE reason...? (which again, I thought I > recognised at some point a need for that non-TE reason, but I've lost > track of it, and it would be down the track of this healing business...) It's not really TE, at least from my point of view. The network is just plain non-functional from an 802 standpoint if there are multiple MTUs involved. But, again, separate thread. -- 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 John.E.Drake2 at boeing.com Tue Apr 14 10:33:02 2009 From: John.E.Drake2 at boeing.com (Drake, John E) Date: Tue, 14 Apr 2009 10:33:02 -0700 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E4BFEA.3080009@juniper.net> References: <6EBD26DE-AB61-4EC3-BE35-759D7413845E@cisco.com> <49DCEE99.5070802@sun.com><49DE7966.1080609@cisco.com> <49DE8993.70401@sun.com> <1028365c0904091705x5c9e4f3bre0eb9f2b4faeb812@mail.gmail.com> <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> <18911.19427.534592.94884@gargle.gargle.HOWL> <49DF70CA.3020106@sun.com><49DF83AA.2000705@raszuk.net> <1028365c0904101131j70072e28m12328b71e925cffd@mail.gmail.com><49DF93D8.4060608@raszuk.net> <49E4BFEA.3080009@juniper.net> Message-ID: <51661468CBD1354294533DA79E85955A01A1B45D@XCH-SW-5V2.sw.nos.boeing.com> Snipped > > if we want to further walk down that road, we should name the > beast TRILL-something and drop the isis-wg groups > involvement, since this is not IS-IS any more. JD: Now there's an idea. > > /hannes > _______________________________________________ > Isis-wg mailing list > Isis-wg at ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > From d3e3e3 at gmail.com Tue Apr 14 13:13:24 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 14 Apr 2009 16:13:24 -0400 Subject: [rbridge] [Isis-wg] Why is MTU discovery important? In-Reply-To: <49E4DC0D.3060302@juniper.net> References: <6fe277dd0904091731k5570f49cu8e8fadd581174341@mail.gmail.com> <18911.19427.534592.94884@gargle.gargle.HOWL> <49DF70CA.3020106@sun.com> <49DF83AA.2000705@raszuk.net> <1028365c0904101131j70072e28m12328b71e925cffd@mail.gmail.com> <49DF93D8.4060608@raszuk.net> <49E4BFEA.3080009@juniper.net> <49E4C312.4080305@raszuk.net> <49E4DC0D.3060302@juniper.net> Message-ID: <1028365c0904141313r378a10f8xb58548b5fa5c0dd3@mail.gmail.com> See below... On Tue, Apr 14, 2009 at 2:55 PM, Hannes Gredler wrote: > Robert Raszuk wrote: >> >> As Dave points out there is "significant amounts of shared code" between >> L3 ISIS & TRILL-ISIS and IMHO it does make sense to keep isis-wg in the >> loop. The Quagga IS-IS implementation supports both. > hehe, i was playing devils advocate here ;-) ... i'll find it worry some > that > the "significant" portion is shrinking for no good reason ... > > i am terribly sorry but i need to bring up an old question again: > > why are there separate PDUs for mult