From Radia.Perlman at sun.com Wed Jun 21 21:47:30 2006 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 21 Jun 2006 21:47:30 -0700 Subject: [rbridge] RBridges and IS-IS packets, revisited In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF932@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0DDAF932@whq-msgusr-02.pit.comms.marconi.com> Message-ID: <449A20E2.50104@sun.com> I think we never decided on this. Encoding is not a very interesting thing, but we should decide. I have a few questions. a) Any reason to optimize sending of layer 3 IS-IS packets? RBridges can know which links contain IS-IS routers because IS-IS routers send IS Hellos. If RBridges told each other "I am attached to an IS-IS router", then IS-IS Link state packets and hellos (This is layer 3 I'm talking about) only need to get sent to links that contain IS-IS routers. I'm assuming we don't care about optimizing this, though perhaps we should on the last hop (don't decapsulate layer 3 IS-IS traffic onto links for which you are Designated RBridge and know there are no IS-IS routers there) b) Do IS-IS Routers actually use VLANs? Do people partition their bridged topology into VLANs and run different instances of layer 3 IS-IS (or OSPF) for each VLAN? Not sure why people would do this, but oh well. I think it isn't hard to avoid breaking this functionality, so it should probably be designed to allow it. But I'm just curious if anyone would use it, and perhaps even get a clue as to why. c) I assume layer 2 multicast addresses are basically free, and if I understood Dino's email from a few weeks ago, he'd prefer using a different MAC multicast address for RBridge IS-IS packets than ordinary encapsulated data packets, so that RBridges will know they should process the packets. d) I'll send a proposal for the encoding of the 3 types of IS-IS packets (encapsulated layer 3 IS-IS packets, core instance RBridge IS-IS, per-VLAN RBridge IS-IS) in a subsequent email Radia From Radia.Perlman at sun.com Wed Jun 21 23:23:33 2006 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 21 Jun 2006 23:23:33 -0700 Subject: [rbridge] Proposed encoding for IS-IS packets In-Reply-To: <449A20E2.50104@sun.com> References: <313680C9A886D511A06000204840E1CF0DDAF932@whq-msgusr-02.pit.comms.marconi.com> <449A20E2.50104@sun.com> Message-ID: <449A3765.3020109@sun.com> 1) layer 3 IS-IS LSPs It would be fine to treat these like any other layer 2 multicasts. The only reason to do anything different would be if we want to optimize distribution of these to go only to links on which there are IS-IS routers. RBridges could recognize such packets because the inner header would indicate the IS-IS DSAP. So I'm assuming these will be encapsulated just like any layer 2 multicast. 2) core IS-IS instance for RBridges (these are the IS-IS packets by which RBridges inform each other about RBridge-to-RBridge connectivity. Outer header: Destination=new (to be assigned) layer 2 multicast address, indicating "core RBridge IS-IS packet" Source=transmitting RBridge protocol type=encapsulated RBridge packet Shim header: TTL and ingress RBridge (in PWE format as defined in the unfortunately expired internet draft by Bryant, et al) No inner layer 2 header: IS-IS packet immediately follows 3) per-VLAN IS-IS instance for RBridges (these are the IS-IS packets by which RBridges in a particular VLAN inform other RBridges attached to the same VLAN of where the endnodes, multicast receivers, and multicast routers associated with that VLAN are) Outer header: Destination=second new (to be assigned) layer 2 multicast address, indicating "per-VLAN RBridge IS-IS packet" Source=transmitting RBridge protocol type=encapsulated RBridge packet Shim header: TTL and ingress RBridge No inner layer 2 header:, just VLAN tag, followed by IS-IS packet From riw at cisco.com Thu Jun 22 06:35:00 2006 From: riw at cisco.com (Russ White) Date: Thu, 22 Jun 2006 09:35:00 -0400 Subject: [rbridge] RBridges and IS-IS packets, revisited In-Reply-To: <449A20E2.50104@sun.com> References: <313680C9A886D511A06000204840E1CF0DDAF932@whq-msgusr-02.pit.comms.marconi.com> <449A20E2.50104@sun.com> Message-ID: <449A9C84.8060208@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > a) Any reason to optimize sending of layer 3 IS-IS packets? RBridges > can know which links contain IS-IS routers because IS-IS routers send > IS Hellos. If RBridges told each other "I am attached to an IS-IS > router", then IS-IS Link state packets and hellos (This is layer 3 > I'm talking about) only need to get sent to links that contain IS-IS > routers. I wouldn't try do this.... The first question that springs to mind is, if you're going to optimize for IS-IS, why not for all the other routing protocols that use link local multicast, as well, such as OSPF, EIGRP, and RIPv2? The problem I see is that it would interfere with the three way handshake used in many RP's, and possibly with OSPF DR election. I would just leave it.... > b) Do IS-IS Routers actually use VLANs? Do people partition their > bridged topology into VLANs and run different instances of layer 3 > IS-IS (or OSPF) for each VLAN? Not sure why people would do this, but > oh well. I think it isn't hard to avoid breaking this functionality, > so it should probably be designed to allow it. But I'm just curious > if anyone would use it, and perhaps even get a clue as to why. Yes, they do.... For normal L3 IS-IS packets, though, we should just encap in the correct vlan shim header, and send it out, just like any other broadcast (link local multicast) packet. > c) I assume layer 2 multicast addresses are basically free, and if I > understood Dino's email from a few weeks ago, he'd prefer using a > different MAC multicast address for RBridge IS-IS packets than > ordinary encapsulated data packets, so that RBridges will know they > should process the packets. This is what I'd prefer, as well. :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmpyEER27sUhU9OQRAisGAKC2XXUYXCLqmORiO4HmQaoluFB2PACg24X9 JcCMdSpTFnfkRVk57WOLz/g= =ExYB -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Jun 22 08:17:33 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 22 Jun 2006 08:17:33 -0700 Subject: [rbridge] RBridges and IS-IS packets, revisited In-Reply-To: <449A20E2.50104@sun.com> References: <313680C9A886D511A06000204840E1CF0DDAF932@whq-msgusr-02.pit.comms.marconi.com> <449A20E2.50104@sun.com> Message-ID: <449AB48D.4050801@isi.edu> Radia Perlman wrote: > I think we never decided on this. Encoding is not a very interesting > thing, but > we should decide. I have a few questions. > > a) Any reason to optimize sending of layer 3 IS-IS packets? There might be, but that's just an optimization, like other L3 optimizations (e.g., IP multicast). ... > c) I assume layer 2 multicast addresses are basically free, and if I > understood Dino's > email from a few weeks ago, he'd prefer using a different MAC multicast > address for > RBridge IS-IS packets than ordinary encapsulated data packets, so that > RBridges will > know they should process the packets. I was assuming we would get a separate L2 address for rbridge control info, and that they'd be multicast as with other L2 control. Are you asking whether we need multiple such addresses, or just one? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20060622/6c12c2fc/signature.bin From riw at cisco.com Thu Jun 22 08:52:32 2006 From: riw at cisco.com (Russ White) Date: Thu, 22 Jun 2006 11:52:32 -0400 Subject: [rbridge] Comments on draft-ietf-trill-prob-00.txt Message-ID: <449ABCC0.60600@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just some comments below that might help... :-) Russ == The spanning tree is dependent on the way a set of bridges are interconnected, i.e., the link layer topology. Small changes in this topology can cause large changes in the spanning tree. Changes in the spanning tree can take time to propagate and converge. [QUESTION: is there a good visual example of this, one that we can walk through in the description?] I think the absolute worst case is when one of the branches connected to the root bridge fails, causing a large number of ports to block and unblock before the network would reconverge. Perhaps a ring would show enough to explain, however (?): A----B----C----D----E | | +-----F-----G-------+ If A is the root bridge, then we can assume the paths A->B->C->D and A->F->G->E are the two open paths, while the D->E link is blocked in both directions (just using hop count). If the A->B link fails, then E must unblock its port to D for traffic to flow again, but it may require recomputation of the entire tree through BPDUs, I think (?). == [QUESTION: is port autolearning in this category too? i.e., are TRILL solutions trying to hide bridge reattachment from other nodes (or is that even necessary?)] I don't think we are trying to address this in TRILL (?). == The spanning tree protocol is inherently global to an entire layer 2 subnet; there is no current way to contain, partition, or otherwise factor the protocol into a number of smaller, more stable subsets that interact as groups. Contrast this with Internet routing, which includes both intradomain and interdomain variants, split to provide exactly that containment and scalability within a domain while allowing domains to interact freely independent of what happens within a domain. [QUESTION: anybody have a convenient reference for a proof? Are new spanning tree protocols not considering AS-like boundaries? (just checking)] I'm not certain you need any reference on this, I would guess it's pretty self evident (?). == 3.5. Multiple Attachments [QUESTION: I'm not sure what this refers to; is it the same NIC attached at different points to a TRIL solution? If so, why should this be possible where it seems ignored in bridges?] I'm not certain what this section would cover, as well. It might mention that while, in STP, a single NIC with multiple attachments to a single spanning tree will always only get traffic over one of the two attachment points (I don't see how it would work otherwise??), with TRILL, it's actually possibly to load share between the attachment points. I don't know if this is worth calling out, or worrying about, though, in this specific document, since this is a problem statement, and this has never been noted as a problem in STP. == -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmry/ER27sUhU9OQRAo+QAKDpNZ9EKzknNW9IrcNZ+EZP0p+G8QCgiOAt 787vOw0eIg6Yy4ZzA7TdC1A= =QuVe -----END PGP SIGNATURE----- From Eric.Gray at marconi.com Thu Jun 22 10:40:04 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 22 Jun 2006 13:40:04 -0400 Subject: [rbridge] Use of the term "campus" Message-ID: <0BF76B30C100624BA997C9CED19D81250A5C36@uspitsmsgusr08.win.marconi.com> Radia, I am having some trouble resolving the use of "campus" in the currently available protocol specification with the way that it has been used in other documents, mailing list discussion, etc. In the protocol specification, "campus" is defined as synonymous with the usual definition of "LAN". Is this use central to the rest of the document? If so, can we use the word "LAN" instead? -- Eric From touch at ISI.EDU Thu Jun 22 10:58:35 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 22 Jun 2006 10:58:35 -0700 Subject: [rbridge] Use of the term "campus" In-Reply-To: <0BF76B30C100624BA997C9CED19D81250A5C36@uspitsmsgusr08.win.marconi.com> References: <0BF76B30C100624BA997C9CED19D81250A5C36@uspitsmsgusr08.win.marconi.com> Message-ID: <449ADA4B.2030208@isi.edu> Gray, Eric wrote: > Radia, > > I am having some trouble resolving the use of "campus" > in the currently available protocol specification with the > way that it has been used in other documents, mailing list > discussion, etc. > > In the protocol specification, "campus" is defined as > synonymous with the usual definition of "LAN". Is this use > central to the rest of the document? If so, can we use the > word "LAN" instead? I thought: - segment what 802 refers to when describing an ethernet LAN or a single VLAN on a VLAN-capable network - campus the set of rbridges on a segment that cooperate together I don't know if 802 has a term that describes the set of all VLANs that share an infrastructure. I would avoid the term LAN, as it could mean VLAN or segment, and I don't think that's the intent. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20060622/a4826a96/signature.bin From Eric.Gray at marconi.com Thu Jun 22 11:09:11 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 22 Jun 2006 14:09:11 -0400 Subject: [rbridge] Use of the term "campus" Message-ID: <0BF76B30C100624BA997C9CED19D81250A5C3A@uspitsmsgusr08.win.marconi.com> Joe, Your definition for "campus" is very close to my own understanding, as well. Meanwhile, we have the term "segment" and the term "LAN" that occasionally over-lap. From back in the days when I worked almost exclusively with bridges and hubs (1989-1994), we used the term "segment" to mean "the bit between bridges" since that was what would be isolated if a bridged network became "segmented" (by losing a bridge). Also, most people usually refer to a "LAN" as a broadcast domain. Otherwise the term "VLAN" (as "Virtual LAN") becomes excessively cumbersome to deal with. I admit all of these terms have overlap and ambiguity in the rest of the world, but can we use them consistently in the set of TRILL documents? I'm perfectly happy to accept the definition of "campus" provided in the protocol specification, but then I need a new term for "the set of rbridges that cooperate together." --> -----Original Message----- --> From: Joe Touch [mailto:touch at ISI.EDU] --> Sent: Thursday, June 22, 2006 1:59 PM --> To: Gray, Eric --> Cc: Radia.Perlman at sun.com; rbridge at postel.org --> Subject: Re: [rbridge] Use of the term "campus" --> --> --> --> Gray, Eric wrote: --> > Radia, --> > --> > I am having some trouble resolving the use of "campus" --> > in the currently available protocol specification with the --> > way that it has been used in other documents, mailing list --> > discussion, etc. --> > --> > In the protocol specification, "campus" is defined as --> > synonymous with the usual definition of "LAN". Is this use --> > central to the rest of the document? If so, can we use the --> > word "LAN" instead? --> --> I thought: --> --> - segment --> what 802 refers to when describing an ethernet LAN --> or a single VLAN on a VLAN-capable network --> --> - campus --> the set of rbridges on a segment that cooperate --> together --> --> I don't know if 802 has a term that describes the set of --> all VLANs that --> share an infrastructure. --> --> I would avoid the term LAN, as it could mean VLAN or segment, and I --> don't think that's the intent. --> --> Joe --> --> From gibanez at it.uc3m.es Thu Jun 22 11:46:49 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Thu, 22 Jun 2006 20:46:49 +0200 Subject: [rbridge] Use of the term "campus" In-Reply-To: <449ADA4B.2030208@isi.edu> References: <0BF76B30C100624BA997C9CED19D81250A5C36@uspitsmsgusr08.win.marconi.com> <449ADA4B.2030208@isi.edu> Message-ID: <449AE599.2080508@it.uc3m.es> Eric, The usual meaning of campus network IMHO, refers to a set of LANs covering several buildings, normally including routers or multilayer switches, switches and end nodes. To use a campus for the set of RBridges on a segment seems a bit confusing. The LAN segment term seems correct. Regards Guillermo Joe Touch wrote: >Gray, Eric wrote: > > >>Radia, >> >> I am having some trouble resolving the use of "campus" >>in the currently available protocol specification with the >>way that it has been used in other documents, mailing list >>discussion, etc. >> >> In the protocol specification, "campus" is defined as >>synonymous with the usual definition of "LAN". Is this use >>central to the rest of the document? If so, can we use the >>word "LAN" instead? >> >> > >I thought: > > - segment > what 802 refers to when describing an ethernet LAN > or a single VLAN on a VLAN-capable network > > - campus > the set of rbridges on a segment that cooperate > together > >I don't know if 802 has a term that describes the set of all VLANs that >share an infrastructure. > >I would avoid the term LAN, as it could mean VLAN or segment, and I >don't think that's the intent. > >Joe > > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > From Radia.Perlman at sun.com Thu Jun 22 11:55:25 2006 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 22 Jun 2006 11:55:25 -0700 Subject: [rbridge] Use of the term "campus" In-Reply-To: <449AE599.2080508@it.uc3m.es> References: <0BF76B30C100624BA997C9CED19D81250A5C36@uspitsmsgusr08.win.marconi.com> <449ADA4B.2030208@isi.edu> <449AE599.2080508@it.uc3m.es> Message-ID: <449AE79D.4010501@sun.com> I agree with Guillermo...that "campus" covers not just the rbridges, but the LAN segments and the attached nodes. But I wouldn't include segments connected via routers. For that, perhaps "corporate network" or "intranet". (I did reply, but I said "reply" rather than "reply all"...I forgot that this mailing list no longer has "reply-to" set to the list). Radia Guillermo Ib??ez wrote: > Eric, > The usual meaning of campus network IMHO, refers to a set of LANs > covering several buildings, normally including routers or multilayer > switches, switches and end nodes. > To use a campus for the set of RBridges on a segment seems a bit > confusing. The LAN segment term seems correct. > Regards > Guillermo > Joe Touch wrote: > >> Gray, Eric wrote: >> >> >>> Radia, >>> >>> I am having some trouble resolving the use of "campus" >>> in the currently available protocol specification with the way that >>> it has been used in other documents, mailing list >>> discussion, etc. >>> >>> In the protocol specification, "campus" is defined as >>> synonymous with the usual definition of "LAN". Is this use >>> central to the rest of the document? If so, can we use the >>> word "LAN" instead? >>> >> >> >> I thought: >> >> - segment >> what 802 refers to when describing an ethernet LAN >> or a single VLAN on a VLAN-capable network >> >> - campus >> the set of rbridges on a segment that cooperate >> together >> >> I don't know if 802 has a term that describes the set of all VLANs that >> share an infrastructure. >> >> I would avoid the term LAN, as it could mean VLAN or segment, and I >> don't think that's the intent. >> >> Joe >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> From Eric.Gray at marconi.com Thu Jun 22 11:56:34 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 22 Jun 2006 14:56:34 -0400 Subject: [rbridge] Use of the term "campus" Message-ID: <0BF76B30C100624BA997C9CED19D81250A5C44@uspitsmsgusr08.win.marconi.com> Yes, that is the usual meaning of "campus" as a quasi-generic term. One could argue that this dates back to using the term campus as equivalent to site. Because we're talking exclusively of device-relative topology - as opposed to location-relative topology (geography?) - we can agree to discount the use of the term "campus" as it might apply to buildings and sites. The problem is that a lot of "stuff" is defined around the way that we've used the term "campus" in this (TRILL) context. If we define it a different way, or decide to use a different term, that's fine with me. I just have to change a lot of text around other terms such as - CTT - Campus Transit Table CFT - Campus Forwarding Table CFT-IRT - Campus Forwarding Table - Ingress RBridge Tree - as well as a lot of textual descriptions and places where we just use the derived acronyms (assuming the "new" term doesn't start with a "C"). Actually, I'm disappointed that we're having this discussion again - and doubly so because I'm the one that had to bring it up. --> -----Original Message----- --> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] --> Sent: Thursday, June 22, 2006 2:47 PM --> To: Joe Touch --> Cc: Gray, Eric; rbridge at postel.org; Radia.Perlman at sun.com --> Subject: Re: [rbridge] Use of the term "campus" --> --> Eric, --> The usual meaning of campus network IMHO, refers to a --> set of LANs --> covering several buildings, normally including routers or --> multilayer --> switches, switches and end nodes. --> To use a campus for the set of RBridges on a segment seems a bit --> confusing. The LAN segment term seems correct. --> Regards --> Guillermo --> Joe Touch wrote: --> --> >Gray, Eric wrote: --> > --> > --> >>Radia, --> >> --> >> I am having some trouble resolving the use of "campus" --> >>in the currently available protocol specification with the --> >>way that it has been used in other documents, mailing list --> >>discussion, etc. --> >> --> >> In the protocol specification, "campus" is defined as --> >>synonymous with the usual definition of "LAN". Is this use --> >>central to the rest of the document? If so, can we use the --> >>word "LAN" instead? --> >> --> >> --> > --> >I thought: --> > --> > - segment --> > what 802 refers to when describing an ethernet LAN --> > or a single VLAN on a VLAN-capable network --> > --> > - campus --> > the set of rbridges on a segment that cooperate --> > together --> > --> >I don't know if 802 has a term that describes the set of --> all VLANs that --> >share an infrastructure. --> > --> >I would avoid the term LAN, as it could mean VLAN or segment, and I --> >don't think that's the intent. --> > --> >Joe --> > --> > --> > --> >----------------------------------------------------------- --> ------------- --> > --> >_______________________________________________ --> >rbridge mailing list --> >rbridge at postel.org --> >http://mailman.postel.org/mailman/listinfo/rbridge --> > --> > --> From gibanez at it.uc3m.es Thu Jun 22 12:05:22 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Thu, 22 Jun 2006 21:05:22 +0200 Subject: [rbridge] Use of the term "campus" In-Reply-To: <449AE79D.4010501@sun.com> References: <0BF76B30C100624BA997C9CED19D81250A5C36@uspitsmsgusr08.win.marconi.com> <449ADA4B.2030208@isi.edu> <449AE599.2080508@it.uc3m.es> <449AE79D.4010501@sun.com> Message-ID: <449AE9F2.2040809@it.uc3m.es> I meant routers in the sense tthat current campus networks include routers/multilayer switches. I agree with Radia that in the Rbridges context the routers are at the edge of campus. The term corporate network is used sometimes for a network covering different distant sites. Intranet might coincide in coverage, although in meaning usually is used as oposed to extranet or Internet. Guillermo Radia Perlman wrote: > I agree with Guillermo...that "campus" covers not just the rbridges, > but the LAN segments and the attached nodes. > But I wouldn't include segments connected via routers. For that, > perhaps "corporate network" or "intranet". > > (I did reply, but I said "reply" rather than "reply all"...I forgot > that this mailing list no longer has "reply-to" > set to the list). > > Radia > > Guillermo Ib??ez wrote: > >> Eric, >> The usual meaning of campus network IMHO, refers to a set of LANs >> covering several buildings, normally including routers or multilayer >> switches, switches and end nodes. >> To use a campus for the set of RBridges on a segment seems a bit >> confusing. The LAN segment term seems correct. >> Regards >> Guillermo >> Joe Touch wrote: >> >>> Gray, Eric wrote: >>> >>> >>>> Radia, >>>> >>>> I am having some trouble resolving the use of "campus" >>>> in the currently available protocol specification with the way that >>>> it has been used in other documents, mailing list >>>> discussion, etc. >>>> >>>> In the protocol specification, "campus" is defined as >>>> synonymous with the usual definition of "LAN". Is this use >>>> central to the rest of the document? If so, can we use the >>>> word "LAN" instead? >>>> >>> >>> >>> >>> I thought: >>> >>> - segment >>> what 802 refers to when describing an ethernet LAN >>> or a single VLAN on a VLAN-capable network >>> >>> - campus >>> the set of rbridges on a segment that cooperate >>> together >>> >>> I don't know if 802 has a term that describes the set of all VLANs that >>> share an infrastructure. >>> >>> I would avoid the term LAN, as it could mean VLAN or segment, and I >>> don't think that's the intent. >>> >>> Joe >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> > From Eric.Gray at marconi.com Thu Jun 22 12:06:35 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 22 Jun 2006 15:06:35 -0400 Subject: [rbridge] Use of the term "campus" Message-ID: <0BF76B30C100624BA997C9CED19D81250A5C45@uspitsmsgusr08.win.marconi.com> Radia, Like I said, that's fine with me. Unfortunately, I inherited the term "campus" - as it is used in CFT and CTT - from the previously-existing document. CFT is the abstract definition of a table we use to determine how to forward an RBridge encapsulated frame from one RBridge to another. CTT is the abstract definition of the table we use to determine what encapsulation to use for any specific un-encasulated frame to be forwarded via one or more RBridges. These terms - not invented by me - are dependent on the understanding that the campus consists of RBridges and "tunnels" between them (corresponding to paths for forwarding RBridge encasulated frames). What do you suggest should be used instead? -- Eric --> -----Original Message----- --> From: Radia Perlman [mailto:Radia.Perlman at sun.com] --> Sent: Thursday, June 22, 2006 2:55 PM --> To: Guillermo Ib??ez --> Cc: Joe Touch; Gray, Eric; rbridge at postel.org --> Subject: Re: [rbridge] Use of the term "campus" --> --> I agree with Guillermo...that "campus" covers not just the --> rbridges, but --> the LAN segments and the attached nodes. --> But I wouldn't include segments connected via routers. For --> that, perhaps --> "corporate network" or "intranet". --> --> (I did reply, but I said "reply" rather than "reply --> all"...I forgot that --> this mailing list no longer has "reply-to" --> set to the list). --> --> Radia --> --> Guillermo Ib??ez wrote: --> --> > Eric, --> > The usual meaning of campus network IMHO, refers to a --> set of LANs --> > covering several buildings, normally including routers or --> multilayer --> > switches, switches and end nodes. --> > To use a campus for the set of RBridges on a segment seems a bit --> > confusing. The LAN segment term seems correct. --> > Regards --> > Guillermo --> > Joe Touch wrote: --> > --> >> Gray, Eric wrote: --> >> --> >> --> >>> Radia, --> >>> --> >>> I am having some trouble resolving the use of "campus" --> >>> in the currently available protocol specification with --> the way that --> >>> it has been used in other documents, mailing list --> >>> discussion, etc. --> >>> --> >>> In the protocol specification, "campus" is defined as --> >>> synonymous with the usual definition of "LAN". Is this use --> >>> central to the rest of the document? If so, can we use the --> >>> word "LAN" instead? --> >>> --> >> --> >> --> >> I thought: --> >> --> >> - segment --> >> what 802 refers to when describing an ethernet LAN --> >> or a single VLAN on a VLAN-capable network --> >> --> >> - campus --> >> the set of rbridges on a segment that cooperate --> >> together --> >> --> >> I don't know if 802 has a term that describes the set of --> all VLANs that --> >> share an infrastructure. --> >> --> >> I would avoid the term LAN, as it could mean VLAN or --> segment, and I --> >> don't think that's the intent. --> >> --> >> Joe --> >> --> >> --> >> --> >> --> ------------------------------------------------------------ --> ------------ --> >> --> >> _______________________________________________ --> >> rbridge mailing list --> >> rbridge at postel.org --> >> http://mailman.postel.org/mailman/listinfo/rbridge --> >> --> >> --> From Eric.Gray at marconi.com Thu Jun 22 12:27:17 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 22 Jun 2006 15:27:17 -0400 Subject: [rbridge] Use of the term "campus" Message-ID: <0BF76B30C100624BA997C9CED19D81250A5C46@uspitsmsgusr08.win.marconi.com> Guillermo, It's not particularly useful to try to resolve all of these terminology inconsistencies in any general sense. For example, the argument that "campus" as used to mean "site" is more consistent with "bridge connected network" than "LAN" is, makes some stark assumptions about how someone sets up their network within a site and/or across multiple sites. I've certainly seen networks where a single site has many different IP subnets (frequently separated by routers), and I've even seen a few networks where a single LAN spans several sites. (What is a L2VPN for, otherwise?) What I'm trying to do is to get us using some terms consistently - without necessarily making up some non-sense syllables as we go along. I believe "LAN" as I described it is consistent in comparison with "VLAN" - meaning that a LAN is a single broadcast domain in the normal sense but this may change as a result of virtualization. But if nobody else agrees with this, then somebody needs to suggest an alternative term to replace campus in the sense that we've been discussing it on this list for about a year now. If not, then I guess I'll have to make something up. One thing we keep losing sight of here is that this solution is supposed to support VLANs, which is not at all the same as "not support anything else." -- Eric --> -----Original Message----- --> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] --> Sent: Thursday, June 22, 2006 3:05 PM --> To: Radia Perlman --> Cc: Joe Touch; Gray, Eric; rbridge at postel.org --> Subject: Re: [rbridge] Use of the term "campus" --> --> I meant routers in the sense tthat current campus networks include --> routers/multilayer switches. I agree with Radia that in the --> Rbridges --> context the routers are at the edge of campus. --> The term corporate network is used sometimes for a network covering --> different distant sites. Intranet might coincide in --> coverage, although --> in meaning usually is used as oposed to extranet or Internet. --> Guillermo --> --> Radia Perlman wrote: --> --> > I agree with Guillermo...that "campus" covers not just --> the rbridges, --> > but the LAN segments and the attached nodes. --> > But I wouldn't include segments connected via routers. For that, --> > perhaps "corporate network" or "intranet". --> > --> > (I did reply, but I said "reply" rather than "reply --> all"...I forgot --> > that this mailing list no longer has "reply-to" --> > set to the list). --> > --> > Radia --> > --> > Guillermo Ib??ez wrote: --> > --> >> Eric, --> >> The usual meaning of campus network IMHO, refers to a --> set of LANs --> >> covering several buildings, normally including routers --> or multilayer --> >> switches, switches and end nodes. --> >> To use a campus for the set of RBridges on a segment seems a bit --> >> confusing. The LAN segment term seems correct. --> >> Regards --> >> Guillermo --> >> Joe Touch wrote: --> >> --> >>> Gray, Eric wrote: --> >>> --> >>> --> >>>> Radia, --> >>>> --> >>>> I am having some trouble resolving the use of "campus" --> >>>> in the currently available protocol specification with --> the way that --> >>>> it has been used in other documents, mailing list --> >>>> discussion, etc. --> >>>> --> >>>> In the protocol specification, "campus" is defined as --> >>>> synonymous with the usual definition of "LAN". Is this use --> >>>> central to the rest of the document? If so, can we use the --> >>>> word "LAN" instead? --> >>>> --> >>> --> >>> --> >>> --> >>> I thought: --> >>> --> >>> - segment --> >>> what 802 refers to when describing an ethernet LAN --> >>> or a single VLAN on a VLAN-capable network --> >>> --> >>> - campus --> >>> the set of rbridges on a segment that cooperate --> >>> together --> >>> --> >>> I don't know if 802 has a term that describes the set --> of all VLANs that --> >>> share an infrastructure. --> >>> --> >>> I would avoid the term LAN, as it could mean VLAN or --> segment, and I --> >>> don't think that's the intent. --> >>> --> >>> Joe --> >>> --> >>> --> >>> --> >>> --> ------------------------------------------------------------ --> ------------ --> >>> --> >>> --> >>> _______________________________________________ --> >>> rbridge mailing list --> >>> rbridge at postel.org --> >>> http://mailman.postel.org/mailman/listinfo/rbridge --> >>> --> >>> --> > --> From gibanez at it.uc3m.es Thu Jun 22 13:36:11 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Thu, 22 Jun 2006 22:36:11 +0200 Subject: [rbridge] Use of the term "campus" In-Reply-To: <0BF76B30C100624BA997C9CED19D81250A5C46@uspitsmsgusr08.win.marconi.com> References: <0BF76B30C100624BA997C9CED19D81250A5C46@uspitsmsgusr08.win.marconi.com> Message-ID: <449AFF3B.3080708@it.uc3m.es> Eric, The term LAN seems the closest. If new terms are allowed, what about campuswide LAN (CLAN) ? Regards Guillermo Gray, Eric wrote: >Guillermo, > > It's not particularly useful to try to resolve all of >these terminology inconsistencies in any general sense. > > For example, the argument that "campus" as used to mean >"site" is more consistent with "bridge connected network" than >"LAN" is, makes some stark assumptions about how someone sets >up their network within a site and/or across multiple sites. > > I've certainly seen networks where a single site has >many different IP subnets (frequently separated by routers), >and I've even seen a few networks where a single LAN spans >several sites. (What is a L2VPN for, otherwise?) > > What I'm trying to do is to get us using some terms >consistently - without necessarily making up some non-sense >syllables as we go along. > > I believe "LAN" as I described it is consistent in >comparison with "VLAN" - meaning that a LAN is a single >broadcast domain in the normal sense but this may change >as a result of virtualization. > > But if nobody else agrees with this, then somebody >needs to suggest an alternative term to replace campus in >the sense that we've been discussing it on this list for >about a year now. If not, then I guess I'll have to make >something up. > > One thing we keep losing sight of here is that this >solution is supposed to support VLANs, which is not at all >the same as "not support anything else." > >-- >Eric > >--> -----Original Message----- >--> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] >--> Sent: Thursday, June 22, 2006 3:05 PM >--> To: Radia Perlman >--> Cc: Joe Touch; Gray, Eric; rbridge at postel.org >--> Subject: Re: [rbridge] Use of the term "campus" >--> >--> I meant routers in the sense tthat current campus networks include >--> routers/multilayer switches. I agree with Radia that in the >--> Rbridges >--> context the routers are at the edge of campus. >--> The term corporate network is used sometimes for a network covering >--> different distant sites. Intranet might coincide in >--> coverage, although >--> in meaning usually is used as oposed to extranet or Internet. >--> Guillermo >--> >--> Radia Perlman wrote: >--> >--> > I agree with Guillermo...that "campus" covers not just >--> the rbridges, >--> > but the LAN segments and the attached nodes. >--> > But I wouldn't include segments connected via routers. For that, >--> > perhaps "corporate network" or "intranet". >--> > >--> > (I did reply, but I said "reply" rather than "reply >--> all"...I forgot >--> > that this mailing list no longer has "reply-to" >--> > set to the list). >--> > >--> > Radia >--> > >--> > Guillermo Ib??ez wrote: >--> > >--> >> Eric, >--> >> The usual meaning of campus network IMHO, refers to a >--> set of LANs >--> >> covering several buildings, normally including routers >--> or multilayer >--> >> switches, switches and end nodes. >--> >> To use a campus for the set of RBridges on a segment seems a bit >--> >> confusing. The LAN segment term seems correct. >--> >> Regards >--> >> Guillermo >--> >> Joe Touch wrote: >--> >> >--> >>> Gray, Eric wrote: >--> >>> >--> >>> >--> >>>> Radia, >--> >>>> >--> >>>> I am having some trouble resolving the use of "campus" >--> >>>> in the currently available protocol specification with >--> the way that >--> >>>> it has been used in other documents, mailing list >--> >>>> discussion, etc. >--> >>>> >--> >>>> In the protocol specification, "campus" is defined as >--> >>>> synonymous with the usual definition of "LAN". Is this use >--> >>>> central to the rest of the document? If so, can we use the >--> >>>> word "LAN" instead? >--> >>>> >--> >>> >--> >>> >--> >>> >--> >>> I thought: >--> >>> >--> >>> - segment >--> >>> what 802 refers to when describing an ethernet LAN >--> >>> or a single VLAN on a VLAN-capable network >--> >>> >--> >>> - campus >--> >>> the set of rbridges on a segment that cooperate >--> >>> together >--> >>> >--> >>> I don't know if 802 has a term that describes the set >--> of all VLANs that >--> >>> share an infrastructure. >--> >>> >--> >>> I would avoid the term LAN, as it could mean VLAN or >--> segment, and I >--> >>> don't think that's the intent. >--> >>> >--> >>> Joe >--> >>> >--> >>> >--> >>> >--> >>> >--> ------------------------------------------------------------ >--> ------------ >--> >>> >--> >>> >--> >>> _______________________________________________ >--> >>> rbridge mailing list >--> >>> rbridge at postel.org >--> >>> http://mailman.postel.org/mailman/listinfo/rbridge >--> >>> >--> >>> >--> > >--> > > From touch at ISI.EDU Thu Jun 22 13:46:06 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 22 Jun 2006 13:46:06 -0700 Subject: [rbridge] Use of the term "campus" In-Reply-To: <449AFF3B.3080708@it.uc3m.es> References: <0BF76B30C100624BA997C9CED19D81250A5C46@uspitsmsgusr08.win.marconi.com> <449AFF3B.3080708@it.uc3m.es> Message-ID: <449B018E.608@isi.edu> I'd prefer using an existing term for an exisitng idea; so far, we're either talking about an ethernet segment (i.e., a broadcast domain) or a LAN. Joe Guillermo Ib??ez wrote: > Eric, > The term LAN seems the closest. If new terms are allowed, what about > campuswide LAN (CLAN) ? > Regards > Guillermo > > Gray, Eric wrote: > >> Guillermo, >> >> It's not particularly useful to try to resolve all of >> these terminology inconsistencies in any general sense. >> >> For example, the argument that "campus" as used to mean >> "site" is more consistent with "bridge connected network" than >> "LAN" is, makes some stark assumptions about how someone sets >> up their network within a site and/or across multiple sites. >> >> I've certainly seen networks where a single site has >> many different IP subnets (frequently separated by routers), >> and I've even seen a few networks where a single LAN spans >> several sites. (What is a L2VPN for, otherwise?) >> >> What I'm trying to do is to get us using some terms >> consistently - without necessarily making up some non-sense >> syllables as we go along. >> >> I believe "LAN" as I described it is consistent in >> comparison with "VLAN" - meaning that a LAN is a single >> broadcast domain in the normal sense but this may change >> as a result of virtualization. >> >> But if nobody else agrees with this, then somebody >> needs to suggest an alternative term to replace campus in >> the sense that we've been discussing it on this list for >> about a year now. If not, then I guess I'll have to make >> something up. >> >> One thing we keep losing sight of here is that this >> solution is supposed to support VLANs, which is not at all >> the same as "not support anything else." >> >> -- >> Eric >> >> --> -----Original Message----- >> --> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] >> --> Sent: Thursday, June 22, 2006 3:05 PM >> --> To: Radia Perlman >> --> Cc: Joe Touch; Gray, Eric; rbridge at postel.org >> --> Subject: Re: [rbridge] Use of the term "campus" >> --> >> --> I meant routers in the sense tthat current campus networks include >> --> routers/multilayer switches. I agree with Radia that in the >> --> Rbridges >> --> context the routers are at the edge of campus. >> --> The term corporate network is used sometimes for a network covering >> --> different distant sites. Intranet might coincide in >> --> coverage, although >> --> in meaning usually is used as oposed to extranet or Internet. >> --> Guillermo >> --> >> --> Radia Perlman wrote: >> --> >> --> > I agree with Guillermo...that "campus" covers not just >> --> the rbridges, >> --> > but the LAN segments and the attached nodes. >> --> > But I wouldn't include segments connected via routers. For that, >> --> > perhaps "corporate network" or "intranet". >> --> > >> --> > (I did reply, but I said "reply" rather than "reply >> --> all"...I forgot >> --> > that this mailing list no longer has "reply-to" >> --> > set to the list). >> --> > >> --> > Radia >> --> > >> --> > Guillermo Ib??ez wrote: >> --> > >> --> >> Eric, >> --> >> The usual meaning of campus network IMHO, refers to a >> --> set of LANs >> --> >> covering several buildings, normally including routers >> --> or multilayer >> --> >> switches, switches and end nodes. >> --> >> To use a campus for the set of RBridges on a segment seems a bit >> --> >> confusing. The LAN segment term seems correct. >> --> >> Regards >> --> >> Guillermo >> --> >> Joe Touch wrote: >> --> >> >> --> >>> Gray, Eric wrote: >> --> >>> >> --> >>> >> --> >>>> Radia, >> --> >>>> >> --> >>>> I am having some trouble resolving the use of "campus" >> --> >>>> in the currently available protocol specification with >> --> the way that >> --> >>>> it has been used in other documents, mailing list >> --> >>>> discussion, etc. >> --> >>>> >> --> >>>> In the protocol specification, "campus" is defined as >> --> >>>> synonymous with the usual definition of "LAN". Is this use >> --> >>>> central to the rest of the document? If so, can we use the >> --> >>>> word "LAN" instead? >> --> >>>> >> --> >>> >> --> >>> >> --> >>> >> --> >>> I thought: >> --> >>> >> --> >>> - segment >> --> >>> what 802 refers to when describing an ethernet LAN >> --> >>> or a single VLAN on a VLAN-capable network >> --> >>> >> --> >>> - campus >> --> >>> the set of rbridges on a segment that cooperate >> --> >>> together >> --> >>> >> --> >>> I don't know if 802 has a term that describes the set >> --> of all VLANs that >> --> >>> share an infrastructure. >> --> >>> >> --> >>> I would avoid the term LAN, as it could mean VLAN or >> --> segment, and I >> --> >>> don't think that's the intent. >> --> >>> >> --> >>> Joe >> --> >>> >> --> >>> >> --> >>> >> --> >>> >> --> ------------------------------------------------------------ >> --> ------------ >> --> >>> >> --> >>> >> --> >>> _______________________________________________ >> --> >>> rbridge mailing list >> --> >>> rbridge at postel.org >> --> >>> http://mailman.postel.org/mailman/listinfo/rbridge >> --> >>> >> --> >>> >> --> > >> --> >> >> > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20060622/7bcfa3c6/signature.bin From riw at cisco.com Thu Jun 22 17:25:57 2006 From: riw at cisco.com (Russ White) Date: Thu, 22 Jun 2006 20:25:57 -0400 Subject: [rbridge] Use of the term "campus" In-Reply-To: <449AFF3B.3080708@it.uc3m.es> References: <0BF76B30C100624BA997C9CED19D81250A5C46@uspitsmsgusr08.win.marconi.com> <449AFF3B.3080708@it.uc3m.es> Message-ID: <449B3515.4020005@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 LAN seems to me to be the best term, or "broadcast domain," but then, that's too long, probably. :-) Russ Guillermo Ib??ez wrote: > Eric, > The term LAN seems the closest. If new terms are allowed, what about > campuswide LAN (CLAN) ? > Regards > Guillermo > > Gray, Eric wrote: > >> Guillermo, >> >> It's not particularly useful to try to resolve all of >> these terminology inconsistencies in any general sense. >> >> For example, the argument that "campus" as used to mean >> "site" is more consistent with "bridge connected network" than >> "LAN" is, makes some stark assumptions about how someone sets >> up their network within a site and/or across multiple sites. >> >> I've certainly seen networks where a single site has >> many different IP subnets (frequently separated by routers), >> and I've even seen a few networks where a single LAN spans >> several sites. (What is a L2VPN for, otherwise?) >> >> What I'm trying to do is to get us using some terms >> consistently - without necessarily making up some non-sense >> syllables as we go along. >> >> I believe "LAN" as I described it is consistent in >> comparison with "VLAN" - meaning that a LAN is a single >> broadcast domain in the normal sense but this may change >> as a result of virtualization. >> >> But if nobody else agrees with this, then somebody >> needs to suggest an alternative term to replace campus in >> the sense that we've been discussing it on this list for >> about a year now. If not, then I guess I'll have to make >> something up. >> >> One thing we keep losing sight of here is that this >> solution is supposed to support VLANs, which is not at all >> the same as "not support anything else." >> >> -- >> Eric >> >> --> -----Original Message----- >> --> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] >> --> Sent: Thursday, June 22, 2006 3:05 PM >> --> To: Radia Perlman >> --> Cc: Joe Touch; Gray, Eric; rbridge at postel.org >> --> Subject: Re: [rbridge] Use of the term "campus" >> --> >> --> I meant routers in the sense tthat current campus networks include >> --> routers/multilayer switches. I agree with Radia that in the >> --> Rbridges >> --> context the routers are at the edge of campus. >> --> The term corporate network is used sometimes for a network covering >> --> different distant sites. Intranet might coincide in >> --> coverage, although >> --> in meaning usually is used as oposed to extranet or Internet. >> --> Guillermo >> --> >> --> Radia Perlman wrote: >> --> >> --> > I agree with Guillermo...that "campus" covers not just >> --> the rbridges, >> --> > but the LAN segments and the attached nodes. >> --> > But I wouldn't include segments connected via routers. For that, >> --> > perhaps "corporate network" or "intranet". >> --> > >> --> > (I did reply, but I said "reply" rather than "reply >> --> all"...I forgot >> --> > that this mailing list no longer has "reply-to" >> --> > set to the list). >> --> > >> --> > Radia >> --> > >> --> > Guillermo Ib??ez wrote: >> --> > >> --> >> Eric, >> --> >> The usual meaning of campus network IMHO, refers to a >> --> set of LANs >> --> >> covering several buildings, normally including routers >> --> or multilayer >> --> >> switches, switches and end nodes. >> --> >> To use a campus for the set of RBridges on a segment seems a bit >> --> >> confusing. The LAN segment term seems correct. >> --> >> Regards >> --> >> Guillermo >> --> >> Joe Touch wrote: >> --> >> >> --> >>> Gray, Eric wrote: >> --> >>> >> --> >>> >> --> >>>> Radia, >> --> >>>> >> --> >>>> I am having some trouble resolving the use of "campus" >> --> >>>> in the currently available protocol specification with >> --> the way that >> --> >>>> it has been used in other documents, mailing list >> --> >>>> discussion, etc. >> --> >>>> >> --> >>>> In the protocol specification, "campus" is defined as >> --> >>>> synonymous with the usual definition of "LAN". Is this use >> --> >>>> central to the rest of the document? If so, can we use the >> --> >>>> word "LAN" instead? >> --> >>>> >> --> >>> >> --> >>> >> --> >>> >> --> >>> I thought: >> --> >>> >> --> >>> - segment >> --> >>> what 802 refers to when describing an ethernet LAN >> --> >>> or a single VLAN on a VLAN-capable network >> --> >>> >> --> >>> - campus >> --> >>> the set of rbridges on a segment that cooperate >> --> >>> together >> --> >>> >> --> >>> I don't know if 802 has a term that describes the set >> --> of all VLANs that >> --> >>> share an infrastructure. >> --> >>> >> --> >>> I would avoid the term LAN, as it could mean VLAN or >> --> segment, and I >> --> >>> don't think that's the intent. >> --> >>> >> --> >>> Joe >> --> >>> >> --> >>> >> --> >>> >> --> >>> >> --> ------------------------------------------------------------ >> --> ------------ >> --> >>> >> --> >>> >> --> >>> _______________________________________________ >> --> >>> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmzUUER27sUhU9OQRAhIEAJ9FHrQLwESdZ5Bzr0xnH3Wa9ebdvgCg0wrH 3bMzOuth2mMnetBPbGRVZkc= =JGzT -----END PGP SIGNATURE----- From Donald.Eastlake at motorola.com Fri Jun 23 11:11:56 2006 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 23 Jun 2006 14:11:56 -0400 Subject: [rbridge] TRILL Montreal agenda posted Message-ID: <3870C46029D1F945B1472F170D2D97900111F260@de01exm64.ds.mot.com> Hi, The tentative agenda for the Montreal TRILL meeting next month has been posted at http://www3.ietf.org/proceedings/06jul/agenda/trill.txt. People should send me presentations so they can also be posted in advance. By the way, if you are not too familiar with the IETF, there is a new draft of a revised version of the "Tao of the IETF" document: http://www.ietf.org/internet-drafts/draft-hoffman-taobis-08.txt. Thanks, Donald From dahmna at gmail.com Wed Jun 28 12:44:31 2006 From: dahmna at gmail.com (Masanori Takashima) Date: Wed, 28 Jun 2006 15:44:31 -0400 Subject: [rbridge] Comments on draft-ietf-trill-prob-00.txt In-Reply-To: <449ABCC0.60600@cisco.com> References: <449ABCC0.60600@cisco.com> Message-ID: Hi, I think, in addition, that those two papers are helpful to understand RSTP causing large changes. Especially, the latter one shows us how bad it is when root bridge in outside ring disappers. Russ expains that root bridge is inside ring, but the paper explains root bridge in outside ring. - A. Myers, T. E. Ng, and H. Zhang. Rethinking the Service Model: Scaling Ethernet to a Million Nodes. In Third Workshop on Hot Topics in networks (HotNets-III), Mar. 2004. - K. Elmeleegy, A.L. Cox and T. E. Ng, On Count-to-Infinity Induced Forwarding Loops in Ethernet Networks. In Infocom '06, April. 2006. Masanori ------------------------------------------- > The spanning tree is dependent on the way a set of bridges are > interconnected, i.e., the link layer topology. Small changes in this > topology can cause large changes in the spanning tree. Changes in the > spanning tree can take time to propagate and converge. > > [QUESTION: is there a good visual example of this, one that we can > walk through in the description?] > > I think the absolute worst case is when one of the branches connected > to the root bridge fails, causing a large number of ports to > block and unblock before the network would reconverge. Perhaps a ring > would show enough to explain, however (?): > > A----B----C----D----E > | | > +-----F-----G-------+ > > If A is the root bridge, then we can assume the paths A->B->C->D and > A->F->G->E are the two open paths, while the D->E link is blocked in > both directions (just using hop count). If the A->B link fails, then E > must unblock its port to D for traffic to flow again, but it may > require recomputation of the entire tree through BPDUs, I think (?). From gibanez at it.uc3m.es Wed Jun 28 13:19:44 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Wed, 28 Jun 2006 22:19:44 +0200 Subject: [rbridge] Comments on draft-ietf-trill-prob-00.txt In-Reply-To: References: <449ABCC0.60600@cisco.com> Message-ID: <44A2E460.8090909@it.uc3m.es> I do agree. It seems that, as shown in the second paper, (I cite aproximately "...when the network gets partitioned and the part that does not contain the previous root bridge has a cycle, a count to infinity may occur"). Regards Guillermo Masanori Takashima wrote: >Hi, > >I think, in addition, that those two papers are helpful to understand >RSTP causing large changes. Especially, the latter one shows us how >bad it is when root bridge in outside ring disappers. Russ expains >that root bridge is inside ring, but the paper explains root bridge in >outside ring. > >- A. Myers, T. E. Ng, and H. Zhang. Rethinking the Service Model: >Scaling Ethernet to a Million Nodes. In Third Workshop on Hot Topics >in networks (HotNets-III), Mar. 2004. >- K. Elmeleegy, A.L. Cox and T. E. Ng, On Count-to-Infinity Induced >Forwarding Loops in Ethernet Networks. In Infocom '06, April. 2006. > > >Masanori >------------------------------------------- > > >> The spanning tree is dependent on the way a set of bridges are >> interconnected, i.e., the link layer topology. Small changes in this >> topology can cause large changes in the spanning tree. Changes in the >> spanning tree can take time to propagate and converge. >> >> [QUESTION: is there a good visual example of this, one that we can >> walk through in the description?] >> >>I think the absolute worst case is when one of the branches connected >>to the root bridge fails, causing a large number of ports to >>block and unblock before the network would reconverge. Perhaps a ring >>would show enough to explain, however (?): >> >>A----B----C----D----E >>| | >>+-----F-----G-------+ >> >>If A is the root bridge, then we can assume the paths A->B->C->D and >>A->F->G->E are the two open paths, while the D->E link is blocked in >>both directions (just using hop count). If the A->B link fails, then E >>must unblock its port to D for traffic to flow again, but it may >>require recomputation of the entire tree through BPDUs, I think (?). >> >> >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > From Radia.Perlman at sun.com Thu Jun 29 10:35:12 2006 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 29 Jun 2006 10:35:12 -0700 Subject: [rbridge] Differentiating multicast from unicast In-Reply-To: <449A3765.3020109@sun.com> References: <313680C9A886D511A06000204840E1CF0DDAF932@whq-msgusr-02.pit.comms.marconi.com> <449A20E2.50104@sun.com> <449A3765.3020109@sun.com> Message-ID: <44A40F50.3010406@sun.com> The Trill protocol document refers to an expired internet draft (bryant, et al) on using the pwe encoding for the shim header, and the coauthors on that document think the content should be moved into the protocol document, rather than keeping the seperate document alive and unexpired. Rereading the expired document, I realized that that specifies a different way of differentiating unicast from multicast than the base Trill protocol document does. In the current base document, it says to differentiate based on whether the MAC address in the outer header is a layer 2 multicast or unicast MAC address. But in the expired pwe draft, it says to do it based on the 20th bit in the label field in the shim header (the other 19 bits in the label field used for the nickname). I think I like the 20th bit method better (the one in the expired pwe draft), because in theory the campus might include links other than Ethernet links, and the outer header is a link-specific header that gets removed and replaced hop by hop, and there might even be a link that does not have the concept of multicast addresses (for example, if I'd been designing Ethernet addresses for the original Ethernet, I wouldn't have set aside a bit in the address...I'd have just said "an address is an address, and it's just up to receivers what to listen to--if more than one is listening it becomes a multicast"). So unless anyone objects, now that we've agreed to the 4-byte pwe-style shim header, I'll change the method of differentiating multicast from unicast to be based on the 20th bit in the label field. And also, could someone review the IS-IS encoding? (attached below) Radia Radia Perlman wrote: >1) layer 3 IS-IS LSPs > >It would be fine to treat these like any other layer 2 multicasts. >The only reason to do anything different would be if we want to >optimize distribution of these to go only to links on which there >are IS-IS routers. RBridges could recognize such packets because the >inner header would indicate the IS-IS DSAP. So I'm assuming these >will be encapsulated just like any layer 2 multicast. > >2) core IS-IS instance for RBridges (these are the IS-IS packets by >which RBridges inform each other about RBridge-to-RBridge connectivity. > >Outer header: > Destination=new (to be assigned) layer 2 multicast address, > indicating "core RBridge IS-IS packet" > Source=transmitting RBridge > protocol type=encapsulated RBridge packet > >Shim header: TTL and ingress RBridge (in PWE format as defined in the >unfortunately >expired internet draft by Bryant, et al) > >No inner layer 2 header: IS-IS packet immediately follows > >3) per-VLAN IS-IS instance for RBridges (these are the IS-IS packets by >which RBridges in a particular VLAN inform other RBridges attached to >the same VLAN of where the endnodes, multicast receivers, and multicast >routers associated with that VLAN are) > > >Outer header: > Destination=second new (to be assigned) layer 2 multicast address, > indicating "per-VLAN RBridge IS-IS packet" > Source=transmitting RBridge > protocol type=encapsulated RBridge packet > >Shim header: TTL and ingress RBridge > >No inner layer 2 header:, just VLAN tag, >followed by IS-IS packet > >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > From Eric.Gray at marconi.com Thu Jun 29 12:11:08 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 29 Jun 2006 15:11:08 -0400 Subject: [rbridge] Differentiating multicast from unicast Message-ID: <0BF76B30C100624BA997C9CED19D81250A5F23@uspitsmsgusr08.win.marconi.com> Radia, If I understand your meaning correctly, I think I agree. I believe using the 20th bit - to determine if the frame is to be flooded, broadcast or multicast - overloads the concept somewhat although I may not be understanding your comment. The reason why we've been talking about "deriving 19 bit nickname" all along is because we were expecting to use the 20th bit to determine if the "nickname" label is the nickname of the ingress or the egress RBridge(s). As it happens - in the multicast, flood and broadcast cases - we want to use the ingress RBridge nickname (in the label) and in the one remaining case (unicast-to-a-known-MAC-DA) we want to use the egress RBridge nickname. So the bit was always going to be used to distinguish the "send it on the Ingress RBridge Tree" case from the "send it unicast to the egress RBridge" case. However, we still want to use the appropriate outer MAC DA (i.e. - multicast for multicast, broadcast for broadcast or unknown) as we would otherwise not be able to take advantage of "broadcast delivery" across a "legacy bridge" segment to deliver multicast, broadcast and flooded frames to multiple "downstream" RBridges. If we use unicast MAC DA in the outer header, we will have to explicitly replicate the frames in any upstream RBridge whenever it will be directly delivered by that RBridge to more than one dowstream RBridge. In other words, given this (very simplistic) topology - S-1 <---> RB-1 <---> B-1 <---> RB-2 <---> S-2 A | +---> RB-3 <---> S-3 - in order for RB-1 to deliver a frame with an unknown destination from segment S-1 to segments S-2 and S-3, RB-1 can use a broadcast out header MAC DA, or it can explicitly replicate it using the MAC DA for each of RB-2 and RB-3. Consequently, we need to use both the 20th bit and a correct MAC DA in the outer encapsulation. For one thing, we need to know - from the outer encapsulation preferrably - whether each specific frame is multicast (so that we might apply multicast optimization) and (possibly) what VLAN it is part of (e.g. - if it is broadcast). Also see one or two other comments below. -- Eric --> -----Original Message----- --> From: rbridge-bounces at postel.org --> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman --> Sent: Thursday, June 29, 2006 1:35 PM --> To: rbridge at postel.org --> Subject: [rbridge] Differentiating multicast from unicast --> --> The Trill protocol document refers to an expired internet draft (bryant, --> et al) on using the pwe encoding for the shim header, and the coauthors --> on that document think the content should be moved into the protocol --> document, rather than keeping the seperate document alive and unexpired. I am not sure that this is the appropriate course of action, but I am okay with going this way for now. --> --> Rereading the expired document, I realized that that specifies a --> different way of differentiating unicast from multicast than the base --> Trill protocol document does. I don't think this is quite correct. I think the base protocol document - as it was when we chartered the WG - implicitly made an assumption that we would have to identify the source RBridge (ingress) for any flooded, multicast or broadcast traffic, as it is otherwise infeasible to select a non-looping shortest path on a hop-by-hop basis. I don't think it has ever been a common understanding that we would be using an SPF routing protocol to do something strange like set up source routed paths at the ingress. And there is some awkwardness in using the ingress source MAC DA across the multiple RBridges - and inter-connecting LAN segments - if we intended to use the source MAC as part of the Inress RBridge Tree look up. --> --> In the current base document, it says to differentiate based on whether --> MAC address in the outer header is a layer 2 multicast or unicast MAC --> address. Differentiate what? Differentiate the forwarding table look up (to either use the CFT-IRT or the CFT), to differentiate VLAN broadcasts and multicast (so that we can optimize bandwidth utilization), or differentiate the way that forwarding takes place in "legacy" portions of the network? See the explanation above for why we should use both MAC and label to differentiate these factors... --> But in the expired pwe draft, it says to do it based on the 20th bit --> in the label field in the shim header (the other 19 bits in the label --> field used for the nickname). --> Which - in all previous discussions - is what I believed we all assumed to be the case (though not quite as you've stated it). The 20th bit is used simply to determine whether the frame is being forwarded on the Ingress RBridge Tree or not. In other words, the 20th bit determines whether the look up is made against the CFT or CFT-IRT (because the nickname in the "label" is for the egress, or the ingress, RBridge - respectively). --> --> I think I like the 20th bit method better (the one in the expired --> pwe draft), because in theory the campus might include links other --> than Ethernet links, and the outer header is a link-specific header --> that gets removed and replaced hop by hop, and there might even be --> a link that does not have the concept of multicast addresses (for --> example, if I'd been designing Ethernet addresses for the original --> Ethernet, I wouldn't have set aside a bit in the address...I'd have --> just said "an address is an address, and it's just up to receivers --> what to listen to--if more than one is listening it becomes a --> multicast"). --> The architecture document has some stuff in it about using the fact that the source MAC is not re-written as yet another way to detect a loop. I think it is simpler if the entire MAC is re-written, however - as you suggest/imply here - and I can make the small number of changes it takes to make it that way there. For one thing, re-writing the entire MAC header in an outer encapsulation will reduce the potential for "strange cases" in "legacy" bridge learning. --> --> So unless anyone objects, now that we've agreed to the 4-byte pwe-style --> shim header, I'll change the method of differentiating multicast from --> unicast to be based on the 20th bit in the label field. --> I do not object, as long as we understand that this does not change the fact that we _still_ need to use multicast/broadcast MAC DAs in the MAC header - AND we still need to use this MAC DA information as part of the forwarding look-up. --> --> And also, could someone review the IS-IS encoding? (attached below) --> --> Radia --> -- [SNIP] --