From Donald.Eastlake at motorola.com Tue Sep 4 05:22:29 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 4 Sep 2007 08:22:29 -0400 Subject: [rbridge] Consensus: Addition of "Other Multicast" bit to the Multicast RouterAttached Bits In-Reply-To: <3870C46029D1F945B1472F170D2D979002D97B79@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002D97B79@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979002FE7B34@de01exm64.ds.mot.com> There seems to be plenty of support and almost no opposition to the technical change below so we declare it to be the consensus of the TRILL working group. Donald & Erik -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Saturday, July 28, 2007 11:43 PM To: Rbridge at postel.org Subject: [rbridge] Addition of "Other Multicast" bit to the Multicast RouterAttached Bits In the base protocol draft -05 there are two multicast router attachment bits. The tentative consensus at the TRILL meeting last week was to add a third bit so the situation would be as follows: o There are 3 bits in TRILL IS-IS LSPs that appear per VLAN per Rbridge. They are named "Other Multicast (OM)", "IPv4 attached multicast router (MR4)", and "IPv6 attached multicast router (MR6)". o When these bits are set, they cause all multicast frames for the appropriate VLAN to be sent to the Rbridge with the bit on for IPv4 derived multicast (MR4), IPv6 derived multicast (MR6), or all other multicast (OM). (Even if the MR4 or MR6 bit is off, multicast data frames are still sent to the Rbridge if multicast listeners for that data are reported by the Rbridge.) o MR4 is set by an RBridge when it, as Designated Rbridge (DRB), receives a native IGMP Query or IPv4 MRD Report on a port. (As per the relevant RFCs, the bit times out and is cleared unless repeatedly set.) This is an IGMP-snooping action. If an RBridge doesn't support this IGMP-snooping action, it always sets this bit to 1. o MR6 is set by an RBridge when it, as DRB, receives a native MLD Query or IPv6 MRD Report on port. This is an MLD-snooping action. (As per the relevant RFCs, the bit times out and is cleared unless repeatedly set.) If an RBridge doesn't support this MLD-snooping action, it always sets this bit to 1. o OM can't be set by dynamic signaling since non-IPv4/IPv6 derived multicast frames have no widely deployed signaling mechanism. It's value is set by either configuration or deciding on a default setting. o The recommendation is to default the 3 bits to {1,0,0} for {OM,MR4,MR6} respectively for Rbridges that implement IP derived multicast snooping. This causes all non-IPv4/IPv6 (other) multicast frames to be flooded to such RBridges and snooping protocols can set the MR4 and MR6 bits conditionally. For Rbridges that do not implement IP derived multicast snooping, the bits should default to (1,1,1). Thanks, Donald _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Tue Sep 4 05:33:02 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 4 Sep 2007 08:33:02 -0400 Subject: [rbridge] Consensus Check: V-field reversion Message-ID: <3870C46029D1F945B1472F170D2D979002FE7B3A@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Chicago meeting for a change from protocol draft -05: Eliminate different V field values and revert to two version bits and two reserved bits with the previous provisions that this draft specifies version zero, frames with an unknown version are discarded, reserved bits MUST be zero and are ignored on receipt. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Tue Sep 4 05:34:59 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 4 Sep 2007 08:34:59 -0400 Subject: [rbridge] Consensus Check: MAC learning timers Message-ID: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Chicago meeting: MAC address remembering timers in TRILL should have the same configuration limits and default as in 802.1Q-2005. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik From erik.nordmark at sun.com Wed Sep 5 16:34:34 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 05 Sep 2007 16:34:34 -0700 Subject: [rbridge] Proposed new milestones In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201FAB1D2@nuova-ex1.hq.nuovaimpresa.com> References: <46D83AE4.30504@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201FAB1D2@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <46DF3D0A.8090203@sun.com> Silvano Gai wrote: > My understanding was that we added a milestone to last call the frame > format before the end of the year. We didn't actually discuss that at the meeting. If the WG wants to commit to doing a WG last call this year that is fine. And we don't actually have to add it to the page. But the ADs want to see us to update the current set of milestones since the current set is out of date. Thus I'm inclined to proceed without adding that particular milestone and instead get the updated milestones to the ADs. Erik > -- Silvano > >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > On >> Behalf Of Erik Nordmark >> Sent: Friday, August 31, 2007 9:00 AM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] Proposed new milestones >> >> Any comments on these proposed new milestone dates? We discussed >> withdrawing the second milestone at and before Chicago. Do the dates >> look reasonable? >> >> >> Dec 2007 Submit architecture document to IEEE/IETF expert review >> >> WITHDRAWN Submit routing protocol requirements to the IESG for >> publication as an Informational RFC >> >> Dec 2007 Submit problem statement and applicability to IESG for >> Informational RFC >> >> Mar 2007 Submit architecture document to the IESG for publication >> as an Informational RFC >> >> Done Choose routing protocol(s) that can meet the >> requirements >> >> Dec 2007 Submit base protocol specification to IEEE/IETF >> expert review >> >> Mar 2008 Base protocol specification submitted to the >> IESG for publication as a Proposed Standard RFC >> >> Dec 2008 Re-charter or shut down the WG >> >> ------ >> >> For reference - the currently posted list of milestones are: >> Done Accept base protocol specification as a WG document >> >> Done Accept problem statement and applicability as a WG work >> item >> >> Done Start work with routing area WG(s) to undertake TRILL >> extensions >> >> Done Accept architecture document as a WG work item >> >> Done Accept routing protocol requirements as a WG work item >> >> Aug 2006 Submit architecture document to IEEE/IETF expert review >> >> Aug 2006 Submit routing protocol requirements to the IESG for >> publication as an Informational RFC >> >> Aug 2006 Submit problem statement and applicability to IESG for >> Informational RFC >> >> Nov 2006 Submit architecture document to the IESG for publication >> as an Informational RFC >> >> Dec 2006 Choose routing protocol(s) that can meet the >> requirements >> >> Dec 2006 Submit base protocol specification to IEEE/IETF >> expert review >> >> Mar 2007 Base protocol specification submitted to the >> IESG for publication as a Proposed Standard RFC >> >> Jul 2007 Re-charter or shut down the WG >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Wed Sep 5 19:56:31 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 05 Sep 2007 19:56:31 -0700 Subject: [rbridge] Proposed new milestones In-Reply-To: <46D83AE4.30504@sun.com> References: <46D83AE4.30504@sun.com> Message-ID: <46DF6C5F.6060705@isi.edu> Regarding the PAS, I'd be very glad to wrap it up by Dec. Unfortunately, I have received no input on the pending issues indicated therein since Oct 2006. Do we have a plan on how to resolve those open issues? (I can post a summary to the list if that'd help) Joe Erik Nordmark wrote: > Any comments on these proposed new milestone dates? We discussed > withdrawing the second milestone at and before Chicago. Do the dates > look reasonable? > > > Dec 2007 Submit architecture document to IEEE/IETF expert review > > WITHDRAWN Submit routing protocol requirements to the IESG for > publication as an Informational RFC > > Dec 2007 Submit problem statement and applicability to IESG for > Informational RFC > > Mar 2007 Submit architecture document to the IESG for publication > as an Informational RFC > > Done Choose routing protocol(s) that can meet the > requirements > > Dec 2007 Submit base protocol specification to IEEE/IETF > expert review > > Mar 2008 Base protocol specification submitted to the > IESG for publication as a Proposed Standard RFC > > Dec 2008 Re-charter or shut down the WG > > ------ > > For reference - the currently posted list of milestones are: > Done Accept base protocol specification as a WG document > > Done Accept problem statement and applicability as a WG work > item > > Done Start work with routing area WG(s) to undertake TRILL > extensions > > Done Accept architecture document as a WG work item > > Done Accept routing protocol requirements as a WG work item > > Aug 2006 Submit architecture document to IEEE/IETF expert review > > Aug 2006 Submit routing protocol requirements to the IESG for > publication as an Informational RFC > > Aug 2006 Submit problem statement and applicability to IESG for > Informational RFC > > Nov 2006 Submit architecture document to the IESG for publication > as an Informational RFC > > Dec 2006 Choose routing protocol(s) that can meet the > requirements > > Dec 2006 Submit base protocol specification to IEEE/IETF > expert review > > Mar 2007 Base protocol specification submitted to the > IESG for publication as a Proposed Standard RFC > > Jul 2007 Re-charter or shut down the WG > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070905/6201427b/signature.bin From touch at ISI.EDU Thu Sep 6 06:52:36 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 06 Sep 2007 06:52:36 -0700 Subject: [rbridge] Consensus Check: V-field reversion In-Reply-To: <3870C46029D1F945B1472F170D2D979002FE7B3A@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3A@de01exm64.ds.mot.com> Message-ID: <46E00624.3060302@isi.edu> Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Chicago meeting for a change from protocol draft -05: > > Eliminate different V field values and revert to two version bits > and two reserved bits with the previous provisions that this draft > specifies version zero, frames with an unknown version are > discarded, reserved bits MUST be zero and are ignored on receipt. Minor nit to avoid ambiguity: ...MUST be _set to_ zero... > If no particular controversy arises over this in the next two 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 -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070906/3bc4eb9a/signature.bin From touch at ISI.EDU Thu Sep 6 06:54:15 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 06 Sep 2007 06:54:15 -0700 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> Message-ID: <46E00687.80507@isi.edu> Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Chicago meeting: > > MAC address remembering timers in TRILL should have the same > configuration limits and default as in 802.1Q-2005. Minor nits: replace "remembering" with "cache persistence" replace "default" with "defaults" (isn't there more than one timer?) Minor question: Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc? Joe > > If no particular controversy arises over this in the next two 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 -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070906/493afcc6/signature.bin From james.d.carlson at sun.com Thu Sep 6 07:54:04 2007 From: james.d.carlson at sun.com (James Carlson) Date: Thu, 6 Sep 2007 10:54:04 -0400 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <46E00687.80507@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> Message-ID: <18144.5260.800390.204166@gargle.gargle.HOWL> Joe Touch writes: > Eastlake III Donald-LDE008 wrote: > > This is a check via the mailing list to confirm or refute an apparent > > consensus at the Chicago meeting: > > > > MAC address remembering timers in TRILL should have the same > > configuration limits and default as in 802.1Q-2005. > > Minor nits: > > replace "remembering" with "cache persistence" > > replace "default" with "defaults" (isn't there more than one timer?) > > Minor question: > > Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc? What would be the basis of the MUST? Is there something in TRILL that falls apart if an implementation fails to heed this advice? I don't see what the exact interoperability issue would be. Lacking a clear interoperability issue for TRILL itself, SHOULD seems right to me. It means that implementations are required to follow that IEEE standard unless they've got a good reason to do otherwise. -- James Carlson, Solaris Networking Sun Microsystems / 1 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 Thu Sep 6 17:22:58 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 06 Sep 2007 17:22:58 -0700 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <18144.5260.800390.204166@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> Message-ID: <46E099E2.4030308@isi.edu> James Carlson wrote: > Joe Touch writes: >> Eastlake III Donald-LDE008 wrote: >>> This is a check via the mailing list to confirm or refute an apparent >>> consensus at the Chicago meeting: >>> >>> MAC address remembering timers in TRILL should have the same >>> configuration limits and default as in 802.1Q-2005. >> Minor nits: >> >> replace "remembering" with "cache persistence" >> >> replace "default" with "defaults" (isn't there more than one timer?) >> >> Minor question: >> >> Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc? > > What would be the basis of the MUST? Is there something in TRILL that > falls apart if an implementation fails to heed this advice? I don't > see what the exact interoperability issue would be. > > Lacking a clear interoperability issue for TRILL itself, SHOULD seems > right to me. It means that implementations are required to follow > that IEEE standard unless they've got a good reason to do otherwise. I'd say MUST follow IEEE requirements. I'm wondering how the IEEE spec's the defaults; if they're a MUST, then why wouldn't we follow suit? How would we know what would break with intermediate bridges? If, alternately, the defaults are SHOULDs, then ours can be too. I don't think it would be useful to diverge from those specs except where we deliberately need to. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070906/4f77c7d1/signature.bin From john at jlc.net Thu Sep 6 18:45:47 2007 From: john at jlc.net (John Leslie) Date: Thu, 6 Sep 2007 21:45:47 -0400 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <46E099E2.4030308@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> Message-ID: <20070907014547.GE80806@verdi> Joe Touch wrote: > James Carlson wrote: >> Joe Touch writes: >>> Eastlake III Donald-LDE008 wrote: >>> >>>> This is a check via the mailing list to confirm or refute an apparent >>>> consensus at the Chicago meeting: >>>> >>>> MAC address remembering timers in TRILL should have the same >>>> configuration limits and default as in 802.1Q-2005. >> >>> Minor question: >>> >>> Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc? >> >> What would be the basis of the MUST? Is there something in TRILL that >> falls apart if an implementation fails to heed this advice? I don't >> see what the exact interoperability issue would be. >> >> Lacking a clear interoperability issue for TRILL itself, SHOULD seems >> right to me. It means that implementations are required to follow >> that IEEE standard unless they've got a good reason to do otherwise. > > I'd say MUST follow IEEE requirements. I agree with James: absent something which falls apart, we should avoid a MUST. > I'm wondering how the IEEE spec's the defaults; if they're a MUST, then > why wouldn't we follow suit? IEEE specs can change; ours (effectively) can't. > How would we know what would break with intermediate bridges? That's what we're paid the big bucks for... ;^) > If, alternately, the defaults are SHOULDs, then ours can be too. If theirs are MUSTs, why doesn't simply referencing them suffice. If we put a MUST in our document, it should be because we know that failure to implement it would harm interoperability of _our_ protocol. > I don't think it would be useful to diverge from those specs except > where we deliberately need to. IMHO, we face scaling issues that IEEE does not. It may not be easy to foresee those effects of scaling, but we should at least leave ourselves wiggle room to deal with them. -- John Leslie From touch at ISI.EDU Thu Sep 6 19:56:20 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 06 Sep 2007 19:56:20 -0700 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <20070907014547.GE80806@verdi> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> <20070907014547.GE80806@verdi> Message-ID: <46E0BDD4.8000209@isi.edu> John Leslie wrote: ... >> I don't think it would be useful to diverge from those specs except >> where we deliberately need to. > > IMHO, we face scaling issues that IEEE does not. It may not be easy > to foresee those effects of scaling, but we should at least leave > ourselves wiggle room to deal with them. Scaling is outside this work. We're not intended to scale beyond what IEEE works for. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070906/b23dbb0e/signature.bin From james.d.carlson at sun.com Fri Sep 7 03:41:50 2007 From: james.d.carlson at sun.com (James Carlson) Date: Fri, 7 Sep 2007 06:41:50 -0400 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <46E099E2.4030308@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> Message-ID: <18145.10990.755022.598448@gargle.gargle.HOWL> Joe Touch writes: > James Carlson wrote: > > Lacking a clear interoperability issue for TRILL itself, SHOULD seems > > right to me. It means that implementations are required to follow > > that IEEE standard unless they've got a good reason to do otherwise. > > I'd say MUST follow IEEE requirements. Where's the TRILL requirement for this? I'm saying SHOULD because our role here isn't to design IEEE protocols, nor is it to "enforce" any rules set down by IEEE. Instead, our role is to design TRILL, and specify what's _required_ to make that work. Is there an issue here that, if someone had a good reason to use some other set of defaults for these parameters, doing so would break TRILL? If there's no such issue, then we don't need a "MUST." Following the IEEE norms becomes just an issue of good practice, and not a fundamental requirement of the protocol. I'm not talking about people who wantonly ignore standards. There's nothing we can do about that situation -- they'll ignore MUST just as easily as they'll ignore the implication of SHOULD. I'm talking about requirements for TRILL itself. > I'm wondering how the IEEE spec's the defaults; if they're a MUST, then > why wouldn't we follow suit? How would we know what would break with > intermediate bridges? If, alternately, the defaults are SHOULDs, then > ours can be too. > > I don't think it would be useful to diverge from those specs except > where we deliberately need to. I'm not suggesting creating a divergence in actual values. I'm suggesting that we don't need to copy the IEEE language into the TRILL documents _unless_ there's a specific TRILL-related issue to solve. Using SHOULD doesn't actually diverge us from IEEE, even if they use MUST. It provides leeway for a savvy implementor to spurn IEEE's mandate for the good of TRILL, _if_ that's actually the right thing to do. It still requires others to follow IEEE if they don't have that "good reason." -- James Carlson, Solaris Networking Sun Microsystems / 1 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 Fri Sep 7 07:15:29 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 07 Sep 2007 07:15:29 -0700 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <18145.10990.755022.598448@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> <18145.10990.755022.598448@gargle.gargle.HOWL> Message-ID: <46E15D01.50702@isi.edu> James Carlson wrote: > Joe Touch writes: >> James Carlson wrote: >>> Lacking a clear interoperability issue for TRILL itself, SHOULD seems >>> right to me. It means that implementations are required to follow >>> that IEEE standard unless they've got a good reason to do otherwise. >> I'd say MUST follow IEEE requirements. > > Where's the TRILL requirement for this? > > I'm saying SHOULD because our role here isn't to design IEEE > protocols, nor is it to "enforce" any rules set down by IEEE. > > Instead, our role is to design TRILL, and specify what's _required_ to > make that work. Is there an issue here that, if someone had a good > reason to use some other set of defaults for these parameters, doing > so would break TRILL? I'm concerned about breaking the non-TRILL devices by TRILL behavior. If our caches have timeouts different from theirs, then the overall system won't be as plug-and-play -- or, more specifically, more 'replug-and-play'. That's why we're recommending IEEE values and defaults; that didn't come out of the blue. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070907/5a3d53f5/signature.bin From james.d.carlson at sun.com Fri Sep 7 10:58:31 2007 From: james.d.carlson at sun.com (James Carlson) Date: Fri, 7 Sep 2007 13:58:31 -0400 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <46E15D01.50702@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> <18145.10990.755022.598448@gargle.gargle.HOWL> <46E15D01.50702@isi.edu> Message-ID: <18145.37191.943519.790828@gargle.gargle.HOWL> Joe Touch writes: > James Carlson wrote: > > Instead, our role is to design TRILL, and specify what's _required_ to > > make that work. Is there an issue here that, if someone had a good > > reason to use some other set of defaults for these parameters, doing > > so would break TRILL? > > I'm concerned about breaking the non-TRILL devices by TRILL behavior. If > our caches have timeouts different from theirs, then the overall system > won't be as plug-and-play -- or, more specifically, more 'replug-and-play'. > > That's why we're recommending IEEE values and defaults; that didn't come > out of the blue. Yes, and that's precisely the reason to "recommend" those defaults -- as in BCP 14 "SHOULD." I never did suggest that they came out of the blue or that anyone ought to ignore them. However, as a matter of operating TRILL, they don't appear (to me at least) to be key issues that will cause TRILL failure. That means they're not a "MUST." I think it's an important distinction, but I suppose it's not a hill worth dying on. If you feel that we simply cannot proceed without a "MUST" here, or a copy of some IEEE text, then I'll relent. It's not as though I was going to ignore those defaults myself anyway. -- James Carlson, Solaris Networking Sun Microsystems / 1 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 Fri Sep 7 16:30:04 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 07 Sep 2007 16:30:04 -0700 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <18145.37191.943519.790828@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> <18145.10990.755022.598448@gargle.gargle.HOWL> <46E15D01.50702@isi.edu> <18145.37191.943519.790828@gargle.gargle.HOWL> Message-ID: <46E1DEFC.9090502@isi.edu> James Carlson wrote: > Joe Touch writes: >> James Carlson wrote: >>> Instead, our role is to design TRILL, and specify what's _required_ to >>> make that work. Is there an issue here that, if someone had a good >>> reason to use some other set of defaults for these parameters, doing >>> so would break TRILL? >> I'm concerned about breaking the non-TRILL devices by TRILL behavior. If >> our caches have timeouts different from theirs, then the overall system >> won't be as plug-and-play -- or, more specifically, more 'replug-and-play'. >> >> That's why we're recommending IEEE values and defaults; that didn't come >> out of the blue. > > Yes, and that's precisely the reason to "recommend" those defaults -- > as in BCP 14 "SHOULD." I never did suggest that they came out of the > blue or that anyone ought to ignore them. > > However, as a matter of operating TRILL, they don't appear (to me at > least) to be key issues that will cause TRILL failure. That means > they're not a "MUST." That's fine. Let's hear what others think. I just want to make sure we're picking the right one and understanding what we're picking; I really didn't have an a-priori decision. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI -------------- 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/20070907/e03bd427/signature.bin From erik.nordmark at sun.com Wed Sep 12 10:43:37 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 12 Sep 2007 10:43:37 -0700 Subject: [rbridge] Ambition with different VLAN configurations Message-ID: <46E82549.7030102@sun.com> The list has had discussions on how to do hellos with VLANs, and the discussion makes me wonder whether we have agreement on the level of ambition with various unusual VLAN configuration in the bridged LANs. By "ambition" I mean whether in a particular case we should: 1. Make RBridges provide full connectivity for all the nodes in the bridged LAN 2. Make RBridges at least detect that there is something odd about the VLAN configuration and ensure that no permanent loops can be formed. But it would be ok to orphan some nodes from communicating. One can ask that question for different VLAN scenarios. One interesting case that Donald brought up is when there isn't a single VLAN tag on which all the RBridges can communicate. For instance, RB0 and RB1 can only send and receive using VLAN tag 3. RB2 can only send and receive using VLAN tag 4. RB3 and RB4 can send and receive using both VLAN tag 3 and 4. There are different schemes for making hellos detect the connectivity in this case. So let's ignore that and instead look at the implications on the data plane if we want ambition #1. Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag should it use? There isn't a single VLAN tag that it can use whichever reach all RBridge neighbors. But RB4 can't treat the port as two logically different ports (one for VLAN tag 3 and a separate one for 4) either, since RB2 is a neighbor for both VLANs. Thus if we wanted this case to provide full connectivity it would seem like the data plane would need to be able to duplicate packets and send some unicast; a possible strategy would be to multicast with tag 3, and then unicast a copy to RB2 (with tag 4). That way all the neighboring RBridges would receive the frame. That sounds complex. There might be other examples of odd VLAN configuration (such as bridges which untag and then add some other tag when forwarding the frame) which are complex to fully support. What level of ambition should we have for the odd cases? Erik From Radia.Perlman at sun.com Fri Sep 14 12:17:39 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 14 Sep 2007 12:17:39 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46E82549.7030102@sun.com> References: <46E82549.7030102@sun.com> Message-ID: <46EADE53.2020305@sun.com> . I think we should only make sure that in odd configurations there are no loops. We should not worry about partitions caused by nontransitive connectivity. . I think we should go to some amount of trouble to ensure there are not even temporary loops (not just "no permanent loops". . It would be nice to say "never ever have any loops", but I don't think that's possible, given repeaters coming up, messages getting lost, a bridge or RBridge exhibiting bizarre behavior due to some bug, etc. That has nothing to do with TRILL -- any design might occasionally wind up with a loop in low probability events, and we should make sure that the probability is very low and minimize the length of time/effect if things go wrong. . I prefer a design in which there should be one VLAN tag (the default one) that is not partitioned on a layer 2 cloud, and all RBridge-RBridge communication on that cloud (including Hello messages) should have that VLAN tag on the outside, and if that VLAN is indeed partitioned, then all but one RBridge, even if elected to be DRB on some set of VLANs, will refrain from forwarding data to/from the link. Radia Erik Nordmark wrote: > The list has had discussions on how to do hellos with VLANs, and the > discussion makes me wonder whether we have agreement on the level of > ambition with various unusual VLAN configuration in the bridged LANs. > > By "ambition" I mean whether in a particular case we should: > 1. Make RBridges provide full connectivity for all the nodes in the > bridged LAN > 2. Make RBridges at least detect that there is something odd about the > VLAN configuration and ensure that no permanent loops can be formed. But > it would be ok to orphan some nodes from communicating. > > One can ask that question for different VLAN scenarios. > One interesting case that Donald brought up is when there isn't a single > VLAN tag on which all the RBridges can communicate. > For instance, RB0 and RB1 can only send and receive using VLAN tag 3. > RB2 can only send and receive using VLAN tag 4. > RB3 and RB4 can send and receive using both VLAN tag 3 and 4. > > There are different schemes for making hellos detect the connectivity in > this case. So let's ignore that and instead look at the implications on > the data plane if we want ambition #1. > > Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag > should it use? There isn't a single VLAN tag that it can use whichever > reach all RBridge neighbors. But RB4 can't treat the port as two > logically different ports (one for VLAN tag 3 and a separate one for 4) > either, since RB2 is a neighbor for both VLANs. > Thus if we wanted this case to provide full connectivity it would seem > like the data plane would need to be able to duplicate packets and send > some unicast; a possible strategy would be to multicast with tag 3, and > then unicast a copy to RB2 (with tag 4). That way all the neighboring > RBridges would receive the frame. > > That sounds complex. > > There might be other examples of odd VLAN configuration (such as bridges > which untag and then add some other tag when forwarding the frame) which > are complex to fully support. What level of ambition should we have for > the odd cases? > > Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Fri Sep 14 16:39:28 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 14 Sep 2007 16:39:28 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46EADE53.2020305@sun.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E6B4A12@HQ-EXCH-5.corp.brocade.com> I concur with Radia on all points. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Friday, September 14, 2007 12:18 PM > To: Erik Nordmark > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Ambition with different VLAN configurations > > . I think we should only make sure that in odd configurations > there are > no loops. We should > not worry about partitions caused by nontransitive connectivity. > > . I think we should go to some amount of trouble to ensure > there are not > even temporary loops (not > just "no permanent loops". > > . It would be nice to say "never ever have any loops", but I > don't think > that's possible, given > repeaters coming up, messages getting lost, a bridge or RBridge > exhibiting bizarre behavior > due to some bug, etc. That has nothing to do with TRILL -- any design > might occasionally > wind up with a loop in low probability events, and we should > make sure > that the probability > is very low and minimize the length of time/effect if things go wrong. > > . I prefer a design in which there should be one VLAN tag > (the default > one) that > is not partitioned on a layer 2 cloud, and all RBridge-RBridge > communication on that cloud > (including Hello messages) > should have that VLAN tag on the outside, and if that VLAN is indeed > partitioned, then > all but one RBridge, even if elected to be DRB on some set of VLANs, > will refrain from > forwarding data to/from the link. > > Radia > > Erik Nordmark wrote: > > The list has had discussions on how to do hellos with > VLANs, and the > > discussion makes me wonder whether we have agreement on the > level of > > ambition with various unusual VLAN configuration in the > bridged LANs. > > > > By "ambition" I mean whether in a particular case we should: > > 1. Make RBridges provide full connectivity for all the nodes in the > > bridged LAN > > 2. Make RBridges at least detect that there is something > odd about the > > VLAN configuration and ensure that no permanent loops can > be formed. But > > it would be ok to orphan some nodes from communicating. > > > > One can ask that question for different VLAN scenarios. > > One interesting case that Donald brought up is when there > isn't a single > > VLAN tag on which all the RBridges can communicate. > > For instance, RB0 and RB1 can only send and receive using > VLAN tag 3. > > RB2 can only send and receive using VLAN tag 4. > > RB3 and RB4 can send and receive using both VLAN tag 3 and 4. > > > > There are different schemes for making hellos detect the > connectivity in > > this case. So let's ignore that and instead look at the > implications on > > the data plane if we want ambition #1. > > > > Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag > > should it use? There isn't a single VLAN tag that it can > use whichever > > reach all RBridge neighbors. But RB4 can't treat the port as two > > logically different ports (one for VLAN tag 3 and a > separate one for 4) > > either, since RB2 is a neighbor for both VLANs. > > Thus if we wanted this case to provide full connectivity it > would seem > > like the data plane would need to be able to duplicate > packets and send > > some unicast; a possible strategy would be to multicast > with tag 3, and > > then unicast a copy to RB2 (with tag 4). That way all the > neighboring > > RBridges would receive the frame. > > > > That sounds complex. > > > > There might be other examples of odd VLAN configuration > (such as bridges > > which untag and then add some other tag when forwarding the > frame) which > > are complex to fully support. What level of ambition should > we have for > > the odd cases? > > > > 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 sgai at nuovasystems.com Sat Sep 15 07:50:07 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sat, 15 Sep 2007 07:50:07 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46EADE53.2020305@sun.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> In the spirit of making progress, I am OK with this with the addition that: 1) we don't generate BPDUs trying to become the root of the Spanning Tree. 2) we don't care about temporary loops generated by repeaters (repeaters don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops. 3) Frame duplication is also a big deal, clearly unacceptable in steady state, need to be analyzed carefully in transient: better to drop than to duplicate. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Friday, September 14, 2007 12:18 PM > To: Erik Nordmark > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Ambition with different VLAN configurations > > . I think we should only make sure that in odd configurations there are > no loops. We should > not worry about partitions caused by nontransitive connectivity. > > . I think we should go to some amount of trouble to ensure there are not > even temporary loops (not > just "no permanent loops". > > . It would be nice to say "never ever have any loops", but I don't think > that's possible, given > repeaters coming up, messages getting lost, a bridge or RBridge > exhibiting bizarre behavior > due to some bug, etc. That has nothing to do with TRILL -- any design > might occasionally > wind up with a loop in low probability events, and we should make sure > that the probability > is very low and minimize the length of time/effect if things go wrong. > > . I prefer a design in which there should be one VLAN tag (the default > one) that > is not partitioned on a layer 2 cloud, and all RBridge-RBridge > communication on that cloud > (including Hello messages) > should have that VLAN tag on the outside, and if that VLAN is indeed > partitioned, then > all but one RBridge, even if elected to be DRB on some set of VLANs, > will refrain from > forwarding data to/from the link. > > Radia > > Erik Nordmark wrote: > > The list has had discussions on how to do hellos with VLANs, and the > > discussion makes me wonder whether we have agreement on the level of > > ambition with various unusual VLAN configuration in the bridged LANs. > > > > By "ambition" I mean whether in a particular case we should: > > 1. Make RBridges provide full connectivity for all the nodes in the > > bridged LAN > > 2. Make RBridges at least detect that there is something odd about the > > VLAN configuration and ensure that no permanent loops can be formed. But > > it would be ok to orphan some nodes from communicating. > > > > One can ask that question for different VLAN scenarios. > > One interesting case that Donald brought up is when there isn't a single > > VLAN tag on which all the RBridges can communicate. > > For instance, RB0 and RB1 can only send and receive using VLAN tag 3. > > RB2 can only send and receive using VLAN tag 4. > > RB3 and RB4 can send and receive using both VLAN tag 3 and 4. > > > > There are different schemes for making hellos detect the connectivity in > > this case. So let's ignore that and instead look at the implications on > > the data plane if we want ambition #1. > > > > Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag > > should it use? There isn't a single VLAN tag that it can use whichever > > reach all RBridge neighbors. But RB4 can't treat the port as two > > logically different ports (one for VLAN tag 3 and a separate one for 4) > > either, since RB2 is a neighbor for both VLANs. > > Thus if we wanted this case to provide full connectivity it would seem > > like the data plane would need to be able to duplicate packets and send > > some unicast; a possible strategy would be to multicast with tag 3, and > > then unicast a copy to RB2 (with tag 4). That way all the neighboring > > RBridges would receive the frame. > > > > That sounds complex. > > > > There might be other examples of odd VLAN configuration (such as bridges > > which untag and then add some other tag when forwarding the frame) which > > are complex to fully support. What level of ambition should we have for > > the odd cases? > > > > 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 ddutt at cisco.com Sat Sep 15 17:24:01 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Sat, 15 Sep 2007 17:24:01 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <46EC77A1.3070904@cisco.com> I agree to Radia's points with the addition of Silvano's points, Dinesh Silvano Gai wrote: > In the spirit of making progress, I am OK with this with the addition > that: > > 1) we don't generate BPDUs trying to become the root of the Spanning > Tree. > > 2) we don't care about temporary loops generated by repeaters (repeaters > don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops. > > 3) Frame duplication is also a big deal, clearly unacceptable in steady > state, need to be analyzed carefully in transient: better to drop than > to duplicate. > > -- Silvano > > > >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] >> > On > >> Behalf Of Radia Perlman >> Sent: Friday, September 14, 2007 12:18 PM >> To: Erik Nordmark >> Cc: Developing a hybrid router/bridge. >> Subject: Re: [rbridge] Ambition with different VLAN configurations >> >> . I think we should only make sure that in odd configurations there >> > are > >> no loops. We should >> not worry about partitions caused by nontransitive connectivity. >> >> . I think we should go to some amount of trouble to ensure there are >> > not > >> even temporary loops (not >> just "no permanent loops". >> >> . It would be nice to say "never ever have any loops", but I don't >> > think > >> that's possible, given >> repeaters coming up, messages getting lost, a bridge or RBridge >> exhibiting bizarre behavior >> due to some bug, etc. That has nothing to do with TRILL -- any design >> might occasionally >> wind up with a loop in low probability events, and we should make sure >> that the probability >> is very low and minimize the length of time/effect if things go wrong. >> >> . I prefer a design in which there should be one VLAN tag (the default >> one) that >> is not partitioned on a layer 2 cloud, and all RBridge-RBridge >> communication on that cloud >> (including Hello messages) >> should have that VLAN tag on the outside, and if that VLAN is indeed >> partitioned, then >> all but one RBridge, even if elected to be DRB on some set of VLANs, >> will refrain from >> forwarding data to/from the link. >> >> Radia >> >> Erik Nordmark wrote: >> >>> The list has had discussions on how to do hellos with VLANs, and the >>> discussion makes me wonder whether we have agreement on the level of >>> ambition with various unusual VLAN configuration in the bridged >>> > LANs. > >>> By "ambition" I mean whether in a particular case we should: >>> 1. Make RBridges provide full connectivity for all the nodes in the >>> bridged LAN >>> 2. Make RBridges at least detect that there is something odd about >>> > the > >>> VLAN configuration and ensure that no permanent loops can be formed. >>> > But > >>> it would be ok to orphan some nodes from communicating. >>> >>> One can ask that question for different VLAN scenarios. >>> One interesting case that Donald brought up is when there isn't a >>> > single > >>> VLAN tag on which all the RBridges can communicate. >>> For instance, RB0 and RB1 can only send and receive using VLAN tag >>> > 3. > >>> RB2 can only send and receive using VLAN tag 4. >>> RB3 and RB4 can send and receive using both VLAN tag 3 and 4. >>> >>> There are different schemes for making hellos detect the >>> > connectivity in > >>> this case. So let's ignore that and instead look at the implications >>> > on > >>> the data plane if we want ambition #1. >>> >>> Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag >>> should it use? There isn't a single VLAN tag that it can use >>> > whichever > >>> reach all RBridge neighbors. But RB4 can't treat the port as two >>> logically different ports (one for VLAN tag 3 and a separate one for >>> > 4) > >>> either, since RB2 is a neighbor for both VLANs. >>> Thus if we wanted this case to provide full connectivity it would >>> > seem > >>> like the data plane would need to be able to duplicate packets and >>> > send > >>> some unicast; a possible strategy would be to multicast with tag 3, >>> > and > >>> then unicast a copy to RB2 (with tag 4). That way all the >>> > neighboring > >>> RBridges would receive the frame. >>> >>> That sounds complex. >>> >>> There might be other examples of odd VLAN configuration (such as >>> > bridges > >>> which untag and then add some other tag when forwarding the frame) >>> > which > >>> are complex to fully support. What level of ambition should we have >>> > for > >>> the odd cases? >>> >>> 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 >> > > _______________________________________________ > 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 Donald.Eastlake at motorola.com Sun Sep 16 22:36:58 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 17 Sep 2007 01:36:58 -0400 Subject: [rbridge] Consensus Check: V-field reversion In-Reply-To: <46E00624.3060302@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3A@de01exm64.ds.mot.com> <46E00624.3060302@isi.edu> Message-ID: <3870C46029D1F945B1472F170D2D9790030B9103@de01exm64.ds.mot.com> Right. (I'm generally using the somewhat less formal wording from the minutes in these consensus checks.) Thanks, Donald -----Original Message----- From: Joe Touch [mailto:touch at ISI.EDU] Sent: Thursday, September 06, 2007 9:53 AM To: Eastlake III Donald-LDE008 Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: V-field reversion Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Chicago meeting for a change from protocol draft -05: > > Eliminate different V field values and revert to two version bits > and two reserved bits with the previous provisions that this draft > specifies version zero, frames with an unknown version are > discarded, reserved bits MUST be zero and are ignored on receipt. Minor nit to avoid ambiguity: ...MUST be _set to_ zero... > If no particular controversy arises over this in the next two 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 -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI From Donald.Eastlake at motorola.com Sun Sep 16 22:36:55 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 17 Sep 2007 01:36:55 -0400 Subject: [rbridge] Consensus Check: MAC learning timers In-Reply-To: <46E1DEFC.9090502@isi.edu> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> <18145.10990.755022.598448@gargle.gargle.HOWL> <46E15D01.50702@isi.edu> <18145.37191.943519.790828@gargle.gargle.HOWL> <46E1DEFC.9090502@isi.edu> Message-ID: <3870C46029D1F945B1472F170D2D9790030B9100@de01exm64.ds.mot.com> It's just a recommendation in the IEEE 802.1Q-2005 Standard as quoted below. Donald >From IEEE 802.1Q-2005, Section 8.8.3, "Dynamic Filtering Entries", page 56: The ageing out of Dynamic Filtering Entries ensures that end stations that have been moved to a different part of the network will not be permanently prevented from receiving frames. It also takes account of changes in the active topology of the network that can cause end stations to appear to move from the point of view of the bridge; i.e., the path to those end stations subsequently lies through a different Bridge Port. The Ageing Time may be set by management (Clause 12). A range of applicable values and a recommended default is specified in Table 8-3; this is suggested to remove the need for explicit configuration in most cases. If the value of Ageing Time can be set by management, the Bridge shall have the capability to use values in the range specified, with a granularity of 1 s. Table 8-3-Ageing time parameter value Parameter Recommended Default Value Range Ageing Time 300.0 s. 10.0 - 1,000,000.0s NOTE 4-The granularity is specified in order to establish a common basis for the granularity expressed in the management operations defined in Clause 12, not to constrain the granularity of the actual timer supported by a conformant implementation. If the implementation supports a granularity other than 1 s, then it is possible that the value read back by management following a Set operation will not match the actual value expressed in the Set. -----Original Message----- From: Joe Touch [mailto:touch at ISI.EDU] Sent: Friday, September 07, 2007 7:30 PM To: James Carlson Cc: Eastlake III Donald-LDE008; Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: MAC learning timers James Carlson wrote: > Joe Touch writes: >> James Carlson wrote: >>> Instead, our role is to design TRILL, and specify what's _required_ to >>> make that work. Is there an issue here that, if someone had a good >>> reason to use some other set of defaults for these parameters, doing >>> so would break TRILL? >> I'm concerned about breaking the non-TRILL devices by TRILL behavior. If >> our caches have timeouts different from theirs, then the overall system >> won't be as plug-and-play -- or, more specifically, more 'replug-and-play'. >> >> That's why we're recommending IEEE values and defaults; that didn't come >> out of the blue. > > Yes, and that's precisely the reason to "recommend" those defaults -- > as in BCP 14 "SHOULD." I never did suggest that they came out of the > blue or that anyone ought to ignore them. > > However, as a matter of operating TRILL, they don't appear (to me at > least) to be key issues that will cause TRILL failure. That means > they're not a "MUST." That's fine. Let's hear what others think. I just want to make sure we're picking the right one and understanding what we're picking; I really didn't have an a-priori decision. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI From Donald.Eastlake at motorola.com Sun Sep 16 22:36:56 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 17 Sep 2007 01:36:56 -0400 Subject: [rbridge] RSTP BRIDGE not receiving BPDUs In-Reply-To: References: <3870C46029D1F945B1472F170D2D979002F658A1@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D9790030B9101@de01exm64.ds.mot.com> I believe that if any of STP, RSTP, or MSTP is enabled on a port, then BPDUs will be sent periodically regardless of whether any BPDUs are being received. Donald ________________________________ From: Amit Gupta [mailto:Amit.Gupta at calix.com] Sent: Thursday, August 23, 2007 11:28 PM To: Eastlake III Donald-LDE008 Cc: rbridge at postel.org Subject: RE: [rbridge] RSTP BRIDGE not receiving BPDUs The scenario here is that the2 bridges are connected in a ring topology with eaps providing the ring protection while RSTP is providing the uplink/downlink protection. The reason the other port is not receiving the BPDU is because the EAPS is blocking one of the links to avoid loops in the ring.Thus even though the each bridge has 2 paths 2 reach the other but at any given time will only be able to receive BPDU from the path that is not blocked by EAPS. so thats why I was wondering what state/role would be the port that is not receiving the BPDU. Will it keep sending the Hello BPDU even though it is not receiving any ? ________________________________ From: Eastlake III Donald-LDE008 [mailto:Donald.Eastlake at motorola.com] Sent: Thu 8/23/2007 6:28 PM To: Amit Gupta Cc: rbridge at postel.org Subject: RE: [rbridge] RSTP BRIDGE not receiving BPDUs Well, I'm sure there are people on this list who could help you but this is really not the 802.1 mailing list, which would seem more appropriate. It is a generally characteristic of STP protocols that the loss of frames leads to ports becoming enabled. So, while I am not an RSTP expert, I would guess that in the normal case the port not receiving BPDUs would end up in Forwarding state and would believe itself to be root unless their is a better root visible out some other port... But I could be wrong and maybe I am misunderstanding you.... I am assuming you mean "2 bridges are interconnected and of the 2 ports only 1 port on *one* bridge is receiving BPDU's" but in your statement in the message below, you say "each" rather than "one" which seems inconsistent. On wonders what is blocking the BPDUs and why the one hop physical link between the bridges is letting BPDUs through in only on direction and not the other... Donald ________________________________ From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Amit Gupta Sent: Thursday, August 23, 2007 8:21 PM To: rbridge at postel.org Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs It is a very basic question. What would be the state and role of a port if you stop receiving the RSTP BPDU's on that bridge port. If 2 bridges are interconnected and of the 2 ports only 1 port on each bridge is receiving BPDU's , will that cause any issues ? Thanks, -A -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20070917/a34043da/attachment.html From Radia.Perlman at sun.com Mon Sep 17 20:23:53 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 17 Sep 2007 20:23:53 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46EC77A1.3070904@cisco.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> <46EC77A1.3070904@cisco.com> Message-ID: <46EF44C9.5030009@sun.com> So, just to summarize what I think the proposed solution is, plus a couple of questions interspersed, marked with ??? a) on each layer 2 cloud, all RBrdge-RBridge communication (including IS-IS Hellos and encapsulated data packet forwarding) will be sent with one VLAN tag. ???question: Which VLAN tag? untagged? VLAN 1? Something else? And is that the *only* VLAN tag, or is it a default, and RBridges could be configured to send on a different VLAN tag? (I'd prefer picking one and not have it be configurable)??? b) it will be a MUST to listen to spanning tree messages and include the root bridge ID in the pseudonode LSP. Also, c) if R1 notices a pseudonode with a root bridge that is the same as a link that R1 thinks R1 is designated on, R1 does not forward data to/from that link if R1's 6-byte IS-IS ID is less than the ID of the DRB for that pseudonode d) if R1 is DRB on a link, R1 will not decapsulate anything onto the link from ingress R2 unless R1 has received an LSP from R2 and all pseudonodes that R2 claims to be attached to, and that R2 claims to be DRB for e) when R1 first comes up, it waits some amount of time on a link before deciding that it is DRB (several Hello intervals), and after becoming DRB, it still does not forward data off the link until it has synchronized LSP databases with its neighbors. "Synchronizing" means that it receives a CSNP from the neighbor, and winds up with LSPs at least as up-to-date as those reported in that CSNP. (Note: I think it would be a good idea to have a flag in the Hello message saying "I'd like to receive a CSNP from you" in case the neighbor sent one and it got lost -- on a LAN, the DRB should be sending them periodically, but if we have pt-to-pt links at least in current IS-IS, CSNPs are not sent periodically, though we could say RBridges should send them periodically on pt-to-pt links.) So...is this pretty much everyone's understanding of how it should work? Radia Dinesh G Dutt wrote: > I agree to Radia's points with the addition of Silvano's points, > > Dinesh > Silvano Gai wrote: >> In the spirit of making progress, I am OK with this with the addition >> that: >> >> 1) we don't generate BPDUs trying to become the root of the Spanning >> Tree. >> >> 2) we don't care about temporary loops generated by repeaters (repeaters >> don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops. >> >> 3) Frame duplication is also a big deal, clearly unacceptable in steady >> state, need to be analyzed carefully in transient: better to drop than >> to duplicate. >> >> -- Silvano >> >> >> >>> -----Original Message----- >>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] >>> >> On >> >>> Behalf Of Radia Perlman >>> Sent: Friday, September 14, 2007 12:18 PM >>> To: Erik Nordmark >>> Cc: Developing a hybrid router/bridge. >>> Subject: Re: [rbridge] Ambition with different VLAN configurations >>> >>> . I think we should only make sure that in odd configurations there >>> >> are >> >>> no loops. We should >>> not worry about partitions caused by nontransitive connectivity. >>> >>> . I think we should go to some amount of trouble to ensure there are >>> >> not >> >>> even temporary loops (not >>> just "no permanent loops". >>> >>> . It would be nice to say "never ever have any loops", but I don't >>> >> think >> >>> that's possible, given >>> repeaters coming up, messages getting lost, a bridge or RBridge >>> exhibiting bizarre behavior >>> due to some bug, etc. That has nothing to do with TRILL -- any design >>> might occasionally >>> wind up with a loop in low probability events, and we should make sure >>> that the probability >>> is very low and minimize the length of time/effect if things go wrong. >>> >>> . I prefer a design in which there should be one VLAN tag (the default >>> one) that >>> is not partitioned on a layer 2 cloud, and all RBridge-RBridge >>> communication on that cloud >>> (including Hello messages) >>> should have that VLAN tag on the outside, and if that VLAN is indeed >>> partitioned, then >>> all but one RBridge, even if elected to be DRB on some set of VLANs, >>> will refrain from >>> forwarding data to/from the link. >>> >>> Radia >>> >>> Erik Nordmark wrote: >>> >>>> The list has had discussions on how to do hellos with VLANs, and the >>>> discussion makes me wonder whether we have agreement on the level of >>>> ambition with various unusual VLAN configuration in the bridged >>>> >> LANs. >> >>>> By "ambition" I mean whether in a particular case we should: >>>> 1. Make RBridges provide full connectivity for all the nodes in the >>>> bridged LAN >>>> 2. Make RBridges at least detect that there is something odd about >>>> >> the >> >>>> VLAN configuration and ensure that no permanent loops can be formed. >>>> >> But >> >>>> it would be ok to orphan some nodes from communicating. >>>> >>>> One can ask that question for different VLAN scenarios. >>>> One interesting case that Donald brought up is when there isn't a >>>> >> single >> >>>> VLAN tag on which all the RBridges can communicate. >>>> For instance, RB0 and RB1 can only send and receive using VLAN tag >>>> >> 3. >> >>>> RB2 can only send and receive using VLAN tag 4. >>>> RB3 and RB4 can send and receive using both VLAN tag 3 and 4. >>>> >>>> There are different schemes for making hellos detect the >>>> >> connectivity in >> >>>> this case. So let's ignore that and instead look at the implications >>>> >> on >> >>>> the data plane if we want ambition #1. >>>> >>>> Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag >>>> should it use? There isn't a single VLAN tag that it can use >>>> >> whichever >> >>>> reach all RBridge neighbors. But RB4 can't treat the port as two >>>> logically different ports (one for VLAN tag 3 and a separate one for >>>> >> 4) >> >>>> either, since RB2 is a neighbor for both VLANs. >>>> Thus if we wanted this case to provide full connectivity it would >>>> >> seem >> >>>> like the data plane would need to be able to duplicate packets and >>>> >> send >> >>>> some unicast; a possible strategy would be to multicast with tag 3, >>>> >> and >> >>>> then unicast a copy to RB2 (with tag 4). That way all the >>>> >> neighboring >> >>>> RBridges would receive the frame. >>>> >>>> That sounds complex. >>>> >>>> There might be other examples of odd VLAN configuration (such as >>>> >> bridges >> >>>> which untag and then add some other tag when forwarding the frame) >>>> >> which >> >>>> are complex to fully support. What level of ambition should we have >>>> >> for >> >>>> the odd cases? >>>> >>>> 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 >>> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > From sgai at nuovasystems.com Tue Sep 18 07:18:48 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Tue, 18 Sep 2007 07:18:48 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46EF44C9.5030009@sun.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20210E0AC@nuova-ex1.hq.nuovaimpresa.com> Radia, I need to sudy your proposal in details, but the answer to your question is easy: " By default is VLAN 1 and it is configurable". VLAN 1 is the default of IEEE, and you cannot forbid with a standard to config it. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Monday, September 17, 2007 8:24 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Ambition with different VLAN configurations > > So, just to summarize what I think the proposed solution is, plus a > couple of questions > interspersed, marked > with ??? > > a) on each layer 2 cloud, all RBrdge-RBridge communication (including > IS-IS Hellos and encapsulated data packet forwarding) will be sent with > one VLAN tag. > > ???question: Which VLAN tag? untagged? VLAN 1? Something else? And is > that the > *only* VLAN tag, or is it a default, and RBridges could be configured to > send on a different > VLAN tag? (I'd prefer picking one and not have it be configurable)??? > > b) it will be a MUST to listen to spanning tree messages and include the > root bridge ID > in the pseudonode LSP. Also, > > c) if R1 notices a pseudonode with a root bridge that is the same as a > link that R1 thinks > R1 is designated on, R1 does not forward data to/from that link if R1's > 6-byte IS-IS ID > is less than the ID of the DRB for that pseudonode > > d) if R1 is DRB on a link, R1 will not decapsulate anything onto the > link from ingress R2 unless > R1 has received an LSP from R2 and all pseudonodes that R2 claims to be > attached to, > and that R2 claims to be DRB for > > e) when R1 first comes up, it waits some amount of time on a link before > deciding that it is DRB > (several Hello intervals), and after becoming DRB, it still does not > forward data off the link until > it has synchronized LSP databases with its neighbors. "Synchronizing" > means that it receives > a CSNP from the neighbor, and winds up with LSPs at least as up-to-date > as those reported > in that CSNP. (Note: I think it would be a good idea to have a flag in > the Hello message saying "I'd > like to receive a CSNP from you" in case the neighbor sent one and it > got lost -- on a LAN, > the DRB should be sending them periodically, but if we have pt-to-pt > links at least in current IS-IS, > CSNPs are not sent periodically, though we could say RBridges should > send them periodically > on pt-to-pt links.) > > So...is this pretty much everyone's understanding of how it should work? > > Radia > > > > > Dinesh G Dutt wrote: > > I agree to Radia's points with the addition of Silvano's points, > > > > Dinesh > > Silvano Gai wrote: > >> In the spirit of making progress, I am OK with this with the addition > >> that: > >> > >> 1) we don't generate BPDUs trying to become the root of the Spanning > >> Tree. > >> > >> 2) we don't care about temporary loops generated by repeaters > (repeaters > >> don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops. > >> > >> 3) Frame duplication is also a big deal, clearly unacceptable in steady > >> state, need to be analyzed carefully in transient: better to drop than > >> to duplicate. > >> > >> -- Silvano > >> > >> > >> > >>> -----Original Message----- > >>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > >>> > >> On > >> > >>> Behalf Of Radia Perlman > >>> Sent: Friday, September 14, 2007 12:18 PM > >>> To: Erik Nordmark > >>> Cc: Developing a hybrid router/bridge. > >>> Subject: Re: [rbridge] Ambition with different VLAN configurations > >>> > >>> . I think we should only make sure that in odd configurations there > >>> > >> are > >> > >>> no loops. We should > >>> not worry about partitions caused by nontransitive connectivity. > >>> > >>> . I think we should go to some amount of trouble to ensure there are > >>> > >> not > >> > >>> even temporary loops (not > >>> just "no permanent loops". > >>> > >>> . It would be nice to say "never ever have any loops", but I don't > >>> > >> think > >> > >>> that's possible, given > >>> repeaters coming up, messages getting lost, a bridge or RBridge > >>> exhibiting bizarre behavior > >>> due to some bug, etc. That has nothing to do with TRILL -- any design > >>> might occasionally > >>> wind up with a loop in low probability events, and we should make sure > >>> that the probability > >>> is very low and minimize the length of time/effect if things go wrong. > >>> > >>> . I prefer a design in which there should be one VLAN tag (the default > >>> one) that > >>> is not partitioned on a layer 2 cloud, and all RBridge-RBridge > >>> communication on that cloud > >>> (including Hello messages) > >>> should have that VLAN tag on the outside, and if that VLAN is indeed > >>> partitioned, then > >>> all but one RBridge, even if elected to be DRB on some set of VLANs, > >>> will refrain from > >>> forwarding data to/from the link. > >>> > >>> Radia > >>> > >>> Erik Nordmark wrote: > >>> > >>>> The list has had discussions on how to do hellos with VLANs, and the > >>>> discussion makes me wonder whether we have agreement on the level of > >>>> ambition with various unusual VLAN configuration in the bridged > >>>> > >> LANs. > >> > >>>> By "ambition" I mean whether in a particular case we should: > >>>> 1. Make RBridges provide full connectivity for all the nodes in the > >>>> bridged LAN > >>>> 2. Make RBridges at least detect that there is something odd about > >>>> > >> the > >> > >>>> VLAN configuration and ensure that no permanent loops can be formed. > >>>> > >> But > >> > >>>> it would be ok to orphan some nodes from communicating. > >>>> > >>>> One can ask that question for different VLAN scenarios. > >>>> One interesting case that Donald brought up is when there isn't a > >>>> > >> single > >> > >>>> VLAN tag on which all the RBridges can communicate. > >>>> For instance, RB0 and RB1 can only send and receive using VLAN tag > >>>> > >> 3. > >> > >>>> RB2 can only send and receive using VLAN tag 4. > >>>> RB3 and RB4 can send and receive using both VLAN tag 3 and 4. > >>>> > >>>> There are different schemes for making hellos detect the > >>>> > >> connectivity in > >> > >>>> this case. So let's ignore that and instead look at the implications > >>>> > >> on > >> > >>>> the data plane if we want ambition #1. > >>>> > >>>> Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag > >>>> should it use? There isn't a single VLAN tag that it can use > >>>> > >> whichever > >> > >>>> reach all RBridge neighbors. But RB4 can't treat the port as two > >>>> logically different ports (one for VLAN tag 3 and a separate one for > >>>> > >> 4) > >> > >>>> either, since RB2 is a neighbor for both VLANs. > >>>> Thus if we wanted this case to provide full connectivity it would > >>>> > >> seem > >> > >>>> like the data plane would need to be able to duplicate packets and > >>>> > >> send > >> > >>>> some unicast; a possible strategy would be to multicast with tag 3, > >>>> > >> and > >> > >>>> then unicast a copy to RB2 (with tag 4). That way all the > >>>> > >> neighboring > >> > >>>> RBridges would receive the frame. > >>>> > >>>> That sounds complex. > >>>> > >>>> There might be other examples of odd VLAN configuration (such as > >>>> > >> bridges > >> > >>>> which untag and then add some other tag when forwarding the frame) > >>>> > >> which > >> > >>>> are complex to fully support. What level of ambition should we have > >>>> > >> for > >> > >>>> the odd cases? > >>>> > >>>> 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 > >>> > >> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge at postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > >> > >> > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From ddutt at cisco.com Tue Sep 18 08:04:18 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 18 Sep 2007 08:04:18 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46EF44C9.5030009@sun.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> <46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com> Message-ID: <46EFE8F2.70204@cisco.com> Hi Radia, Some comments. Radia Perlman wrote: > So, just to summarize what I think the proposed solution is, plus a > couple of questions > interspersed, marked > with ??? > > a) on each layer 2 cloud, all RBrdge-RBridge communication (including > IS-IS Hellos and encapsulated data packet forwarding) will be sent with > one VLAN tag. > > ???question: Which VLAN tag? untagged? VLAN 1? Something else? And is > that the > *only* VLAN tag, or is it a default, and RBridges could be configured to > send on a different > VLAN tag? (I'd prefer picking one and not have it be configurable)??? > > VLAN 1 and I prefer it to be the only one, but maybe configurable. The frame must be tagged, not untagged as it leads to all kinds of corner cases. > b) it will be a MUST to listen to spanning tree messages and include the > root bridge ID > in the pseudonode LSP. Also, > > Will it need to support both (three if you include the currently dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP (Cisco's PVST is IEEE's STP run per VLAN). > c) if R1 notices a pseudonode with a root bridge that is the same as a > link that R1 thinks > R1 is designated on, R1 does not forward data to/from that link if R1's > 6-byte IS-IS ID > is less than the ID of the DRB for that pseudonode > Need to think through this one. > d) if R1 is DRB on a link, R1 will not decapsulate anything onto the > link from ingress R2 unless > R1 has received an LSP from R2 and all pseudonodes that R2 claims to be > attached to, > and that R2 claims to be DRB for > Need to think through this one. > e) when R1 first comes up, it waits some amount of time on a link before > deciding that it is DRB > (several Hello intervals), and after becoming DRB, it still does not > forward data off the link until > it has synchronized LSP databases with its neighbors. "Synchronizing" > This could cause a significant delay in bringing an RBridge up and how things work when a network is powered down and comes up. I'm not sure about this part yet. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Radia.Perlman at sun.com Tue Sep 18 18:12:15 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 18 Sep 2007 18:12:15 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46EFE8F2.70204@cisco.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> <46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com> <46EFE8F2.70204@cisco.com> Message-ID: <46F0776F.9050603@sun.com> Dinesh G Dutt wrote: > > Will it need to support both (three if you include the currently > dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP > (Cisco's PVST is IEEE's STP run per VLAN). How different are these? How much trouble is it to listen to all the variants? I assumed they were all interoperable. What happens if there is a bridged network with bridges that support different of these variants? From what I remember of "original STP" and "RSTP", listening to them should be identical. RSTP uses the same message formats, and is the same protocol other than adding loop prevention messages. So I'd assume if you are listening, it wouldn't matter if it was STP vs RSTP. MSTP, if I understand it correctly, involves noticing that different bridges are root for different VLANs. However, maybe we can ignore that, and only listen to messages for the spanning tree for VLAN 1. I'm assuming we can do that -- someone should correct me if I'm wrong. The other plausible alternative is to listen to all the spanning trees, and if you're doing load splitting of DRBs (one for VLANs 1-50, and the other for VLANs 51-79, say), then in the pseudonode representing VLANs 1-50, you'd list the root bridges for the spanning tree associated with each of the VLANs 1 through 50. As for your description of "PVST" -- again, the implication might be that if you have a pseudonode representing all the VLANs, you'd have to list, in that pseudonode, a different bridge ID since (if I understand what PVST is from your one phrase above), there might be a different root bridge ID for each of those. But...I *thought* that the spanning tree is guaranteed not to be partitioned, so listing just the root of the spanning tree corresponding to VLAN 1 should be all you need in order to detect that there's an RBridge on the same link that you're not hearing Hellos from, right? ***************** And as for allowing configuration to be some other VLAN other than 1 -- that makes things complicated, because what do you do if some of the RBridges on a cloud are configured differently from others? Radia From anoop at brocade.com Wed Sep 19 18:40:29 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 19 Sep 2007 18:40:29 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46F0776F.9050603@sun.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com><46EFE8F2.70204@cisco.com> <46F0776F.9050603@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E6B5275@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, September 18, 2007 6:12 PM > To: Dinesh G Dutt > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Ambition with different VLAN configurations > > Dinesh G Dutt wrote: > > > > Will it need to support both (three if you include the currently > > dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP > > (Cisco's PVST is IEEE's STP run per VLAN). > How different are these? How much trouble is it to listen to > all the variants? I assumed they were all interoperable. What > happens if there is a bridged network with bridges that > support different of these variants? > > From what I remember of "original STP" and "RSTP", listening > to them should be identical. > RSTP uses the same message formats, and is the same protocol > other than adding loop prevention messages. So I'd assume if > you are listening, it wouldn't matter if it was STP vs RSTP. This is correct. > MSTP, if I understand it correctly, involves noticing that > different bridges are root for different VLANs. However, > maybe we can ignore that, and only listen to messages for the > spanning tree for VLAN 1. I'm assuming we can do that -- > someone should correct me if I'm wrong. The other plausible > alternative is to listen to all the spanning trees, and if > you're doing load splitting of DRBs (one for VLANs 1-50, and > the other for VLANs 51-79, say), then in the pseudonode > representing VLANs 1-50, you'd list the root bridges for the > spanning tree associated with each of the VLANs 1 through 50. And so is this. Basically, from the perspective of what we are trying to accomplish with MSTP, we could just listen to the messages for the CIST (common and internal spanning tree) which is the spanning tree that goes across all spanning tree regions and forwards traffic to VLANs that is not mapped to any of the other instances. > As for your description of "PVST" -- again, the implication > might be that if you have a pseudonode representing all the > VLANs, you'd have to list, in that pseudonode, a different > bridge ID since (if I understand what PVST is from your one > phrase above), there might be a different root bridge ID for > each of those. > > But...I *thought* that the spanning tree is guaranteed not to > be partitioned, so listing just the root of the spanning tree > corresponding to VLAN 1 should be all you need in order to > detect that there's an RBridge on the same link that you're > not hearing Hellos from, right? > > ***************** > And as for allowing configuration to be some other VLAN other > than 1 -- that makes things complicated, because what do you > do if some of the RBridges on a cloud are configured > differently from others? The only problem with using VLAN 1 only is that it may require an operator to renumber their VLAN configuration if VLAN 1 is being used for something other than what we would like it to be used for. One way to handle misconfiguration would be to say that, if this condition is detected, then we use the lower numbered VLAN and the one with the higher numbered VLAN logs a misconfiguration error and goes silent. A misconfiguration is detected if the root/VLAN combination reported for the same pseudonode by 2 RBridges is different. Anoop From anoop at brocade.com Wed Sep 19 18:59:24 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 19 Sep 2007 18:59:24 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46EF44C9.5030009@sun.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E6B527E@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Monday, September 17, 2007 8:24 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Ambition with different VLAN configurations > > So, just to summarize what I think the proposed solution is, > plus a couple of questions interspersed, marked with ??? > > a) on each layer 2 cloud, all RBrdge-RBridge communication > (including IS-IS Hellos and encapsulated data packet > forwarding) will be sent with one VLAN tag. > > ???question: Which VLAN tag? untagged? VLAN 1? Something > else? And is that the > *only* VLAN tag, or is it a default, and RBridges could be > configured to send on a different VLAN tag? (I'd prefer > picking one and not have it be configurable)??? > > b) it will be a MUST to listen to spanning tree messages and > include the root bridge ID in the pseudonode LSP. Also, And the root bridge ID in the case where MSTP is enabled is that of the CIST. It must also include in the list of VLANs reachable on that pseudonode and what is configured as the "RBridge control VLAN". The list of VLANs reachable is later used for doing DRB election. > c) if R1 notices a pseudonode with a root bridge that is the > same as a link that R1 thinks > R1 is designated on, R1 does not forward data to/from that > link if R1's 6-byte IS-IS ID is less than the ID of the DRB > for that pseudonode > > d) if R1 is DRB on a link, R1 will not decapsulate anything > onto the link from ingress R2 unless > R1 has received an LSP from R2 and all pseudonodes that R2 > claims to be attached to, and that R2 claims to be DRB for > > e) when R1 first comes up, it waits some amount of time on a > link before deciding that it is DRB (several Hello > intervals), and after becoming DRB, it still does not forward > data off the link until it has synchronized LSP databases > with its neighbors. "Synchronizing" > means that it receives > a CSNP from the neighbor, and winds up with LSPs at least as > up-to-date as those reported in that CSNP. (Note: I think it > would be a good idea to have a flag in the Hello message > saying "I'd like to receive a CSNP from you" in case the > neighbor sent one and it got lost -- on a LAN, the DRB should > be sending them periodically, but if we have pt-to-pt links > at least in current IS-IS, CSNPs are not sent periodically, > though we could say RBridges should send them periodically on > pt-to-pt links.) > > So...is this pretty much everyone's understanding of how it > should work? From ddutt at cisco.com Wed Sep 19 22:51:35 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 19 Sep 2007 22:51:35 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46F0776F.9050603@sun.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> <46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com> <46EFE8F2.70204@cisco.com> <46F0776F.9050603@sun.com> Message-ID: <46F20A67.3030906@cisco.com> Hi Radia, Radia Perlman wrote: > Dinesh G Dutt wrote: >> >> Will it need to support both (three if you include the currently >> dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP >> (Cisco's PVST is IEEE's STP run per VLAN). > How different are these? How much trouble is it to listen to all the > variants? I assumed they > were all interoperable. What happens if there is a bridged network > with bridges that > support different of these variants? Don't know how different things are. MSTP/RSTP can interoperate with older STP, I believe. > > From what I remember of "original STP" and "RSTP", listening to them > should be identical. > RSTP uses the same message formats, and is the same protocol other > than adding loop prevention > messages. So I'd assume if you are listening, it wouldn't matter if it > was STP vs RSTP. The PDUs look different between MSTP and regular STP. > > MSTP, if I understand it correctly, involves noticing that different > bridges are root for different > VLANs. However, maybe we can ignore that, and only listen to messages > for the spanning > tree for VLAN 1. I'm assuming we can do that -- someone should correct > me if I'm wrong. The > other plausible alternative is to listen to all the spanning trees, > and if you're doing load splitting > of DRBs (one for VLANs 1-50, and the other for VLANs 51-79, say), then > in the pseudonode > representing VLANs 1-50, you'd list the root bridges for the spanning > tree associated with > each of the VLANs 1 through 50. > > > As for your description of "PVST" -- again, the implication might be > that if you have a pseudonode > representing all the VLANs, you'd have to list, in that pseudonode, a > different bridge ID since > (if I understand what PVST is from your one phrase above), there might > be a different root > bridge ID for each of those. > > But...I *thought* that the spanning tree is guaranteed not to be > partitioned, so listing just the > root of the spanning tree corresponding to VLAN 1 should be all you > need in order to detect > that there's an RBridge on the same link that you're not hearing > Hellos from, right? I think you maybe right here. > > ***************** > And as for allowing configuration to be some other VLAN other than 1 > -- that makes things > complicated, because what do you do if some of the RBridges on a cloud > are configured differently > from others? I agree. I prefer to not provide a configurable option on this, but I can foresee people complain, Dinesh -- 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 Sep 19 23:31:38 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 19 Sep 2007 23:31:38 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E6B5275@HQ-EXCH-5.corp.brocade.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com><46EFE8F2.70204@cisco.com> <46F0776F.9050603@sun.com> <4C94DE2070B172459E4F1EE14BD2364E6B5275@HQ-EXCH-5.corp.brocade.com> Message-ID: <46F213CA.2030406@cisco.com> Anoop, Anoop Ghanwani wrote: > And so is this. Basically, from the perspective of what > we are trying to accomplish with MSTP, we could just listen > to the messages for the CIST (common and internal spanning > tree) which is the spanning tree that goes across all > spanning tree regions and forwards traffic to VLANs that is > not mapped to any of the other instances. > What you're saying then is that the DRB must be the root of CIST, not of VLAN 1. Am I right ? Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From sgai at nuovasystems.com Thu Sep 20 07:58:09 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 20 Sep 2007 07:58:09 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46F20A67.3030906@cisco.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com><46EFE8F2.70204@cisco.com> <46F0776F.9050603@sun.com> <46F20A67.3030906@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202160E10@nuova-ex1.hq.nuovaimpresa.com> ... snip ... > > > > ***************** > > And as for allowing configuration to be some other VLAN other than 1 > > -- that makes things > > complicated, because what do you do if some of the RBridges on a cloud > > are configured differently > > from others? > I agree. I prefer to not provide a configurable option on this, but I > can foresee people complain, > Let's be realistic, if a customer has access to an existing VLAN 7 on a backbone and he wants to connect two RBridges to it, we are going to disallow it? Disallowing reasonable configuration by standard is never an option. -- Silvano From sgai at nuovasystems.com Thu Sep 20 07:59:42 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 20 Sep 2007 07:59:42 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46F213CA.2030406@cisco.com> References: <46E82549.7030102@sun.com><46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com><46EF44C9.5030009@sun.com><46EFE8F2.70204@cisco.com><46F0776F.9050603@sun.com><4C94DE2070B172459E4F1EE14BD2364E6B5275@HQ-EXCH-5.corp.brocade.com> <46F213CA.2030406@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202160E12@nuova-ex1.hq.nuovaimpresa.com> > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Wednesday, September 19, 2007 11:32 PM > To: Anoop Ghanwani > Cc: Developing a hybrid router/bridge.; Radia Perlman > Subject: Re: [rbridge] Ambition with different VLAN configurations > > Anoop, > > Anoop Ghanwani wrote: > > And so is this. Basically, from the perspective of what > > we are trying to accomplish with MSTP, we could just listen > > to the messages for the CIST (common and internal spanning > > tree) which is the spanning tree that goes across all > > spanning tree regions and forwards traffic to VLANs that is > > not mapped to any of the other instances. > > > What you're saying then is that the DRB must be the root of CIST, not of > VLAN 1. Am I right ? I disagree that the DRB must be the root of the CIST. This imposes severe restrictions on interoperability. -- Silvano From ddutt at cisco.com Thu Sep 20 08:09:17 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 20 Sep 2007 08:09:17 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202160E10@nuova-ex1.hq.nuovaimpresa.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com><46EFE8F2.70204@cisco.com> <46F0776F.9050603@sun.com> <46F20A67.3030906@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA202160E10@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <46F28D1D.9020601@cisco.com> The statement pertained to which VLAN the DRB election is held on, not the VLAN on which the traffic is transported. I think this was for the case of doing DRB on a single VLAN, Dinesh Silvano Gai wrote: > ... snip ... > > > >>> ***************** >>> And as for allowing configuration to be some other VLAN other than 1 >>> -- that makes things >>> complicated, because what do you do if some of the RBridges on a >>> > cloud > >>> are configured differently >>> from others? >>> >> I agree. I prefer to not provide a configurable option on this, but I >> can foresee people complain, >> >> > > > Let's be realistic, if a customer has access to an existing VLAN 7 on a > backbone and he wants to connect two RBridges to it, we are going to > disallow it? > > Disallowing reasonable configuration by standard is never an option. > > -- Silvano > > -- 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 Thu Sep 20 09:05:18 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Thu, 20 Sep 2007 09:05:18 -0700 Subject: [rbridge] Ambition with different VLAN configurations In-Reply-To: <46F213CA.2030406@cisco.com> References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com><34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com><46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com><46EFE8F2.70204@cisco.com> <46F0776F.9050603@sun.com> <4C94DE2070B172459E4F1EE14BD2364E6B5275@HQ-EXCH-5.corp.brocade.com> <46F213CA.2030406@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E6B532E@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Wednesday, September 19, 2007 11:32 PM > To: Anoop Ghanwani > Cc: Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Ambition with different VLAN configurations > > Anoop, > > Anoop Ghanwani wrote: > > And so is this. Basically, from the perspective of what we > are trying > > to accomplish with MSTP, we could just listen to the > messages for the > > CIST (common and internal spanning > > tree) which is the spanning tree that goes across all spanning tree > > regions and forwards traffic to VLANs that is not mapped to > any of the > > other instances. > > > What you're saying then is that the DRB must be the root of > CIST, not of VLAN 1. Am I right ? Hi Dinesh, That's not what I'm trying to say at all. All I'm saying is that all RBridges (designated or not) report who the root is for the CIST. This is basically to figure out whether they are connected to the same LAN. Anoop From anoop at brocade.com Thu Sep 20 10:47:55 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Thu, 20 Sep 2007 10:47:55 -0700 Subject: [rbridge] inner tag always an s-tag? Message-ID: <4C94DE2070B172459E4F1EE14BD2364E6B5391@HQ-EXCH-5.corp.brocade.com> This is a long overdue followup on whether or not it is OK to have the inner tag always be an s-tag. The issue was brought up by Donald at the TRILL meeting in Chicago: http://www3.ietf.org/proceedings/07jul/slides/trill-3/sld7.htm The argument in favor of doing this was that it allows us to get a DE (discard eligible) bit. I was opposed to this. The reason is that we should preserve whatever inner tag was received from the attached LAN. RBridges could be attached to LANs that actually use s-tags, or they could be attached to LANs that use c-tags. We need to preserve what was originally received. Also, if in future, IEEE comes up with some other way to use the CFI bit and if we need to use that within the RBridge network, we would have to find a new place to carry that bit. Finally, even with the c-tag format, we do have the capability to signal drop eligibility. It is just encoded within the PCP (what used to be called the priority and is now the priority code point) so it reduces the number of priorities, but if it's OK for bridges, it's probably going to be OK for RBridges as well. Anoop