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