From Donald.Eastlake at motorola.com Wed Jan 2 11:29:49 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 2 Jan 2008 14:29:49 -0500 Subject: [rbridge] Minutes for TRILL at IETF-70 posted Message-ID: <3870C46029D1F945B1472F170D2D9790036223FF@de01exm64.ds.mot.com> Hi, Tentative minutes from the Vancouver TRILL meeting in December 2007 have been posted and are available on the Meeting Materials page for IETF-70 at http://www3.ietf.org/proceedings/07dec/minutes/trill.txt. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Donald.Eastlake at motorola.com Thu Jan 3 11:13:32 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 3 Jan 2008 14:13:32 -0500 Subject: [rbridge] Consensus Check: Pseudonode suppression In-Reply-To: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Move the Pseudonode suppression provisions out of the TRILL base protocol specification into a document closer to IS-IS. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Mon Jan 7 10:34:19 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 7 Jan 2008 13:34:19 -0500 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Currently broadcast, unknown unicast, and non-IP-derived multicast frames are output to all links. This is wasteful if there are no end stations on the link. Provide that a port can be configured so as to be disabled for end station traffic. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Mon Jan 7 10:36:15 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 7 Jan 2008 13:36:15 -0500 Subject: [rbridge] Consensus Check: Allow GVRP/MVRP In-Reply-To: <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Remove any text prohibiting implementation of GVRP or MVRP on RBridges. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From anoop at brocade.com Mon Jan 7 11:14:27 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 7 Jan 2008 11:14:27 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> This certainly makes sense is what I tend to think of as a TRILL "core" port. On such a port, we would never see non-TRILL encap'ed frames (other than the usual exceptions such as BPDUs and other link layer control traffic). I wonder if it makes sense to also have a configuration for a TRILL "edge" port -- one where we are configured to never send TRILL encap'ed traffic because we don't intend for it to be used as a transit link (even though connectivity may exist to another RBridge for redundancy purposes). Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Monday, January 07, 2008 10:34 AM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Configure ports to > disable end stationtraffic > > This is a check via the mailing list to confirm or refute an > apparent consensus at the Vancouver meeting taken from the > minutes of that > meeting: > > Currently broadcast, unknown unicast, and > non-IP-derived multicast frames are output to all links. This is > wasteful if there are no end stations on the link. Provide that > a port can be configured so as to be disabled for end station > traffic. > > If no particular controversy arises over this in the next > three weeks, We will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Caitlin.Bestler at neterion.com Mon Jan 7 11:26:41 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Mon, 7 Jan 2008 14:26:41 -0500 Subject: [rbridge] Consensus Check: Configure ports to disable endstationtraffic In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAA5B1@nekter> > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Anoop Ghanwani > Sent: Monday, January 07, 2008 11:14 AM > To: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Configure ports to disable > endstationtraffic > > > This certainly makes sense is what I tend to > think of as a TRILL "core" port. On such a > port, we would never see non-TRILL encap'ed > frames (other than the usual exceptions such > as BPDUs and other link layer control traffic). > > I wonder if it makes sense to also have a > configuration for a TRILL "edge" port -- one > where we are configured to never send TRILL > encap'ed traffic because we don't intend for > it to be used as a transit link (even though > connectivity may exist to another RBridge > for redundancy purposes). > This is certainly something specialized implementations SHOULD be allowed to do. The physical ingress/egress point for a chassis could be given RBridge functionality, and it would certainly be in a position to know what sort of networking functionality was allowed in the internal slots. From touch at ISI.EDU Mon Jan 7 11:32:24 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 07 Jan 2008 11:32:24 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> Message-ID: <47827E48.7080400@isi.edu> I'm concerned about the case where an end station moves and doesn't announce itself. There's no requirement in ethernet to do so, and such a station would never be discovered if we don't flood broadcast to all links. I.e., the optimization below is a recipe for ARP failure in such cases. I disagree with it. Joe Anoop Ghanwani wrote: > This certainly makes sense is what I tend to > think of as a TRILL "core" port. On such a > port, we would never see non-TRILL encap'ed > frames (other than the usual exceptions such > as BPDUs and other link layer control traffic). > > I wonder if it makes sense to also have a > configuration for a TRILL "edge" port -- one > where we are configured to never send TRILL > encap'ed traffic because we don't intend for > it to be used as a transit link (even though > connectivity may exist to another RBridge > for redundancy purposes). > > Anoop > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III >> Donald-LDE008 >> Sent: Monday, January 07, 2008 10:34 AM >> To: Rbridge at postel.org >> Subject: [rbridge] Consensus Check: Configure ports to >> disable end stationtraffic >> >> This is a check via the mailing list to confirm or refute an >> apparent consensus at the Vancouver meeting taken from the >> minutes of that >> meeting: >> >> Currently broadcast, unknown unicast, and >> non-IP-derived multicast frames are output to all links. This is >> wasteful if there are no end stations on the link. Provide that >> a port can be configured so as to be disabled for end station >> traffic. >> >> If no particular controversy arises over this in the next >> three weeks, We will declare it to be the working group consensus. >> >> Thanks, >> Donald & Erik >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080107/fa55a4ba/signature.bin From Caitlin.Bestler at neterion.com Mon Jan 7 12:43:49 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Mon, 7 Jan 2008 15:43:49 -0500 Subject: [rbridge] Consensus Check: Configure ports to disableend stationtraffic In-Reply-To: <47827E48.7080400@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAA62D@nekter> > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Joe Touch > Sent: Monday, January 07, 2008 11:32 AM > To: Anoop Ghanwani > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Configure ports to disableend > stationtraffic > > I'm concerned about the case where an end station moves and doesn't > announce itself. There's no requirement in ethernet to do so, and such > a station would never be discovered if we don't flood broadcast to all > links. > > I.e., the optimization below is a recipe for ARP failure in such cases. > I disagree with it. > > Joe > In the general case, I agree with you. But I believe there are special cases where such optimization are valid and valuable. For example, a chassis manager does not need to rely on ARP to detect when the card in a given slot has been inserted or removed. In other words, designation of an "edge port" should be based on something more than a network administrator checking a box that says "I don't plan on putting any rbridges to the left of this rbridge". Inherent physical topology is at least one criteria that I think justifies making such assumptions. There may be others, but I haven't worked with any of them. From james.d.carlson at sun.com Mon Jan 7 12:39:27 2008 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 7 Jan 2008 15:39:27 -0500 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <47827E48.7080400@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> Message-ID: <18306.36351.575064.975092@gargle.gargle.HOWL> Joe Touch writes: > I'm concerned about the case where an end station moves and doesn't > announce itself. There's no requirement in ethernet to do so, and such a > station would never be discovered if we don't flood broadcast to all links. > > I.e., the optimization below is a recipe for ARP failure in such cases. > I disagree with it. That "failure" is exactly the intent. In other words, if you connect an end station to a special internal network that is intentionally designed by a network administrator _not_ to have end stations on it at all (which is what this configuration option specifies), then you've made a mistake, and you should _expect_ the node's attempts to communicate to fail miserably. Obviously, the default should be to forward these messages (ports can't be "TRILL-only" type by default), but why try to prohibit implementations from offering an option if vendors so choose? ARP failure modes for nodes that shouldn't be there at all shouldn't be a reason for a prohibition. On the consensus proposal, I don't see a real reason why a description of such an option needs to be in the spec -- it seems to me that an implementation could provide such a feature under the guise of a "local optimization" without needing this group's permission to do so -- but if it is going to be there as an option, I'd weakly support it. (Really ... do we think we can outlaw vendor features or that we need to explicitly endorse each one?) (I say "weakly" because _every_ option added increases complexity, and that's one of the important problems. But if it's somehow crucial, then ok.) -- 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 touch at ISI.EDU Mon Jan 7 13:08:34 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 07 Jan 2008 13:08:34 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <18306.36351.575064.975092@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> Message-ID: <478294D2.6010706@isi.edu> James Carlson wrote: > Joe Touch writes: >> I'm concerned about the case where an end station moves and doesn't >> announce itself. There's no requirement in ethernet to do so, and such a >> station would never be discovered if we don't flood broadcast to all links. >> >> I.e., the optimization below is a recipe for ARP failure in such cases. >> I disagree with it. > > That "failure" is exactly the intent. > > In other words, if you connect an end station to a special internal > network that is intentionally designed by a network administrator > _not_ to have end stations on it at all (which is what this > configuration option specifies), then you've made a mistake, and you > should _expect_ the node's attempts to communicate to fail miserably. > > Obviously, the default should be to forward these messages (ports > can't be "TRILL-only" type by default), but why try to prohibit > implementations from offering an option if vendors so choose? No reason. This is fine in that case. The doc should be clear about the potential for silent misconfiguration in those cases. (note - this is a silent misconfiguration issue; it'd be much easier if we could know that such a misconfiguration would be detectable) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080107/785d48f2/signature.bin From anoop at brocade.com Mon Jan 7 13:15:59 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 7 Jan 2008 13:15:59 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <47827E48.7080400@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> Message-ID: <4C94DE2070B172459E4F1EE14BD2364ECCD163@HQ-EXCH-5.corp.brocade.com> If the network operator decides that a link should never have end stations on it, and if an end station ends up there, then that is a misconfiguration and I think it would be OK for the end station to not be reachable in that case. BTW, even if the end station annouced itself, configuring the link per Donald's message would have prevented us from reaching that station. In other words, this problem will happen regardless of the protocol in operation. If we don't allow the optimization, the spec will require that RBridges flood copies of all frames on all links. This is a configuration optimization which I think is essential and which, even if not provided by the spec, will most likely be provided by implementations. Anoop > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Monday, January 07, 2008 11:32 AM > To: Anoop Ghanwani > Cc: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Configure ports to > disable end stationtraffic > > I'm concerned about the case where an end station moves and > doesn't announce itself. There's no requirement in ethernet > to do so, and such a station would never be discovered if we > don't flood broadcast to all links. > > I.e., the optimization below is a recipe for ARP failure in > such cases. > I disagree with it. > > Joe > > Anoop Ghanwani wrote: > > This certainly makes sense is what I tend to > > think of as a TRILL "core" port. On such a > > port, we would never see non-TRILL encap'ed frames (other than the > > usual exceptions such as BPDUs and other link layer control > traffic). > > > > I wonder if it makes sense to also have a configuration for a TRILL > > "edge" port -- one where we are configured to never send TRILL > > encap'ed traffic because we don't intend for it to be used as a > > transit link (even though connectivity may exist to another RBridge > > for redundancy purposes). > > > > Anoop > > > >> -----Original Message----- > >> From: rbridge-bounces at postel.org > >> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > >> Donald-LDE008 > >> Sent: Monday, January 07, 2008 10:34 AM > >> To: Rbridge at postel.org > >> Subject: [rbridge] Consensus Check: Configure ports to disable end > >> stationtraffic > >> > >> This is a check via the mailing list to confirm or refute > an apparent > >> consensus at the Vancouver meeting taken from the minutes of that > >> meeting: > >> > >> Currently broadcast, unknown unicast, and > >> non-IP-derived multicast frames are output to all > links. This is > >> wasteful if there are no end stations on the link. > Provide that > >> a port can be configured so as to be disabled for end station > >> traffic. > >> > >> If no particular controversy arises over this in the next three > >> weeks, We will declare it to be the working group consensus. > >> > >> Thanks, > >> Donald & Erik > >> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge at postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > >> > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > From touch at ISI.EDU Mon Jan 7 13:31:56 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 07 Jan 2008 13:31:56 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <478294D2.6010706@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> <478294D2.6010706@isi.edu> Message-ID: <47829A4C.9040200@isi.edu> PS - I do have to admit I don't like optimizations that have silent failure modes. I hope we can spend more time focusing on the core functionality, and less time on things like this. Joe Joe Touch wrote: > > > James Carlson wrote: >> Joe Touch writes: >>> I'm concerned about the case where an end station moves and doesn't >>> announce itself. There's no requirement in ethernet to do so, and >>> such a station would never be discovered if we don't flood broadcast >>> to all links. >>> >>> I.e., the optimization below is a recipe for ARP failure in such >>> cases. I disagree with it. >> >> That "failure" is exactly the intent. >> >> In other words, if you connect an end station to a special internal >> network that is intentionally designed by a network administrator >> _not_ to have end stations on it at all (which is what this >> configuration option specifies), then you've made a mistake, and you >> should _expect_ the node's attempts to communicate to fail miserably. >> >> Obviously, the default should be to forward these messages (ports >> can't be "TRILL-only" type by default), but why try to prohibit >> implementations from offering an option if vendors so choose? > > No reason. This is fine in that case. The doc should be clear about the > potential for silent misconfiguration in those cases. > > (note - this is a silent misconfiguration issue; it'd be much easier if > we could know that such a misconfiguration would be detectable) > > Joe > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080107/def20837/signature.bin From eric.gray at ericsson.com Tue Jan 8 11:15:51 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Jan 2008 13:15:51 -0600 Subject: [rbridge] Consensus Check: Configure ports todisable end stationtraffic In-Reply-To: <18306.36351.575064.975092@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> James, I agree with you and Anoop on one point: if configuration assumes the absence of end-stations on a local link and end stations are either already present, or are later are added on that local link, then this is a configuration/deployment error. However I disagree that ARP failure is a specific intent of the configuration option mentioned in Donald's "consensus check" or that this is sufficient to somehow "enforce" a network operator's intention that a link should remain "end-station free." Certainly ARP will not work, but neither will any other broadcast or (non-IP) multicast based application or protocol. That is essentially a side effect, however, and not the intent of the consensus originally proposed. In the original proposed consensus (which I notice has been removed from this thread), the intention was to eliminate wasteful forwarding to a link that contains no end-stations. While I believe the consensus proposal has been misworded in such a way that it implies configuration would be used to indicate that a link has no end-stations, merely disabling the forwarding of ARP (and other similar traffic) will not prevent end-stations from being added to a link - and working on that link - nor will it necessarily prevent existing end-stations from continuing to work on such a link. Hence configuring an RBridge to disable certain types of presumed wasteful traffic forwarding on a link is orthogonal to indentifying that link as end-station free. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > Sent: Monday, January 07, 2008 3:39 PM > To: Joe Touch > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Configure ports > todisable end stationtraffic > > Joe Touch writes: > > I'm concerned about the case where an end station moves and doesn't > > announce itself. There's no requirement in ethernet to do > so, and such a > > station would never be discovered if we don't flood > broadcast to all links. > > > > I.e., the optimization below is a recipe for ARP failure in > such cases. > > I disagree with it. > > That "failure" is exactly the intent. > > In other words, if you connect an end station to a special internal > network that is intentionally designed by a network administrator > _not_ to have end stations on it at all (which is what this > configuration option specifies), then you've made a mistake, and you > should _expect_ the node's attempts to communicate to fail miserably. > > Obviously, the default should be to forward these messages (ports > can't be "TRILL-only" type by default), but why try to prohibit > implementations from offering an option if vendors so choose? ARP > failure modes for nodes that shouldn't be there at all shouldn't be a > reason for a prohibition. > > On the consensus proposal, I don't see a real reason why a description > of such an option needs to be in the spec -- it seems to me that an > implementation could provide such a feature under the guise of a > "local optimization" without needing this group's permission to do so > -- but if it is going to be there as an option, I'd weakly support it. > (Really ... do we think we can outlaw vendor features or that we need > to explicitly endorse each one?) > > (I say "weakly" because _every_ option added increases complexity, and > that's one of the important problems. But if it's somehow crucial, > then ok.) > > -- > 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 james.d.carlson at sun.com Tue Jan 8 11:51:15 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 8 Jan 2008 14:51:15 -0500 Subject: [rbridge] Consensus Check: Configure ports todisable end stationtraffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> Message-ID: <18307.54323.323114.728064@gargle.gargle.HOWL> Eric Gray writes: > However I disagree that ARP failure is a specific intent > of the configuration option mentioned in Donald's "consensus > check" or that this is sufficient to somehow "enforce" a network > operator's intention that a link should remain "end-station free." [...] > Hence configuring an RBridge to disable certain types of > presumed wasteful traffic forwarding on a link is orthogonal to > indentifying that link as end-station free. I don't think it's quite orthogonal. The two are related in that if you "optimize" away this "wasteful" traffic, you necessarily also break the operation of any ordinary end stations that may be present on that link, as Joe Touch was correctly pointing out. Those nodes can't work normally, so you're already partway down the path to breaking those nodes intentionally. But fair enough to observe that there are two different intents here. I think Anoop was arguing more forcefully in favor of having a more generic (and thus simpler) "no end-station on this link" option on the theory that some links may be "known" (by an administrator) to be on the inside of a network, and thus optimizing all of the end-station- related behavior away would be useful for some implementations. It seems particularly attractive given that TRILL wants to encapsulate things. If we were "only" bridging, this wouldn't be an issue. I'd be ok with either intended option, but would slightly prefer not bothering to document this special link behavior, as it looks to me to be the sort of enhancement that vendors could cook up on their own without affecting either TRILL interoperability or ordinary RBridge operation. It's not something I think is strictly _needed_ in the TRILL document in order to make it complete ... though it seems Anoop does. -- 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 Tue Jan 8 12:16:53 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Jan 2008 14:16:53 -0600 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023A80D5@eusrcmw721.eamcs.ericsson.se> Donald, The wording of this is ambiguous and the intention is therefore not clear. What it appears like people are arguing for is the option to exclude - via configuration - any port from the flooding or other broadcast/multicast traffic. One reason for doing this might be that the network operator is certain that there are not and never will be end-stations associated with this link. This is merely one reason. As I mentioned in response to James' comment, disabling flooding, and forwarding of other forms of broadcast/multicast traffic does not necessarily preclude attachment of many of today's end-stations (although disabling ARP responses would make it more difficult, as would bi-directionally disabling broadcast forwarding). Hence configuring a port to disable flooding for that port and configuring a port to say there are no end-stations is not exactly that same thing. Further, the proposed consensus is unclear on the scope to which it might apply. I assume that the intention is only to apply this on egress from the RBridge domain onto a legacy Ethernet link. If this is the case, however, that should be explicitly stated as part of the proposed consensus. However, even if this is the case, it clearly must be the case that we are assuming no similar technology is also connected to this same link - and the link is in fact a stub with respect to every VLAN with which it is associated - or we face the situation in which we don't forward broadcast or flooded messages some other technology relies on to discover topological pathologies itself - in the event of accidental connections. Also, the proposed consensus is unclear on the impact that declaring a port as transit only would have on non-IP multicast traffic Frankly, I believe the proposed consensus would be more clear and acceptable if it implied less. For example, I would find something along these lines more acceptable: "Forwarding of flooded and/broadcast frames on every port associated with a VLAN, or every port in a LAN, except the port on which it was received is the default case. However, it is possible to preclude forwarding of this traffic for any port on which it is not required - via configuration, for example." Naturally, this also would need to be explicitly defined to apply only to RBridge egress. And even in this case, I have to wonder why we need to say anything at all on this topic. This strikes me as being pretty much out of scope, since it relates to behavior that does not impact RBridge interoperability in any way. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Monday, January 07, 2008 1:34 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Configure ports to > disable end stationtraffic > > This is a check via the mailing list to confirm or refute an apparent > consensus at the Vancouver meeting taken from the minutes of that > meeting: > > Currently broadcast, unknown unicast, and > non-IP-derived multicast frames are output to all links. This is > wasteful if there are no end stations on the link. Provide that > a port can be configured so as to be disabled for end station > traffic. > > If no particular controversy arises over this in the next three weeks, > We will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Tue Jan 8 15:51:37 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Jan 2008 17:51:37 -0600 Subject: [rbridge] Consensus Check: Configure ports todisable endstationtraffic In-Reply-To: <18307.54323.323114.728064@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> James, Perhaps not quite orthogonal, but definitely not 100 % correlated. I disagree that you would necessarily break the normal operation of end-stations running on the link. I thought I had said that previosuly, so maybe I am not getting your point. However, I am pretty sure Joe was talking about "silent end stations" which is pretty far from the "normal case" these days. Many of today's end stations would work, as long as you don't explicitly disable ARP (as in both sending requests and receiving responses) because many of them do not rely on being discovered by flooding. Also, the notion of "known to be on the inside of the network" is a trap people fall into if they were not listening to the discussion in this working group from 18 to 24 months ago in which the point was made on several occasions that the intended "topological" notion of "inside the network" is not actually topological at all. Connect two links that appear to be "outside of the network" and they are now "inside of the network." The apparent "connection" of two or more "outside links" is a normal occurrence during network startup. Connection or disconnection of physical links is something that an operator may not have direct control over. However, I agree that this is something that should be out of scope (avoiding these discussions entirely). And for mostly the same reasons. But I also thought I said that already too... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Tuesday, January 08, 2008 2:51 PM > To: Eric Gray > Cc: Joe Touch; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Configure ports > todisable endstationtraffic > Importance: High > > Eric Gray writes: > > However I disagree that ARP failure is a specific intent > > of the configuration option mentioned in Donald's "consensus > > check" or that this is sufficient to somehow "enforce" a network > > operator's intention that a link should remain "end-station free." > [...] > > Hence configuring an RBridge to disable certain types of > > presumed wasteful traffic forwarding on a link is orthogonal to > > indentifying that link as end-station free. > > I don't think it's quite orthogonal. The two are related in that if > you "optimize" away this "wasteful" traffic, you necessarily also > break the operation of any ordinary end stations that may be present > on that link, as Joe Touch was correctly pointing out. Those nodes > can't work normally, so you're already partway down the path to > breaking those nodes intentionally. > > But fair enough to observe that there are two different intents here. > I think Anoop was arguing more forcefully in favor of having a more > generic (and thus simpler) "no end-station on this link" option on the > theory that some links may be "known" (by an administrator) to be on > the inside of a network, and thus optimizing all of the end-station- > related behavior away would be useful for some implementations. > > It seems particularly attractive given that TRILL wants to encapsulate > things. If we were "only" bridging, this wouldn't be an issue. > > I'd be ok with either intended option, but would slightly prefer not > bothering to document this special link behavior, as it looks to me to > be the sort of enhancement that vendors could cook up on their own > without affecting either TRILL interoperability or ordinary RBridge > operation. It's not something I think is strictly _needed_ in the > TRILL document in order to make it complete ... though it seems Anoop > does. > > -- > 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 touch at ISI.EDU Tue Jan 8 16:11:40 2008 From: touch at ISI.EDU (Joe Touch) Date: Tue, 08 Jan 2008 16:11:40 -0800 Subject: [rbridge] Consensus Check: Configure ports todisable endstationtraffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> Message-ID: <4784113C.6040906@isi.edu> Eric Gray wrote: > James, > > Perhaps not quite orthogonal, but definitely not > 100 % correlated. > > I disagree that you would necessarily break the > normal operation of end-stations running on the link. > I thought I had said that previosuly, so maybe I am > not getting your point. However, I am pretty sure > Joe was talking about "silent end stations" which is > pretty far from the "normal case" these days. Keep in mind that a station may not know it moved. Sure, if its ether cable is disconnected at the end station, the most common current implemetations will announce themselves when reconnected. But users can move a hub without disrupting connectivity at an end station, and nodes would never re-announce themselves in that case. I.e., AFAICT this is the normal case when moving a hub. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080108/4f216a50/signature.bin From anoop at brocade.com Tue Jan 8 18:18:11 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 8 Jan 2008 18:18:11 -0800 Subject: [rbridge] Consensus Check: Configure portstodisable end stationtraffic In-Reply-To: <18307.54323.323114.728064@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> Message-ID: <4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > Sent: Tuesday, January 08, 2008 11:51 AM > To: Eric Gray > Cc: Rbridge at postel.org; Joe Touch > Subject: Re: [rbridge] Consensus Check: Configure > portstodisable end stationtraffic > > I'd be ok with either intended option, but would slightly > prefer not bothering to document this special link behavior, > as it looks to me to be the sort of enhancement that vendors > could cook up on their own without affecting either TRILL > interoperability or ordinary RBridge operation. It's not > something I think is strictly _needed_ in the TRILL document > in order to make it complete ... though it seems Anoop does. I agree it's not absolutely needed, but now that we have discussed it on the mailing list, that we know it's useful, and that we know the potential problems, we might as well document it so we don't have to depend on every implementer figuring it out for themselves. Anoop From eric.gray at ericsson.com Wed Jan 9 05:39:19 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 9 Jan 2008 07:39:19 -0600 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> Anoop, Sorry to have to disagree with your well-intended suggestion, but this is a BAD idea. The fact that we don't need to document it from a interoperability perspective is sufficient reason not to do so. In addition, anything we document because we "know it to be true and useful" we need to be certain is also immutable - even if we also know that we need to include it in the specification. Otherwise, it's a risk we are undertaking that what we "know to be true and useful" will be false or dangerous next year. Hence the fact that we believe we could document it is not sufficient reason to do so. Therefore, to remove any possible ambiguity, the argument to avoid including this is sufficient while the argument to include it is not. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Tuesday, January 08, 2008 9:18 PM > To: James Carlson; Eric Gray > Cc: Rbridge at postel.org; Joe Touch > Subject: RE: [rbridge] Consensus Check: Configure > portstodisable end stationtraffic > Importance: High > > > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > > Sent: Tuesday, January 08, 2008 11:51 AM > > To: Eric Gray > > Cc: Rbridge at postel.org; Joe Touch > > Subject: Re: [rbridge] Consensus Check: Configure > > portstodisable end stationtraffic > > > > > I'd be ok with either intended option, but would slightly > > prefer not bothering to document this special link behavior, > > as it looks to me to be the sort of enhancement that vendors > > could cook up on their own without affecting either TRILL > > interoperability or ordinary RBridge operation. It's not > > something I think is strictly _needed_ in the TRILL document > > in order to make it complete ... though it seems Anoop does. > > I agree it's not absolutely needed, but now that we have > discussed it on the mailing list, that we know it's useful, > and that we know the potential problems, we might as well > document it so we don't have to depend on every implementer > figuring it out for themselves. > > Anoop > From ddutt at cisco.com Wed Jan 9 08:04:39 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 09 Jan 2008 08:04:39 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <18306.36351.575064.975092@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> Message-ID: <4784F097.3090801@cisco.com> I agree with James' position. 802.1d bridges do such optimizations without their being specified in the spec. This seems like a box-specific optimization and I don't see a need for something like this in the spec. Dinesh James Carlson wrote: > Joe Touch writes: > >> I'm concerned about the case where an end station moves and doesn't >> announce itself. There's no requirement in ethernet to do so, and such a >> station would never be discovered if we don't flood broadcast to all links. >> >> I.e., the optimization below is a recipe for ARP failure in such cases. >> I disagree with it. >> > > That "failure" is exactly the intent. > > In other words, if you connect an end station to a special internal > network that is intentionally designed by a network administrator > _not_ to have end stations on it at all (which is what this > configuration option specifies), then you've made a mistake, and you > should _expect_ the node's attempts to communicate to fail miserably. > > Obviously, the default should be to forward these messages (ports > can't be "TRILL-only" type by default), but why try to prohibit > implementations from offering an option if vendors so choose? ARP > failure modes for nodes that shouldn't be there at all shouldn't be a > reason for a prohibition. > > On the consensus proposal, I don't see a real reason why a description > of such an option needs to be in the spec -- it seems to me that an > implementation could provide such a feature under the guise of a > "local optimization" without needing this group's permission to do so > -- but if it is going to be there as an option, I'd weakly support it. > (Really ... do we think we can outlaw vendor features or that we need > to explicitly endorse each one?) > > (I say "weakly" because _every_ option added increases complexity, and > that's one of the important problems. But if it's somehow crucial, > then ok.) > > -- 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 Wed Jan 9 08:06:34 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 09 Jan 2008 08:06:34 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> Message-ID: <4784F10A.2090302@cisco.com> I concur with Eric, Dinesh Eric Gray wrote: > Anoop, > > Sorry to have to disagree with your well-intended > suggestion, but this is a BAD idea. > > The fact that we don't need to document it from a > interoperability perspective is sufficient reason not to > do so. > > In addition, anything we document because we "know > it to be true and useful" we need to be certain is also > immutable - even if we also know that we need to include > it in the specification. Otherwise, it's a risk we are > undertaking that what we "know to be true and useful" > will be false or dangerous next year. > > Hence the fact that we believe we could document it > is not sufficient reason to do so. Therefore, to remove > any possible ambiguity, the argument to avoid including > this is sufficient while the argument to include it is > not. > > -- > Eric Gray > Principal Engineer > Ericsson > > >> -----Original Message----- >> From: Anoop Ghanwani [mailto:anoop at brocade.com] >> Sent: Tuesday, January 08, 2008 9:18 PM >> To: James Carlson; Eric Gray >> Cc: Rbridge at postel.org; Joe Touch >> Subject: RE: [rbridge] Consensus Check: Configure >> portstodisable end stationtraffic >> Importance: High >> >> >> >> >>> -----Original Message----- >>> From: rbridge-bounces at postel.org >>> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson >>> Sent: Tuesday, January 08, 2008 11:51 AM >>> To: Eric Gray >>> Cc: Rbridge at postel.org; Joe Touch >>> Subject: Re: [rbridge] Consensus Check: Configure >>> portstodisable end stationtraffic >>> >>> >>> I'd be ok with either intended option, but would slightly >>> prefer not bothering to document this special link behavior, >>> as it looks to me to be the sort of enhancement that vendors >>> could cook up on their own without affecting either TRILL >>> interoperability or ordinary RBridge operation. It's not >>> something I think is strictly _needed_ in the TRILL document >>> in order to make it complete ... though it seems Anoop does. >>> >> I agree it's not absolutely needed, but now that we have >> discussed it on the mailing list, that we know it's useful, >> and that we know the potential problems, we might as well >> document it so we don't have to depend on every implementer >> figuring it out for themselves. >> >> Anoop >> >> > > _______________________________________________ > 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 Wed Jan 9 08:07:03 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 09 Jan 2008 08:07:03 -0800 Subject: [rbridge] Consensus Check: Allow GVRP/MVRP In-Reply-To: <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> Message-ID: <4784F127.6020603@cisco.com> I concur, Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Vancouver meeting taken from the minutes of that > meeting: > > Remove any text prohibiting implementation > of GVRP or MVRP on RBridges. > > If no particular controversy arises over this in the next three weeks, > We will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > 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 Wed Jan 9 08:18:09 2008 From: james.d.carlson at sun.com (James Carlson) Date: Wed, 9 Jan 2008 11:18:09 -0500 Subject: [rbridge] Consensus Check: Configure ports todisable endstationtraffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> Message-ID: <18308.62401.632012.271374@gargle.gargle.HOWL> Eric Gray writes: > I disagree that you would necessarily break the > normal operation of end-stations running on the link. > I thought I had said that previosuly, so maybe I am > not getting your point. However, I am pretty sure > Joe was talking about "silent end stations" which is > pretty far from the "normal case" these days. Silent end stations are but one instance of the breakage -- and those can actually happen if (as another poster pointed out) there's a repeater or an ordinary bridge in the way that prevents the link up/down transitions that would ordinarily cause chatter. > Many of today's end stations would work, as long > as you don't explicitly disable ARP (as in both sending > requests and receiving responses) because many of them > do not rely on being discovered by flooding. I don't see how that's true. The original message in this thread (lost in context due to odd quoting practices) said this: Currently broadcast, unknown unicast, and non-IP-derived multicast frames are output to all links. This is wasteful if there are no end stations on the link. Provide that a port can be configured so as to be disabled for end station traffic. Suppose we have such a switch, and someone enables it to disable that traffic. If that's done, then: - Broadcast ARP queries from other nodes on other Ethernet subnetworks will not be relayed to this link. There will be no way for other nodes to _find_ the marooned node. - Broadcast ARP probes for address use (duplicate address detection) will not be sent to this link, allowing nodes on other links within the same broadcast domain to use the same IP address, undetected. - Non-IP broadcast messages won't be sent to this link. Any protocols built on broadcast will fail. I'm not sure what functionality you're intending to describe, but it doesn't sound at all to me like this configuration will "work." -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Caitlin.Bestler at neterion.com Wed Jan 9 10:20:38 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Wed, 9 Jan 2008 13:20:38 -0500 Subject: [rbridge] Consensus Check: Configure portstodisable endstationtraffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAABA0@nekter> Eric Gray wrote: > > Also, the notion of "known to be on the inside > of the network" is a trap people fall into if they were > not listening to the discussion in this working group > from 18 to 24 months ago in which the point was made on > several occasions that the intended "topological" notion > of "inside the network" is not actually topological at > all. Connect two links that appear to be "outside of the > network" and they are now "inside of the network." The > apparent "connection" of two or more "outside links" is > a normal occurrence during network startup. Connection > or disconnection of physical links is something that an > operator may not have direct control over. > If all that is required to have a "port known not to do X" actually do X is for an operator to misconnect a cable then I would agree that the RBridge (or Bridge) probably should not be assuming that the cables were inserted properly. That's just dangerous. But there are specialized Bridges where such mis-configurations are simply not physically possible. To cite one example, it is common for Hypervisor's to offer (via a privileged domain such as "Dom 0") a software switch that has internal ports leading to virtual NICs associated with Guest Partitions and the actual external Ethernet ports leading to the real world. No network technician can accidentally plug a Virtual Machine into the Ethernet Port, or vise versa. > However, I agree that this is something that should > be out of scope (avoiding these discussions entirely). > And for mostly the same reasons. But I also thought I > said that already too... > Agreed. The key is that we do no what any RBridge to be forced to do something that is clearly not appropriate given its physical packaging solely because a poorly worded paragraph made it a requirement even though there was no actual benefit to any actual deployment. These special configurations do not need explicit blessing in the draft. Not being anywhere near as familiar with core bridges as I am with edge issues, I am still unclear as to whether "port with no end stations" is an aspiration that a network administrator would like to see (but for which there is no guarantee, and hence equipment should not simply assume that the aspiration will be met) or something inherent (it would be physically absurd to connect end stations off a given link because it inherently is a long-haul link outside the building, or somesuch). From anoop at brocade.com Wed Jan 9 10:30:06 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 9 Jan 2008 10:30:06 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <4784F10A.2090302@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> <4784F10A.2090302@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364ECCD5C3@HQ-EXCH-5.corp.brocade.com> I'd be interested in finding out what caused the editors to send out the consensus check. Obviously there was some discussion about this at the Vancouver meeting and some folks must've thought it was a good idea. (I wasn't at the meeting so I don't know who supported this.) While I don't feel very strongly about having to put this in the document, I think it would be useful. I disagree that it would be a "BAD idea" to put it in the document - I see it as extra information to help the implementer. Anoop > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Wednesday, January 09, 2008 8:07 AM > To: Eric Gray > Cc: Anoop Ghanwani; James Carlson; Rbridge at postel.org; Joe Touch > Subject: Re: [rbridge] Consensus Check: Configure ports to > disable end station traffic > > I concur with Eric, > > Dinesh > Eric Gray wrote: > > Anoop, > > > > Sorry to have to disagree with your well-intended > suggestion, but > > this is a BAD idea. > > > > The fact that we don't need to document it from a > interoperability > > perspective is sufficient reason not to do so. > > > > In addition, anything we document because we "know it > to be true and > > useful" we need to be certain is also immutable - even if > we also know > > that we need to include it in the specification. Otherwise, it's a > > risk we are undertaking that what we "know to be true and useful" > > will be false or dangerous next year. > > > > Hence the fact that we believe we could document it is > not sufficient > > reason to do so. Therefore, to remove any possible ambiguity, the > > argument to avoid including this is sufficient while the > argument to > > include it is not. > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > >> -----Original Message----- > >> From: Anoop Ghanwani [mailto:anoop at brocade.com] > >> Sent: Tuesday, January 08, 2008 9:18 PM > >> To: James Carlson; Eric Gray > >> Cc: Rbridge at postel.org; Joe Touch > >> Subject: RE: [rbridge] Consensus Check: Configure > portstodisable end > >> stationtraffic > >> Importance: High > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: rbridge-bounces at postel.org > >>> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > >>> Sent: Tuesday, January 08, 2008 11:51 AM > >>> To: Eric Gray > >>> Cc: Rbridge at postel.org; Joe Touch > >>> Subject: Re: [rbridge] Consensus Check: Configure > portstodisable end > >>> stationtraffic > >>> > >>> > >>> I'd be ok with either intended option, but would slightly > prefer not > >>> bothering to document this special link behavior, as it > looks to me > >>> to be the sort of enhancement that vendors could cook up on their > >>> own without affecting either TRILL interoperability or ordinary > >>> RBridge operation. It's not something I think is > strictly _needed_ > >>> in the TRILL document in order to make it complete ... though it > >>> seems Anoop does. > >>> > >> I agree it's not absolutely needed, but now that we have > discussed it > >> on the mailing list, that we know it's useful, and that we > know the > >> potential problems, we might as well document it so we > don't have to > >> depend on every implementer figuring it out for themselves. > >> > >> Anoop > >> > >> > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > -- > We make our world significant by the courage of our questions and by > the depth of our answers. - Carl Sagan > > From anoop at brocade.com Wed Jan 9 10:56:18 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 9 Jan 2008 10:56:18 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <18309.5481.845012.208242@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL><4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com><941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se><4784F10A.2090302@cisco.com><4C94DE2070B172459E4F1EE14BD2364ECCD5C3@HQ-EXCH-5.corp.brocade.com> <18309.5481.845012.208242@gargle.gargle.HOWL> Message-ID: <4C94DE2070B172459E4F1EE14BD2364ECCD5DA@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Wednesday, January 09, 2008 10:42 AM > To: Anoop Ghanwani > Cc: Dinesh G Dutt; Eric Gray; Rbridge at postel.org; Joe Touch > Subject: RE: [rbridge] Consensus Check: Configure ports to > disable end station traffic > > Anoop Ghanwani writes: > > I'd be interested in finding out what caused the editors to > send out > > the consensus check. Obviously there was some discussion > about this > > at the Vancouver meeting and some folks must've thought it > was a good > > idea. > > Please clarify. Do you mean the rationale that the proposers > had for including the feature in the specification at all or > literally the reason for sending the confirmation email message? > > If it's the latter, I don't understand. Official business of > the IETF needs to take place on mailing lists, not in the > limited confines of in-person meetings. See RFC 2418. It's the latter...I'm wondering where the idea of putting this in originated because I didn't see anything about it on the list until the consensus check was sent out, and it must've been something at the meeting that prompted the consensus check. Anoop From james.d.carlson at sun.com Wed Jan 9 10:41:45 2008 From: james.d.carlson at sun.com (James Carlson) Date: Wed, 9 Jan 2008 13:41:45 -0500 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364ECCD5C3@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> <4784F10A.2090302@cisco.com> <4C94DE2070B172459E4F1EE14BD2364ECCD5C3@HQ-EXCH-5.corp.brocade.com> Message-ID: <18309.5481.845012.208242@gargle.gargle.HOWL> Anoop Ghanwani writes: > I'd be interested in finding out what caused the editors > to send out the consensus check. Obviously there was > some discussion about this at the Vancouver meeting and > some folks must've thought it was a good idea. Please clarify. Do you mean the rationale that the proposers had for including the feature in the specification at all or literally the reason for sending the confirmation email message? If it's the latter, I don't understand. Official business of the IETF needs to take place on mailing lists, not in the limited confines of in-person meetings. See RFC 2418. -- 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 Wed Jan 9 11:47:37 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 9 Jan 2008 13:47:37 -0600 Subject: [rbridge] Consensus Check: Configure ports todisableendstationtraffic In-Reply-To: <18308.62401.632012.271374@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> <18308.62401.632012.271374@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023A8B0E@eusrcmw721.eamcs.ericsson.se> James, Please see below... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Wednesday, January 09, 2008 11:18 AM > To: Eric Gray > Cc: Joe Touch; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Configure ports > todisableendstationtraffic > Importance: High > > Eric Gray writes: > > I disagree that you would necessarily break the > > normal operation of end-stations running on the link. > > I thought I had said that previosuly, so maybe I am > > not getting your point. However, I am pretty sure > > Joe was talking about "silent end stations" which is > > pretty far from the "normal case" these days. > > Silent end stations are but one instance of the breakage -- and those > can actually happen if (as another poster pointed out) there's a > repeater or an ordinary bridge in the way that prevents the link > up/down transitions that would ordinarily cause chatter. > > > Many of today's end stations would work, as long > > as you don't explicitly disable ARP (as in both sending > > requests and receiving responses) because many of them > > do not rely on being discovered by flooding. > > I don't see how that's true. The original message in this thread > (lost in context due to odd quoting practices) said this: > > Currently broadcast, unknown unicast, and > non-IP-derived multicast frames are output to all links. This is > wasteful if there are no end stations on the link. Provide that > a port can be configured so as to be disabled for end station > traffic. > > Suppose we have such a switch, and someone enables it to disable that > traffic. > > If that's done, then: > > - Broadcast ARP queries from other nodes on other Ethernet > subnetworks will not be relayed to this link. There will be no > way for other nodes to _find_ the marooned node. That is not strictly true in many cases. For example, if the "marooned node" has used DHCP to obtain an IP address and the information for the default router, DNS server, etc. - then it will be in the bridge (and presumably RBridge) forwarding tables, and if the DHCP server is also the local LAN's default router (or, in many cases, any router), then it will have the MAC<->IP address mapping to respond to an ARP request from anywhere else. This is the common case in many enterprise networks. Note that - if broadcast traffic is bi-directionaally disabled, then the DHCP request will not have been forwarded and the end station ("marooned node") will truly be marooned. However, I suggest that this could be a very bad idea over the long run. This could break things that work today and will very probably break things (or make it difficult to work around) in anything new proposed - for example - by IEEE. > > - Broadcast ARP probes for address use (duplicate address detection) > will not be sent to this link, allowing nodes on other links > within the same broadcast domain to use the same IP address, > undetected. Again, this is difficult to imagine unless the "marooned node" is unable to contact the DHCP server, or DHCP is not in use. > > - Non-IP broadcast messages won't be sent to this link. Any > protocols built on broadcast will fail. Yes - at least to the extent that the "marooned node" counts on receiving broadcast messages. And? Given the prevalence of VLAN technologies, and the detrimental effect that broadcast-based protocols have in a VLAN environment, how common is it in today's networks for workstations to use many protocols that uses broadcast for both query and response? > > I'm not sure what functionality you're intending to describe, but it > doesn't sound at all to me like this configuration will "work." Try it in your home network, if you can. Better yet, use Ethereal to see what happens when you add a laptop to your local network. Chances are you will see only one broadcast message associated with adding the laptop and that will be coming from it, not going to it. Also, once you start using the laptop, it may send one or more ARP queries to your default router (or it may simply forward everything to the default router's MAC, which it may have acquired from the DHCP response, and rely on IP re-directs if necessary). Again, broadcast messages come from the "marooned node" instead of going to it. If you let the laptop stay idle long enough, it may get lost from bridge/switch forwarding tables. But even if this happens, it is very likely that the user will release and re-acquire an IP address (via the DHCP server) - or reboot - and all will be well. Note that the need to do that is not uncommon for some operating systems as it is. Meanwhile, if you were thinking that merely disabling forwarding of broadcast traffic to a link would prevent someone (e.g. - a hacker) from putting an end-station on the link and accessing the network, you should think again. This is especially true if the person in question merely wants to access the network for a short period of time and then leave. It will "work", sometimes without special effort, but almost any time with some minimal amount of manual configuration at the end station being inserted. > > -- > 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 Wed Jan 9 11:53:46 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 9 Jan 2008 13:53:46 -0600 Subject: [rbridge] Consensus Check: Configure ports todisable endstationtraffic In-Reply-To: <4784113C.6040906@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> <4784113C.6040906@isi.edu> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023A8B23@eusrcmw721.eamcs.ericsson.se> Joe, That being the case, it is likely that I have unfairly blamed the OS when I've been obliged to use "ipconfig /release" and "ipconfig /renew" because I can't get a response from the network. :-) -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Tuesday, January 08, 2008 7:12 PM > To: Eric Gray > Cc: James Carlson; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Configure ports > todisable endstationtraffic > Importance: High > > * PGP Signed: 01/09/2008 at 01:11:41 AM > > > Eric Gray wrote: > > James, > > > > Perhaps not quite orthogonal, but definitely not > > 100 % correlated. > > > > I disagree that you would necessarily break the > > normal operation of end-stations running on the link. > > I thought I had said that previosuly, so maybe I am > > not getting your point. However, I am pretty sure > > Joe was talking about "silent end stations" which is > > pretty far from the "normal case" these days. > > Keep in mind that a station may not know it moved. Sure, if its ether > cable is disconnected at the end station, the most common current > implemetations will announce themselves when reconnected. But > users can > move a hub without disrupting connectivity at an end station, > and nodes > would never re-announce themselves in that case. > > I.e., AFAICT this is the normal case when moving a hub. > > Joe > > * Joe Touch > * 0x89A766BB > > From Caitlin.Bestler at neterion.com Wed Jan 9 12:33:34 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Wed, 9 Jan 2008 15:33:34 -0500 Subject: [rbridge] Consensus Check: Configure ports to disable endstation traffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL><4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAAC5E@nekter> > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eric Gray > Sent: Wednesday, January 09, 2008 5:39 AM > To: Anoop Ghanwani; James Carlson > Cc: Rbridge at postel.org; Joe Touch > Subject: Re: [rbridge] Consensus Check: Configure ports to disable > endstation traffic > > Anoop, > > Sorry to have to disagree with your well-intended > suggestion, but this is a BAD idea. > > The fact that we don't need to document it from a > interoperability perspective is sufficient reason not to > do so. > Would it make sense to go as far as to state that any implementation-specific optimizations on frame forwarding that are appropriate for a 802.1 Bridge are appropriate for an RBRidge? From james.d.carlson at sun.com Wed Jan 9 12:04:29 2008 From: james.d.carlson at sun.com (James Carlson) Date: Wed, 9 Jan 2008 15:04:29 -0500 Subject: [rbridge] Consensus Check: Configure ports todisableendstationtraffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023A8B0E@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> <18308.62401.632012.271374@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A8B0E@eusrcmw721.eamcs.ericsson.se> Message-ID: <18309.10445.145190.729328@gargle.gargle.HOWL> Eric Gray writes: > > -----Original Message----- > > From: James Carlson [mailto:james.d.carlson at sun.com] [...] > > If that's done, then: > > > > - Broadcast ARP queries from other nodes on other Ethernet > > subnetworks will not be relayed to this link. There will be no > > way for other nodes to _find_ the marooned node. > > That is not strictly true in many cases. For example, if the > "marooned node" has used DHCP to obtain an IP address and the > information for the default router, DNS server, etc. - then > it will be in the bridge (and presumably RBridge) forwarding > tables, and if the DHCP server is also the local LAN's default > router (or, in many cases, any router), then it will have the > MAC<->IP address mapping to respond to an ARP request from > anywhere else. Who is generating that ARP response? It can't be the marooned node, because the ARP request itself is a broadcast, which (by definition of this new feature) is not propagated onto the feature-limited link. Thus, it sounds like you're talking about some sort of proxy ARP within a bridged network. I suppose that's "possible" but I would have a hard time calling it anything other than "extraordinary." > This is the common case in many enterprise networks. Generating an ARP response on behalf of a node that's bridged but can't see the original ARP request is "common?" Not in any of the networks I work on. The only case I know of is with proxy-ARP'd PPP links, but I don't think we're talking about that sort of situation. > Note that - if broadcast traffic is bi-directionaally disabled, > then the DHCP request will not have been forwarded and the end > station ("marooned node") will truly be marooned. Some DHCP servers generate broadcast responses and others generate unicast only. It depends. :-< > However, I > suggest that this could be a very bad idea over the long run. > This could break things that work today and will very probably > break things (or make it difficult to work around) in anything > new proposed - for example - by IEEE. Certainly ... and the existence of that breakage does in fact leave that node "broken," which was my original claim. It's broken anyway, so we might as well assume that the admin was smart enough not to put it there. It's not much different from assuming that he knows enough to apply power, and to plug the Ethernet wire into the network rather than the PBX line. > > - Broadcast ARP probes for address use (duplicate address detection) > > will not be sent to this link, allowing nodes on other links > > within the same broadcast domain to use the same IP address, > > undetected. > > Again, this is difficult to imagine unless the "marooned node" > is unable to contact the DHCP server, or DHCP is not in use. It's by definition of the proposed configuration option we've been discussing. When configured in this way, broadcast messages will not be sent to that link. The existence or use of DHCP is immaterial. > > - Non-IP broadcast messages won't be sent to this link. Any > > protocols built on broadcast will fail. > > Yes - at least to the extent that the "marooned node" counts on > receiving broadcast messages. And? ... and it's broken. > Given the prevalence of VLAN technologies, and the detrimental > effect that broadcast-based protocols have in a VLAN environment, > how common is it in today's networks for workstations to use many > protocols that uses broadcast for both query and response? "Very." What do VLANs have to do with anything at all? Broadcast works fine on VLANs. > > I'm not sure what functionality you're intending to describe, but it > > doesn't sound at all to me like this configuration will "work." > > Try it in your home network, if you can. Better yet, use Ethereal > to see what happens when you add a laptop to your local network. > > Chances are you will see only one broadcast message associated with > adding the laptop and that will be coming from it, not going to it. I'm snooping broadcast right now, and I see a bunch of traffic. I really don't understand what you're saying. -- 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 Wed Jan 9 12:27:59 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 9 Jan 2008 14:27:59 -0600 Subject: [rbridge] Consensus Check: Configure ports todisableendstationtraffic In-Reply-To: <18309.10445.145190.729328@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se><18308.62401.632012.271374@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A8B0E@eusrcmw721.eamcs.ericsson.se> <18309.10445.145190.729328@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023DC2BE@eusrcmw721.eamcs.ericsson.se> James, Given that we (and a number of others) seem to agree that this should not be included in the specification - for whatever reason - than the fact that we don't seem to be understanding each other's point is a good reason to just let this drop. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Wednesday, January 09, 2008 3:04 PM > To: Eric Gray > Cc: Joe Touch; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Configure ports > todisableendstationtraffic > Importance: High > > Eric Gray writes: > > > -----Original Message----- > > > From: James Carlson [mailto:james.d.carlson at sun.com] > [...] > > > If that's done, then: > > > > > > - Broadcast ARP queries from other nodes on other Ethernet > > > subnetworks will not be relayed to this link. There > will be no > > > way for other nodes to _find_ the marooned node. > > > > That is not strictly true in many cases. For example, if the > > "marooned node" has used DHCP to obtain an IP address and the > > information for the default router, DNS server, etc. - then > > it will be in the bridge (and presumably RBridge) forwarding > > tables, and if the DHCP server is also the local LAN's default > > router (or, in many cases, any router), then it will have the > > MAC<->IP address mapping to respond to an ARP request from > > anywhere else. > > Who is generating that ARP response? > > It can't be the marooned node, because the ARP request itself is a > broadcast, which (by definition of this new feature) is not propagated > onto the feature-limited link. > > Thus, it sounds like you're talking about some sort of proxy ARP > within a bridged network. I suppose that's "possible" but I would > have a hard time calling it anything other than "extraordinary." > > > This is the common case in many enterprise networks. > > Generating an ARP response on behalf of a node that's bridged but > can't see the original ARP request is "common?" Not in any of the > networks I work on. The only case I know of is with proxy-ARP'd PPP > links, but I don't think we're talking about that sort of situation. > > > Note that - if broadcast traffic is bi-directionaally disabled, > > then the DHCP request will not have been forwarded and the end > > station ("marooned node") will truly be marooned. > > Some DHCP servers generate broadcast responses and others generate > unicast only. It depends. :-< > > > However, I > > suggest that this could be a very bad idea over the long run. > > This could break things that work today and will very probably > > break things (or make it difficult to work around) in anything > > new proposed - for example - by IEEE. > > Certainly ... and the existence of that breakage does in fact leave > that node "broken," which was my original claim. It's broken anyway, > so we might as well assume that the admin was smart enough not to put > it there. It's not much different from assuming that he knows enough > to apply power, and to plug the Ethernet wire into the network rather > than the PBX line. > > > > - Broadcast ARP probes for address use (duplicate > address detection) > > > will not be sent to this link, allowing nodes on other links > > > within the same broadcast domain to use the same IP address, > > > undetected. > > > > Again, this is difficult to imagine unless the "marooned node" > > is unable to contact the DHCP server, or DHCP is not in use. > > It's by definition of the proposed configuration option we've been > discussing. When configured in this way, broadcast messages will not > be sent to that link. The existence or use of DHCP is immaterial. > > > > - Non-IP broadcast messages won't be sent to this link. Any > > > protocols built on broadcast will fail. > > > > Yes - at least to the extent that the "marooned node" counts on > > receiving broadcast messages. And? > > ... and it's broken. > > > Given the prevalence of VLAN technologies, and the detrimental > > effect that broadcast-based protocols have in a VLAN environment, > > how common is it in today's networks for workstations to use many > > protocols that uses broadcast for both query and response? > > "Very." > > What do VLANs have to do with anything at all? Broadcast works fine > on VLANs. > > > > I'm not sure what functionality you're intending to > describe, but it > > > doesn't sound at all to me like this configuration will "work." > > > > Try it in your home network, if you can. Better yet, use Ethereal > > to see what happens when you add a laptop to your local network. > > > > Chances are you will see only one broadcast message associated with > > adding the laptop and that will be coming from it, not going to it. > > I'm snooping broadcast right now, and I see a bunch of traffic. > > I really don't understand what you're saying. > > -- > 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 Wed Jan 9 12:52:35 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 9 Jan 2008 14:52:35 -0600 Subject: [rbridge] Consensus Check: Configure ports to disable endstation traffic In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7702CAAC5E@nekter> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL><4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se> <78C9135A3D2ECE4B8162EBDCE82CAD7702CAAC5E@nekter> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023DC315@eusrcmw721.eamcs.ericsson.se> Not especially. Personally, I think that statement may be true, but I shy away from including it in the specification. To a certain extent, that would be a motherhood and apple pie statement that - unfortunately - might not be true all of the time. Plus, in this case, there is still no particular issue with respect to interoperability between RBridges that is addressed by this specific aspect of forwarding at the egress. Given that it is not hard to determine that there are a large number of things (implementation specific optimizations) that are okay (they seem to work at least in some deployments) for 802.1 bridges that may have to be considered before we could make such a statement, and no really relevant reason to make it, the sensible thing to do would be to remain silent on that score. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Caitlin Bestler [mailto:Caitlin.Bestler at neterion.com] > Sent: Wednesday, January 09, 2008 3:34 PM > To: Eric Gray; Anoop Ghanwani; James Carlson > Cc: Rbridge at postel.org; Joe Touch > Subject: RE: [rbridge] Consensus Check: Configure ports to > disable endstation traffic > Importance: High > > > > > -----Original Message----- > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > On > > Behalf Of Eric Gray > > Sent: Wednesday, January 09, 2008 5:39 AM > > To: Anoop Ghanwani; James Carlson > > Cc: Rbridge at postel.org; Joe Touch > > Subject: Re: [rbridge] Consensus Check: Configure ports to disable > > endstation traffic > > > > Anoop, > > > > Sorry to have to disagree with your well-intended > > suggestion, but this is a BAD idea. > > > > The fact that we don't need to document it from a > > interoperability perspective is sufficient reason not to > > do so. > > > > Would it make sense to go as far as to state that any > implementation-specific optimizations on frame forwarding > that are appropriate for a 802.1 Bridge are appropriate > for an RBRidge? > > > From james.d.carlson at sun.com Wed Jan 9 12:32:15 2008 From: james.d.carlson at sun.com (James Carlson) Date: Wed, 9 Jan 2008 15:32:15 -0500 Subject: [rbridge] Consensus Check: Configure ports todisableendstationtraffic In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF023DC2BE@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se> <18307.54323.323114.728064@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A838E@eusrcmw721.eamcs.ericsson.se> <18308.62401.632012.271374@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023A8B0E@eusrcmw721.eamcs.ericsson.se> <18309.10445.145190.729328@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF023DC2BE@eusrcmw721.eamcs.ericsson.se> Message-ID: <18309.12111.749249.612417@gargle.gargle.HOWL> Eric Gray writes: > Given that we (and a number of others) seem to agree that > this should not be included in the specification - for whatever > reason - than the fact that we don't seem to be understanding > each other's point is a good reason to just let this drop. I'll certainly agree with that. -- 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 Wed Jan 9 14:16:29 2008 From: james.d.carlson at sun.com (James Carlson) Date: Wed, 9 Jan 2008 17:16:29 -0500 Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic In-Reply-To: <478294D2.6010706@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu> <18306.36351.575064.975092@gargle.gargle.HOWL> <478294D2.6010706@isi.edu> Message-ID: <18309.18365.731448.360292@gargle.gargle.HOWL> Joe Touch writes: > James Carlson wrote: > > Obviously, the default should be to forward these messages (ports > > can't be "TRILL-only" type by default), but why try to prohibit > > implementations from offering an option if vendors so choose? > > No reason. This is fine in that case. The doc should be clear about the > potential for silent misconfiguration in those cases. One possibility would be for implementations that offer this option to listen to traffic on the links on which default broadcast has been disabled. If the implementation sees packets it's not expecting there, then either raise an alarm or simply turn the option flag back off automatically in order to preserve correct operation. That wouldn't be _perfect_, as a quarry of completely silent local nodes would (as described before) fail to operate completely correctly, but it may well be "good enough" for general use, given that most nodes will eventually send some sort of packet once in a while, if only as a lark, and you just need _one_ to detect the misconfiguration. The option proposed is an optimization that reduces duplicate transmissions ... but does so only for traffic that ought to be (by design) very low rate; unknown destinations and broadcast. If it isn't implemented or if it might automatically turn itself back off, it doesn't seem like a substantial problem to me, though I suppose there are a few degenerate large flat networks out there where broadcast more resembles a shower than a mist. -- 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 Wed Jan 9 14:46:43 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 9 Jan 2008 16:46:43 -0600 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364ECCD5DA@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL><4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com><941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se><4784F10A.2090302@cisco.com><4C94DE2070B172459E4F1EE14BD2364ECCD5C3@HQ-EXCH-5.corp.brocade.com> <18309.5481.845012.208242@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364ECCD5DA@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023DC4D5@eusrcmw721.eamcs.ericsson.se> Anoop, Look for "Tentative Consensus" in the presentation on "Changes from -06 to -07", given by Donald Eastlake (III). It's from the minutes available at: http://www3.ietf.org/proceedings/07dec/minutes/trill.txt -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Wednesday, January 09, 2008 1:56 PM > To: James Carlson > Cc: Dinesh G Dutt; Eric Gray; Rbridge at postel.org; Joe Touch > Subject: RE: [rbridge] Consensus Check: Configure ports to > disable end station traffic > > > > > -----Original Message----- > > From: James Carlson [mailto:james.d.carlson at sun.com] > > Sent: Wednesday, January 09, 2008 10:42 AM > > To: Anoop Ghanwani > > Cc: Dinesh G Dutt; Eric Gray; Rbridge at postel.org; Joe Touch > > Subject: RE: [rbridge] Consensus Check: Configure ports to > > disable end station traffic > > > > Anoop Ghanwani writes: > > > I'd be interested in finding out what caused the editors to > > send out > > > the consensus check. Obviously there was some discussion > > about this > > > at the Vancouver meeting and some folks must've thought it > > was a good > > > idea. > > > > Please clarify. Do you mean the rationale that the proposers > > had for including the feature in the specification at all or > > literally the reason for sending the confirmation email message? > > > > If it's the latter, I don't understand. Official business of > > the IETF needs to take place on mailing lists, not in the > > limited confines of in-person meetings. See RFC 2418. > > It's the latter...I'm wondering where the idea of > putting this in originated because I didn't see > anything about it on the list until the consensus > check was sent out, and it must've been something > at the meeting that prompted the consensus check. > > Anoop > From eric.gray at ericsson.com Wed Jan 9 14:59:32 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 9 Jan 2008 16:59:32 -0600 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364ECCD5DA@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com><47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF023A7FE8@eusrcmw721.eamcs.ericsson.se><18307.54323.323114.728064@gargle.gargle.HOWL><4C94DE2070B172459E4F1EE14BD2364ECCD502@HQ-EXCH-5.corp.brocade.com><941D5DCD8C42014FAF70FB7424686DCF023A8514@eusrcmw721.eamcs.ericsson.se><4784F10A.2090302@cisco.com><4C94DE2070B172459E4F1EE14BD2364ECCD5C3@HQ-EXCH-5.corp.brocade.com> <18309.5481.845012.208242@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364ECCD5DA@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023DC4F5@eusrcmw721.eamcs.ericsson.se> Anoop, This is a good question. Hopefully we've all had a chance to look at the minutes. From the minutes, it looks as if we could say two things: 1) there was not anything like an overwhelming consensus even at the meeting and 2) there seems to be some disparity between the wording in this and the apparent meaning given in the discussion about it. For the second point, there is a distinction that is not made clear (in any way) between a link with no end-stations and a point to point link between exactly two RBridges. Also, the minutes do not make clear what happens on discovery of the fact that this configuration is incorrect (the minutes state that the port would be disabled - which hardly strikes me as the most robust thing to do in handling this situation). In defense of the question, there had been prior discussion on the mailing list to allow that RBridges might be configured to recognize that a link is point to point. I am not at all sure there was any basis to call this a "tentative consensus." In the prior discussion on the mailing list, I believe the points that Joe brought up at the meeting were also made (i.e. - it is a soruce for configuration error with no real benefit). On the first point, only one opinion is expressed in the minutes and that opinion is disagreement (Joe's point mentioned above). -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Wednesday, January 09, 2008 1:56 PM > To: James Carlson > Cc: Dinesh G Dutt; Eric Gray; Rbridge at postel.org; Joe Touch > Subject: RE: [rbridge] Consensus Check: Configure ports to > disable end station traffic > > > > > -----Original Message----- > > From: James Carlson [mailto:james.d.carlson at sun.com] > > Sent: Wednesday, January 09, 2008 10:42 AM > > To: Anoop Ghanwani > > Cc: Dinesh G Dutt; Eric Gray; Rbridge at postel.org; Joe Touch > > Subject: RE: [rbridge] Consensus Check: Configure ports to > > disable end station traffic > > > > Anoop Ghanwani writes: > > > I'd be interested in finding out what caused the editors to > > send out > > > the consensus check. Obviously there was some discussion > > about this > > > at the Vancouver meeting and some folks must've thought it > > was a good > > > idea. > > > > Please clarify. Do you mean the rationale that the proposers > > had for including the feature in the specification at all or > > literally the reason for sending the confirmation email message? > > > > If it's the latter, I don't understand. Official business of > > the IETF needs to take place on mailing lists, not in the > > limited confines of in-person meetings. See RFC 2418. > > It's the latter...I'm wondering where the idea of > putting this in originated because I didn't see > anything about it on the list until the consensus > check was sent out, and it must've been something > at the meeting that prompted the consensus check. > > Anoop > From anoop at brocade.com Wed Jan 9 17:19:43 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 9 Jan 2008 17:19:43 -0800 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <4784F097.3090801@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL> <4784F097.3090801@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364ECCD744@HQ-EXCH-5.corp.brocade.com> Well, this can be seen as more than an optimization. It could be seen as a security feature. For example, with 802.1Q bridges, we have configurations for "Admit VLAN-tagged frames" or "Admit all" on each port. This does not affect interoperability in any way. However, it just says that the switch port is not willing to admit untagged traffic. They could have just left this out of the spec and untagged traffic would have gotten the PVID and the world would have done just fine. Going back to the example that has been pointed out by folks where ARP breaks. In 802.1Q, if an end station moves from a port that admits untagged traffic to a port that doesn't admit untagged traffic then things would break there as well. In any case, I don't know why folks are making such a big deal about this. Since it doesn't affect interoperability, it's not required in the spec. But the spec already has TONS of informational material, so I don't see why adding something like this is a problem - something which actually helps the implementer. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt > Sent: Wednesday, January 09, 2008 8:05 AM > To: James Carlson > Cc: Rbridge at postel.org; Joe Touch > Subject: Re: [rbridge] Consensus Check: Configure portsto > disable end stationtraffic > > I agree with James' position. 802.1d bridges do such > optimizations without their being specified in the spec. This > seems like a box-specific optimization and I don't see a need > for something like this in the spec. > > Dinesh > James Carlson wrote: > > Joe Touch writes: > > > >> I'm concerned about the case where an end station moves > and doesn't > >> announce itself. There's no requirement in ethernet to do so, and > >> such a station would never be discovered if we don't flood > broadcast to all links. > >> > >> I.e., the optimization below is a recipe for ARP failure > in such cases. > >> I disagree with it. > >> > > > > That "failure" is exactly the intent. > > > > In other words, if you connect an end station to a special internal > > network that is intentionally designed by a network administrator > > _not_ to have end stations on it at all (which is what this > > configuration option specifies), then you've made a > mistake, and you > > should _expect_ the node's attempts to communicate to fail > miserably. > > > > Obviously, the default should be to forward these messages (ports > > can't be "TRILL-only" type by default), but why try to prohibit > > implementations from offering an option if vendors so choose? ARP > > failure modes for nodes that shouldn't be there at all > shouldn't be a > > reason for a prohibition. > > > > On the consensus proposal, I don't see a real reason why a > description > > of such an option needs to be in the spec -- it seems to me that an > > implementation could provide such a feature under the guise of a > > "local optimization" without needing this group's > permission to do so > > -- but if it is going to be there as an option, I'd weakly > support it. > > (Really ... do we think we can outlaw vendor features or > that we need > > to explicitly endorse each one?) > > > > (I say "weakly" because _every_ option added increases > complexity, and > > that's one of the important problems. But if it's somehow crucial, > > then ok.) > > > > > > -- > 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 Donald.Eastlake at motorola.com Wed Jan 9 20:26:24 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 9 Jan 2008 23:26:24 -0500 Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic In-Reply-To: <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D97900366D3B0@de01exm64.ds.mot.com> Hi, Speaking as co-chair: All "Consensus Check" messages that have been posted here are because there was at least a rough consensus at a meeting and, per IETF procedure, the consensus is being tested on the mailing list. It is then the job of the working group chairs to judge the consensus of the working group based on integrating the meeting and mailing list. There were two distinct proposals presented in Vancouver, one of which is outlined in the message below, and for which there was a consensus in favor at the meeting. The second was a specific proposal for point-2-point links between Rbridges for which I will post a Consensus Check right after this message. This second proposal specified fixed destination and source addresses for a port so configured and the consensus at the meeting was against it. There were several negative comments on the second proposal. Sorry if the minutes are confusing on this point. If it is not too late to change them, I'll try to clarify them. Speaking as a member of the WG: "End station traffic" below means all traffic except (1) TRILL Ethertype frames and (2) link/media control frames (frames with a destination address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F). An end station on a link where all connectivity to the outside world is via one or more Rbridges whose ports to that link are configured to disable such traffic would be completely marooned. It seems likely that there would be a MIB counter for end station frames received on a port that was "disabled" for them but we haven't done any MIB work yet. I was motivated to make this proposal when I recently read the Architecture draft and was thereby reminded that the current TRILL specification requires that all broadcast, unknown unicast, and non-IP-derived multicast are output to every link. In a modern all Rbridged 802.3 campus, one would expect that all links would be Rbridge to end station or Rbridge to Rbridge. Thus, all such frames output on an Rbridge to Rbridge link are completely wasted. The extent of the waste would depend on the percentage of traffic of this type. While keeping such traffic to a small percentage is generally desirable, there may be networks where it is substantial, resulting in a substantial waste of capacity on all Rbridge to Rbridge links. So I believe this capability will be present in essentially all configurable Rbridges. Given this, and the simplicity of the option, my personal opinion is that we should provide for it. In principle you could also disable TRILL traffic. But that does seems like a bad idea. Disabling end station traffic incorrectly would just maroon one or more end stations. Disabling TRILL traffic incorrectly can lead to loops and traffic storms that could bring down part or all of your network. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, January 07, 2008 1:34 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Configure ports to disable end stationtraffic This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Currently broadcast, unknown unicast, and non-IP-derived multicast frames are output to all links. This is wasteful if there are no end stations on the link. Provide that a port can be configured so as to be disabled for end station traffic. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Wed Jan 9 20:27:27 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 9 Jan 2008 23:27:27 -0500 Subject: [rbridge] Consensus Check: Against P2P Fixed Addresses Proposal Message-ID: <3870C46029D1F945B1472F170D2D97900366D3B1@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Against the proposal presented at IETF-70 for p2p link configuration permitting a fixed source and destination address. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Donald.Eastlake at motorola.com Wed Jan 9 20:46:05 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 9 Jan 2008 23:46:05 -0500 Subject: [rbridge] Consensus Check: Milestone Move In-Reply-To: <3870C46029D1F945B1472F170D2D97900366D3B1@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D97900366D3B1@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D97900366D3B9@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Move milestones to March 2008 for Problem Statement and Architecture document. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From eric.gray at ericsson.com Thu Jan 10 08:05:12 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 10 Jan 2008 10:05:12 -0600 Subject: [rbridge] Consensus Check: Configure ports to disable endstation traffic In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364ECCD744@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E0D@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364ECCD0F4@HQ-EXCH-5.corp.brocade.com> <47827E48.7080400@isi.edu><18306.36351.575064.975092@gargle.gargle.HOWL><4784F097.3090801@cisco.com> <4C94DE2070B172459E4F1EE14BD2364ECCD744@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF023DC993@eusrcmw721.eamcs.ericsson.se> Anoop, Please see in-line below... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani > Sent: Wednesday, January 09, 2008 8:20 PM > To: Dinesh G Dutt; James Carlson > Cc: Rbridge at postel.org; Joe Touch > Subject: Re: [rbridge] Consensus Check: Configure ports to > disable endstation traffic > > > Well, this can be seen as more than an optimization. > It could be seen as a security feature. Possibly, but not as originally proposed at the start of this thread. Donald has restated the portion of the proposal that breaks the original statement into two pieces - with one of those pieces being the option to configure a port on an RBridge as one end of a P2P link. You should note two things in Donald's new post: 1) the new proposal does not elaborate on the implications of having a P2P configuration option, it does not state why it might be useful, nor does it state what impact adding this feature would have on the specification; 2) the consensus at the meeting was against including that in the protocol specification. Part of the message, in which he said he was planning to re- state that portion of the consensus call, mentioned that one advantage of allowing this would be an implementation could exclude all traffic that is neither TRILL-encapsulated nor bridging control traffic from ports that might be configured for P2P connection. IFF he were to make that an explicit part of the proposal, THEN you could make the argument that this is a security feature. I don't know whether or not that argument would fly, but you could make it. For it to work, though, the specification would have to be very explicit about what is not allowed - and it would have to deal with both the P2P case and the MP2MP, RBridge only, case OR it would simply not be very effective as a security feature. As it is, most people were under the impression that the reason why this had been brought up previously is that a few of the working members of the WG had proposed use of an abbreviated encapsulation for RBridge links that were strictly point to point. In that case, and with that background, the existence of end-stations on a link was a collateral consideration, since the proposal depended on more than the lack of end-stations - it also required the presence of not more than 2 RBridges on the same link. Apparently, several ideas have been conflated into a single potential approach - configuring a port as one end of a P2P link could allow many things. However, it is also the case that the WG decided that it is not necessary for us to say this in the protocol specification, since it is obvious that many people can think of these things on their own, we are not planning to specify a distinct encapsulation in the P2P case, and it isn't relevant from a protocol interoperability perspective. > > For example, with 802.1Q bridges, we have configurations > for "Admit VLAN-tagged frames" or "Admit all" on each > port. This does not affect interoperability in any > way. However, it just says that the switch port is > not willing to admit untagged traffic. They could > have just left this out of the spec and untagged > traffic would have gotten the PVID and the world > would have done just fine. I think that might be an over-simplification. Having the option to ignore untagged frames allows implementations built to only handle tagged frames to interoperate with other 802.1Q bridges, since requiring the option to turn off forwarding of untagged frames provides a means to ensure that an 802.1Q bridge that doesn't handle untagged frames, doesn't see them. Apparently, there must have been at least one implementer that felt that having the option to ensure only tagged frames show up on core links was important - hence it is necessary to be able to ensure that they can be blocked. That is fairly close to being an interoperability issue. > > Going back to the example that has been pointed > out by folks where ARP breaks. In 802.1Q, if an > end station moves from a port that admits untagged > traffic to a port that doesn't admit untagged traffic > then things would break there as well. Maybe. I believe it is the case that some platform/OS combinations may have the native ability to discover the existing link encapsulation from simple snooping. > > In any case, I don't know why folks are making > such a big deal about this. Since it doesn't affect > interoperability, it's not required in the spec. > But the spec already has TONS of informational > material, so I don't see why adding something > like this is a problem - something which actually > helps the implementer. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt > > Sent: Wednesday, January 09, 2008 8:05 AM > > To: James Carlson > > Cc: Rbridge at postel.org; Joe Touch > > Subject: Re: [rbridge] Consensus Check: Configure portsto > > disable end stationtraffic > > > > I agree with James' position. 802.1d bridges do such > > optimizations without their being specified in the spec. This > > seems like a box-specific optimization and I don't see a need > > for something like this in the spec. > > > > Dinesh > > James Carlson wrote: > > > Joe Touch writes: > > > > > >> I'm concerned about the case where an end station moves > > and doesn't > > >> announce itself. There's no requirement in ethernet to > do so, and > > >> such a station would never be discovered if we don't flood > > broadcast to all links. > > >> > > >> I.e., the optimization below is a recipe for ARP failure > > in such cases. > > >> I disagree with it. > > >> > > > > > > That "failure" is exactly the intent. > > > > > > In other words, if you connect an end station to a > special internal > > > network that is intentionally designed by a network administrator > > > _not_ to have end stations on it at all (which is what this > > > configuration option specifies), then you've made a > > mistake, and you > > > should _expect_ the node's attempts to communicate to fail > > miserably. > > > > > > Obviously, the default should be to forward these messages (ports > > > can't be "TRILL-only" type by default), but why try to prohibit > > > implementations from offering an option if vendors so > choose? ARP > > > failure modes for nodes that shouldn't be there at all > > shouldn't be a > > > reason for a prohibition. > > > > > > On the consensus proposal, I don't see a real reason why a > > description > > > of such an option needs to be in the spec -- it seems to > me that an > > > implementation could provide such a feature under the guise of a > > > "local optimization" without needing this group's > > permission to do so > > > -- but if it is going to be there as an option, I'd weakly > > support it. > > > (Really ... do we think we can outlaw vendor features or > > that we need > > > to explicitly endorse each one?) > > > > > > (I say "weakly" because _every_ option added increases > > complexity, and > > > that's one of the important problems. But if it's > somehow crucial, > > > then ok.) > > > > > > > > > > -- > > 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 > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Donald.Eastlake at motorola.com Sun Jan 13 19:56:31 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 13 Jan 2008 22:56:31 -0500 Subject: [rbridge] Updated Vancouver minutes Message-ID: <3870C46029D1F945B1472F170D2D9790036AC7AB@de01exm64.ds.mot.com> Hi, A slightly expanded and hopefully more clear set of minutes for the TRILL meeting at IETF-70 in Vancouver have been uploaded to the meeting materials page. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Donald.Eastlake at motorola.com Sun Jan 13 20:01:29 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 13 Jan 2008 23:01:29 -0500 Subject: [rbridge] IEEE 802.1 Review Message-ID: <3870C46029D1F945B1472F170D2D9790036AC7AC@de01exm64.ds.mot.com> At the Vancouver meeting, the TRILL co-chairs took an action item to check with our Area Director and determine whether the slide presentation of the TRILL architecture to IEEE 802.1, which Eric Gray did a while ago, and his report back to TRILL, meets our Charter requirement for such review. The TRILL Charter currently says "... IEEE 802.1 will be asked to review the architecture document ...". The conclusion of the Chairs and AD is that the 802.1 review needs to be of a version of the architecture document to meet this Charter requirement. So, unless the Charter is modified, at some point in the future we would need to request such a review of a specific architecture draft. Thanks, Donald & Erik From Radia.Perlman at sun.com Mon Jan 28 21:05:13 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 28 Jan 2008 21:05:13 -0800 Subject: [rbridge] Pseudonode minimization thoughts... Message-ID: <479EB409.7070901@sun.com> The WG seemed to think that the pseudonode minimization was a good thing for all link state protocols, and therefore should be proposed in the routing working group rather than in TRILL. I'm not convinced it is possible to put in the extra flags necessary for OSPF, so perhaps it should just be presented in IS-IS instead. Also, I was thinking about a rationale for a good cutover. What I proposed originally, picking numbers out of the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, and anything in between, stick with what it was. Originally, IS-IS was designed for CLNP, and it was necessary to report, for each link, all the attached endnodes. So even if there were only 2 routers on a LAN, it made sense to create a pseudonode, so that all the endnodes wouldn't get reported by both routers. But for TRILL--there really isn't anything reported in the pseudonode other than the set of router neighbors. Things like the set of supported VLANs, and the set of roots that an RBridge might select for a multicast tree, are all reported in the RBridge's individual LSP. The only thing in the pseudonode LSP is the set of RBridge neighbors. So, I'm thinking that the right cutover would be something like 15 RBridge neighbors before it's worth creating another LSP that has a whole header, and appears in every other RBridge's CSNP. I must say it's not easy to find the packet formats for IS-IS to get the exact number of bytes in an LSP. :-( Radia From mrthom at essex.ac.uk Tue Jan 29 11:26:42 2008 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Tue, 29 Jan 2008 19:26:42 -0000 Subject: [rbridge] Pseudonode minimization thoughts... References: <479EB409.7070901@sun.com> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CCE866E@sernt14.essex.ac.uk> Yes, There are a few concerns.. I have been looking at this with Radia. Using Link Local Signalling (Extended Options -TLV) worked on by Alex Zinin this is in fact quite possible with OSPF. This draft is an OSPF working group draft and so presumably will be implemented. draft-ietf-ospf-lls-03.txt Matthew R Thomas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: 29 January 2008 05:05 To: Developing a hybrid router/bridge. Subject: [rbridge] Pseudonode minimization thoughts... The WG seemed to think that the pseudonode minimization was a good thing for all link state protocols, and therefore should be proposed in the routing working group rather than in TRILL. I'm not convinced it is possible to put in the extra flags necessary for OSPF, so perhaps it should just be presented in IS-IS instead. Also, I was thinking about a rationale for a good cutover. What I proposed originally, picking numbers out of the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, and anything in between, stick with what it was. Originally, IS-IS was designed for CLNP, and it was necessary to report, for each link, all the attached endnodes. So even if there were only 2 routers on a LAN, it made sense to create a pseudonode, so that all the endnodes wouldn't get reported by both routers. But for TRILL--there really isn't anything reported in the pseudonode other than the set of router neighbors. Things like the set of supported VLANs, and the set of roots that an RBridge might select for a multicast tree, are all reported in the RBridge's individual LSP. The only thing in the pseudonode LSP is the set of RBridge neighbors. So, I'm thinking that the right cutover would be something like 15 RBridge neighbors before it's worth creating another LSP that has a whole header, and appears in every other RBridge's CSNP. I must say it's not easy to find the packet formats for IS-IS to get the exact number of bytes in an LSP. :-( Radia _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From mshand at cisco.com Wed Jan 30 01:19:13 2008 From: mshand at cisco.com (mike shand) Date: Wed, 30 Jan 2008 09:19:13 +0000 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <479EB409.7070901@sun.com> References: <479EB409.7070901@sun.com> Message-ID: <47A04111.2010204@cisco.com> Radia, I'm confused. I thought that what you were proposing was switching all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the pseudonode, but also using pt-pt mechanisms for the update process, rather than the broadcast and CSNP mechanism we have for LANs. This is exactly what we do at the moment when we configure a LAN as a 2 node pt-pt "LAN". However, this made me very nervous since I don't like the idea of dynamically messing with the operation of the update process. But, this post makes me think that you mean ONLY getting rid of the pseudonode, but retaining the CSNP and broadcast based update process. Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt you are going to get in excess of 200 LSPs crossing the LAN (not to mention ACKs). If all you want to do is get rid of the pseudonode, then I am much less nervous, But I'm still not really convinced it is worth the bother. Could you explain exactly what you have in mind. Mike Radia Perlman wrote: > The WG seemed to think that the pseudonode minimization was a good thing > for all link state protocols, and therefore > should be proposed in the routing working group rather than in TRILL. > > I'm not convinced it is possible to put in the extra flags necessary for > OSPF, so perhaps it should just be presented in IS-IS instead. > > Also, I was thinking about a rationale for a good cutover. What I > proposed originally, picking numbers out of > the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, and > anything in between, stick with what it was. > > Originally, IS-IS was designed for CLNP, and it was necessary to report, > for each link, all the attached endnodes. So > even if there were only 2 routers on a LAN, it made sense to create a > pseudonode, so that all the endnodes wouldn't > get reported by both routers. > > But for TRILL--there really isn't anything reported in the pseudonode > other than the set of router neighbors. > Things like the set of supported VLANs, and the set of roots that an > RBridge might select for a multicast tree, are all > reported in the RBridge's individual LSP. The only thing in the > pseudonode LSP is the set of RBridge neighbors. > > So, I'm thinking that the right cutover would be something like 15 > RBridge neighbors before it's worth creating another > LSP that has a whole header, and appears in every other RBridge's CSNP. > > I must say it's not easy to find the packet formats for IS-IS to get > the exact number of bytes in an LSP. :-( > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > From eric.gray at ericsson.com Wed Jan 30 10:22:03 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 30 Jan 2008 12:22:03 -0600 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A04111.2010204@cisco.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF025A2FFE@eusrcmw721.eamcs.ericsson.se> Mike, I'm not sure where you got the impression that we're planning to change all interactions between RBridges to a P2P model. I think it's possible that you're conflating a few - probably unrelated - discussions/issues. We've had a lot of discussion around behaviors and possible optimizations for the case where we can be certain (possibly based on configuration) that a connection between exactly 2 RBridges is P2P. One of the optimizations is that - where this applies - then it's clearly unnecessary to use any of the mechanisms associated with the MP2MP case. Such an optimization should include not using pseudo nodes - if (for some reason) pseudo nodes might otherwise be created in all cases. This is not obviously related to possibly using P2P update processes when more than 2 RBridges are connected via the same link, is it? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of mike shand > Sent: Wednesday, January 30, 2008 4:19 AM > To: Radia Perlman > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Pseudonode minimization thoughts... > > Radia, > I'm confused. I thought that what you were proposing was > switching > all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the > pseudonode, but also using pt-pt mechanisms for the update process, > rather than the broadcast and CSNP mechanism we have for LANs. > > This is exactly what we do at the moment when we configure a > LAN as a 2 > node pt-pt "LAN". > > However, this made me very nervous since I don't like the idea of > dynamically messing with the operation of the update process. > > > But, this post makes me think that you mean ONLY getting rid of the > pseudonode, but retaining the CSNP and broadcast based update > process. > Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt you are > going to get in excess of 200 LSPs crossing the LAN (not to > mention ACKs). > > > If all you want to do is get rid of the pseudonode, then I am > much less > nervous, But I'm still not really convinced it is worth the bother. > > Could you explain exactly what you have in mind. > > Mike > > Radia Perlman wrote: > > The WG seemed to think that the pseudonode minimization was > a good thing > > for all link state protocols, and therefore > > should be proposed in the routing working group rather than > in TRILL. > > > > I'm not convinced it is possible to put in the extra flags > necessary for > > OSPF, so perhaps it should just be presented in IS-IS instead. > > > > Also, I was thinking about a rationale for a good cutover. What I > > proposed originally, picking numbers out of > > the air, was 1 or 2 routers, no pseudonode, 5 or more, > pseudonode, and > > anything in between, stick with what it was. > > > > Originally, IS-IS was designed for CLNP, and it was > necessary to report, > > for each link, all the attached endnodes. So > > even if there were only 2 routers on a LAN, it made sense > to create a > > pseudonode, so that all the endnodes wouldn't > > get reported by both routers. > > > > But for TRILL--there really isn't anything reported in the > pseudonode > > other than the set of router neighbors. > > Things like the set of supported VLANs, and the set of > roots that an > > RBridge might select for a multicast tree, are all > > reported in the RBridge's individual LSP. The only thing in the > > pseudonode LSP is the set of RBridge neighbors. > > > > So, I'm thinking that the right cutover would be something like 15 > > RBridge neighbors before it's worth creating another > > LSP that has a whole header, and appears in every other > RBridge's CSNP. > > > > I must say it's not easy to find the packet formats for > IS-IS to get > > the exact number of bytes in an LSP. :-( > > > > Radia > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Wed Jan 30 11:59:27 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 30 Jan 2008 11:59:27 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A04111.2010204@cisco.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> Message-ID: <47A0D71F.1070207@sun.com> Absolutely. The intention wasn't to "treat the link like a pt-to-pt link" in terms of how LSPs get flooded and ack'ed and all that. That would be too much trouble. It might be more efficient if there are really just two RBridges, to send acks for each LSP rather than the periodic CSNP, but it seems like more trouble for implementations to be able to switch back and forth, and more confusing to switch modes. And even with just two RBridges, it isn't horrible to send CSNPs. However, it does seem horrible to create a pseudonode and an associated LSP for it, for every port, whether there are only two RBridges on the link, or worse yet, a single RBridge with a single endnode. So yes...I'm only proposing that a "non-pseudonode LAN" get reported in LSPs differently. If R1, R2, R3, and R4 are on a link, and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", then each of R1, R2, R3, and R4 report the neighbor "R1.25" in their LSP, and R1 also generates a pseudonode for R1.25, and reports in that, neighbors R1, R2, R3, and R4. If R1 says "don't use pseudonode", then each of them reports 3 neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc. Hope that clarifies -- and sorry for the English ambiguity in the phrase "treat the link like a bunch of pt-to-pt links" which undoubtedly was a bit scary if you interpreted it the other way. Radia mike shand wrote: > Radia, > I'm confused. I thought that what you were proposing was switching > all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the > pseudonode, but also using pt-pt mechanisms for the update process, > rather than the broadcast and CSNP mechanism we have for LANs. > > This is exactly what we do at the moment when we configure a LAN as a > 2 node pt-pt "LAN". > > However, this made me very nervous since I don't like the idea of > dynamically messing with the operation of the update process. > > > But, this post makes me think that you mean ONLY getting rid of the > pseudonode, but retaining the CSNP and broadcast based update process. > Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt you are > going to get in excess of 200 LSPs crossing the LAN (not to mention > ACKs). > > > If all you want to do is get rid of the pseudonode, then I am much > less nervous, But I'm still not really convinced it is worth the bother. > > Could you explain exactly what you have in mind. > > Mike > > Radia Perlman wrote: >> The WG seemed to think that the pseudonode minimization was a good >> thing for all link state protocols, and therefore >> should be proposed in the routing working group rather than in TRILL. >> >> I'm not convinced it is possible to put in the extra flags necessary >> for OSPF, so perhaps it should just be presented in IS-IS instead. >> >> Also, I was thinking about a rationale for a good cutover. What I >> proposed originally, picking numbers out of >> the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, >> and anything in between, stick with what it was. >> >> Originally, IS-IS was designed for CLNP, and it was necessary to >> report, for each link, all the attached endnodes. So >> even if there were only 2 routers on a LAN, it made sense to create a >> pseudonode, so that all the endnodes wouldn't >> get reported by both routers. >> >> But for TRILL--there really isn't anything reported in the pseudonode >> other than the set of router neighbors. >> Things like the set of supported VLANs, and the set of roots that an >> RBridge might select for a multicast tree, are all >> reported in the RBridge's individual LSP. The only thing in the >> pseudonode LSP is the set of RBridge neighbors. >> >> So, I'm thinking that the right cutover would be something like 15 >> RBridge neighbors before it's worth creating another >> LSP that has a whole header, and appears in every other RBridge's CSNP. >> >> I must say it's not easy to find the packet formats for IS-IS to get >> the exact number of bytes in an LSP. :-( >> >> Radia >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > From mshand at cisco.com Thu Jan 31 02:19:39 2008 From: mshand at cisco.com (mike shand) Date: Thu, 31 Jan 2008 10:19:39 +0000 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A0D71F.1070207@sun.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> Message-ID: <47A1A0BB.5040506@cisco.com> Radia Perlman wrote: > Absolutely. The intention wasn't to "treat the link like a pt-to-pt > link" in terms of how LSPs get flooded and ack'ed and all that. > That would be too much trouble. It might be more efficient if there > are really just two RBridges, to send acks for each LSP > rather than the periodic CSNP, but it seems like more trouble for > implementations to be > able to switch back and forth, and more confusing to switch modes. And > even with just two RBridges, it isn't horrible > to send CSNPs. > > However, it does seem horrible to create a pseudonode and an > associated LSP for it, > for every port, whether there are only two RBridges on the link, > or worse yet, a single RBridge with a single endnode. > > So yes...I'm only proposing that a "non-pseudonode LAN" get reported > in LSPs differently. If R1, R2, R3, and R4 are on a link, > and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", > then each of R1, R2, R3, and R4 report the > neighbor "R1.25" in their LSP, and R1 also generates a pseudonode for > R1.25, and reports in that, neighbors R1, R2, R3, and R4. > > If R1 says "don't use pseudonode", then each of them reports 3 > neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc. > > Hope that clarifies -- and sorry for the English ambiguity in the > phrase "treat the link like a bunch of pt-to-pt links" which undoubtedly > was a bit scary if you interpreted it the other way. Radia, Thanks for the clarification. Much less scary:-) But I'm still not convinced there is any need for this complexity. We already handle the N=2 case by configuration, and that DOES turn the link into a genuine pt-pt link using pt-pt update process. This seems like a worthwhile optimization, but I wouldn't want to do it automagically. Configuration seems to work well. People tend to know whether or not they have 2 or more routers on a LAN, and if they think there are 2 and a third turns up that is clearly an error, and should be treated as such. See draft-ietf-isis-igp-p2p-over-lan-06.txt If the motivation for removing the pseudonode is purely space saving in the LSP database, then it seems to me that this only applies for very small N. I think you win with N=3, and lose with N=4, and it gets worse rapidy for >4. And that is assuming we only have router neighbor advertisements. with no pseudonode we get n(n-1) neighbor advertisments, and with a pseudoonode we get 2n advertisments. The pseudonode itself adds some 27 octets of header, and there is no area address. and we need another 2 for the neighbor TLV header. Router neighbors take 12 octets per additional neighbor (narrow metrics), or 11 for wide metrics. So for N=3 we have with PN 6*12 +29 = 101 without PN 3*2*12 = 72 For n=4 with 8*12+29 =125 without 4*3*12 = 144 for n=15 with 30*12+29 = 389 without 15*14*12 = 2520 I may have made a few errors there, but I think the principle is clear. It only seems worthwhile for the n=3 case. And even that is marginal. Of course there is the additional complexity of generating the PN, but we have to do all the DR election stuff for the update process anyway, so I don't see that as much complexity compared with the complexity of figuring out whether you have to do it or not. I'm not even convinced it simplifies the SPF, but since an SPF for a several hundred node network takes < 1mS, I don't see this as a big issue either way. However for a 15 node LAN, WITH pseudonode you explore 1 hop to the PN then 14 hops to the other nodes, then check on back link from each of the 14 to the PN (i.e 29 links). In the non PN case you explore 14 hops, then another 14 hops back from each of those 14 (i.e. 210 links). It would need a better analysis to determine exactly what the relative merits are, but at best I would say it is a wash, and it might even be a pessimisation not to have a PN. "If it ain't broke, don't fix it." Mike > > Radia > > > mike shand wrote: >> Radia, >> I'm confused. I thought that what you were proposing was switching >> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the >> pseudonode, but also using pt-pt mechanisms for the update process, >> rather than the broadcast and CSNP mechanism we have for LANs. >> >> This is exactly what we do at the moment when we configure a LAN as a >> 2 node pt-pt "LAN". >> >> However, this made me very nervous since I don't like the idea of >> dynamically messing with the operation of the update process. >> >> >> But, this post makes me think that you mean ONLY getting rid of the >> pseudonode, but retaining the CSNP and broadcast based update >> process. Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt >> you are going to get in excess of 200 LSPs crossing the LAN (not to >> mention ACKs). >> >> >> If all you want to do is get rid of the pseudonode, then I am much >> less nervous, But I'm still not really convinced it is worth the bother. >> >> Could you explain exactly what you have in mind. >> >> Mike >> >> Radia Perlman wrote: >>> The WG seemed to think that the pseudonode minimization was a good >>> thing for all link state protocols, and therefore >>> should be proposed in the routing working group rather than in TRILL. >>> >>> I'm not convinced it is possible to put in the extra flags necessary >>> for OSPF, so perhaps it should just be presented in IS-IS instead. >>> >>> Also, I was thinking about a rationale for a good cutover. What I >>> proposed originally, picking numbers out of >>> the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, >>> and anything in between, stick with what it was. >>> >>> Originally, IS-IS was designed for CLNP, and it was necessary to >>> report, for each link, all the attached endnodes. So >>> even if there were only 2 routers on a LAN, it made sense to create >>> a pseudonode, so that all the endnodes wouldn't >>> get reported by both routers. >>> >>> But for TRILL--there really isn't anything reported in the >>> pseudonode other than the set of router neighbors. >>> Things like the set of supported VLANs, and the set of roots that an >>> RBridge might select for a multicast tree, are all >>> reported in the RBridge's individual LSP. The only thing in the >>> pseudonode LSP is the set of RBridge neighbors. >>> >>> So, I'm thinking that the right cutover would be something like 15 >>> RBridge neighbors before it's worth creating another >>> LSP that has a whole header, and appears in every other RBridge's CSNP. >>> >>> I must say it's not easy to find the packet formats for IS-IS to >>> get the exact number of bytes in an LSP. :-( >>> >>> Radia >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> > > From mrthom at essex.ac.uk Thu Jan 31 03:00:55 2008 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Thu, 31 Jan 2008 11:00:55 -0000 Subject: [rbridge] FW: Pseudonode minimization thoughts... References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CEADA00@sernt14.essex.ac.uk> Hi Mike I did similar slightly more detailed (but approx the same math) on this last year for OSPF and produced quite similar results. This is a byte count justification, but the SPF one yields similar numbers. The issue here is the build up of (OSPF) the Network-LSA. / Pseudonode LSP. For each Lan that is missed by the designers a Network-LSA is flooded out to the whole area. Over time these build up. The amount of data we are discussing on the LAN here is as you say quite small. Perhaps a decrease for 4? routers, and perhaps a small increase for 5? depending on circumstances, but its still bytes on Mb links The problem is a remote router processing all sorts of unneccessary LSAs that arnt required to build the graph. Its a clean up that has been waiting for a while I would guess? So much of the world has moved pt-to-pt... If this can be done as Radia is suggesting without upsetting the flooding on the Lan and with few changes, and have the database clean itself up a bit I think that this is worthwhile.. my 2 cents.. Matthew R Thomas ________________________________ From: rbridge-bounces at postel.org on behalf of mike shand Sent: Thu 31/01/2008 10:19 To: Radia Perlman Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] Pseudonode minimization thoughts... Radia Perlman wrote: > Absolutely. The intention wasn't to "treat the link like a pt-to-pt > link" in terms of how LSPs get flooded and ack'ed and all that. > That would be too much trouble. It might be more efficient if there > are really just two RBridges, to send acks for each LSP > rather than the periodic CSNP, but it seems like more trouble for > implementations to be > able to switch back and forth, and more confusing to switch modes. And > even with just two RBridges, it isn't horrible > to send CSNPs. > > However, it does seem horrible to create a pseudonode and an > associated LSP for it, > for every port, whether there are only two RBridges on the link, > or worse yet, a single RBridge with a single endnode. > > So yes...I'm only proposing that a "non-pseudonode LAN" get reported > in LSPs differently. If R1, R2, R3, and R4 are on a link, > and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", > then each of R1, R2, R3, and R4 report the > neighbor "R1.25" in their LSP, and R1 also generates a pseudonode for > R1.25, and reports in that, neighbors R1, R2, R3, and R4. > > If R1 says "don't use pseudonode", then each of them reports 3 > neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc. > > Hope that clarifies -- and sorry for the English ambiguity in the > phrase "treat the link like a bunch of pt-to-pt links" which undoubtedly > was a bit scary if you interpreted it the other way. Radia, Thanks for the clarification. Much less scary:-) But I'm still not convinced there is any need for this complexity. We already handle the N=2 case by configuration, and that DOES turn the link into a genuine pt-pt link using pt-pt update process. This seems like a worthwhile optimization, but I wouldn't want to do it automagically. Configuration seems to work well. People tend to know whether or not they have 2 or more routers on a LAN, and if they think there are 2 and a third turns up that is clearly an error, and should be treated as such. See draft-ietf-isis-igp-p2p-over-lan-06.txt If the motivation for removing the pseudonode is purely space saving in the LSP database, then it seems to me that this only applies for very small N. I think you win with N=3, and lose with N=4, and it gets worse rapidy for >4. And that is assuming we only have router neighbor advertisements. with no pseudonode we get n(n-1) neighbor advertisments, and with a pseudoonode we get 2n advertisments. The pseudonode itself adds some 27 octets of header, and there is no area address. and we need another 2 for the neighbor TLV header. Router neighbors take 12 octets per additional neighbor (narrow metrics), or 11 for wide metrics. So for N=3 we have with PN 6*12 +29 = 101 without PN 3*2*12 = 72 For n=4 with 8*12+29 =125 without 4*3*12 = 144 for n=15 with 30*12+29 = 389 without 15*14*12 = 2520 I may have made a few errors there, but I think the principle is clear. It only seems worthwhile for the n=3 case. And even that is marginal. Of course there is the additional complexity of generating the PN, but we have to do all the DR election stuff for the update process anyway, so I don't see that as much complexity compared with the complexity of figuring out whether you have to do it or not. I'm not even convinced it simplifies the SPF, but since an SPF for a several hundred node network takes < 1mS, I don't see this as a big issue either way. However for a 15 node LAN, WITH pseudonode you explore 1 hop to the PN then 14 hops to the other nodes, then check on back link from each of the 14 to the PN (i.e 29 links). In the non PN case you explore 14 hops, then another 14 hops back from each of those 14 (i.e. 210 links). It would need a better analysis to determine exactly what the relative merits are, but at best I would say it is a wash, and it might even be a pessimisation not to have a PN. "If it ain't broke, don't fix it." Mike > > Radia > > > mike shand wrote: >> Radia, >> I'm confused. I thought that what you were proposing was switching >> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the >> pseudonode, but also using pt-pt mechanisms for the update process, >> rather than the broadcast and CSNP mechanism we have for LANs. >> >> This is exactly what we do at the moment when we configure a LAN as a >> 2 node pt-pt "LAN". >> >> However, this made me very nervous since I don't like the idea of >> dynamically messing with the operation of the update process. >> >> >> But, this post makes me think that you mean ONLY getting rid of the >> pseudonode, but retaining the CSNP and broadcast based update >> process. Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt >> you are going to get in excess of 200 LSPs crossing the LAN (not to >> mention ACKs). >> >> >> If all you want to do is get rid of the pseudonode, then I am much >> less nervous, But I'm still not really convinced it is worth the bother. >> >> Could you explain exactly what you have in mind. >> >> Mike >> >> Radia Perlman wrote: >>> The WG seemed to think that the pseudonode minimization was a good >>> thing for all link state protocols, and therefore >>> should be proposed in the routing working group rather than in TRILL. >>> >>> I'm not convinced it is possible to put in the extra flags necessary >>> for OSPF, so perhaps it should just be presented in IS-IS instead. >>> >>> Also, I was thinking about a rationale for a good cutover. What I >>> proposed originally, picking numbers out of >>> the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, >>> and anything in between, stick with what it was. >>> >>> Originally, IS-IS was designed for CLNP, and it was necessary to >>> report, for each link, all the attached endnodes. So >>> even if there were only 2 routers on a LAN, it made sense to create >>> a pseudonode, so that all the endnodes wouldn't >>> get reported by both routers. >>> >>> But for TRILL--there really isn't anything reported in the >>> pseudonode other than the set of router neighbors. >>> Things like the set of supported VLANs, and the set of roots that an >>> RBridge might select for a multicast tree, are all >>> reported in the RBridge's individual LSP. The only thing in the >>> pseudonode LSP is the set of RBridge neighbors. >>> >>> So, I'm thinking that the right cutover would be something like 15 >>> RBridge neighbors before it's worth creating another >>> LSP that has a whole header, and appears in every other RBridge's CSNP. >>> >>> I must say it's not easy to find the packet formats for IS-IS to >>> get the exact number of bytes in an LSP. :-( >>> >>> Radia >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> > > _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From ddutt at cisco.com Thu Jan 31 12:48:18 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 31 Jan 2008 12:48:18 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A1A0BB.5040506@cisco.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> Message-ID: <47A23412.8060807@cisco.com> I agree with Mike. We already have an existing IS-IS way, using config, to support this and I prefer to not make the protocol more complex, Dinesh mike shand wrote: > Radia Perlman wrote: > >> Absolutely. The intention wasn't to "treat the link like a pt-to-pt >> link" in terms of how LSPs get flooded and ack'ed and all that. >> That would be too much trouble. It might be more efficient if there >> are really just two RBridges, to send acks for each LSP >> rather than the periodic CSNP, but it seems like more trouble for >> implementations to be >> able to switch back and forth, and more confusing to switch modes. And >> even with just two RBridges, it isn't horrible >> to send CSNPs. >> >> However, it does seem horrible to create a pseudonode and an >> associated LSP for it, >> for every port, whether there are only two RBridges on the link, >> or worse yet, a single RBridge with a single endnode. >> >> So yes...I'm only proposing that a "non-pseudonode LAN" get reported >> in LSPs differently. If R1, R2, R3, and R4 are on a link, >> and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", >> then each of R1, R2, R3, and R4 report the >> neighbor "R1.25" in their LSP, and R1 also generates a pseudonode for >> R1.25, and reports in that, neighbors R1, R2, R3, and R4. >> >> If R1 says "don't use pseudonode", then each of them reports 3 >> neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc. >> >> Hope that clarifies -- and sorry for the English ambiguity in the >> phrase "treat the link like a bunch of pt-to-pt links" which undoubtedly >> was a bit scary if you interpreted it the other way. >> > Radia, > Thanks for the clarification. Much less scary:-) > > But I'm still not convinced there is any need for this complexity. > > We already handle the N=2 case by configuration, and that DOES turn the > link into a genuine pt-pt link using pt-pt update process. This seems > like a worthwhile optimization, but I wouldn't want to do it > automagically. Configuration seems to work well. People tend to know > whether or not they have 2 or more routers on a LAN, and if they think > there are 2 and a third turns up that is clearly an error, and should be > treated as such. See > > draft-ietf-isis-igp-p2p-over-lan-06.txt > > > If the motivation for removing the pseudonode is purely space saving in > the LSP database, then it seems to me that this only applies for very > small N. I think you win with N=3, and lose with N=4, and it gets worse > rapidy for >4. And that is assuming we only have router neighbor > advertisements. > > with no pseudonode we get n(n-1) neighbor advertisments, and with a > pseudoonode we get 2n advertisments. > The pseudonode itself adds some 27 octets of header, and there is no > area address. and we need another 2 for the neighbor TLV header. > Router neighbors take 12 octets per additional neighbor (narrow > metrics), or 11 for wide metrics. > > So for N=3 we have > > with PN 6*12 +29 = 101 > without PN 3*2*12 = 72 > > For n=4 > > with 8*12+29 =125 > without 4*3*12 = 144 > > for n=15 > > with 30*12+29 = 389 > without 15*14*12 = 2520 > > > I may have made a few errors there, but I think the principle is clear. > > It only seems worthwhile for the n=3 case. And even that is marginal. > > Of course there is the additional complexity of generating the PN, but > we have to do all the DR election stuff for the update process anyway, > so I don't see that as much complexity compared with the complexity of > figuring out whether you have to do it or not. > > I'm not even convinced it simplifies the SPF, but since an SPF for a > several hundred node network takes < 1mS, I don't see this as a big > issue either way. However for a 15 node LAN, WITH pseudonode you explore > 1 hop to the PN then 14 hops to the other nodes, then check on back link > from each of the 14 to the PN (i.e 29 links). In the non PN case you > explore 14 hops, then another 14 hops back from each of those 14 (i.e. > 210 links). It would need a better analysis to determine exactly what > the relative merits are, but at best I would say it is a wash, and it > might even be a pessimisation not to have a PN. > > "If it ain't broke, don't fix it." > > Mike > > >> Radia >> >> >> mike shand wrote: >> >>> Radia, >>> I'm confused. I thought that what you were proposing was switching >>> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the >>> pseudonode, but also using pt-pt mechanisms for the update process, >>> rather than the broadcast and CSNP mechanism we have for LANs. >>> >>> This is exactly what we do at the moment when we configure a LAN as a >>> 2 node pt-pt "LAN". >>> >>> However, this made me very nervous since I don't like the idea of >>> dynamically messing with the operation of the update process. >>> >>> >>> But, this post makes me think that you mean ONLY getting rid of the >>> pseudonode, but retaining the CSNP and broadcast based update >>> process. Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt >>> you are going to get in excess of 200 LSPs crossing the LAN (not to >>> mention ACKs). >>> >>> >>> If all you want to do is get rid of the pseudonode, then I am much >>> less nervous, But I'm still not really convinced it is worth the bother. >>> >>> Could you explain exactly what you have in mind. >>> >>> Mike >>> >>> Radia Perlman wrote: >>> >>>> The WG seemed to think that the pseudonode minimization was a good >>>> thing for all link state protocols, and therefore >>>> should be proposed in the routing working group rather than in TRILL. >>>> >>>> I'm not convinced it is possible to put in the extra flags necessary >>>> for OSPF, so perhaps it should just be presented in IS-IS instead. >>>> >>>> Also, I was thinking about a rationale for a good cutover. What I >>>> proposed originally, picking numbers out of >>>> the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, >>>> and anything in between, stick with what it was. >>>> >>>> Originally, IS-IS was designed for CLNP, and it was necessary to >>>> report, for each link, all the attached endnodes. So >>>> even if there were only 2 routers on a LAN, it made sense to create >>>> a pseudonode, so that all the endnodes wouldn't >>>> get reported by both routers. >>>> >>>> But for TRILL--there really isn't anything reported in the >>>> pseudonode other than the set of router neighbors. >>>> Things like the set of supported VLANs, and the set of roots that an >>>> RBridge might select for a multicast tree, are all >>>> reported in the RBridge's individual LSP. The only thing in the >>>> pseudonode LSP is the set of RBridge neighbors. >>>> >>>> So, I'm thinking that the right cutover would be something like 15 >>>> RBridge neighbors before it's worth creating another >>>> LSP that has a whole header, and appears in every other RBridge's CSNP. >>>> >>>> I must say it's not easy to find the packet formats for IS-IS to >>>> get the exact number of bytes in an LSP. :-( >>>> >>>> Radia >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- 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 Jan 31 13:14:37 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 31 Jan 2008 13:14:37 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A1A0BB.5040506@cisco.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> Message-ID: <47A23A3D.2040907@sun.com> Well, I think it is really important to avoid configuration -- both because of the hassle of configuration, and people getting configruation wrong. This proposal eliminates "silly pseudonodes", i.e., pseudonodes when there are only 1 or 2 routers on a link, and does not require configuration. I don't think it is complex. It costs 2 bits in Hellos. I'm glad you worked out the math though. You're right, Mike, that if you just look at bytes in the LSP database, the cutover is at 4 routers where it is better to have a pseudonode, if you ignore the overhead of the CSNP (with a pseudonode *every* RBridge has to report an extra LSP ID and sequence number in the CSNP which is not trivial). Your math was a bit terse, so let me redo it using your basic numbers and with a bit more explanation. I agree with your numbers, but I think it might be hard for others (it was hard for me) to understand it. You said a pseudonode has 27 bytes of header. Plus it has to list all the router neighbors on the link. You said that to report a neighbor it is 12 octets for narrow metrics, and 1 octets for wide metrics. Is that backwards perhaps? I'd think it should take more space to report a side metric, but no matter -- I'll use 12 octets per neighbor. (though it would be nice to get a clarification on that -- I could imagine that when they redid the TLV for reporting metrics, they not only widened the metric but also compressed the format, or maybe got rid of multiple metrics). So, with 4 routers, I seem to get the same result as you said, which is it costs 21 octets in the LSP database to not use a pseudonode: Here's the math worked out, with more comments: Assuming 4 routers: Without pseudonode: each router reports 3 neighbors, so that costs 36 octets each. With pseudonode, each router reports 1 neighbor, so that saves 24 octets in 4 LSPs, at a total savings of 96 octets, but then you have to add in the pseudonode LSP which has a header of 27, plus 4 neighbors, so 27+4*12=75 octets. So I get that with 4 routers the octets in the LSP database alone, as you observe, you lose without a pseudonode by 21 octets. Though as I said, the extra LSP also means an extra field in all the CSNPs. With 5 routers, I get: Without pseudonode, each router reports 4 neighbors, so that costs 48 octets each, at a total cost of 5*48=240. With pseudonode, each router reports 1 neighbor instead of 4, saving 36 octets in each of 5, at a savings of 180. The cost of the pseudonode is 27+5*12=87, so not having a pseudonode costs 180-87, or 93 octets. (though again, this is somewhat mitigated by getting rid of the extra LSP to report in the CSNP). This is useful data, in helping to pick the cutoff point. A possible reason to have a wider window between "no" and "yes" for pseudonode is so that it won't flip very often -- once a link has lots of routers, it stays that way. I think it will be very rare for a link to have exactly 5 routers, and even though in theory you are wasting 93 bytes in the LSP database with 5 routers, it is mitigated by one less entry in the CSNP, which is multiplied by the total number of routers in the campus. So I think that the cutoffs of "2" and "5" are probably justifiable as the default, though I'd be happy with "2" and "4" as the default. But at any rate, the difference in complexity between this proposal (which is 2 bits in a Hello, and the code to follow orders and report your neighbors directly rather than the pseudonode) vs requiring configuration on every pt-to-pt port (which more and more will be close to "all of them"), plus the potential for wrong configuration (more likely, the mistake will be not configuring a port to be pt-to-pt and therefore winding up with "silly pseudonodes") -- I think that this is important in order to allow reasonable operation with zero configuration. Radia mike shand wrote: > Radia Perlman wrote: > >> Absolutely. The intention wasn't to "treat the link like a pt-to-pt >> link" in terms of how LSPs get flooded and ack'ed and all that. >> That would be too much trouble. It might be more efficient if there >> are really just two RBridges, to send acks for each LSP >> rather than the periodic CSNP, but it seems like more trouble for >> implementations to be >> able to switch back and forth, and more confusing to switch modes. And >> even with just two RBridges, it isn't horrible >> to send CSNPs. >> >> However, it does seem horrible to create a pseudonode and an >> associated LSP for it, >> for every port, whether there are only two RBridges on the link, >> or worse yet, a single RBridge with a single endnode. >> >> So yes...I'm only proposing that a "non-pseudonode LAN" get reported >> in LSPs differently. If R1, R2, R3, and R4 are on a link, >> and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", >> then each of R1, R2, R3, and R4 report the >> neighbor "R1.25" in their LSP, and R1 also generates a pseudonode for >> R1.25, and reports in that, neighbors R1, R2, R3, and R4. >> >> If R1 says "don't use pseudonode", then each of them reports 3 >> neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc. >> >> Hope that clarifies -- and sorry for the English ambiguity in the >> phrase "treat the link like a bunch of pt-to-pt links" which undoubtedly >> was a bit scary if you interpreted it the other way. >> > Radia, > Thanks for the clarification. Much less scary:-) > > But I'm still not convinced there is any need for this complexity. > > We already handle the N=2 case by configuration, and that DOES turn the > link into a genuine pt-pt link using pt-pt update process. This seems > like a worthwhile optimization, but I wouldn't want to do it > automagically. Configuration seems to work well. People tend to know > whether or not they have 2 or more routers on a LAN, and if they think > there are 2 and a third turns up that is clearly an error, and should be > treated as such. See > > draft-ietf-isis-igp-p2p-over-lan-06.txt > > > If the motivation for removing the pseudonode is purely space saving in > the LSP database, then it seems to me that this only applies for very > small N. I think you win with N=3, and lose with N=4, and it gets worse > rapidy for >4. And that is assuming we only have router neighbor > advertisements. > > with no pseudonode we get n(n-1) neighbor advertisments, and with a > pseudoonode we get 2n advertisments. > The pseudonode itself adds some 27 octets of header, and there is no > area address. and we need another 2 for the neighbor TLV header. > Router neighbors take 12 octets per additional neighbor (narrow > metrics), or 11 for wide metrics. > > So for N=3 we have > > with PN 6*12 +29 = 101 > without PN 3*2*12 = 72 > > For n=4 > > with 8*12+29 =125 > without 4*3*12 = 144 > > for n=15 > > with 30*12+29 = 389 > without 15*14*12 = 2520 > > > I may have made a few errors there, but I think the principle is clear. > > It only seems worthwhile for the n=3 case. And even that is marginal. > > Of course there is the additional complexity of generating the PN, but > we have to do all the DR election stuff for the update process anyway, > so I don't see that as much complexity compared with the complexity of > figuring out whether you have to do it or not. > > I'm not even convinced it simplifies the SPF, but since an SPF for a > several hundred node network takes < 1mS, I don't see this as a big > issue either way. However for a 15 node LAN, WITH pseudonode you explore > 1 hop to the PN then 14 hops to the other nodes, then check on back link > from each of the 14 to the PN (i.e 29 links). In the non PN case you > explore 14 hops, then another 14 hops back from each of those 14 (i.e. > 210 links). It would need a better analysis to determine exactly what > the relative merits are, but at best I would say it is a wash, and it > might even be a pessimisation not to have a PN. > > "If it ain't broke, don't fix it." > > Mike > > >> Radia >> >> >> mike shand wrote: >> >>> Radia, >>> I'm confused. I thought that what you were proposing was switching >>> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the >>> pseudonode, but also using pt-pt mechanisms for the update process, >>> rather than the broadcast and CSNP mechanism we have for LANs. >>> >>> This is exactly what we do at the moment when we configure a LAN as a >>> 2 node pt-pt "LAN". >>> >>> However, this made me very nervous since I don't like the idea of >>> dynamically messing with the operation of the update process. >>> >>> >>> But, this post makes me think that you mean ONLY getting rid of the >>> pseudonode, but retaining the CSNP and broadcast based update >>> process. Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt >>> you are going to get in excess of 200 LSPs crossing the LAN (not to >>> mention ACKs). >>> >>> >>> If all you want to do is get rid of the pseudonode, then I am much >>> less nervous, But I'm still not really convinced it is worth the bother. >>> >>> Could you explain exactly what you have in mind. >>> >>> Mike >>> >>> Radia Perlman wrote: >>> >>>> The WG seemed to think that the pseudonode minimization was a good >>>> thing for all link state protocols, and therefore >>>> should be proposed in the routing working group rather than in TRILL. >>>> >>>> I'm not convinced it is possible to put in the extra flags necessary >>>> for OSPF, so perhaps it should just be presented in IS-IS instead. >>>> >>>> Also, I was thinking about a rationale for a good cutover. What I >>>> proposed originally, picking numbers out of >>>> the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, >>>> and anything in between, stick with what it was. >>>> >>>> Originally, IS-IS was designed for CLNP, and it was necessary to >>>> report, for each link, all the attached endnodes. So >>>> even if there were only 2 routers on a LAN, it made sense to create >>>> a pseudonode, so that all the endnodes wouldn't >>>> get reported by both routers. >>>> >>>> But for TRILL--there really isn't anything reported in the >>>> pseudonode other than the set of router neighbors. >>>> Things like the set of supported VLANs, and the set of roots that an >>>> RBridge might select for a multicast tree, are all >>>> reported in the RBridge's individual LSP. The only thing in the >>>> pseudonode LSP is the set of RBridge neighbors. >>>> >>>> So, I'm thinking that the right cutover would be something like 15 >>>> RBridge neighbors before it's worth creating another >>>> LSP that has a whole header, and appears in every other RBridge's CSNP. >>>> >>>> I must say it's not easy to find the packet formats for IS-IS to >>>> get the exact number of bytes in an LSP. :-( >>>> >>>> Radia >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From ginsberg at cisco.com Thu Jan 31 17:01:57 2008 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Thu, 31 Jan 2008 17:01:57 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A23A3D.2040907@sun.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com><47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> <47A23A3D.2040907@sun.com> Message-ID: Radia - The CSNP cost is a red herring. CSNPs are not permanently stored in your LSPDB - they are used to verify that your LSPDB is in sync with your neighbor(s) and then discarded. So unless you are going to argue that the extra bandwidth used by CSNPs (which are sent infrequently - even when periodic) with the additional pseudo-LSP entries is prohibitive - this issue can be ignored. Therefore Mike's calculations of the space savings/costs should be taken as representative of the impact of this "enhancement". As for your statement: "I don't think it is complex. It costs 2 bits in Hellos." This is a gross oversimplification. Although only two bits may needed for encoding, there are numerous concerns which have to be addressed in a robust implementation. For example: 1)How to do the transitions in a hitless manner 2)What should be done if all routers on the network do not support the extension 3)Rate limiting transitions to avoid storms associated with router instability Given the quite limited set of circumstances in which any benefits are realized and the modest gains that the extension can achieve in those cases, it is very difficult for me to have any enthusiasm for this idea. As for the zero configuration issue, treat LANs as LANs always if you must. Les > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Thursday, January 31, 2008 1:15 PM > To: Mike Shand (mshand) > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Pseudonode minimization thoughts... > > Well, I think it is really important to avoid configuration -- both > because of the hassle of configuration, > and people getting configruation wrong. > > This proposal eliminates > "silly pseudonodes", i.e., pseudonodes > when there are only 1 or 2 routers on a link, and does not require > configuration. > > I don't think it is complex. It costs 2 bits in Hellos. I'm glad you > worked out the math though. You're right, Mike, that if > you just look at bytes in the LSP database, the cutover is at 4 routers > where it is better to have a pseudonode, if you > ignore the overhead of the CSNP (with a pseudonode *every* RBridge has > to report an extra LSP ID and sequence number > in the CSNP which is not trivial). > > Your math was a bit terse, so let me redo it using your basic numbers > and with a bit more explanation. > I agree with your numbers, but I think it might be hard for others (it > was hard for me) to understand it. > > You said a pseudonode has 27 bytes of header. > Plus it has to list all the router neighbors on the link. > > You said that to report a neighbor it is 12 octets for narrow metrics, > and 1 octets for wide metrics. Is that backwards perhaps? > I'd think it should take more space to report a side metric, but no > matter -- I'll use 12 octets per neighbor. (though it would > be nice to get a clarification on that -- I could imagine that when they > redid the TLV for reporting metrics, they not only > widened the metric but also compressed the format, or maybe got rid of > multiple metrics). > > So, with 4 routers, I seem to get the same result as you said, which is > it costs 21 octets in the LSP database to not use a pseudonode: > > Here's the math worked out, with more comments: > > Assuming 4 routers: > Without pseudonode: each router reports 3 neighbors, so that costs 36 > octets each. > With pseudonode, each router reports 1 neighbor, so that saves 24 octets > in 4 LSPs, at a total savings of 96 octets, but then > you have to add in the pseudonode LSP which has a header of 27, plus 4 > neighbors, so 27+4*12=75 octets. So I get that with > 4 routers the octets in the LSP database alone, as you observe, you lose > without a pseudonode by 21 octets. > Though as I said, the extra LSP also means an extra field in all the > CSNPs. > > With 5 routers, I get: > > Without pseudonode, each router reports 4 neighbors, so that costs 48 > octets each, at a total cost of 5*48=240. > With pseudonode, each router reports 1 neighbor instead of 4, saving 36 > octets in each of 5, at a savings of 180. > The cost of the pseudonode is 27+5*12=87, so not having a pseudonode > costs 180-87, or 93 octets. (though again, this is > somewhat mitigated by getting rid of the extra LSP to report in the CSNP). > > This is useful data, in helping to pick the cutoff point. A possible > reason to have a wider window between "no" and "yes" for > pseudonode is so that it won't flip very often -- once a link has lots > of routers, it stays that way. I think it will be very rare > for a link to have exactly 5 routers, and even though in theory you are > wasting 93 bytes in the LSP database with 5 routers, > it is mitigated by one less entry in the CSNP, which is multiplied by > the total number of routers in the campus. So I think that > the cutoffs of "2" and "5" are probably justifiable as the default, > though I'd be happy with "2" and "4" as the default. > > But at any rate, the difference in complexity between this proposal > (which is 2 bits in a Hello, and the code to follow orders > and report your neighbors directly rather than the pseudonode) vs > requiring configuration on every pt-to-pt port (which more and > more will be close to "all of them"), plus the potential for wrong > configuration (more likely, the mistake will be not configuring a port > to be pt-to-pt and therefore winding up with "silly pseudonodes") -- I > think that this is important in order to allow reasonable > operation with zero configuration. > > Radia > > > > > mike shand wrote: > > Radia Perlman wrote: > > > >> Absolutely. The intention wasn't to "treat the link like a pt-to-pt > >> link" in terms of how LSPs get flooded and ack'ed and all that. > >> That would be too much trouble. It might be more efficient if there > >> are really just two RBridges, to send acks for each LSP > >> rather than the periodic CSNP, but it seems like more trouble for > >> implementations to be > >> able to switch back and forth, and more confusing to switch modes. And > >> even with just two RBridges, it isn't horrible > >> to send CSNPs. > >> > >> However, it does seem horrible to create a pseudonode and an > >> associated LSP for it, > >> for every port, whether there are only two RBridges on the link, > >> or worse yet, a single RBridge with a single endnode. > >> > >> So yes...I'm only proposing that a "non-pseudonode LAN" get reported > >> in LSPs differently. If R1, R2, R3, and R4 are on a link, > >> and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", > >> then each of R1, R2, R3, and R4 report the > >> neighbor "R1.25" in their LSP, and R1 also generates a pseudonode for > >> R1.25, and reports in that, neighbors R1, R2, R3, and R4. > >> > >> If R1 says "don't use pseudonode", then each of them reports 3 > >> neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc. > >> > >> Hope that clarifies -- and sorry for the English ambiguity in the > >> phrase "treat the link like a bunch of pt-to-pt links" which > undoubtedly > >> was a bit scary if you interpreted it the other way. > >> > > Radia, > > Thanks for the clarification. Much less scary:-) > > > > But I'm still not convinced there is any need for this complexity. > > > > We already handle the N=2 case by configuration, and that DOES turn the > > link into a genuine pt-pt link using pt-pt update process. This seems > > like a worthwhile optimization, but I wouldn't want to do it > > automagically. Configuration seems to work well. People tend to know > > whether or not they have 2 or more routers on a LAN, and if they think > > there are 2 and a third turns up that is clearly an error, and should be > > treated as such. See > > > > draft-ietf-isis-igp-p2p-over-lan-06.txt > > > > > > If the motivation for removing the pseudonode is purely space saving in > > the LSP database, then it seems to me that this only applies for very > > small N. I think you win with N=3, and lose with N=4, and it gets worse > > rapidy for >4. And that is assuming we only have router neighbor > > advertisements. > > > > with no pseudonode we get n(n-1) neighbor advertisments, and with a > > pseudoonode we get 2n advertisments. > > The pseudonode itself adds some 27 octets of header, and there is no > > area address. and we need another 2 for the neighbor TLV header. > > Router neighbors take 12 octets per additional neighbor (narrow > > metrics), or 11 for wide metrics. > > > > So for N=3 we have > > > > with PN 6*12 +29 = 101 > > without PN 3*2*12 = 72 > > > > For n=4 > > > > with 8*12+29 =125 > > without 4*3*12 = 144 > > > > for n=15 > > > > with 30*12+29 = 389 > > without 15*14*12 = 2520 > > > > > > I may have made a few errors there, but I think the principle is clear. > > > > It only seems worthwhile for the n=3 case. And even that is marginal. > > > > Of course there is the additional complexity of generating the PN, but > > we have to do all the DR election stuff for the update process anyway, > > so I don't see that as much complexity compared with the complexity of > > figuring out whether you have to do it or not. > > > > I'm not even convinced it simplifies the SPF, but since an SPF for a > > several hundred node network takes < 1mS, I don't see this as a big > > issue either way. However for a 15 node LAN, WITH pseudonode you explore > > 1 hop to the PN then 14 hops to the other nodes, then check on back link > > from each of the 14 to the PN (i.e 29 links). In the non PN case you > > explore 14 hops, then another 14 hops back from each of those 14 (i.e. > > 210 links). It would need a better analysis to determine exactly what > > the relative merits are, but at best I would say it is a wash, and it > > might even be a pessimisation not to have a PN. > > > > "If it ain't broke, don't fix it." > > > > Mike > > > > > >> Radia > >> > >> > >> mike shand wrote: > >> > >>> Radia, > >>> I'm confused. I thought that what you were proposing was switching > >>> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing the > >>> pseudonode, but also using pt-pt mechanisms for the update process, > >>> rather than the broadcast and CSNP mechanism we have for LANs. > >>> > >>> This is exactly what we do at the moment when we configure a LAN as a > >>> 2 node pt-pt "LAN". > >>> > >>> However, this made me very nervous since I don't like the idea of > >>> dynamically messing with the operation of the update process. > >>> > >>> > >>> But, this post makes me think that you mean ONLY getting rid of the > >>> pseudonode, but retaining the CSNP and broadcast based update > >>> process. Otherwise, if you reduce a 15 node LAN to a full mesh pt-pt > >>> you are going to get in excess of 200 LSPs crossing the LAN (not to > >>> mention ACKs). > >>> > >>> > >>> If all you want to do is get rid of the pseudonode, then I am much > >>> less nervous, But I'm still not really convinced it is worth the > bother. > >>> > >>> Could you explain exactly what you have in mind. > >>> > >>> Mike > >>> > >>> Radia Perlman wrote: > >>> > >>>> The WG seemed to think that the pseudonode minimization was a good > >>>> thing for all link state protocols, and therefore > >>>> should be proposed in the routing working group rather than in TRILL. > >>>> > >>>> I'm not convinced it is possible to put in the extra flags necessary > >>>> for OSPF, so perhaps it should just be presented in IS-IS instead. > >>>> > >>>> Also, I was thinking about a rationale for a good cutover. What I > >>>> proposed originally, picking numbers out of > >>>> the air, was 1 or 2 routers, no pseudonode, 5 or more, pseudonode, > >>>> and anything in between, stick with what it was. > >>>> > >>>> Originally, IS-IS was designed for CLNP, and it was necessary to > >>>> report, for each link, all the attached endnodes. So > >>>> even if there were only 2 routers on a LAN, it made sense to create > >>>> a pseudonode, so that all the endnodes wouldn't > >>>> get reported by both routers. > >>>> > >>>> But for TRILL--there really isn't anything reported in the > >>>> pseudonode other than the set of router neighbors. > >>>> Things like the set of supported VLANs, and the set of roots that an > >>>> RBridge might select for a multicast tree, are all > >>>> reported in the RBridge's individual LSP. The only thing in the > >>>> pseudonode LSP is the set of RBridge neighbors. > >>>> > >>>> So, I'm thinking that the right cutover would be something like 15 > >>>> RBridge neighbors before it's worth creating another > >>>> LSP that has a whole header, and appears in every other RBridge's > CSNP. > >>>> > >>>> I must say it's not easy to find the packet formats for IS-IS to > >>>> get the exact number of bytes in an LSP. :-( > >>>> > >>>> Radia > >>>> _______________________________________________ > >>>> rbridge mailing list > >>>> rbridge at postel.org > >>>> http://mailman.postel.org/mailman/listinfo/rbridge > >>>> > >>>> > >>>> > >> > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Thu Jan 31 20:31:01 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 31 Jan 2008 20:31:01 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> <47A23A3D.2040907@sun.com> Message-ID: <47A2A085.30801@sun.com> Les, I'll address each of your concerns in the points below, and below that I have some questions for Mike and Les about IS-IS. 1) "What happens with mix of routers that support this feature or not?" No problem at all. Whether this is being done or not on link L is completely irrelevant to routers that are not attached to L. Having a mix of routers on L is also not a problem. That's what the extra bit in the Hello is -- saying you support this feature. If any router on L does not support the feature, it works like it does today -- with a pseudonode, even if there are just 2 routers, unless someone has configured all the routers on L to consider L to be pt-to-pt. 2) "How bad a hit are transitions?": I think most "Ethernet" links, once we get rid of bridges, will only be pt-to-pt, so in that case there will be no transitions to/from pseudonode. There would be no pseudonodes. The only time there would be transitions is if we actually have a shared cloud with 3 or more routers. I don't think this is a problem. It *is* a little worse when a (non-DR) router goes up or down when you have n (with n>2) routers on a link when you don't use a pseudonode. With a pseudonode, when a non-DR goes up or down, there are just 2 new LSPs (if someone is coming up). Without a pseudonode, all the routers have to reissue their LSP to include the new neighbor (or get rid of the dead one). But the proposal is to have a pseudonode if there are "a lot" of routers. We just need to decide what "a lot" is. Obviously I'm not against pseudonodes (just "silly pseudonodes" -- where there are only 2 or 1 routers on a link). Suppose we got rid of the hysteresis and made it be "use pseudonode if there are at least 3 routers, otherwise, don't". Some people get concerned about the hit of transitioning between pseudonode and not. But I think the only difference at that threshold (2 routers vs 3) is that with a pseudonode, if it's a non-DR that joins or leaves, it's 2 LSPs that gets issued, and without, it's 3 LSPs that get issued (the new guy, and the existing 2 have to each reissue their LSP to include the new guy. I don't think that can be considered a big deal. With the hysteresis, transitions would happen even less frequently (the first time you get to the high water mark, and then the first time you hit the low water mark. 3) "CSNP cost is a red herring since they take up no memory": Counting the exact bytes in memory is a good back of the envelope estimate, but the exact numbers are not that important (a few percent one way or the other are not that important -- both schemes work just fine in some ranges). Nor is it possible to get an exact answer since there are other factors such as bandwidth. That's all I was saying. There *are* issues other than just counting the LSP database size in terms of the bytes in the LSPs. CSNPs and acks take up bandwidth on each link, proportional to the number of LSPs (and each pseudonode adds an extra LSP). On pt-to-pt links, keeping track of the ack-status for each neighbor for each LSP presumably takes up memory, so each pseudonode takes up memory in each pt-to-pt port on routers anywhere in the area And there is probably various implementation-specific housekeeping like pointers to LSPs, that would take up memory per LSP. Mike's arithmetic does show it's not stupid to use pseudonodes with relatively small numbers of routers on the link (like 3). His arithmetic eased my anxiety attack over having introduced pseudonodes in the first place (for DECnet Phase V routing), since I was thinking that although it made sense for CLNP and large shared CSMA/CD links, in this new world where if we get rid of bridges, "Ethernets" are basically all links are pt-to-pt links, that pseudonodes would wind up being a bad idea. In my anxiety attack, I was thinking that pseudonodes would only be cheaper if there were like 20 routers on a link, since in TRILL (unlike CLNP where you have to list all the endnodes) there's nothing in the pseudonode LSP except listing the routers on that link. But as I said, Mike's arithmetic reassured me that it's fine to use pseudonodes, except it would be good to avoid them without any configuration, in the cases of 1 or 2 routers on the link. 4) limited circumstances when this is useful: Suppose a router mindlessly assumed there was a pseudonode for every port? I'd hope it's smart enough not to create a pseudonode when there isn't even a single router neighbor? Not sure what IS-IS implementations do with this. I could imagine that a router with a bunch of ports, each of which are "Ethernets", and for which hundreds of them just have a single endnode on the other end, the router might elect itself DR, and create and advertise a pseudonode for each of those ports. That would clearly be silly, and fairly easily avoided with the rule "don't advertise a pseudonode unless there is at least 2 routers listed in the pseudonode (you and one other). So I think we need to ensure that this doesn't happen (don't advertise pseudonodes when there is just a single router). And maybe it already does (can anyone verify this?) The other case is when there are 2 routers. This might be basically *all* the router-router links, assuming a campus where all the bridges have been upgraded into RBridges. In that case there would be 33% more LSPs, and an LSP approximately twice as big. It could be even bigger than that if there are multiple pt-to-pt Ethernets connecting the same two routers. With pseudonodes, each port would be a pseudonode, whereas it would be relatively easy for R1 to realize it shouldn't list R2 as a neighbor multiple times. **************** So, actually, I have a few questions: a) without configuration, would an IS-IS router today create a pseudonode if it is the only router on an Ethernet link? For instance, suppose R1 and R2 are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two LSPs, one saying the pseudonode is R1.25 with neighbor R1, and another saying R1 has neighbor R1.25? Or when R2 goes down, does R1 get rid of the pseudonode? b) suppose R1 and R2 are both on the same Ethernet, and one is configured that that port is pt-to-pt and the other is not configured that way. What happens? c) suppose R1, R2, and R3 are all on the same Ethernet, and all are configured that that port is pt-to-pt. What happens? Radia Les Ginsberg (ginsberg) wrote: > Radia - > > The CSNP cost is a red herring. > CSNPs are not permanently stored in your LSPDB - they are used to verify > that your LSPDB is in sync with your neighbor(s) and then discarded. So > unless you are going to argue that the extra bandwidth used by CSNPs > (which are sent infrequently - even when periodic) with the additional > pseudo-LSP entries is prohibitive - this issue can be ignored. > > Therefore Mike's calculations of the space savings/costs should be taken > as representative of the impact of this "enhancement". > > As for your statement: > > "I don't think it is complex. It costs 2 bits in Hellos." > > This is a gross oversimplification. Although only two bits may needed > for encoding, there are numerous concerns which have to be addressed in > a robust implementation. For example: > > 1)How to do the transitions in a hitless manner > 2)What should be done if all routers on the network do not support the > extension > 3)Rate limiting transitions to avoid storms associated with router > instability > > Given the quite limited set of circumstances in which any benefits are > realized and the modest gains that the extension can achieve in those > cases, it is very difficult for me to have any enthusiasm for this idea. > > As for the zero configuration issue, treat LANs as LANs always if you > must. > > Les > > >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] >> > On > >> Behalf Of Radia Perlman >> Sent: Thursday, January 31, 2008 1:15 PM >> To: Mike Shand (mshand) >> Cc: Developing a hybrid router/bridge. >> Subject: Re: [rbridge] Pseudonode minimization thoughts... >> >> Well, I think it is really important to avoid configuration -- both >> because of the hassle of configuration, >> and people getting configruation wrong. >> >> This proposal eliminates >> "silly pseudonodes", i.e., pseudonodes >> when there are only 1 or 2 routers on a link, and does not require >> configuration. >> >> I don't think it is complex. It costs 2 bits in Hellos. I'm glad you >> worked out the math though. You're right, Mike, that if >> you just look at bytes in the LSP database, the cutover is at 4 >> > routers > >> where it is better to have a pseudonode, if you >> ignore the overhead of the CSNP (with a pseudonode *every* RBridge has >> to report an extra LSP ID and sequence number >> in the CSNP which is not trivial). >> >> Your math was a bit terse, so let me redo it using your basic numbers >> and with a bit more explanation. >> I agree with your numbers, but I think it might be hard for others (it >> was hard for me) to understand it. >> >> You said a pseudonode has 27 bytes of header. >> Plus it has to list all the router neighbors on the link. >> >> You said that to report a neighbor it is 12 octets for narrow metrics, >> and 1 octets for wide metrics. Is that backwards perhaps? >> I'd think it should take more space to report a side metric, but no >> matter -- I'll use 12 octets per neighbor. (though it would >> be nice to get a clarification on that -- I could imagine that when >> > they > >> redid the TLV for reporting metrics, they not only >> widened the metric but also compressed the format, or maybe got rid of >> multiple metrics). >> >> So, with 4 routers, I seem to get the same result as you said, which >> > is > >> it costs 21 octets in the LSP database to not use a pseudonode: >> >> Here's the math worked out, with more comments: >> >> Assuming 4 routers: >> Without pseudonode: each router reports 3 neighbors, so that costs 36 >> octets each. >> With pseudonode, each router reports 1 neighbor, so that saves 24 >> > octets > >> in 4 LSPs, at a total savings of 96 octets, but then >> you have to add in the pseudonode LSP which has a header of 27, plus 4 >> neighbors, so 27+4*12=75 octets. So I get that with >> 4 routers the octets in the LSP database alone, as you observe, you >> > lose > >> without a pseudonode by 21 octets. >> Though as I said, the extra LSP also means an extra field in all the >> CSNPs. >> >> With 5 routers, I get: >> >> Without pseudonode, each router reports 4 neighbors, so that costs 48 >> octets each, at a total cost of 5*48=240. >> With pseudonode, each router reports 1 neighbor instead of 4, saving >> > 36 > >> octets in each of 5, at a savings of 180. >> The cost of the pseudonode is 27+5*12=87, so not having a pseudonode >> costs 180-87, or 93 octets. (though again, this is >> somewhat mitigated by getting rid of the extra LSP to report in the >> > CSNP). > >> This is useful data, in helping to pick the cutoff point. A possible >> reason to have a wider window between "no" and "yes" for >> pseudonode is so that it won't flip very often -- once a link has lots >> of routers, it stays that way. I think it will be very rare >> for a link to have exactly 5 routers, and even though in theory you >> > are > >> wasting 93 bytes in the LSP database with 5 routers, >> it is mitigated by one less entry in the CSNP, which is multiplied by >> the total number of routers in the campus. So I think that >> the cutoffs of "2" and "5" are probably justifiable as the default, >> though I'd be happy with "2" and "4" as the default. >> >> But at any rate, the difference in complexity between this proposal >> (which is 2 bits in a Hello, and the code to follow orders >> and report your neighbors directly rather than the pseudonode) vs >> requiring configuration on every pt-to-pt port (which more and >> more will be close to "all of them"), plus the potential for wrong >> configuration (more likely, the mistake will be not configuring a port >> to be pt-to-pt and therefore winding up with "silly pseudonodes") -- I >> think that this is important in order to allow reasonable >> operation with zero configuration. >> >> Radia >> >> >> >> >> mike shand wrote: >> >>> Radia Perlman wrote: >>> >>> >>>> Absolutely. The intention wasn't to "treat the link like a pt-to-pt >>>> link" in terms of how LSPs get flooded and ack'ed and all that. >>>> That would be too much trouble. It might be more efficient if there >>>> are really just two RBridges, to send acks for each LSP >>>> rather than the periodic CSNP, but it seems like more trouble for >>>> implementations to be >>>> able to switch back and forth, and more confusing to switch modes. >>>> > And > >>>> even with just two RBridges, it isn't horrible >>>> to send CSNPs. >>>> >>>> However, it does seem horrible to create a pseudonode and an >>>> associated LSP for it, >>>> for every port, whether there are only two RBridges on the link, >>>> or worse yet, a single RBridge with a single endnode. >>>> >>>> So yes...I'm only proposing that a "non-pseudonode LAN" get >>>> > reported > >>>> in LSPs differently. If R1, R2, R3, and R4 are on a link, >>>> and, say, R1 is DRB, then if R1 says "use pseudonode named R1.25", >>>> then each of R1, R2, R3, and R4 report the >>>> neighbor "R1.25" in their LSP, and R1 also generates a pseudonode >>>> > for > >>>> R1.25, and reports in that, neighbors R1, R2, R3, and R4. >>>> >>>> If R1 says "don't use pseudonode", then each of them reports 3 >>>> neighbors; R1 reports R2, R3, R4.....R2 reports R1, R3, R4, etc. >>>> >>>> Hope that clarifies -- and sorry for the English ambiguity in the >>>> phrase "treat the link like a bunch of pt-to-pt links" which >>>> >> undoubtedly >> >>>> was a bit scary if you interpreted it the other way. >>>> >>>> >>> Radia, >>> Thanks for the clarification. Much less scary:-) >>> >>> But I'm still not convinced there is any need for this complexity. >>> >>> We already handle the N=2 case by configuration, and that DOES turn >>> > the > >>> link into a genuine pt-pt link using pt-pt update process. This >>> > seems > >>> like a worthwhile optimization, but I wouldn't want to do it >>> automagically. Configuration seems to work well. People tend to know >>> whether or not they have 2 or more routers on a LAN, and if they >>> > think > >>> there are 2 and a third turns up that is clearly an error, and >>> > should be > >>> treated as such. See >>> >>> draft-ietf-isis-igp-p2p-over-lan-06.txt >>> >>> >>> If the motivation for removing the pseudonode is purely space saving >>> > in > >>> the LSP database, then it seems to me that this only applies for >>> > very > >>> small N. I think you win with N=3, and lose with N=4, and it gets >>> > worse > >>> rapidy for >4. And that is assuming we only have router neighbor >>> advertisements. >>> >>> with no pseudonode we get n(n-1) neighbor advertisments, and with a >>> pseudoonode we get 2n advertisments. >>> The pseudonode itself adds some 27 octets of header, and there is no >>> area address. and we need another 2 for the neighbor TLV header. >>> Router neighbors take 12 octets per additional neighbor (narrow >>> metrics), or 11 for wide metrics. >>> >>> So for N=3 we have >>> >>> with PN 6*12 +29 = 101 >>> without PN 3*2*12 = 72 >>> >>> For n=4 >>> >>> with 8*12+29 =125 >>> without 4*3*12 = 144 >>> >>> for n=15 >>> >>> with 30*12+29 = 389 >>> without 15*14*12 = 2520 >>> >>> >>> I may have made a few errors there, but I think the principle is >>> > clear. > >>> It only seems worthwhile for the n=3 case. And even that is >>> > marginal. > >>> Of course there is the additional complexity of generating the PN, >>> > but > >>> we have to do all the DR election stuff for the update process >>> > anyway, > >>> so I don't see that as much complexity compared with the complexity >>> > of > >>> figuring out whether you have to do it or not. >>> >>> I'm not even convinced it simplifies the SPF, but since an SPF for a >>> several hundred node network takes < 1mS, I don't see this as a big >>> issue either way. However for a 15 node LAN, WITH pseudonode you >>> > explore > >>> 1 hop to the PN then 14 hops to the other nodes, then check on back >>> > link > >>> from each of the 14 to the PN (i.e 29 links). In the non PN case you >>> explore 14 hops, then another 14 hops back from each of those 14 >>> > (i.e. > >>> 210 links). It would need a better analysis to determine exactly >>> > what > >>> the relative merits are, but at best I would say it is a wash, and >>> > it > >>> might even be a pessimisation not to have a PN. >>> >>> "If it ain't broke, don't fix it." >>> >>> Mike >>> >>> >>> >>>> Radia >>>> >>>> >>>> mike shand wrote: >>>> >>>> >>>>> Radia, >>>>> I'm confused. I thought that what you were proposing was >>>>> > switching > >>>>> all the mechanisms from "LAN" to "Pt-Pt". i.e. not only removing >>>>> > the > >>>>> pseudonode, but also using pt-pt mechanisms for the update >>>>> > process, > >>>>> rather than the broadcast and CSNP mechanism we have for LANs. >>>>> >>>>> This is exactly what we do at the moment when we configure a LAN >>>>> > as a > >>>>> 2 node pt-pt "LAN". >>>>> >>>>> However, this made me very nervous since I don't like the idea of >>>>> dynamically messing with the operation of the update process. >>>>> >>>>> >>>>> But, this post makes me think that you mean ONLY getting rid of >>>>> > the > >>>>> pseudonode, but retaining the CSNP and broadcast based update >>>>> process. Otherwise, if you reduce a 15 node LAN to a full mesh >>>>> > pt-pt > >>>>> you are going to get in excess of 200 LSPs crossing the LAN (not >>>>> > to > >>>>> mention ACKs). >>>>> >>>>> >>>>> If all you want to do is get rid of the pseudonode, then I am much >>>>> less nervous, But I'm still not really convinced it is worth the >>>>> >> bother. >> >>>>> Could you explain exactly what you have in mind. >>>>> >>>>> Mike >>>>> >>>>> Radia Perlman wrote: >>>>> >>>>> >>>>>> The WG seemed to think that the pseudonode minimization was a >>>>>> > good > >>>>>> thing for all link state protocols, and therefore >>>>>> should be proposed in the routing working group rather than in >>>>>> > TRILL. > >>>>>> I'm not convinced it is possible to put in the extra flags >>>>>> > necessary > >>>>>> for OSPF, so perhaps it should just be presented in IS-IS >>>>>> > instead. > >>>>>> Also, I was thinking about a rationale for a good cutover. What I >>>>>> proposed originally, picking numbers out of >>>>>> the air, was 1 or 2 routers, no pseudonode, 5 or more, >>>>>> > pseudonode, > >>>>>> and anything in between, stick with what it was. >>>>>> >>>>>> Originally, IS-IS was designed for CLNP, and it was necessary to >>>>>> report, for each link, all the attached endnodes. So >>>>>> even if there were only 2 routers on a LAN, it made sense to >>>>>> > create > >>>>>> a pseudonode, so that all the endnodes wouldn't >>>>>> get reported by both routers. >>>>>> >>>>>> But for TRILL--there really isn't anything reported in the >>>>>> pseudonode other than the set of router neighbors. >>>>>> Things like the set of supported VLANs, and the set of roots that >>>>>> > an > >>>>>> RBridge might select for a multicast tree, are all >>>>>> reported in the RBridge's individual LSP. The only thing in the >>>>>> pseudonode LSP is the set of RBridge neighbors. >>>>>> >>>>>> So, I'm thinking that the right cutover would be something like >>>>>> > 15 > >>>>>> RBridge neighbors before it's worth creating another >>>>>> LSP that has a whole header, and appears in every other RBridge's >>>>>> >> CSNP. >> >>>>>> I must say it's not easy to find the packet formats for IS-IS to >>>>>> get the exact number of bytes in an LSP. :-( >>>>>> >>>>>> Radia >>>>>> _______________________________________________ >>>>>> rbridge mailing list >>>>>> rbridge at postel.org >>>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>>> >>>>>> >>>>>> >>>>>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >>