From eric.gray at ericsson.com Thu Nov 1 02:09:31 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 1 Nov 2007 04:09:31 -0500 Subject: [rbridge] RBridge: a case of study In-Reply-To: <4728F8AC.8080506@sun.com> References: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF01DDF347@eusrcmw721.eamcs.ericsson.se> <4728F8AC.8080506@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01E0BE88@eusrcmw721.eamcs.ericsson.se> Radia, I don't think you've quite captured the concern. As a matter of practicality, it is most likely to be the case that the (at least intended) "normal" paths across an RBridge campus will use either point to point, or RBridge exclusive LAN connections. In these cases, what you are saying is correct. However, it may be the case that there are also end stations located on a LAN connecting RBridges that are also (perhaps mostly) used as intermediate RBridges. Simple picture: _____ _____ _____ / \ +---+ / \ +---+ / \ { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C } \_____/ +---+ \_____/ +---+ \_____/ | +-+-+ | 3 | +-+-+ __|__ / \ { LAN-D } \_____/ If you consider that LAN-B may have end stations, then part of the "load-sharing" concern has to do with sharing "load" associated with delivering frames to (or from) those local end stations. To do this, the VLAN-based DRB election may require that multiple RBridges (1, 2 and/or 3 in this case) - of course depending on the possibility that there are end stations in LAN-B in more than one VLAN. One could argue that a scenario like this - where the number of end-stations on LAN-B is sufficient to justify a "load sharing" concern - is artificially "constructed" (i.e. - unlikely to occur in a real network). However, it is a good idea to consider that one can arrive at this scenario, or one very like it, as a result of a fault in a deployment where redundancy is provided. For example, this topology - _____ / \ +---+ { LAN-A }--+ 1 +-. \_____/ +---+ \ | \_ _____ +-+-+ / \ | 4 | { LAN-B } +-+-+ _\_____/ __|__ / / \ +---+ / { LAN-C }--+ 2 +-' \_____/ +---+ - fails to this topology (on removing RBridge 4): _____ _____ _____ / \ +---+ / \ +---+ / \ { LAN-A }--+ 1 +--{ LAN-B }--+ 2 +--{ LAN-C } \_____/ +---+ \_____/ +---+ \_____/ The interesting point - in this case - is that it seems likely that a load-sharing election process was needed in the initial (unbroken) topology - and MUST NOT be broken by the "recovery" process associated with remote failure of RBridge 4. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Wednesday, October 31, 2007 5:51 PM > To: Eric Gray > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] RBridge: a case of study > Importance: High > > Eric....if I understand your concern... > > Having all RBridge-RBridge traffic between neighbor > RBridges (RBridges on a single layer 2 cloud) take place on a > single VLAN > (whether the VLAN used be configurable for that cloud, or > whether it's > always VLAN 1), > does not preclude load splitting. "VLAN 1" as the VLAN tag in > the outer header is just used in order to get a packet from one > RBridge to a neighbor RBridge. Layer 3 techniques for load splitting, > traffic engineering, etc., > can be used for having RBridges choose paths across the campus. When > doing load > splitting, a smart RBridge, just like a router, could choose > anything it > can see in order to decide which > path to send a frame on, or which traffic to drop when there is > congestion, including the inner VLAN tag. And although some might > consider it > architecturally impure, there isn't anything precluding an > RBridge from > looking > even further into the packet and making forwarding/traffic > splitting/traffic dropping decisions based > on things like the diffsrv field in the IP > header, or the TCP ports. > > The outer VLAN tag is just how to wrap up the frame when > forwarding to > the next hop > RBridge that the RBridge forwarding decision has selected for > this frame. > > Radia > > > > Eric Gray wrote: > > Anoop, > > > > This is a generic VLAN bridging problem, commonly > > dealt with using VLAN bridges today. Clearly, it is not > > the case that all VLAN bridges are required to use a > > common VLAN for frame forwarding. > > > > In addition, as I understand it (in part based on > > James' reply), we are NOT saying that the common VLAN > > you mention must be used for all frame forwarding - > > hence it is likely that the existence of a common VLAN > > does not necessarily fix the problem. > > > > Just to be clear, if we were saying that a common > > VLAN must be used for all forwarding between RBridges, > > it quickly becomes obvious that load-sharing based on > > VLAN separation becomes useless in practice. If load > > sharing based on VID is not useful, then MSTP already > > provides L2 forwarding that makes more efficient use of > > links than would be possible using RBridges (unless all > > RBridge-to-RBridge connections are via P2P links). > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > >> -----Original Message----- > >> From: Anoop Ghanwani [mailto:anoop at brocade.com] > >> Sent: Wednesday, October 31, 2007 1:33 PM > >> To: Zhi-Hern Loh; Eric Gray > >> Cc: Developing a hybrid router/bridge. > >> Subject: RE: [rbridge] RBridge: a case of study > >> Importance: High > >> > >> > >> Hern, > >> > >> That's one of the problems that we're trying to avoid > >> by forcing all RBridges on a bridged LAN to be configured > >> such that they are all reachable and see one another on > >> a single VLAN. > >> > >> Anoop > >> > >> > >>> -----Original Message----- > >>> From: rbridge-bounces at postel.org > >>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh > >>> Sent: Wednesday, October 31, 2007 10:17 AM > >>> To: Eric Gray > >>> Cc: Developing a hybrid router/bridge. > >>> Subject: Re: [rbridge] RBridge: a case of study > >>> > >>> Donald, > >>> > >>> In addition to Eric's questions, could you (or anyone else) > >>> explain what would happen in the following scenario? > >>> > >>> Toplogy: > >>> > >>> RBa > >>> / > >>> VID a > >>> / > >>> RBn-link X-----VID b------RBb > >>> > >>> Problem: > >>> > >>> RBn is connected to 2 VLANs on link/port X. Connectivity to > >>> RBa is via VLAN a, and connectivity to RBb is via VLAN b. > >>> > >>> Suppose that RBa and RBb are in the multi-destination > >>> distribution tree from RBn. For a multi-destination frame > >>> going out link/port X on RBn to RBa and RBb, what is the VID > >>> on the outer VLAN tag? Or could there be need to send 2 > >>> frames, one with VID a and another with VID b? > >>> > >>> > >>> > >>> Thanks, > >>> Hern > >>> Fulcrum Microsystems > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Eric Gray" > >>> To: "Eastlake III Donald-LDE008" > >>> , "Zhi-Hern Loh" > >>> > >> > >> > >>> Cc: "Developing a hybrid router/bridge." > >>> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) > >>> America/Los_Angeles > >>> Subject: RE: [rbridge] RBridge: a case of study > >>> > >>> Donald, > >>> > >>> When you say "would all have the same Outer [VID]" > >>> - do you mean: > >>> > >>> 1) all frames MUST have the same VID within the an RBridge > >>> campus, > >>> 2) all frames forwarded from a (physical) port on one RBridge > >>> to a (physical) port on another RBridge MUST have the same > >>> VID, or > >>> 3) something else? > >>> > >>> -- > >>> Eric Gray > >>> Principal Engineer > >>> Ericsson > >>> > >>> > >>>> -----Original Message----- > >>>> From: rbridge-bounces at postel.org > >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > >>>> Donald-LDE008 > >>>> Sent: Wednesday, October 31, 2007 12:22 AM > >>>> To: Zhi-Hern Loh > >>>> Cc: Developing a hybrid router/bridge. > >>>> Subject: Re: [rbridge] RBridge: a case of study > >>>> > >>>> Hi, > >>>> > >>>> Yes, as noted in protocol draft -05, the pseudo code was > >>>> > >> unchanged > >> > >>>> from > >>>> -04 and is out of date. > >>>> > >>>> As currently being discussed, the TRILL encapsulated data being > >>>> forwarded out a particular physical port would all have the > >>>> > >>> same Outer > >>> > >>>> VLAN ID. > >>>> > >>>> Thanks, > >>>> Donald > >>>> > >>>> -----Original Message----- > >>>> From: rbridge-bounces at postel.org > >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh > >>>> Sent: Tuesday, October 30, 2007 10:54 PM > >>>> To: Anoop Ghanwani > >>>> Cc: Developing a hybrid router/bridge.; Radia Perlman; > >>>> > >> James Carlson > >> > >>>> Subject: Re: [rbridge] RBridge: a case of study > >>>> > >>>> > >>>> ----- "Anoop Ghanwani" wrote: > >>>> > >>>>>> -----Original Message----- > >>>>>> From: rbridge-bounces at postel.org > >>>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > >>>>>> Sent: Tuesday, October 30, 2007 2:37 PM > >>>>>> To: Silvano Gai > >>>>>> Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM > >>>>>> Subject: Re: [rbridge] RBridge: a case of study > >>>>>> > >>>>>> Silvano Gai writes: > >>>>>> > >>>>>>> Radia, > >>>>>>> > >>>>>>> I have added few slides to the example and I suggest that > >>>>>>> > >>>>>> we use it as > >>>>>> > >>>>>>> a possible case of study for TRILL (of course, not the > >>>>>>> > >>>> only one). > >>>> > >>>>>>> Let's see if the solutions we have discussed work on this > >>>>>>> > >>>>> example. > >>>>> > >>>>>>> The complete case of study is at: > >>>>>>> > >>>>>>> http://www.ip6.com/acme-example-v1.ppt > >>>>>>> > >>>>>> I have a few narrow questions that I think might help me > >>>>>> understand this picture a bit better. (I probably have more > >>>>>> questions once I know the narrow answers. ;-}) > >>>>>> > >>>>> Let me take a shot at answering these. > >>>>> > >>>>> > >>>>>> 1. After the proposed fix, should VLAN 3 on Cloud L > >>>>>> > >>> be bridged > >>> > >>>>>> together with VLAN 3 on Cloud R, even though > >>>>>> > >> the backbone > >> > >>>>> itself > >>>>> > >>>>>> doesn't directly carry VLAN 3? (I.e., are TRILL > >>>>>> > >>>> packets with > >>>> > >>>>>> outer VLAN ID 7 or 8 and with inner VLAN 3 > >>>>>> > >> present on the > >> > >>>>>> backbone?) > >>>>>> > >>>>> Yes, that's pretty much what ends up happening. > >>>>> We have effectively extended the bridged LAN. > >>>>> > >>>>> > >>>> Anoop, I'm reading the RBridge protocol specification > >>>> > >>> version 5 and it > >>> > >>>> seems to me that your comment is inconsistent with the spec. > >>>> In section, > >>>> 5.2.2.3, the spec says that the outer VLAN tag of TRILL data > >>>> frames has > >>>> the same VID as the inner tag. Is this section going to > >>>> > >> be changed? > >> > >>>> Futhermore, if we were to use different VIDs on outer VLAN > >>>> tags then we > >>>> would need to handle the multi-destination case where one > >>>> would need to > >>>> send a multi-destination frame per outer VID to communicate > >>>> with the RBs > >>>> in the distribution tree which are using different VIDs. Is this > >>>> correct? > >>>> > >>>> Thanks, > >>>> Hern > >>>> Fulcrum Microsystems > >>>> > >>>> _______________________________________________ > >>>> 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 Donald.Eastlake at motorola.com Fri Nov 2 21:02:38 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 3 Nov 2007 00:02:38 -0400 Subject: [rbridge] Separating DRB election from encapsulator/decapsulator In-Reply-To: <47294F89.4050905@sun.com> References: <47294F89.4050905@sun.com> Message-ID: <3870C46029D1F945B1472F170D2D97900336DBD2@de01exm64.ds.mot.com> That seems like a good idea and should simplify the Hellos. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Thursday, November 01, 2007 12:01 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Separating DRB election from encapsulator/decapsulator When trying to carefully write up all the rules with respect to RBridges and VLANs, it occurs to me that one place in which things can be simplified is to separate the function of the DRB on a layer 2 cloud from the selection of data packet encapsulator/decapsulator for each VLAN. What I mean is that instead of having n different DRB elections with different priorities for different, possibly overlapping sets of VLANs for that cloud, we instead have a single DRB election for that cloud, and as a result, a single pseudonode associated with the cloud that would be visible to any RBridges not on the cloud. The DRB on a cloud has the following duties: a) names the pseudonode associated with the cloud b) reports an LSP on behalf of the pseudonode c) issues IS-IS CSNPs (a way of acknowledging LSPs that have been sent on the cloud) d) specifies, for each VLAN supported on that cloud, which RBridge on the cloud will be doing encapsulation/decapsulation for that VLAN e) chooses a VLAN tag with which all RBridge-RBridge communication on that cloud will be tagged in the outer header (explanation of this will be in a future email). For now, does anyone see any problem with this? It's unfortunately a bit entwined with the other hairy discussion going on, but I think that we're going to converge for that. Radia _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Sat Nov 3 09:38:52 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 3 Nov 2007 12:38:52 -0400 Subject: [rbridge] RBridge: a case of study In-Reply-To: <18216.36269.214404.179226@gargle.gargle.HOWL> References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com><18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com><3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <18216.36269.214404.179226@gargle.gargle.HOWL> Message-ID: <3870C46029D1F945B1472F170D2D97900336DBEC@de01exm64.ds.mot.com> See below at @@@ -----Original Message----- From: James Carlson [mailto:james.d.carlson at sun.com] Sent: Wednesday, October 31, 2007 10:14 AM To: Eric Gray Cc: Eastlake III Donald-LDE008; Zhi-Hern Loh; Developing a hybrid router/bridge. Subject: Re: [rbridge] RBridge: a case of study Eric Gray writes: > Donald, > > When you say "would all have the same Outer [VID]" > - do you mean: > > 1) all frames MUST have the same VID within the an RBridge > campus, > 2) all frames forwarded from a (physical) port on one RBridge > to a (physical) port on another RBridge MUST have the same > VID, or > 3) something else? (I'm not Donald, but ...) @@@ Well, I am Donald and I meant something like (2) but a bit narrower. I would have said "all TRILL frames" because "all frames" is way too inclusive. What about control frames like 802.1AB? Furthermore, in the case of point-to-point links between two Rbridges (i.e., no bridges or end station connections in between), as far as I can see there is no particular utility in considering the TRILL frames to have any external VLAN coloring and certainly no need for them to be outer tagged with a VLAN ID or priority. My understanding was more like: 3) Where an outer VLAN tag is present, all frames transmitted by an RBridge must have the same inner and outer VLAN tag numbers. Where an outer VLAN tag is not present, the implicit tag for that port must match or be compatible with the inner tag. ... which would be consistent with "traditional" bridge behavior and would effectively rule out the type of solution that Silvano Gai has been proposing. @@@ Well, your version of (3) above is, as I recall, roughly how things were in draft -04. However, by -05 posted in July of this year (except in the pseudo code which is clearly labeled as still being that from -04), in order to actually provide the promised optimal pair-wise routing, the Outer and Inner VLANs are completely decoupled. See, for example, Section 4.1.2 of -05. And some recent proposals suggest using a single Outer VLAN ID on a link. The distinction with (2) in your list is that (2) appears to rule out the use of so-called "tagged" or leaf or ingress ports, forcing all ports to carry VLAN tags. @@@ I find your above statement a bit confusing. Item (2) seems to be talking about TRILL frames between Rbridges which doesn't have anything to do with ingressing native frames. @@@ Thanks, @@@ Donald -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Donald.Eastlake at motorola.com Sat Nov 3 09:50:04 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 3 Nov 2007 12:50:04 -0400 Subject: [rbridge] RBridge: a case of study In-Reply-To: <18216.31931.91042.199304@gargle.gargle.HOWL> References: <283f04e35585.47263880@sunlabs.com><34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com><18215.42006.843620.853514@gargle.gargle.HOWL><34BDD2A93E5FD84594BB230DD6C18EA20260671F@nuova-ex1.hq.nuovaimpresa.com> <18216.31931.91042.199304@gargle.gargle.HOWL> Message-ID: <3870C46029D1F945B1472F170D2D97900336DBED@de01exm64.ds.mot.com> Hi, See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson Sent: Wednesday, October 31, 2007 9:02 AM To: Silvano Gai Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM Subject: Re: [rbridge] RBridge: a case of study Silvano Gai writes: > James, > > -- snip -- > > > > > 3. Suppose we were to configure VLAN 7 within Cloud L. Would you > > expect H1 to be able to access nodes within the backbone Cloud G > > at that point? (I'm trying to figure out whether the "X" and > > "Y" interfaces are of fundamentally different types or if the > > RBridges are just bridges. I suspect they're different.) > > > > I have produced an updated drawing to cover the case of "hybrid ports". > > http://www.ip6.com/example-v2.ppt > > In this drawing I assume that H5 is able to talk with H6. That new diagram still does not show the confusing situation that I was referring to above. In fact, it shows a situation that is essentially _identical_ to the previous one you showed in terms of added bridge functionality. To replicate the confusing functionality, consider what happens when adding a host (call it H7) attached to Cloud P. Without VLAN 7 in Cloud P, H7 will not be able to participate in VLAN 7 even though all attached RBridges are in fact transiting VLAN 7 traffic on that network. If VLAN 7 is provisioned onto Cloud P (exactly how does this happen?), then H7 can play. I see no functionality comparable to this in the existing draft. The core change that I think you're asserting here is that when the user deploys RBridges, the network automatically discovers all of the far-flung and disjoint islands of VLAN ID usage, and glues those together by tunneling over whatever VLANs might be in the way between them. It no longer matters what configuration separates them. @@@ This is not some new change just coming from Silvano. For some time now the base protocol specification has assumed that all the islands of a VLAN seen by an Rbridge get glued together. Bridges can keep them apart because they are myopic. Rbridges have a global view and it would add significant complexity to the protocol to somehow defeat the automatic connection of station on a VLAN by Rbridges. This was discussed extensively on the list including such ideas as adding a further qualifying "island-ID" or something to the VLANID+Address that are the current basis for TRILL routing. There was no support for such added complexity. This is quite a departure from traditional bridging, and I think it's likely to be both confusing and dangerous, so I'm not sure it ought to be the default behavior. In today's bridges, if I configure a trunk port such that VLAN 3 traffic does not traverse the link, then -- quite simply -- no packets with VLAN ID set to 3 go over that link. In the new model, that restriction does not apply. If I say "allow VLAN ID 3," then both an O-RBridge (original RBridge as I understood it) and the new G-RBridge (Silvano Gai modified RBridge) will allow VLAN ID 3 across the link. If I say "disallow VLAN ID 3 and allow only VLAN 7," then the O-RBridge would stop passing VLAN ID 3 traffic, but the G-RBridge would simply switch the outer VLAN ID number and use VLAN 7 effectively as a tunnel to pass VLAN 3. The TRILL-encapsulated packets will have VLAN 3 on the inside and VLAN 7 on the outside. @@@ The only suggestion that was made to preserve VLAN islands was to, in effect, create a bigger VLAN ID or other higher order qualifier on top of the 60 bits of VLAN plus address. There was no support in the working group for this suggestion. @@@ Thanks, @@@ Donald I'm not at all sure that's a good thing. I can see why folks who are struggling with the unkempt nature of VLAN ID provisioning across complex (and politically divided) networks would be excited about a "do what I mean" option -- particularly if it means that I don't have to tell my local IT group to reconfigure switches to allow separated chunks of my new VLAN to connect together -- but the side-effects seem extreme. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Sat Nov 3 10:16:54 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sat, 3 Nov 2007 13:16:54 -0400 Subject: [rbridge] RBridge: a case of study In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> References: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se><22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D97900336DBEE@de01exm64.ds.mot.com> Hern, Your question is the same as my question in point 2 of my mail at http://www.postel.org/pipermail/rbridge/2007-October/002584.html. The way things are described in the text of draft -05, I think you would indeed have to send some TRILL data frames multiple times. That is why there is currently discussion of ways to avoid this problem while maintaining our charter goal of optional pairwise routing. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani Sent: Wednesday, October 31, 2007 1:33 PM To: Zhi-Hern Loh; Eric Gray Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] RBridge: a case of study Hern, That's one of the problems that we're trying to avoid by forcing all RBridges on a bridged LAN to be configured such that they are all reachable and see one another on a single VLAN. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh > Sent: Wednesday, October 31, 2007 10:17 AM > To: Eric Gray > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] RBridge: a case of study > > Donald, > > In addition to Eric's questions, could you (or anyone else) > explain what would happen in the following scenario? > > Toplogy: > > RBa > / > VID a > / > RBn-link X-----VID b------RBb > > Problem: > > RBn is connected to 2 VLANs on link/port X. Connectivity to > RBa is via VLAN a, and connectivity to RBb is via VLAN b. > > Suppose that RBa and RBb are in the multi-destination > distribution tree from RBn. For a multi-destination frame > going out link/port X on RBn to RBa and RBb, what is the VID > on the outer VLAN tag? Or could there be need to send 2 > frames, one with VID a and another with VID b? > > > > Thanks, > Hern > Fulcrum Microsystems > > > ----- Original Message ----- > From: "Eric Gray" > To: "Eastlake III Donald-LDE008" > , "Zhi-Hern Loh" > Cc: "Developing a hybrid router/bridge." > Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) > America/Los_Angeles > Subject: RE: [rbridge] RBridge: a case of study > > Donald, > > When you say "would all have the same Outer [VID]" > - do you mean: > > 1) all frames MUST have the same VID within the an RBridge > campus, > 2) all frames forwarded from a (physical) port on one RBridge > to a (physical) port on another RBridge MUST have the same > VID, or > 3) something else? > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Wednesday, October 31, 2007 12:22 AM > > To: Zhi-Hern Loh > > Cc: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] RBridge: a case of study > > > > Hi, > > > > Yes, as noted in protocol draft -05, the pseudo code was unchanged > > from > > -04 and is out of date. > > > > As currently being discussed, the TRILL encapsulated data being > > forwarded out a particular physical port would all have the > same Outer > > VLAN ID. > > > > Thanks, > > Donald > > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh > > Sent: Tuesday, October 30, 2007 10:54 PM > > To: Anoop Ghanwani > > Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > ----- "Anoop Ghanwani" wrote: > > > > -----Original Message----- > > > > From: rbridge-bounces at postel.org > > > > [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > > > > Sent: Tuesday, October 30, 2007 2:37 PM > > > > To: Silvano Gai > > > > Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM > > > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > > > Silvano Gai writes: > > > > > Radia, > > > > > > > > > > I have added few slides to the example and I suggest that > > > > we use it as > > > > > a possible case of study for TRILL (of course, not the > > only one). > > > > > > > > > > Let's see if the solutions we have discussed work on this > > > example. > > > > > > > > > > The complete case of study is at: > > > > > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > > > > > I have a few narrow questions that I think might help me > > > > understand this picture a bit better. (I probably have more > > > > questions once I know the narrow answers. ;-}) > > > > > > Let me take a shot at answering these. > > > > > > > 1. After the proposed fix, should VLAN 3 on Cloud L > be bridged > > > > together with VLAN 3 on Cloud R, even though the backbone > > > itself > > > > doesn't directly carry VLAN 3? (I.e., are TRILL > > packets with > > > > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > > > > backbone?) > > > > > > Yes, that's pretty much what ends up happening. > > > We have effectively extended the bridged LAN. > > > > > > > Anoop, I'm reading the RBridge protocol specification > version 5 and it > > seems to me that your comment is inconsistent with the spec. > > In section, > > 5.2.2.3, the spec says that the outer VLAN tag of TRILL data > > frames has > > the same VID as the inner tag. Is this section going to be changed? > > > > Futhermore, if we were to use different VIDs on outer VLAN > > tags then we > > would need to handle the multi-destination case where one > > would need to > > send a multi-destination frame per outer VID to communicate > > with the RBs > > in the distribution tree which are using different VIDs. Is this > > correct? > > > > Thanks, > > Hern > > Fulcrum Microsystems > > > > _______________________________________________ > > 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 james.d.carlson at sun.com Mon Nov 5 07:15:58 2007 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 5 Nov 2007 10:15:58 -0500 Subject: [rbridge] RBridge: a case of study In-Reply-To: <3870C46029D1F945B1472F170D2D97900336DBEC@de01exm64.ds.mot.com> References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> <3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <18216.36269.214404.179226@gargle.gargle.HOWL> <3870C46029D1F945B1472F170D2D97900336DBEC@de01exm64.ds.mot.com> Message-ID: <18223.13230.626187.543062@gargle.gargle.HOWL> Eastlake III Donald-LDE008 writes: > From: James Carlson [mailto:james.d.carlson at sun.com] [...] > Eric Gray writes: [...] > > 2) all frames forwarded from a (physical) port on one RBridge > > to a (physical) port on another RBridge MUST have the same > > VID, or [...] > @@@ Well, I am Donald and I meant something like (2) but a bit narrower. > I would have said "all TRILL frames" because "all frames" is way too > inclusive. What about control frames like 802.1AB? Furthermore, in the > case of point-to-point links between two Rbridges (i.e., no bridges or > end station connections in between), as far as I can see there is no > particular utility in considering the TRILL frames to have any external > VLAN coloring and certainly no need for them to be outer tagged with a > VLAN ID or priority. I mostly agree with that. In fact, I think that's a desirable end state for TRILL, when all other bridges are obsolete. Having no VLAN tag on the outside makes a lot of sense there. (I think omitting the priority makes a bit less sense to me, though. Wouldn't you want the priority value set on an 802.1q header with VLAN ID 0 in this case?) I think the question is how to get there when there are networks that are half-TRILL and half-otherwise. > @@@ Well, your version of (3) above is, as I recall, roughly how things > were in draft -04. Yes. > However, by -05 posted in July of this year (except > in the pseudo code which is clearly labeled as still being that from > -04), in order to actually provide the promised optimal pair-wise > routing, the Outer and Inner VLANs are completely decoupled. See, for > example, Section 4.1.2 of -05. And some recent proposals suggest using a > single Outer VLAN ID on a link. As long as these things are manually configured, as described in 4.1.2, I don't see a problem. As I understood Silvano Gai's discussion, it seemed he didn't want to have those things be manually configured, so the RBridges would somehow "find" each other on whatever underlying outer VLAN IDs might be available and then forward packets without regard to the restrictions placed on those other VLANs. Perhaps I've misunderstood *that* part of it, but it's that part that I wanted to clarify. > The distinction with (2) in your list is that (2) appears to rule out > the use of so-called "tagged" or leaf or ingress ports, forcing all > ports to carry VLAN tags. > > @@@ I find your above statement a bit confusing. Item (2) seems to be > talking about TRILL frames between Rbridges which doesn't have anything > to do with ingressing native frames. The original statement said this: 2) all frames forwarded from a (physical) port on one RBridge to a (physical) port on another RBridge MUST have the same VID [...] Packets that don't have VLAN tags (such as those on "tagged" ports) don't have ID numbers. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From james.d.carlson at sun.com Mon Nov 5 07:21:03 2007 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 5 Nov 2007 10:21:03 -0500 Subject: [rbridge] RBridge: a case of study In-Reply-To: <3870C46029D1F945B1472F170D2D97900336DBED@de01exm64.ds.mot.com> References: <283f04e35585.47263880@sunlabs.com> <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> <18215.42006.843620.853514@gargle.gargle.HOWL> <34BDD2A93E5FD84594BB230DD6C18EA20260671F@nuova-ex1.hq.nuovaimpresa.com> <18216.31931.91042.199304@gargle.gargle.HOWL> <3870C46029D1F945B1472F170D2D97900336DBED@de01exm64.ds.mot.com> Message-ID: <18223.13535.22482.195169@gargle.gargle.HOWL> Eastlake III Donald-LDE008 writes: > @@@ This is not some new change just coming from Silvano. For some time > now the base protocol specification has assumed that all the islands of > a VLAN seen by an Rbridge get glued together. Bridges can keep them > apart because they are myopic. Rbridges have a global view and it would > add significant complexity to the protocol to somehow defeat the > automatic connection of station on a VLAN by Rbridges. This was > discussed extensively on the list including such ideas as adding a > further qualifying "island-ID" or something to the VLANID+Address that > are the current basis for TRILL routing. There was no support for such > added complexity. I'm asking about how Silvano Gai's diagram agrees with the current spec. According to the current spec, you have to configure any outer VLAN ID number that's present. It's in the realm of manual configuration and thus doesn't violate anything the administrator has specifically set up. If I read Silvano Gai's diagram correctly, that configuration isn't present. Instead, the RBridges _automatically_ discover the non-default connections amongst themselves, and use them as they see fit. (At a guess, they do so by sending Hello messages on all 4094 VLAN ID numbers.) I'm not asking to have islands supported. I agree that it'd be a mess. I'm asking whether he's assuming they'll always be automatically glued together without manual configuration, even if there are restricted outer VLANs. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From eric.gray at ericsson.com Mon Nov 5 12:45:26 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Mon, 5 Nov 2007 14:45:26 -0600 Subject: [rbridge] RBridge: a case of study In-Reply-To: <4728F8AC.8080506@sun.com> References: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF01DDF347@eusrcmw721.eamcs.ericsson.se> <4728F8AC.8080506@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01E7B739@eusrcmw721.eamcs.ericsson.se> Radia, On looking at this again, it seems as if you've tried to answer a question I am not asking. I will try this again. Please see in-line below. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Wednesday, October 31, 2007 5:51 PM > To: Eric Gray > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] RBridge: a case of study > Importance: High > > Eric....if I understand your concern... > > Having all RBridge-RBridge traffic between neighbor RBridges > (RBridges on a single layer 2 cloud) take place on a single > VLAN (whether the VLAN used be configurable for that cloud, > or whether it's always VLAN 1), does not preclude load > splitting. For some types of load splitting, what you're saying may be correct. At the egress from, and ingress to, the RBridge campus, the only form of load-splitting that we have talked about thus far is based on the DRB election process - in combination with VLAN-specific DRB election. The why's and wherefore's of the issues of other forms of load splitting at the campus edge have to do with the need to have symmetrical frame delivery - and that's a discussion complex enough to ignore (because it is irrelevant) in this discussion. For this particular form of load-splitting, obviously using only one VLAN for forwarding precludes it. > > "VLAN 1" as the VLAN tag in the outer header is just used in > order to get a packet from one RBridge to a neighbor RBridge. > Layer 3 techniques for load splitting, traffic engineering, > etc., can be used for having RBridges choose paths across the > campus. When doing load splitting, a smart RBridge, just like > a router, could choose anything it can see in order to decide > which path to send a frame on, or which traffic to drop when > there is congestion, including the inner VLAN tag. > And although some might consider it architecturally impure, > there isn't anything precluding an RBridge from looking > even further into the packet and making forwarding/traffic > splitting/traffic dropping decisions based on things like the > diffsrv field in the IP header, or the TCP ports. And this is where we're missing the point. If there is only one DRB for a given TRILL link, only that device will act as egress from, and ingress to, the link. Many of the clever load-splitting approaches out there will break a layer 2 network because they lead to asymmetrical forwarding. > > The outer VLAN tag is just how to wrap up the frame when > forwarding to the next hop RBridge that the RBridge forwarding > decision has selected for this frame. And - for the case where the forwarding RBridge is not the DRB - it is necessary for the frame to traverse the local network twice; once with TRILL encaps and again without. It is quite likely that this will often result in the DRB forwarding frames onto a local bridged LAN for a VLAN that it would otherwise not participate in. > > Radia > My earlier response pointed out - possibly at too much length - that you CANNOT assume that a link that provides egress from the RBridge campus is not also a link between RBridges, nor that a link between RBridges is not also an egress/ingress point. I thought this obvious because I did qualify the concern by the words "based on VLAN separation" - in reference to the specific mechanism by which load-splitting would occur. Even if we are talking about traffic that is not going to be egressed onto the local link, this statement would have been true. All of that said, if you are referring JUST to traffic that is literally traversing the local link, then what you say is true. The DRB election does not apply in that case. However, that is not the way I initially interpretted what you said. In part, that is because of the earlier statement from Donald - regarding the use of a single VLAN ID for all traffic sent on any physical interface. If that is not what you were referring to, then my objection to the idea is simply that it's unnecessarily restrictive and may, in fact, interfere with deployment. > > > Eric Gray wrote: > > Anoop, > > > > This is a generic VLAN bridging problem, commonly > > dealt with using VLAN bridges today. Clearly, it is not > > the case that all VLAN bridges are required to use a > > common VLAN for frame forwarding. > > > > In addition, as I understand it (in part based on > > James' reply), we are NOT saying that the common VLAN > > you mention must be used for all frame forwarding - > > hence it is likely that the existence of a common VLAN > > does not necessarily fix the problem. > > > > Just to be clear, if we were saying that a common > > VLAN must be used for all forwarding between RBridges, > > it quickly becomes obvious that load-sharing based on > > VLAN separation becomes useless in practice. If load > > sharing based on VID is not useful, then MSTP already > > provides L2 forwarding that makes more efficient use of > > links than would be possible using RBridges (unless all > > RBridge-to-RBridge connections are via P2P links). > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > >> -----Original Message----- > >> From: Anoop Ghanwani [mailto:anoop at brocade.com] > >> Sent: Wednesday, October 31, 2007 1:33 PM > >> To: Zhi-Hern Loh; Eric Gray > >> Cc: Developing a hybrid router/bridge. > >> Subject: RE: [rbridge] RBridge: a case of study > >> Importance: High > >> > >> > >> Hern, > >> > >> That's one of the problems that we're trying to avoid > >> by forcing all RBridges on a bridged LAN to be configured > >> such that they are all reachable and see one another on > >> a single VLAN. > >> > >> Anoop > >> > >> > >>> -----Original Message----- > >>> From: rbridge-bounces at postel.org > >>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh > >>> Sent: Wednesday, October 31, 2007 10:17 AM > >>> To: Eric Gray > >>> Cc: Developing a hybrid router/bridge. > >>> Subject: Re: [rbridge] RBridge: a case of study > >>> > >>> Donald, > >>> > >>> In addition to Eric's questions, could you (or anyone else) > >>> explain what would happen in the following scenario? > >>> > >>> Toplogy: > >>> > >>> RBa > >>> / > >>> VID a > >>> / > >>> RBn-link X-----VID b------RBb > >>> > >>> Problem: > >>> > >>> RBn is connected to 2 VLANs on link/port X. Connectivity to > >>> RBa is via VLAN a, and connectivity to RBb is via VLAN b. > >>> > >>> Suppose that RBa and RBb are in the multi-destination > >>> distribution tree from RBn. For a multi-destination frame > >>> going out link/port X on RBn to RBa and RBb, what is the VID > >>> on the outer VLAN tag? Or could there be need to send 2 > >>> frames, one with VID a and another with VID b? > >>> > >>> > >>> > >>> Thanks, > >>> Hern > >>> Fulcrum Microsystems > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Eric Gray" > >>> To: "Eastlake III Donald-LDE008" > >>> , "Zhi-Hern Loh" > >>> > >> > >> > >>> Cc: "Developing a hybrid router/bridge." > >>> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) > >>> America/Los_Angeles > >>> Subject: RE: [rbridge] RBridge: a case of study > >>> > >>> Donald, > >>> > >>> When you say "would all have the same Outer [VID]" > >>> - do you mean: > >>> > >>> 1) all frames MUST have the same VID within the an RBridge > >>> campus, > >>> 2) all frames forwarded from a (physical) port on one RBridge > >>> to a (physical) port on another RBridge MUST have the same > >>> VID, or > >>> 3) something else? > >>> > >>> -- > >>> Eric Gray > >>> Principal Engineer > >>> Ericsson > >>> > >>> > >>>> -----Original Message----- > >>>> From: rbridge-bounces at postel.org > >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > >>>> Donald-LDE008 > >>>> Sent: Wednesday, October 31, 2007 12:22 AM > >>>> To: Zhi-Hern Loh > >>>> Cc: Developing a hybrid router/bridge. > >>>> Subject: Re: [rbridge] RBridge: a case of study > >>>> > >>>> Hi, > >>>> > >>>> Yes, as noted in protocol draft -05, the pseudo code was > >>>> > >> unchanged > >> > >>>> from > >>>> -04 and is out of date. > >>>> > >>>> As currently being discussed, the TRILL encapsulated data being > >>>> forwarded out a particular physical port would all have the > >>>> > >>> same Outer > >>> > >>>> VLAN ID. > >>>> > >>>> Thanks, > >>>> Donald > >>>> > >>>> -----Original Message----- > >>>> From: rbridge-bounces at postel.org > >>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Zhi-Hern Loh > >>>> Sent: Tuesday, October 30, 2007 10:54 PM > >>>> To: Anoop Ghanwani > >>>> Cc: Developing a hybrid router/bridge.; Radia Perlman; > >>>> > >> James Carlson > >> > >>>> Subject: Re: [rbridge] RBridge: a case of study > >>>> > >>>> > >>>> ----- "Anoop Ghanwani" wrote: > >>>> > >>>>>> -----Original Message----- > >>>>>> From: rbridge-bounces at postel.org > >>>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > >>>>>> Sent: Tuesday, October 30, 2007 2:37 PM > >>>>>> To: Silvano Gai > >>>>>> Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM > >>>>>> Subject: Re: [rbridge] RBridge: a case of study > >>>>>> > >>>>>> Silvano Gai writes: > >>>>>> > >>>>>>> Radia, > >>>>>>> > >>>>>>> I have added few slides to the example and I suggest that > >>>>>>> > >>>>>> we use it as > >>>>>> > >>>>>>> a possible case of study for TRILL (of course, not the > >>>>>>> > >>>> only one). > >>>> > >>>>>>> Let's see if the solutions we have discussed work on this > >>>>>>> > >>>>> example. > >>>>> > >>>>>>> The complete case of study is at: > >>>>>>> > >>>>>>> http://www.ip6.com/acme-example-v1.ppt > >>>>>>> > >>>>>> I have a few narrow questions that I think might help me > >>>>>> understand this picture a bit better. (I probably have more > >>>>>> questions once I know the narrow answers. ;-}) > >>>>>> > >>>>> Let me take a shot at answering these. > >>>>> > >>>>> > >>>>>> 1. After the proposed fix, should VLAN 3 on Cloud L > >>>>>> > >>> be bridged > >>> > >>>>>> together with VLAN 3 on Cloud R, even though > >>>>>> > >> the backbone > >> > >>>>> itself > >>>>> > >>>>>> doesn't directly carry VLAN 3? (I.e., are TRILL > >>>>>> > >>>> packets with > >>>> > >>>>>> outer VLAN ID 7 or 8 and with inner VLAN 3 > >>>>>> > >> present on the > >> > >>>>>> backbone?) > >>>>>> > >>>>> Yes, that's pretty much what ends up happening. > >>>>> We have effectively extended the bridged LAN. > >>>>> > >>>>> > >>>> Anoop, I'm reading the RBridge protocol specification > >>>> > >>> version 5 and it > >>> > >>>> seems to me that your comment is inconsistent with the spec. > >>>> In section, > >>>> 5.2.2.3, the spec says that the outer VLAN tag of TRILL data > >>>> frames has > >>>> the same VID as the inner tag. Is this section going to > >>>> > >> be changed? > >> > >>>> Futhermore, if we were to use different VIDs on outer VLAN > >>>> tags then we > >>>> would need to handle the multi-destination case where one > >>>> would need to > >>>> send a multi-destination frame per outer VID to communicate > >>>> with the RBs > >>>> in the distribution tree which are using different VIDs. Is this > >>>> correct? > >>>> > >>>> Thanks, > >>>> Hern > >>>> Fulcrum Microsystems > >>>> > >>>> _______________________________________________ > >>>> 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 Radia.Perlman at sun.com Mon Nov 5 14:52:29 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 05 Nov 2007 14:52:29 -0800 Subject: [rbridge] Preview of changes for VLANs, etc. Message-ID: <472F9EAD.2040600@sun.com> Based on talking to people, here is how I'm assuming the VLAN stuff will look. The main points are a) single DRB per link (rather than DRB election per VLAN). b) that DRB can delegate to another RBridge on the link the job of forwarding VLAN-x data to/from the link. c) RBridges MAY be configured to send Hellos on a set of VLANs, though VLAN 1 is the default. They are also configured with a single preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other RBridges on the link to send ALL RBridge-Rbridge traffic (Hellos, LSPs, forwarded encapsulated data traffic) with outer VLAN tag "V". d) For safety, the DRB RB1 continues to send Hellos not only on V, but on all the VLANs that RB1 is configured to send Hellos on. e) The set of VLANs that RB1 is configured to support on the link may be greater than the set of VLANs that RB1 is configured to send Hellos on f) We use all the link-avoidance stuff we'd discussed before (don't decapsulate from ingress RBx unless you have RBx's LSP and all pseudonodes that RBx claims to be attached to, and can verify that none of them have the same root bridge ID as the link you are about to decapsulate onto -- also, be conservative about when you start encapsulting data off the link by waiting a few Hello intervals, and waiting until you've synchornized LSP databases with your neighbors). g) IS-IS Hellos list the set of neighbors from which Hellos are heard. Once the DRB RB1 specifies "V" as the VLAN, the only neighbors listed in IS-IS Hellos are those from which a Hello is received on VLAN V. From anoop at brocade.com Mon Nov 5 15:28:17 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 5 Nov 2007 15:28:17 -0800 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <472F9EAD.2040600@sun.com> References: <472F9EAD.2040600@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E9B27B6@HQ-EXCH-5.corp.brocade.com> Hi Radia, I think the proposal is reasonable in that per-VLAN hellos are now optional (and can be made use of in certain scenarios). However, what is not specified is the recipient behavior. Can an RBridge choose to ignore hellos from all other VLANs except the one it is configured to send hellos on? It seems like that should be allowed because it won't do anything other than detect misconfigurations that can also be detected by other means (although perhaps taking slightly longer to be detected). If that recipient behavior is not allowed, we will still get into scaling issues with having to receive and process hellos from potentially all VLANs configured on a port. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Monday, November 05, 2007 2:52 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Preview of changes for VLANs, etc. > > Based on talking to people, here is how I'm assuming the VLAN > stuff will look. The main points are > > a) single DRB per link (rather than DRB election per VLAN). > > b) that DRB can delegate to another RBridge on the link the > job of forwarding VLAN-x data to/from the link. > > c) RBridges MAY be configured to send Hellos on a set of > VLANs, though VLAN 1 is the default. They are also configured > with a single preferred VLAN "V". If RBridge RB1 is DRB, it > tells all the other RBridges on the link to send ALL > RBridge-Rbridge traffic (Hellos, LSPs, forwarded encapsulated > data traffic) with outer VLAN tag "V". > > d) For safety, the DRB RB1 continues to send Hellos not only > on V, but on all the VLANs that RB1 is configured to send Hellos on. > > e) The set of VLANs that RB1 is configured to support on the > link may be greater than the set of VLANs that RB1 is > configured to send Hellos on > > f) We use all the link-avoidance stuff we'd discussed before > (don't decapsulate from ingress RBx unless you have RBx's LSP > and all pseudonodes that RBx claims to be attached to, and > can verify that none of them have the same root bridge ID as > the link you are about to decapsulate onto -- also, be > conservative about when you start encapsulting data off the > link by waiting a few Hello intervals, and waiting until > you've synchornized LSP databases with your neighbors). > > g) IS-IS Hellos list the set of neighbors from which Hellos are heard. > Once the DRB RB1 specifies "V" as the VLAN, the only > neighbors listed in IS-IS Hellos are those from which a Hello > is received on VLAN V. > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Mon Nov 5 17:14:53 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 05 Nov 2007 17:14:53 -0800 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E9B27B6@HQ-EXCH-5.corp.brocade.com> References: <472F9EAD.2040600@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B27B6@HQ-EXCH-5.corp.brocade.com> Message-ID: <472FC00D.90809@sun.com> Good question. Once an RBridge knows it isn't the DRB, it seems like the only VLAN it should need to send or receive Hellos on is the one that the DRB specifies should be used for interbridge communication. I think the "safety" case is to maximize the probability that RB1 and RB2 can hear each other if they both believe they are DRB. That was why I was suggesting that the DRB continue to send Hellos on all the VLANs that it is configured to send Hellos on, which is hopefully a much smaller set than the set of VLANs it supports. In other words, even if an RBridge is configured to accept frames with any of the 4000 VLANs on a link, that doesn't mean it would send Hellos on all 4000. It would have to be separately configured for the set of VLANs to send Hellos on, and hopefully it would only be configured to send Hellos on a handful of VLANs (3 or 4). But...if an RBridge is configured to accept frames with any VLAN tag, is it burdensome for it to accept Hellos on any of those VLANs? Radia Anoop Ghanwani wrote: > Hi Radia, > > I think the proposal is reasonable in that per-VLAN > hellos are now optional (and can be made use of in > certain scenarios). However, what is not specified > is the recipient behavior. Can an RBridge choose > to ignore hellos from all other VLANs except the > one it is configured to send hellos on? It seems > like that should be allowed because it won't do > anything other than detect misconfigurations that > can also be detected by other means (although > perhaps taking slightly longer to be detected). > > If that recipient behavior is not allowed, we will > still get into scaling issues with having to receive > and process hellos from potentially all VLANs > configured on a port. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >> Sent: Monday, November 05, 2007 2:52 PM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] Preview of changes for VLANs, etc. >> >> Based on talking to people, here is how I'm assuming the VLAN >> stuff will look. The main points are >> >> a) single DRB per link (rather than DRB election per VLAN). >> >> b) that DRB can delegate to another RBridge on the link the >> job of forwarding VLAN-x data to/from the link. >> >> c) RBridges MAY be configured to send Hellos on a set of >> VLANs, though VLAN 1 is the default. They are also configured >> with a single preferred VLAN "V". If RBridge RB1 is DRB, it >> tells all the other RBridges on the link to send ALL >> RBridge-Rbridge traffic (Hellos, LSPs, forwarded encapsulated >> data traffic) with outer VLAN tag "V". >> >> d) For safety, the DRB RB1 continues to send Hellos not only >> on V, but on all the VLANs that RB1 is configured to send Hellos on. >> >> e) The set of VLANs that RB1 is configured to support on the >> link may be greater than the set of VLANs that RB1 is >> configured to send Hellos on >> >> f) We use all the link-avoidance stuff we'd discussed before >> (don't decapsulate from ingress RBx unless you have RBx's LSP >> and all pseudonodes that RBx claims to be attached to, and >> can verify that none of them have the same root bridge ID as >> the link you are about to decapsulate onto -- also, be >> conservative about when you start encapsulting data off the >> link by waiting a few Hello intervals, and waiting until >> you've synchornized LSP databases with your neighbors). >> >> g) IS-IS Hellos list the set of neighbors from which Hellos are heard. >> Once the DRB RB1 specifies "V" as the VLAN, the only >> neighbors listed in IS-IS Hellos are those from which a Hello >> is received on VLAN V. >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> From anoop at brocade.com Mon Nov 5 17:17:28 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 5 Nov 2007 17:17:28 -0800 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <472FC00D.90809@sun.com> References: <472F9EAD.2040600@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B27B6@HQ-EXCH-5.corp.brocade.com> <472FC00D.90809@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E9B2813@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Monday, November 05, 2007 5:15 PM > To: Anoop Ghanwani > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Preview of changes for VLANs, etc. > But...if an RBridge is configured to accept frames with any > VLAN tag, is it burdensome for it to accept Hellos on any of > those VLANs? It most certainly would be. Data frames are all processed in hardware while the hellos would have to make their way through system bus up the software stack to IS-IS. Anoop From riw at cisco.com Mon Nov 5 17:53:30 2007 From: riw at cisco.com (Russ White) Date: Mon, 05 Nov 2007 20:53:30 -0500 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <472F9EAD.2040600@sun.com> References: <472F9EAD.2040600@sun.com> Message-ID: <472FC91A.2070908@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Based on talking to people, here is how I'm assuming the VLAN stuff > will look. The main points are I'm a bit confused by this entire thread, and these changes.... > a) single DRB per link (rather than DRB election per VLAN). I assume this is to reduce overhead by reducing the number of hello's.... But, then we turn around and make the hellos significantly larger, and change the format significantly, and we change their processing significantly.... I don't think there's any savings here. Further, how does this look in SPF to other devices? Suppose you have one pnode per link, with multiple vlans: o Do all the devices on the link advertise themselves as connected to the pnode? How does the pnode indicate all the vlans it transits, so the SPF tree will work correctly? Does the pnode advertise one lsp per vlan? If so, then how does this one pnode per link really save anything? o What if there is no device that's actually on every vlan on the segment? Does it act as the pnode for vlans in which it doesn't participate? How do other is' build a tree in this situation--do they route through a pnode that's not on the vlan they're building a tree for? > b) that DRB can delegate to another RBridge on the link the > job of forwarding VLAN-x data to/from the link. I think this kills all thoughts of load sharing through any sort of multiaccess medium. You'll still be able to load share on point-to-point links, but not across Ethernet, for instance.... Is that an acceptable tradeoff? What if an rbridge sends some traffic to the only path on which it can send traffic for a specific vlan, and the exit point finds the only path it has is through the rbridge that just sent it the traffic? How do we resolve this? Do we need ICMP redirects for TRILL? > c) RBridges MAY be configured to send Hellos on a set of VLANs, > though VLAN 1 is the default. They are also configured with a single > preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other RBridges > on the link to send ALL RBridge-Rbridge traffic (Hellos, LSPs, > forwarded encapsulated data traffic) with outer VLAN tag "V". Doesn't this concept of a single "management" vlan on any given link destroy the ability to see what's going on on a specific vlan throughout a network? IE, if I want to look at the neighbor adjacencies for vlan x, I must look at debugs for vlan y, because the hellos are only sent on vlan y. I find this confusing--it will probably contribute to many hours of lost network time as engineers try to figure out what "vlan v" is so they can see what's actually going on. > d) For safety, the DRB RB1 continues to send Hellos not only on V, > but on all the VLANs that RB1 is configured to send Hellos on. Which kills off any advantages from not sending all those hellos and doing dis election on all those vlans, doesn't it? > f) We use all the link-avoidance stuff we'd discussed before (don't > decapsulate from ingress RBx unless you have RBx's LSP and all pseudonodes > that RBx claims to be attached to, and can verify that none of them > have the same root bridge ID as the link you are about to decapsulate > onto -- also, be conservative about when you start encapsulting data > off the link by waiting a few Hello intervals, and waiting until > you've synchornized LSP databases with your neighbors). This is a lot of complex stuff at layer 2.... Are current chipsets going to be able to handle all of this? Or have we abandoned the idea of minor or no modifications in hardware? > g) IS-IS Hellos list the set of neighbors from which Hellos are heard. > Once the DRB RB1 specifies "V" as the VLAN, the only neighbors listed > in IS-IS Hellos are those from which a Hello is received on VLAN V. What if someone's not configured to run on vlan v? What if a box has a limited number of vlans it can support, and already has that number of vlans configured? There will probably be an upper limit on support on any given box, after all, so this is always a possibility as we get into the virtualization that rbridges will open up as possibilities. Finally, I see a lot of stuff about welding together vlans with the same id no matter where they are in the network. I consider this to be a huge "surprise" problem, at the least, and extremely dangerous, at the worst.... Just because two vlans are configured with the same id does not mean they were intended to be in the same broadcast domain. So, can someone explain why we are doing all of this work, changing fundamental principles of IS-IS, changing SPF operation, etc.? :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHL8kaER27sUhU9OQRAjcEAKCFZEHG7u6OzBc8ysqc6h5u7IQMIACg9tCG RBP6jhPZ0HtaYae+XAYg+5A= =J+a1 -----END PGP SIGNATURE----- From Radia.Perlman at sun.com Mon Nov 5 19:48:53 2007 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Mon, 05 Nov 2007 19:48:53 -0800 Subject: [rbridge] Preview of changes for VLANs, etc. Message-ID: <489af9d376b9.472f73a5@sunlabs.com> Russ, The way to look at it is that the VLAN tag with which RBridges talk to each other on one link is irrelevant outside the link. So really...one pseudonode, and one VLAN per link for interRBridge communication is a simplification. Really. Though I'm not surprised if my sketch of a design might have not been self-explanatory. Let me try to explain a bit more, and from an IS-IS point of view. If this isn't clear, or if you still have concerns, then we (you and I) can have a quick phone call (are you available tomorrow afternoon?), or you can wait until you see the details in the spec. Or you can ask another question on the list. a) all RBridges on a link can talk to each other using a single (outer) VLAN tag, and that VLAN is not allowed to be partitioned. If it is, whichever RBridges can't talk to the DRB on that VLAN are just orphaned. All the other RBridges send IS-IS messages (Hellos, LSPs, CSNPs) on that link tagged with the one VLAN tag. b) All RBridge-RBridge links can be used as transit for data that belongs on any VLAN. So a data packet from VLAN x on one link destined to VLAN x on some other link in the campus can transit any RBridge-RBridge link (say from R2 to R3) regardless of what VLAN tag R2 has to slap on the outside of the frame in order to carry the frame from R2 to R3. c) the only time VLANs are relevant, in terms of IS-IS forwarding, is when pruning multicast (you don't have to send down a branch if none of the links at the end of that branch support that VLAN. But for sending unicast...you are sending to the specified egress RBridge. The forwarding RBridge does not care at all what the inner VLAN is. It also doesn't care what VLAN tag R3 has to tack on in order to forward it across the next hop to R4. e) A LAN will have a single DRB. A single pseudonode. No VLANs or endnodes are associated with the pseudonode. Endnodes and VLANs are only associated with RBridges. If R1 is DRB for pseudonode R1.25, then R1.25's LSP only lists the other RBridges attached to R1.25. Whatever RBridge R2 is appointed by R1 to forward VLAN x traffic to/from pseudonode R1.25 will specify in R2's LSP, "I, R2, am attached to VLAN x". R2 might even have lots of links attached to VLAN x. But R2 just says in R2's LSP "I am attached to VLAN x". f) Hellos shouldn't have to be bigger with this proposal. What's in a Hello? . my ID . my priority for becoming DRB . name of the pseudonode if I am DRB . VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB . set of neighbors I've heard Hellos from on the specified VLAN tag (V) . flag "please send CSNP" used when starting up, to ensure that you have synchronized LSP databases with your neighbors Now there might also be the following in the Hello: . "Bidding for VLANs": If I'm not DRB, set of (priority, {set of VLAN tags}) that I would like to be assigned to en/decapsulate for . "VLAN assignments" If I am DRB, en/decapsulator assignments, of the form (RBridge neighbor ID, {set of VLANs}) that I want that RBridge to encapsulate/decapsulate for. I think we could come up with reasonably compact encodings for those. Though they don't really have to be in the Hello. Instead, especially the "bidding" part could be in a separate message to the DRB. I like having the DRB specify assignments in its Hello, though, to ensure there is no confusion. I'd think that 99% of the time there would be no assignments, and the DRB itself would be the encapsulator/decapsulator for all VLANs on that link. Hope that's clearer... Radia ----- Original Message ----- From: Russ White Date: Monday, November 5, 2007 5:53 pm Subject: Re: [rbridge] Preview of changes for VLANs, etc. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Based on talking to people, here is how I'm assuming the VLAN stuff > > will look. The main points are > > I'm a bit confused by this entire thread, and these changes.... > > > a) single DRB per link (rather than DRB election per VLAN). > > I assume this is to reduce overhead by reducing the number of > hello's.... But, then we turn around and make the hellos significantly > larger, and change the format significantly, and we change their > processing significantly.... I don't think there's any savings here. > > Further, how does this look in SPF to other devices? Suppose you have > one pnode per link, with multiple vlans: > > o Do all the devices on the link advertise themselves as connected to > the pnode? How does the pnode indicate all the vlans it transits, > so the > SPF tree will work correctly? Does the pnode advertise one lsp per > vlan?If so, then how does this one pnode per link really save > anything? > o What if there is no device that's actually on every vlan on the > segment? Does it act as the pnode for vlans in which it doesn't > participate? How do other is' build a tree in this situation--do they > route through a pnode that's not on the vlan they're building a > tree for? > > > b) that DRB can delegate to another RBridge on the link the > > job of forwarding VLAN-x data to/from the link. > > I think this kills all thoughts of load sharing through any sort of > multiaccess medium. You'll still be able to load share on point-to- > pointlinks, but not across Ethernet, for instance.... Is that an > acceptabletradeoff? > > What if an rbridge sends some traffic to the only path on which it can > send traffic for a specific vlan, and the exit point finds the only > pathit has is through the rbridge that just sent it the traffic? > How do we > resolve this? Do we need ICMP redirects for TRILL? > > > c) RBridges MAY be configured to send Hellos on a set of VLANs, > > though VLAN 1 is the default. They are also configured with a single > > preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other > RBridges> on the link to send ALL RBridge-Rbridge traffic (Hellos, > LSPs,> forwarded encapsulated data traffic) with outer VLAN tag "V". > > Doesn't this concept of a single "management" vlan on any given link > destroy the ability to see what's going on on a specific vlan > throughouta network? IE, if I want to look at the neighbor > adjacencies for vlan x, > I must look at debugs for vlan y, because the hellos are only sent on > vlan y. I find this confusing--it will probably contribute to many > hoursof lost network time as engineers try to figure out what "vlan > v" is so > they can see what's actually going on. > > > d) For safety, the DRB RB1 continues to send Hellos not only on V, > > but on all the VLANs that RB1 is configured to send Hellos on. > > Which kills off any advantages from not sending all those hellos and > doing dis election on all those vlans, doesn't it? > > > f) We use all the link-avoidance stuff we'd discussed before (don't > > decapsulate from ingress RBx unless you have RBx's LSP and all > pseudonodes> that RBx claims to be attached to, and can verify that > none of them > > have the same root bridge ID as the link you are about to > decapsulate> onto -- also, be conservative about when you start > encapsulting data > > off the link by waiting a few Hello intervals, and waiting until > > you've synchornized LSP databases with your neighbors). > > This is a lot of complex stuff at layer 2.... Are current chipsets > goingto be able to handle all of this? Or have we abandoned the > idea of minor > or no modifications in hardware? > > > g) IS-IS Hellos list the set of neighbors from which Hellos are > heard.> Once the DRB RB1 specifies "V" as the VLAN, the only > neighbors listed > > in IS-IS Hellos are those from which a Hello is received on VLAN V. > > What if someone's not configured to run on vlan v? What if a box > has a > limited number of vlans it can support, and already has that number of > vlans configured? There will probably be an upper limit on support on > any given box, after all, so this is always a possibility as we get > intothe virtualization that rbridges will open up as possibilities. > > Finally, I see a lot of stuff about welding together vlans with the > sameid no matter where they are in the network. I consider this to > be a huge > "surprise" problem, at the least, and extremely dangerous, at the > worst.... Just because two vlans are configured with the same id does > not mean they were intended to be in the same broadcast domain. > > So, can someone explain why we are doing all of this work, changing > fundamental principles of IS-IS, changing SPF operation, etc.? > > :-) > > Russ > > - -- > riw at cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHL8kaER27sUhU9OQRAjcEAKCFZEHG7u6OzBc8ysqc6h5u7IQMIACg9tCG > RBP6jhPZ0HtaYae+XAYg+5A= > =J+a1 > -----END PGP SIGNATURE----- > From Radia.Perlman at sun.com Mon Nov 5 22:10:39 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 05 Nov 2007 22:10:39 -0800 Subject: [rbridge] Can we ever have pt-to-pt links? Message-ID: <4730055F.3000507@sun.com> Suppose the topology consisted only of RBridges with pt-to-pt links either to each other or to endnodes, e.g., no bridges, no CSMA/CD. As specified, we'd wind up creating a pseudonode for each link. Not a total disaster, but it does seem suboptimal, especially if we created a pseudonode for every port that contains an endnode. I think we discussed this and said that there was no way of knowing for sure that a port was a pt-to-pt link. Do we want to try to optimize this case, for instance by: a) allowing a port to be configured as "pt-to-pt", and freaking out (as in disabling the port and declaring an error) if an RBridge sees multiple nodes on that port, or sees a BPDU? b) assuming if there is only one RBridge neighbors on a port that it is a pt-to-pt link and there does not need to be a pseudonode? That makes me nervous because if a third RBridge comes and goes, then things could get messy. c) if there are zero RBridge neighbors on a port (just an endnode or set of endnodes), do not create a pseudonode for it d) something else? Or is it fine as is (if R1 and R2 are connected with a pt-to-pt link, R1 will get elected DRB, name the link R1.x, and issue two LSPs -- one for R1, one for R1.x, with R1.x claiming connectivity to R1 and R2). Basically, there will be a pseudonode for every RBridge-RBridge link. I hope we don't have to create a pseudonode for every port to every endnode. Radia From anoop at brocade.com Mon Nov 5 22:26:14 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 5 Nov 2007 22:26:14 -0800 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <4730055F.3000507@sun.com> References: <4730055F.3000507@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E9B2873@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, November 05, 2007 10:11 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Can we ever have pt-to-pt links? > > Suppose the topology consisted only of RBridges with pt-to-pt > links either to each other or to endnodes, e.g., no bridges, > no CSMA/CD. As specified, we'd wind up creating a pseudonode > for each link. Not a total disaster, but it does seem > suboptimal, especially if we created a pseudonode for every > port that contains an endnode. > > I think we discussed this and said that there was no way of > knowing for sure that a port was a pt-to-pt link. If you were using LLDP, you could be certain that the link is a point to point link if the system information in LLDP matches what you receive in the IS-IS hello. Or you we could identify RBridges as a type of device in LLDP itself. > Do we want to try to optimize this case, for instance by: I think it would be useful to optimize. > a) allowing a port to be configured as "pt-to-pt", and > freaking out (as in disabling the port and declaring an > error) if an RBridge sees multiple nodes on that port, or sees a BPDU? > b) assuming if there is only one RBridge neighbors on a port > that it is a pt-to-pt link and there does not need to be a > pseudonode? That makes me nervous because if a third RBridge > comes and goes, then things could get messy. > c) if there are zero RBridge neighbors on a port (just an > endnode or set of endnodes), do not create a pseudonode for it > d) something else? Is a combination of (a) and (b) possible? A node can either use LLDP to discover it is point to point (and that won't change as long as the link stays up), or it can be manually configured (in which case if a third adjacency is discovered, then you switch to broadcast-media mode and once in broadcast-media mode you never switch back). > Or is it fine as is (if R1 and R2 are connected with a > pt-to-pt link, R1 will get elected DRB, name the link R1.x, > and issue two LSPs -- one for R1, one for R1.x, with R1.x > claiming connectivity to R1 and R2). Basically, there will be > a pseudonode for every RBridge-RBridge link. I hope we don't > have to create a pseudonode for every port to every endnode. > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Mon Nov 5 22:54:44 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 05 Nov 2007 22:54:44 -0800 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com> References: <4730055F.3000507@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com> Message-ID: <47300FB4.707@sun.com> Hmm. I don't know what LLDP is, but here is a proposal. Observation: It's actually OK to consider a link with n RBridges to be n*2 pt-to-pt links as long as n isn't very large. So here's a proposal: The Designated RBridge, R1, gets to decide if a particular link is to have a pseudonode or not. R1 specifies either a pseudonode name in its Hello, or some value (like 0) that says "Hey, I don't want to bother with a pseudonode, so just report all your RBridge neighbors as pt-to-pt links". So if there is a link with R1, R2, R3, and R4, then R1 gets to decide whether to a) create pseudonode R1.x, and R1, R2, R3, and R4 all claim just the neighbor R1.x, and R1.x claims neighbors R1, R2, R3, and R4, or b) don't create a pseudonode, so R1 claims neighbors R2, R3, and R4...R2 claims neighbors R1, R3, and R4, etc. The only thing special we were doing with the pseudonode was reporting the bridge root. So that means that R1, the DRB, would report the root bridge ID in its LSP if R1 has decided not to create a pseudonode. We could declare some threshold, like 4 RBridges, and if R1 is DRB and there are every 3 RBridge neighbors on a port, then R1 declares a pseudonode, and perhaps leaves the pseudonode even if one of the neighbors goes down. Maybe once a port is a pseudonode, it stays a pseudonode. That way R1 would definitely not create pseudonodes for ports with just endnodes, or for ports that are just pt-to-pt links. The default would be "no pseudonode", but once a port had 3 RBridge neighbors, R1 decides that port should have a pseudonode. Radia Anoop Ghanwani wrote: > > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >> Sent: Monday, November 05, 2007 10:11 PM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] Can we ever have pt-to-pt links? >> >> Suppose the topology consisted only of RBridges with pt-to-pt >> links either to each other or to endnodes, e.g., no bridges, >> no CSMA/CD. As specified, we'd wind up creating a pseudonode >> for each link. Not a total disaster, but it does seem >> suboptimal, especially if we created a pseudonode for every >> port that contains an endnode. >> >> I think we discussed this and said that there was no way of >> knowing for sure that a port was a pt-to-pt link. >> > > If you were using LLDP, you could be certain that the link > is a point to point link if the system information in LLDP > matches what you receive in the IS-IS hello. Or you we could > identify RBridges as a type of device in LLDP itself. > > >> Do we want to try to optimize this case, for instance by: >> > > I think it would be useful to optimize. > > >> a) allowing a port to be configured as "pt-to-pt", and >> freaking out (as in disabling the port and declaring an >> error) if an RBridge sees multiple nodes on that port, or sees a BPDU? >> b) assuming if there is only one RBridge neighbors on a port >> that it is a pt-to-pt link and there does not need to be a >> pseudonode? That makes me nervous because if a third RBridge >> comes and goes, then things could get messy. >> c) if there are zero RBridge neighbors on a port (just an >> endnode or set of endnodes), do not create a pseudonode for it >> d) something else? >> > > Is a combination of (a) and (b) possible? A node can > either use LLDP to discover it is point to point (and > that won't change as long as the link stays up), or > it can be manually configured (in which case if a third > adjacency is discovered, then you switch to broadcast-media > mode and once in broadcast-media mode you never switch > back). > > >> Or is it fine as is (if R1 and R2 are connected with a >> pt-to-pt link, R1 will get elected DRB, name the link R1.x, >> and issue two LSPs -- one for R1, one for R1.x, with R1.x >> claiming connectivity to R1 and R2). Basically, there will be >> a pseudonode for every RBridge-RBridge link. I hope we don't >> have to create a pseudonode for every port to every endnode. >> >> Radia >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> From Radia.Perlman at sun.com Mon Nov 5 23:11:52 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 05 Nov 2007 23:11:52 -0800 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <47300FB4.707@sun.com> References: <4730055F.3000507@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com> <47300FB4.707@sun.com> Message-ID: <473013B8.7040805@sun.com> Radia Perlman wrote: > > The only thing special we were doing with the pseudonode was reporting > the bridge root. > So that means that R1, the DRB, would report the root bridge ID in its > LSP if > R1 has decided not to create a pseudonode. > Actually, let me change that to: "Let's always report the root bridge ID in the DRB's LSP, not the pseudonode LSP" So I'm getting more comfortable with that proposal -- the DRB only declares a pseudonode if there really are too many neighbors, and switching over from non-pseudonode to pseudnode is really not very disruptive. Radia From riw at cisco.com Tue Nov 6 06:33:20 2007 From: riw at cisco.com (Russ White) Date: Tue, 06 Nov 2007 09:33:20 -0500 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <489af9d376b9.472f73a5@sunlabs.com> References: <489af9d376b9.472f73a5@sunlabs.com> Message-ID: <47307B30.307@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > a) all RBridges on a link can talk to each other using a single (outer) VLAN tag, and > that VLAN is not allowed to be partitioned. If it is, whichever RBridges can't talk > to the DRB on that VLAN are just orphaned. All the other RBridges send IS-IS > messages (Hellos, LSPs, CSNPs) on that link tagged with the one VLAN tag. Why have this vlan tag at all? If the traffic for any given vlan is tunneled to the outer edge using the direct layer 2 address of the exit rbridge, then the "outer" vlan tag is an unnecessary complication. The simpler rule would be the only traffic on link which should have a vlan tag will be that originating from a non-rbridge device. Once traffic hits the first rbridge, there should never be an "outer" vlan tag, just the destination address in the outer tunnel header. All the other stuff you talk about seems to be much easier without this outer header--the way IS-IS runs, the DIS election on each link, forwarding, etc. > f) Hellos shouldn't have to be bigger with this proposal. What's in a Hello? > . my ID > . my priority for becoming DRB > . name of the pseudonode if I am DRB > . VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB > . set of neighbors I've heard Hellos from on the specified > VLAN tag (V) > . flag "please send CSNP" used when starting up, to ensure that > you have synchronized LSP databases with your neighbors > > Now there might also be the following in the Hello: > . "Bidding for VLANs": If I'm not DRB, set of (priority, {set of VLAN tags}) that I would like > to be assigned to en/decapsulate for This does make the hello larger. Probably much larger.... > . "VLAN assignments" If I am DRB, en/decapsulator assignments, of the form > (RBridge neighbor ID, {set of VLANs}) that I want that RBridge > to encapsulate/decapsulate for. I don't understand why we need this.... I don't think you're really going to have a case where a single interface on the user side "services" multiple vlans, which are generally separated at the edge through virtual interfaces on the box. IE, if I receive a packet on interface ethernet 1.1, then it's vlan x, if it's on ethernet 1.2, then it's vlan y. There's no reason not to stick with this convention--the chipsets already know how to separate things this way, I think. IE, forwarding would look like this: 1. Receive packet on interface X. 2. Check to see if there's a 1q header. 3. If so, then look up appropriate edge destination, encap in a tunnel, and resend. 3. If not, then find correct vlan, look up appropriate edge destination, place vlan header on packet, encap in tunnel, and resend. On the receiving side, you just strip off mac headers and process them normally. There's no need for special processing of any type, is there? I don't see anything about the "merging" vlans automatically.... I don't think this should be done, in any case. :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMHswER27sUhU9OQRAkk+AKDf3LMTQCXPCL3Z7vNy5mmZT9c7bgCfbldB RYbmkapg1cE1sSlsgQNVneQ= =1x27 -----END PGP SIGNATURE----- From riw at cisco.com Tue Nov 6 06:35:32 2007 From: riw at cisco.com (Russ White) Date: Tue, 06 Nov 2007 09:35:32 -0500 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <473013B8.7040805@sun.com> References: <4730055F.3000507@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com> <47300FB4.707@sun.com> <473013B8.7040805@sun.com> Message-ID: <47307BB4.60206@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> The only thing special we were doing with the pseudonode was reporting >> the bridge root. >> So that means that R1, the DRB, would report the root bridge ID in its >> LSP if >> R1 has decided not to create a pseudonode. >> > Actually, let me change that to: "Let's always report the root bridge ID > in the DRB's > LSP, not the pseudonode LSP" > > So I'm getting more comfortable with that proposal -- the DRB only > declares a pseudonode > if there really are too many neighbors, and switching over from > non-pseudonode to > pseudnode is really not very disruptive. In most implementations of IS-IS, there is a way to manually configured a link as point-to-point, no matter what the layer 2 part of the device thinks it is. The IS-IS WG pretty much eschewed auto-detection schemes when we went through this exercise. :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMHu0ER27sUhU9OQRAgyEAKC3ic9tS1kROaWxVSWuwnrr2HUh9gCeJJss wNbLsz14yV/oQ3FCO6Xh2Pg= =vYAd -----END PGP SIGNATURE----- From eric.gray at ericsson.com Tue Nov 6 07:39:03 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 6 Nov 2007 09:39:03 -0600 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <4730055F.3000507@sun.com> References: <4730055F.3000507@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01E7BCDD@eusrcmw721.eamcs.ericsson.se> Radia, The usual approach to specifying the (optimized) behavior you describe would be to say something like: "An implementation MAY be aware that a specific link is point-to- point, in which case MAY be omitted." However, it is worth realizing that this relies on a common view at both ends of the point-to-point link. What happens if one end tries to perform a DRB election and the other does not? It then becomes necessary to specify the behavior in this case. I suspect that - if one has valid reasons to think that a link is point-to-point - one might configure both ends to assume this is the case. In the event that any RBridge on the link tries to do DRB election, then this MUST become the common mode. Using that approach, the only failure mode where RBridges will become confused is if three (or more) RBridges are 1) connected to the same shared media and 2) configured to assume P2P. Clever implementations MAY deal with that scenario in some robust way - but we should not need to specify how that may be done (it is always possible to misconfigure yourself into a hole, so there is little point in trying to prevent that). -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, November 06, 2007 1:11 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Can we ever have pt-to-pt links? > > Suppose the topology consisted only of RBridges with pt-to-pt links > either to each other or > to endnodes, e.g., no bridges, no CSMA/CD. As specified, > we'd wind up > creating > a pseudonode for each link. Not a total disaster, but it does seem > suboptimal, especially > if we created a pseudonode for every port that contains an endnode. > > I think we discussed this and said that there was no way of > knowing for > sure that a port > was a pt-to-pt link. > > Do we want to try to optimize this case, for instance by: > a) allowing a port to be configured as "pt-to-pt", and > freaking out (as > in disabling > the port and declaring an error) if an RBridge sees multiple nodes on > that port, or sees > a BPDU? > b) assuming if there is only one RBridge neighbors on a port > that it is > a pt-to-pt > link and there does not need to be a pseudonode? That makes > me nervous > because if > a third RBridge comes and goes, then things could get messy. > c) if there are zero RBridge neighbors on a port (just an endnode or > set of endnodes), do not create a pseudonode > for it > d) something else? > > Or is it fine as is (if R1 and R2 are connected with a > pt-to-pt link, R1 > will get elected DRB, > name the link R1.x, and issue two LSPs -- one for R1, one for > R1.x, with > R1.x claiming > connectivity to R1 and R2). Basically, there will be a pseudonode for > every RBridge-RBridge > link. I hope we don't have to create a pseudonode for every port to > every endnode. > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Tue Nov 6 07:49:18 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 6 Nov 2007 09:49:18 -0600 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <47307B30.307@cisco.com> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se> Russ, I think you have made a very valid point, here. I would like to qualify it somewhat by saying that we should specify this as the default behavior - for the exact reason you state - but without explicitly forbidding the use of a VLAN tag in the link-level encapsulation required to get a frame from one RBridge to another. It's important to remember that VLAN tags may be used to "virtualize" a LAN (link) and it may be the case that a VID is mandated for some other reason. Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White > Sent: Tuesday, November 06, 2007 9:33 AM > To: Radia.Perlman at sun.com > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Preview of changes for VLANs, etc. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > a) all RBridges on a link can talk to each other using a > single (outer) VLAN tag, and > > that VLAN is not allowed to be partitioned. If it is, > whichever RBridges can't talk > > to the DRB on that VLAN are just orphaned. All the other > RBridges send IS-IS > > messages (Hellos, LSPs, CSNPs) on that link tagged with the > one VLAN tag. > > Why have this vlan tag at all? If the traffic for any given vlan is > tunneled to the outer edge using the direct layer 2 address > of the exit > rbridge, then the "outer" vlan tag is an unnecessary complication. The > simpler rule would be the only traffic on link which should > have a vlan > tag will be that originating from a non-rbridge device. Once traffic > hits the first rbridge, there should never be an "outer" vlan > tag, just > the destination address in the outer tunnel header. > > All the other stuff you talk about seems to be much easier > without this > outer header--the way IS-IS runs, the DIS election on each link, > forwarding, etc. > > > f) Hellos shouldn't have to be bigger with this proposal. > What's in a Hello? > > . my ID > > . my priority for becoming DRB > > . name of the pseudonode if I am DRB > > . VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB > > . set of neighbors I've heard Hellos from on the specified > > VLAN tag (V) > > . flag "please send CSNP" used when starting up, to ensure that > > you have synchronized LSP databases with your neighbors > > > > Now there might also be the following in the Hello: > > . "Bidding for VLANs": If I'm not DRB, set of (priority, > {set of VLAN tags}) that I would like > > to be assigned to en/decapsulate for > > This does make the hello larger. Probably much larger.... > > > . "VLAN assignments" If I am DRB, en/decapsulator > assignments, of the form > > (RBridge neighbor ID, {set of VLANs}) that I want that RBridge > > to encapsulate/decapsulate for. > > I don't understand why we need this.... I don't think you're really > going to have a case where a single interface on the user side > "services" multiple vlans, which are generally separated at the edge > through virtual interfaces on the box. IE, if I receive a packet on > interface ethernet 1.1, then it's vlan x, if it's on ethernet > 1.2, then > it's vlan y. There's no reason not to stick with this convention--the > chipsets already know how to separate things this way, I think. > > IE, forwarding would look like this: > > 1. Receive packet on interface X. > 2. Check to see if there's a 1q header. > 3. If so, then look up appropriate edge destination, encap in > a tunnel, > and resend. > 3. If not, then find correct vlan, look up appropriate edge > destination, > place vlan header on packet, encap in tunnel, and resend. > > On the receiving side, you just strip off mac headers and process them > normally. There's no need for special processing of any type, > is there? > > I don't see anything about the "merging" vlans > automatically.... I don't > think this should be done, in any case. > > :-) > > Russ > > - -- > riw at cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHMHswER27sUhU9OQRAkk+AKDf3LMTQCXPCL3Z7vNy5mmZT9c7bgCfbldB > RYbmkapg1cE1sSlsgQNVneQ= > =1x27 > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From riw at cisco.com Tue Nov 6 08:17:36 2007 From: riw at cisco.com (Russ White) Date: Tue, 06 Nov 2007 11:17:36 -0500 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se> Message-ID: <473093A0.6030708@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > - but without explicitly forbidding the use of a VLAN tag in > the link-level encapsulation required to get a frame from one > RBridge to another. Sure--If the only way to reach the next hop is through a vlan, then you would need to encap in that vlan to get to the next hop. I think the cleanest way to do this is: 1. Receive packet. 2. Look up exit rbridge. 3. Find next hop to the exit. 4. Look at the outbound interface towards this next hop. 5. If the outbound interface is a 1q interface (logical, rather than physical), then encap with the inside vlan stuff, then the tunnel header, then put it in another tunnel header, with the destination address being the next hop, and the vlan stuff being the correct one to reach that next hop. 6. If the outbound interface is not a 1q interface (physical, rather than logical), then encap with the vlan stuff, then the tunnel header for the outer edge rbridge (egress rbridge), and forward it. When the next hop receives the packet in the case of #5, it will see the packet is to it, strip the outer header, and then see the inner tunnel, and forward the packet according to local rules, based on it's tree, etc. I think this is much simpler than having a "set" vlan on any given link, or having to carry around a set of vlans you forward for, and such. :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9 RfgcEqMnZgWPpnAh+RRwy0k= =//s3 -----END PGP SIGNATURE----- From Radia.Perlman at sun.com Tue Nov 6 09:34:55 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 06 Nov 2007 09:34:55 -0800 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <473093A0.6030708@cisco.com> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se> <473093A0.6030708@cisco.com> Message-ID: <4730A5BF.30408@sun.com> Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, bridges on the link can be configured in weird ways such that the only way to send a packet is using a particular set of VLAN tags. Then there are other complicated issues, like finding which VLAN tag works for which neighbors. And then if you form an adjacency with each neighbor via a potentially different (set of) VLAN tags, then how would you send multicast on a link? There wouldn't be guaranteed to be a single VLAN tag that would reach everyone on the link. So the proposal is to use a single, unpartitioned VLAN tag for communication on the link, and if anyone can't talk to the DRB on that link using the VLAN tag that the DRB specifies, then they basically can't use the link. If "which VLAN number" is configurable, then we have to deal with different configurations in different RBridges, which we do by having the DRB inform all the other RBridges what VLAN tag to use. Radia Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >> - but without explicitly forbidding the use of a VLAN tag in >> the link-level encapsulation required to get a frame from one >> RBridge to another. >> > > Sure--If the only way to reach the next hop is through a vlan, then you > would need to encap in that vlan to get to the next hop. I think the > cleanest way to do this is: > > 1. Receive packet. > 2. Look up exit rbridge. > 3. Find next hop to the exit. > 4. Look at the outbound interface towards this next hop. > 5. If the outbound interface is a 1q interface (logical, rather than > physical), then encap with the inside vlan stuff, then the tunnel > header, then put it in another tunnel header, with the destination > address being the next hop, and the vlan stuff being the correct one to > reach that next hop. > 6. If the outbound interface is not a 1q interface (physical, rather > than logical), then encap with the vlan stuff, then the tunnel header > for the outer edge rbridge (egress rbridge), and forward it. > > When the next hop receives the packet in the case of #5, it will see the > packet is to it, strip the outer header, and then see the inner tunnel, > and forward the packet according to local rules, based on it's tree, > etc. I think this is much simpler than having a "set" vlan on any given > link, or having to carry around a set of vlans you forward for, and such. > > :-) > > Russ > > - -- > riw at cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9 > RfgcEqMnZgWPpnAh+RRwy0k= > =//s3 > -----END PGP SIGNATURE----- > From Radia.Perlman at sun.com Tue Nov 6 09:44:07 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 06 Nov 2007 09:44:07 -0800 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <47307BB4.60206@cisco.com> References: <4730055F.3000507@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com> <47300FB4.707@sun.com> <473013B8.7040805@sun.com> <47307BB4.60206@cisco.com> Message-ID: <4730A7E7.5030709@sun.com> I'm going to ask on the IS-IS list. Manual configuration is actually scarier (and harder) because different RBridges can be configured differently. With this proposal (the DRB switches over to pseudonode once there are, say, 3 other RBridges on the link, and perhaps stays that way forever, or until there is ever a time when there is just one (or zero) RBridge neighbors. It's not disruptive to take away the pseudonode when there are very few neighbors, since the coming or going of an RBridge neighbor would require reissuing the pseudonode LSP anyway. So if there were three guys, R1, R2, and R3, with pseudonode R1.x, then if R3 went away, and we kept the pseudonode, then the pseudonode (R1.x) would reissue its LSP saying it now had just two neighbors (R1 and R2), whereas if R1 decided to go with "no pseudonode now", then R1 would change its Hello to be "no pseudonode", and R1 and R2 would reissue their LSPs to say their only neighbor was eachother (R1 would remove R1.x as a neighbor and say it is connected to R2....similarly R2). There is no confusion about whether or not there is a pseudonode because the DRB decides. The exact algorithm for deciding doesn't have to be standardized even, though we certainly should recommend something. Radia Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>> The only thing special we were doing with the pseudonode was reporting >>> the bridge root. >>> So that means that R1, the DRB, would report the root bridge ID in its >>> LSP if >>> R1 has decided not to create a pseudonode. >>> >>> >> Actually, let me change that to: "Let's always report the root bridge ID >> in the DRB's >> LSP, not the pseudonode LSP" >> >> So I'm getting more comfortable with that proposal -- the DRB only >> declares a pseudonode >> if there really are too many neighbors, and switching over from >> non-pseudonode to >> pseudnode is really not very disruptive. >> > > In most implementations of IS-IS, there is a way to manually configured > a link as point-to-point, no matter what the layer 2 part of the device > thinks it is. The IS-IS WG pretty much eschewed auto-detection schemes > when we went through this exercise. > > :-) > > Russ > > - -- > riw at cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHMHu0ER27sUhU9OQRAgyEAKC3ic9tS1kROaWxVSWuwnrr2HUh9gCeJJss > wNbLsz14yV/oQ3FCO6Xh2Pg= > =vYAd > -----END PGP SIGNATURE----- > From Radia.Perlman at sun.com Tue Nov 6 11:07:37 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 06 Nov 2007 11:07:37 -0800 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <4730A7E7.5030709@sun.com> References: <4730055F.3000507@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com> <47300FB4.707@sun.com> <473013B8.7040805@sun.com> <47307BB4.60206@cisco.com> <4730A7E7.5030709@sun.com> Message-ID: <4730BB79.4090309@sun.com> FYI: This is the proposal I'm running by the IS-IS list. Summary: DRB chooses whether or not to create a pseudonode on the port, and tells the other RBridges whether to claim pt-to-pt links to the other RBridges on the link, or attachment to a pseudonode. Algorithm: if R1 has zero or one RBridge neighbor, no pseudonode. If R1 has 4 or more RBridge neighbors, R1 creates pseudonode for the port. If R1 has 2 o3 3 RBridge neighbors, R1 leaves the state of the link (pseudonode or not) alone. ********************************** a) perform normal DR election. If R1 is the only router, R1 is the DR. Assuming there are other routers on the link, say R1, R2, R3, and R4, let's say R1 is the DR. b) R1 (DR) is the one that decides on behalf of the link whether there will be a pseudonode or not. R1 has some algorithm for deciding if there should be a pseudonode. In R1's Hello it says "the name of the pseudonode is R1.x", which means that there will be a pseudonode. The other routers issue LSPs claiming to be connected to R1.x. However....if R1 decides not to have a pseudonode, then R1's Hello says "the name of the pseudonode is 0" in which case any routers on the link claim the other routers on the link as direct neighbors. c) a reasonable strategy for DR R1 to decide when to have a pseudonode: If R1 has zero or one router neighbors on the link, R1 puts the link into "no pseudonode" mode. If R1 has at least 4 router neighbors, R1 puts the link into "pseudonode" mode. If R1 has 2 or 3 router neighbors, R1 does not change the state of the link. (so 3 router neighbors have to come up or go down before R1 switches the link between pseudonode vs no pseudonode). d) if you aren't DR, then you do as you are told. I believe this proposal is 1) zero configuration 2) safe 3) simple 4) not disruptive if a router is going up and down 5) no danger of confusion 6) much more efficient than creating a pseudonode for every port From eric.gray at ericsson.com Tue Nov 6 11:51:42 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 6 Nov 2007 13:51:42 -0600 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <4730A7E7.5030709@sun.com> References: <4730055F.3000507@sun.com><4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com><47300FB4.707@sun.com> <473013B8.7040805@sun.com><47307BB4.60206@cisco.com> <4730A7E7.5030709@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01E7C16D@eusrcmw721.eamcs.ericsson.se> Radia, I think taking this to the IS-IS mailing list is a great idea. I'd hate to think we were trying to "fix" something to do with IS-IS generally, in this working group. However, as a general observation, the argument that putting complexity into protocol - to avoid some types of configuration errors - is often used, and frequently either wrong or irrelevant. As the paraphrased saying goes, people who think anything can be made proof against configuration error are under-estimating the ability, inventiveness and - possibly - evil intentions of the person doing the configuration. Also, in many cases, it is better for a misconfigured network to not work at all, than it is to have it working in some unexpected way. In my opinion, implementers want to build equipment that behaves reasonably under misconfigured operating conditions, and that may simply mean that it doesn't fail in some spectacular way. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, November 06, 2007 12:44 PM > To: Russ White > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Can we ever have pt-to-pt links? > > I'm going to ask on the IS-IS list. Manual configuration is actually > scarier (and harder) because different RBridges can be configured > differently. With this proposal (the DRB switches over to pseudonode > once there are, say, 3 other RBridges on the link, and perhaps stays > that way forever, or until there is ever a time when there is just > one (or zero) RBridge neighbors. > > It's not disruptive to take away the pseudonode when there are very > few neighbors, since the coming or going of an RBridge neighbor would > require reissuing the pseudonode LSP anyway. So if there were three > guys, R1, R2, and R3, with pseudonode R1.x, then if R3 went away, and > we kept the pseudonode, then the pseudonode (R1.x) would reissue its > LSP saying it now had just two neighbors (R1 and R2), whereas if R1 > decided to go with "no pseudonode now", then R1 would change its > Hello to be "no pseudonode", and R1 and R2 would reissue their LSPs > to say their only neighbor was each other (R1 would remove R1.x as a > neighbor and say it is connected to R2....similarly R2). > > There is no confusion about whether or not there is a pseudonode > because the DRB decides. > > The exact algorithm for deciding doesn't have to be standardized even, > though we certainly should recommend something. > > Radia > > > > > Russ White wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > >>> The only thing special we were doing with the pseudonode > was reporting > >>> the bridge root. > >>> So that means that R1, the DRB, would report the root > bridge ID in its > >>> LSP if > >>> R1 has decided not to create a pseudonode. > >>> > >>> > >> Actually, let me change that to: "Let's always report the > root bridge ID > >> in the DRB's > >> LSP, not the pseudonode LSP" > >> > >> So I'm getting more comfortable with that proposal -- the DRB only > >> declares a pseudonode > >> if there really are too many neighbors, and switching over from > >> non-pseudonode to > >> pseudnode is really not very disruptive. > >> > > > > In most implementations of IS-IS, there is a way to > manually configured > > a link as point-to-point, no matter what the layer 2 part > of the device > > thinks it is. The IS-IS WG pretty much eschewed > auto-detection schemes > > when we went through this exercise. > > > > :-) > > > > Russ > > > > - -- > > riw at cisco.com CCIE <>< Grace Alone > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFHMHu0ER27sUhU9OQRAgyEAKC3ic9tS1kROaWxVSWuwnrr2HUh9gCeJJss > > wNbLsz14yV/oQ3FCO6Xh2Pg= > > =vYAd > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From riw at cisco.com Tue Nov 6 12:14:40 2007 From: riw at cisco.com (Russ White) Date: Tue, 06 Nov 2007 15:14:40 -0500 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <4730A5BF.30408@sun.com> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se> <473093A0.6030708@cisco.com> <4730A5BF.30408@sun.com> Message-ID: <4730CB30.5020702@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, > bridges on the link > can be configured in weird ways such that the only way to send a packet > is using a > particular set of VLAN tags. Then there are other complicated issues, Since this is probably going to be 5% or less of the cases, we should make this capability optional, and make the 95% case the simpler case of sending with no vlan tag. The only case this really arises in is when you have hosts on links with through traffic, which any good network designer avoids like the plague. I'd rather not make this whole thing really complicated just to support a small set of networks.... :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMMswER27sUhU9OQRAsoPAJ9BLiR9MOpIeoZr7O2IZ0+Dt4wEGwCcCsSz L4dMGZWmOWwpkh+nJH2RPrY= =PgGG -----END PGP SIGNATURE----- From riw at cisco.com Tue Nov 6 12:19:43 2007 From: riw at cisco.com (Russ White) Date: Tue, 06 Nov 2007 15:19:43 -0500 Subject: [rbridge] Can we ever have pt-to-pt links? In-Reply-To: <4730A7E7.5030709@sun.com> References: <4730055F.3000507@sun.com> <4C94DE2070B172459E4F1EE14BD2364E9B2873@HQ-EXCH-5.corp.brocade.com> <47300FB4.707@sun.com> <473013B8.7040805@sun.com> <47307BB4.60206@cisco.com> <4730A7E7.5030709@sun.com> Message-ID: <4730CC5F.30302@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm going to ask on the IS-IS list. Manual configuration is actually > scarier (and harder) because different > RBridges can be configured differently. With this proposal (the DRB I'm pretty certain the worst that is going to have with two ends configured differently is that the link won't be used for transit. One end will be transmitting a pnode, but the other end won't be advertising a connection to it--instead, it will be advertising a connection to the other is on the link. This means the twcc won't work, and the tree won't build through that link. The only other possibility is that the link could be configured for p-2-p, while there are actually three devices on it. A good implementation would shut down all adj's on such a link, but that's implementation specific, though perhaps we should have suggested in the p-2-p draft.... Even if it tries to form, the twcc across the 0 cost backlinks to the pnode are going to cause the tree to fail to build through the link, I think. It might build for the pair that do build an adjacency, but the third is on the link will just be left out in everyone else's tree..... Hence, I think the manual configuration option is pretty safe.... And, the protocol can't tell if the link was intended to be a p-2-p or not. If you have a link with three is', and one fails, auto detecting the link has now become p-2-p makes everyone in the domain run SPF. If you don't do the auto-detection, they can run a partial, just slicing off the link that failed. :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMMxfER27sUhU9OQRAkiiAJ0TVIpBTMINkn8xvYm5+5njibqlywCdF+u7 27otCI2fnWz1MQXz0tAVv6o= =z9eC -----END PGP SIGNATURE----- From eric.gray at ericsson.com Tue Nov 6 12:41:43 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 6 Nov 2007 14:41:43 -0600 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <4730A5BF.30408@sun.com> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se> <473093A0.6030708@cisco.com> <4730A5BF.30408@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01E7C210@eusrcmw721.eamcs.ericsson.se> Radia, What gets us wrapped around the axle is attemtping to specify things in such a way that we have to care about the VLAN tag used in RBridge-to-RBridge forwarding. The point to using logical interfaces - or virtualization - is to hide network complexity. Trying to "unroll it" is not making it simpler. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Tuesday, November 06, 2007 12:35 PM > To: Russ White > Cc: Eric Gray; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Preview of changes for VLANs, etc. > > Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, > bridges on the link can be configured in weird ways such that the > only way to send a packet is using a particular set of VLAN tags. > Then there are other complicated issues, like finding which VLAN > tag works for which neighbors. And then if you form an adjacency > with each neighbor via a potentially different (set of) VLAN tags, > then how would you send multicast on a link? There wouldn't be > guaranteed to be a single VLAN tag that would reach everyone on > the link. > > So the proposal is to use a single, unpartitioned VLAN tag for > communication on the link, and if anyone can't talk to the DRB on > that link using the VLAN tag that the DRB specifies, then they > basically can't use the link. > > If "which VLAN number" is configurable, then we have to deal with > different configurations in different RBridges, which we do by > having the DRB inform all the other RBridges what VLAN tag to > use. > > Radia > > > Russ White wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > >> - but without explicitly forbidding the use of a VLAN tag in > >> the link-level encapsulation required to get a frame from one > >> RBridge to another. > >> > > > > Sure--If the only way to reach the next hop is through a > vlan, then you > > would need to encap in that vlan to get to the next hop. I think the > > cleanest way to do this is: > > > > 1. Receive packet. > > 2. Look up exit rbridge. > > 3. Find next hop to the exit. > > 4. Look at the outbound interface towards this next hop. > > 5. If the outbound interface is a 1q interface (logical, rather than > > physical), then encap with the inside vlan stuff, then the tunnel > > header, then put it in another tunnel header, with the destination > > address being the next hop, and the vlan stuff being the > correct one to > > reach that next hop. > > 6. If the outbound interface is not a 1q interface (physical, rather > > than logical), then encap with the vlan stuff, then the > tunnel header > > for the outer edge rbridge (egress rbridge), and forward it. > > > > When the next hop receives the packet in the case of #5, it > will see the > > packet is to it, strip the outer header, and then see the > inner tunnel, > > and forward the packet according to local rules, based on it's tree, > > etc. I think this is much simpler than having a "set" vlan > on any given > > link, or having to carry around a set of vlans you forward > for, and such. > > > > :-) > > > > Russ > > > > - -- > > riw at cisco.com CCIE <>< Grace Alone > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9 > > RfgcEqMnZgWPpnAh+RRwy0k= > > =//s3 > > -----END PGP SIGNATURE----- > > > > From Donald.Eastlake at motorola.com Tue Nov 6 13:31:22 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 6 Nov 2007 16:31:22 -0500 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <4730CB30.5020702@cisco.com> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com><941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se><473093A0.6030708@cisco.com> <4730A5BF.30408@sun.com> <4730CB30.5020702@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D9790033B0F10@de01exm64.ds.mot.com> The big problem is incremental deployment. Sure, looking at existing 802.3 bridged networks, you almost never have links with both bridges and end station on them. But with incremental deployment of Rbridges, a bridged LAN between N Rbridges will commonly look like a through link that also has end stations on it. And furthermore, it can easily be a link between these N Rbridges with odd, VLAN dependent connectivity. Some people in the working group consider the mixed bridges and Rbridges case very important. So, while I'm fine with noticing/configuring point-to-point Rbridge links and omitting the outer VLAN tag on them, since it pretty much serves no function, you want a scheme that has a reasonable chance of working if a link is a complex bridged LAN. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White Sent: Tuesday, November 06, 2007 3:15 PM To: Radia Perlman Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] Preview of changes for VLANs, etc. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, > bridges on the link > can be configured in weird ways such that the only way to send a packet > is using a > particular set of VLAN tags. Then there are other complicated issues, Since this is probably going to be 5% or less of the cases, we should make this capability optional, and make the 95% case the simpler case of sending with no vlan tag. The only case this really arises in is when you have hosts on links with through traffic, which any good network designer avoids like the plague. I'd rather not make this whole thing really complicated just to support a small set of networks.... :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMMswER27sUhU9OQRAsoPAJ9BLiR9MOpIeoZr7O2IZ0+Dt4wEGwCcCsSz L4dMGZWmOWwpkh+nJH2RPrY= =PgGG -----END PGP SIGNATURE----- _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From riw at cisco.com Tue Nov 6 13:35:56 2007 From: riw at cisco.com (Russ White) Date: Tue, 06 Nov 2007 16:35:56 -0500 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <3870C46029D1F945B1472F170D2D9790033B0F10@de01exm64.ds.mot.com> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com><941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se><473093A0.6030708@cisco.com> <4730A5BF.30408@sun.com> <4730CB30.5020702@cisco.com> <3870C46029D1F945B1472F170D2D9790033B0F10@de01exm64.ds.mot.com> Message-ID: <4730DE3C.7050002@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So, while I'm fine with noticing/configuring point-to-point > Rbridge links and omitting the outer VLAN tag on them, since it pretty > much serves no function, you want a scheme that has a reasonable chance > of working if a link is a complex bridged LAN. I'm not certain I can see where always putting an outer vlan tag on a packet will really help on a mixed bridge/rbridge link.... You would have the bridges configured with a bunch of subinterfaces, one for each vlan, and you'd configure the rbridges the same way, I think. I don't think it's useful to expect the rbridges to autodetect all the possible vlans on the link, and try to sort out what the user normally sorts out through manual configuration anyway. The only other situation is an rbridge connected to a normal bridge through a trunk port--but this would normally be a p-2-p link, so I think the rules I suggested earlier would work in this situation. :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMN48ER27sUhU9OQRAreFAKCZdYxmCdnCghiEelIXAhz8MRD74gCfS8Hg yZHFWRD1wxz5auExfZmg+uM= =WAk/ -----END PGP SIGNATURE----- From anoop at brocade.com Tue Nov 6 13:56:58 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 6 Nov 2007 13:56:58 -0800 Subject: [rbridge] Preview of changes for VLANs, etc. In-Reply-To: <4730CB30.5020702@cisco.com> References: <489af9d376b9.472f73a5@sunlabs.com> <47307B30.307@cisco.com><941D5DCD8C42014FAF70FB7424686DCF01E7BD13@eusrcmw721.eamcs.ericsson.se><473093A0.6030708@cisco.com> <4730A5BF.30408@sun.com> <4730CB30.5020702@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E9B2A06@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White > Sent: Tuesday, November 06, 2007 12:15 PM > To: Radia Perlman > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Preview of changes for VLANs, etc. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, > > bridges on the link can be configured in weird ways such > that the only > > way to send a packet is using a particular set of VLAN tags. Then > > there are other complicated issues, > > Since this is probably going to be 5% or less of the cases, > we should make this capability optional, and make the 95% > case the simpler case of sending with no vlan tag. The only > case this really arises in is when you have hosts on links > with through traffic, which any good network designer avoids > like the plague. > > I'd rather not make this whole thing really complicated just > to support a small set of networks.... It's not that simple...again back to terminology: - For ports that support only bridged traffic 802.1 defines what they should do. - For ports that support only TRILL traffic, we get to define how they operate (within some limits since we may still see link-local control traffic). - For ports that support both bridged and TRILL traffic we have to go with what 802.1 says (otherwise the traffic won't go through bridges). Thus far, all RBridge ports are assumed to be of the last type. That means the encapsulation has to follow rules defined by 802.1 - i.e. you have a set of VLANs on that port. We only transmit traffic on those VLANs. Some of those VLANs belong to the "tagged set" in which case we transmit frames for those VLANs in tagged format; other VLANs belong to the "untagged" set in which case we transmit frames without a tag. I think what we have defined so far is fine. There is no need to change it. Making it optional won't work. Even routers have to follow those rules or their packets don't make it through the LAN! Anoop From Donald.Eastlake at motorola.com Tue Nov 6 13:58:44 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 6 Nov 2007 16:58:44 -0500 Subject: [rbridge] RBridge: a case of study In-Reply-To: <18223.13230.626187.543062@gargle.gargle.HOWL> References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com><18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com><3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se><18216.36269.214404.179226@gargle.gargle.HOWL><3870C46029D1F945B1472F170D2D97900336DBEC@de01exm64.ds.mot.com> <18223.13230.626187.543062@gargle.gargle.HOWL> Message-ID: <3870C46029D1F945B1472F170D2D9790033B0F3A@de01exm64.ds.mot.com> See below at ### -----Original Message----- From: James Carlson [mailto:james.d.carlson at sun.com] Sent: Monday, November 05, 2007 10:16 AM To: Eastlake III Donald-LDE008 Cc: Developing a hybrid router/bridge. Subject: RE: [rbridge] RBridge: a case of study Eastlake III Donald-LDE008 writes: > From: James Carlson [mailto:james.d.carlson at sun.com] [...] > Eric Gray writes: [...] > > 2) all frames