From ginsberg at cisco.com Fri Feb 1 00:47:35 2008 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Fri, 1 Feb 2008 00:47:35 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A2A085.30801@sun.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> <47A23A3D.2040907@sun.com> <47A2A085.30801@sun.com> Message-ID: Radia - It seems you missed my point entirely. When I objected to your characterization of the proposal as: "I don't think it is complex. It costs 2 bits in Hellos." I was not trying to demonstrate that the problem is insolvable - just that the solution is not trivial - and requires care in both specification and implementation. This raises the bar - at least to me - in that the benefits have to be worth the cost. Obviously we differ on that value judgment. As to your questions: > a) without configuration, would an IS-IS router today create a > pseudonode if it is the only router on an Ethernet link? > For instance, suppose R1 and R2 > are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two > LSPs, one saying the pseudonode is R1.25 with neighbor R1, > and another saying R1 has neighbor R1.25? Or when R2 goes down, does R1 > get rid of the pseudonode? In order for a router to elect itself DIS on a circuit it MUST have at least one ES or IS adjacency on that circuit in the UP state. (ISO 10589:2002 Section 8.4.5) > > b) suppose R1 and R2 are both on the same Ethernet, and one is > configured that that port is pt-to-pt and the other is not configured > that way. What happens? No adjacency will be formed as the router which is configured to be Pt-Pt discards LAN IIHs it receives on that circuit. > > c) suppose R1, R2, and R3 are all on the same Ethernet, and all are > configured that that port is pt-to-pt. What happens? No more than one adjacency will be formed on each router. Received hellos whose system ID does not match an existing adjacency are discarded. See Section 4.5 of http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06. txt for further details. Les From mrthom at essex.ac.uk Fri Feb 1 01:27:51 2008 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Fri, 1 Feb 2008 09:27:51 -0000 Subject: [rbridge] Pseudonode minimization thoughts... References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> <47A23A3D.2040907@sun.com> <47A2A085.30801@sun.com> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CEADA0E@sernt14.essex.ac.uk> Hi Les, Just for comparison: In the case a.) then with OSPF, then yes it actually would issue a Psuedonode. (LSA type 2) Matthew ________________________________ From: rbridge-bounces at postel.org on behalf of Les Ginsberg (ginsberg) Sent: Fri 01/02/2008 08:47 To: Radia Perlman Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] Pseudonode minimization thoughts... Radia - It seems you missed my point entirely. When I objected to your characterization of the proposal as: "I don't think it is complex. It costs 2 bits in Hellos." I was not trying to demonstrate that the problem is insolvable - just that the solution is not trivial - and requires care in both specification and implementation. This raises the bar - at least to me - in that the benefits have to be worth the cost. Obviously we differ on that value judgment. As to your questions: > a) without configuration, would an IS-IS router today create a > pseudonode if it is the only router on an Ethernet link? > For instance, suppose R1 and R2 > are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two > LSPs, one saying the pseudonode is R1.25 with neighbor R1, > and another saying R1 has neighbor R1.25? Or when R2 goes down, does R1 > get rid of the pseudonode? In order for a router to elect itself DIS on a circuit it MUST have at least one ES or IS adjacency on that circuit in the UP state. (ISO 10589:2002 Section 8.4.5) > > b) suppose R1 and R2 are both on the same Ethernet, and one is > configured that that port is pt-to-pt and the other is not configured > that way. What happens? No adjacency will be formed as the router which is configured to be Pt-Pt discards LAN IIHs it receives on that circuit. > > c) suppose R1, R2, and R3 are all on the same Ethernet, and all are > configured that that port is pt-to-pt. What happens? No more than one adjacency will be formed on each router. Received hellos whose system ID does not match an existing adjacency are discarded. See Section 4.5 of http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06. txt for further details. Les _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From mshand at cisco.com Fri Feb 1 02:50:56 2008 From: mshand at cisco.com (mike shand) Date: Fri, 01 Feb 2008 10:50:56 +0000 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A23A3D.2040907@sun.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> <47A23A3D.2040907@sun.com> Message-ID: <47A2F990.2010908@cisco.com> On 31/01/2008 Radia Perlman wrote: > You said that to report a neighbor it is 12 octets for narrow metrics, > and 1 octets for wide metrics. Is that backwards perhaps? > I'd think it should take more space to report a side metric, but no > matter -- I'll use 12 octets per neighbor. (though it would > be nice to get a clarification on that -- I could imagine that when > they redid the TLV for reporting metrics, they not only > widened the metric but also compressed the format, or maybe got rid of > multiple metrics). > Excatly. 12 for narrow, 11 for wide, becuase although the metric istelf uses 3 octets rather than one, we only have the single metric, rather than 4 separate metrics. Mike From mshand at cisco.com Fri Feb 1 08:29:49 2008 From: mshand at cisco.com (mike shand) Date: Fri, 01 Feb 2008 16:29:49 +0000 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A1A0BB.5040506@cisco.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> Message-ID: <47A348FD.1000905@cisco.com> On 31/01/2008 mike shand wrote: > I'm not even convinced it simplifies the SPF, but since an SPF for a > several hundred node network takes < 1mS, I don't see this as a big > issue either way. However for a 15 node LAN, WITH pseudonode you explore > 1 hop to the PN then 14 hops to the other nodes, then check on back link > from each of the 14 to the PN (i.e 29 links). In the non PN case you > explore 14 hops, then another 14 hops back from each of those 14 (i.e. > 210 links). It would need a better analysis to determine exactly what > the relative merits are, but at best I would say it is a wash, and it > > might even be a pessimisation not to have a PN. > I couldn't resist conducting the experiment:-) For what its worth, my simulation seems to indicate that the SPF is faster WITH the pseudonodes than without, at least for 4 node LANs and above. I constructed a network consisting of 4 LANs each containing 4 routers. The groups of routers were randomly interconnected with point to point links. The average time to run an SPF WITH pseudonodes was 52 uS, and without pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully meshed set of pt-pt links... each router connected to the 3 other routers on the "LAN", was 64uS. The absolute values are irrelevant, but it does seem to indicate that, for 4 node LANs, the SPF is faster with pseudonodes. As I said, I don't think this matters at all; it is lost in the noise, but it certainly can't be said that it is BETTER not to have the pseudonodes from the SPF point of view. Mike From Radia.Perlman at sun.com Fri Feb 1 10:48:27 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 01 Feb 2008 10:48:27 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A348FD.1000905@cisco.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com> <47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com> <47A348FD.1000905@cisco.com> Message-ID: <47A3697B.4060402@sun.com> Here's a compromise proposal. My goals: a) no configuration required b) no pseudonode if you have no router neighbors on the link (whether or not there are endnodes). c) avoid pseudonodes if easy to do so (explain in a minute) when there are just 2 routers (with perhaps endnodes) Before Mike's arithmetic, I was thinking that pseudonodes weren't valuable until maybe 10 neighbors, and just was embarrassed about the whole pseudonode thing in this brave new world where "Ethernets" are usually pt-to-pt links, but now I think it's fine to simply *always* get rid of pseudonodes in the case of one router, and *almost always* in the case of just two routers. So, here's the proposal: a) do not report a pseudonode unless there is at least one *IS* adjacency. This eliminates my nightmare of an unconfigured RBridge with 1000 ports, each with one endnode on it, reporting 1000 pseudonodes. (Les confirmed my nightmare, that all it takes is a single ES adjacency on a port and IS-IS today would create a pseudonode for that port. We *really* have to fix that case, and without requiring configuration) b) if there is just one IS adjacency, and you are the DR, and your other IS is cool with this feature (as signalled in its Hello), don't use a pseudonode. Just have each of the two IS's report a link to the other. If your neighbor IS isn't cool with it, go ahead and make an adjacency. (Note: for TRILL, I'd hope we'd put this feature in from the start, so that all RBridges would be cool with this, so that is simple) c) if there are ever 2 IS adjacencies on the port, create a pseudonode *and remember, as long as you are up, that this link should have a pseudonode as long as there is at least one IS adjacency*. In other words, this is not really a pt-to-pt link, and it won't be wasteful to keep the link with a pseudonode because there might be other IS's that will come up in the future. I would drop the pseudonode (in the case of TRILL especially, maybe not for CLNP), if there is ever no other IS adjacencies. This is kind of like the original proposal but with the threshold of "1" and "3" rather than "2" and "5", except once you hit 3, the threshold becomes "1" and "2". So in this case R1 would do the following a) no IS neighbors: no pseudonode. R1 reports nothing about that port in its LSP, and does not report a pseudonode. b) neighbor R2 comes up: no pseudonode: R1 just reports a link to R2 in its LSP. R2 reports a link to R1 in its LSP. c) R3 comes up (two IS nbrs): R1 says "use pseudonode". R1, R2, and R3 claim neighbor R1.25. R1.25 (the pseudonode name) reports an LSP with neighbors R1, R2, R3. d) R3 dies, leaving just R1 and R2: still pseudonode. R1.25 reissued, with just R1 and R2 reported. R3's LSP dies of old age. e) R2 dies (so there is just R1): no pseudonode. R1 does not report any adjacencies for that port. R1 reissues its LSP without R1.25 in it. R1.25's LSP dies of old age (or is given a premature death by R1) f) R2 comes up: R1 says "use pseudonode". R2 issues its first LSP saying it is connected to R1.25. R1 adds R1.25 to its LSP, and issues R1.25's LSP with neighbors R1 and R2. Note I think pseudonode minimization might not work for OSPF, since if I remember correctly, OSPF reports some things in the pseudonode LSA (type 2?) like the IP prefix for that link, that I think cannot go in a non-pseudonode LSA (type 1?). So I think OSPF needs a pseudonode for every link. (is this true?). But TRILL IS-IS has *no* information in the pseudonode LSP other than reporting router neighbors. Radia mike shand wrote: > On 31/01/2008 mike shand wrote: > >> I'm not even convinced it simplifies the SPF, but since an SPF for a >> several hundred node network takes < 1mS, I don't see this as a big >> issue either way. However for a 15 node LAN, WITH pseudonode you explore >> 1 hop to the PN then 14 hops to the other nodes, then check on back link >> from each of the 14 to the PN (i.e 29 links). In the non PN case you >> explore 14 hops, then another 14 hops back from each of those 14 (i.e. >> 210 links). It would need a better analysis to determine exactly what >> the relative merits are, but at best I would say it is a wash, and it >> >> might even be a pessimisation not to have a PN. >> >> > I couldn't resist conducting the experiment:-) For what its worth, my > simulation seems to indicate that the SPF is faster WITH the pseudonodes > than without, at least for 4 node LANs and above. > > I constructed a network consisting of 4 LANs each containing 4 routers. > The groups of routers were randomly interconnected with point to point > links. > > The average time to run an SPF WITH pseudonodes was 52 uS, and without > pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully meshed > set of pt-pt links... each router connected to the 3 other routers on > the "LAN", was 64uS. > > The absolute values are irrelevant, but it does seem to indicate that, > for 4 node LANs, the SPF is faster with pseudonodes. > > > As I said, I don't think this matters at all; it is lost in the noise, > but it certainly can't be said that it is BETTER not to have the > pseudonodes from the SPF point of view. > > Mike > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From ginsberg at cisco.com Fri Feb 1 12:48:39 2008 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Fri, 1 Feb 2008 12:48:39 -0800 Subject: [rbridge] Pseudonode minimization thoughts... In-Reply-To: <47A3697B.4060402@sun.com> References: <479EB409.7070901@sun.com> <47A04111.2010204@cisco.com><47A0D71F.1070207@sun.com> <47A1A0BB.5040506@cisco.com><47A348FD.1000905@cisco.com> <47A3697B.4060402@sun.com> Message-ID: Radia - > (Les confirmed my nightmare, that > all it takes is a single ES adjacency on a port and IS-IS today would > create a pseudonode for that port. We *really* have to > fix that case, and without requiring configuration) Unless you are planning to run ES-IS on IP hosts, you won't have any ES adjacencies. Sleep peacefully. :-) Les From mrthom at essex.ac.uk Fri Feb 1 13:59:10 2008 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Fri, 1 Feb 2008 21:59:10 -0000 Subject: [rbridge] Pseudonode minimization thoughts... References: <479EB409.7070901@sun.com><47A04111.2010204@cisco.com><47A0D71F.1070207@sun.com><47A1A0BB.5040506@cisco.com><47A348FD.1000905@cisco.com><47A3697B.4060402@sun.com> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CEADA19@sernt14.essex.ac.uk> Well unless you are running OSPF Les. If this is the case then the pseudonode is generated whether you have an adjacency or not. To turn it off would require removal of the network from the area or explicit Pt-to-Pt configuration/ and messing about. This proposal is accross the boards and covering ospf as well, so this is an issue. This is easily fixed though, by implementing this proposal suggested by Radia et al MT ________________________________ From: rbridge-bounces at postel.org on behalf of Les Ginsberg (ginsberg) Sent: Fri 01/02/2008 20:48 To: Radia Perlman; Developing a hybrid router/bridge. Subject: Re: [rbridge] Pseudonode minimization thoughts... Radia - > (Les confirmed my nightmare, that > all it takes is a single ES adjacency on a port and IS-IS today would > create a pseudonode for that port. We *really* have to > fix that case, and without requiring configuration) Unless you are planning to run ES-IS on IP hosts, you won't have any ES adjacencies. Sleep peacefully. :-) Les _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From mrthom at essex.ac.uk Fri Feb 1 17:01:51 2008 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Sat, 2 Feb 2008 01:01:51 -0000 Subject: [rbridge] FW: Pseudonode minimization thoughts... Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CCE8679@sernt14.essex.ac.uk> Hi Radia, Adding v quick tutorial as suggested... I have been involved in looking at this for a bit, but your original solution is significantly more elegant, backwardly compatible, only 2 flags to add etc etc, than ospf-lite and more elegant. Here is a summary as requested of the general discussion / explanation from people so far. I hope I do them justice.. please forgive any errors OSPF language (appologies if anyone not interested) *************************************************************** Ospf works in a very similar way to ISIS. Two types of LSA are generated. OSPF type 1 (router) you would refer to as a normal ISIS LSP. Our type 2 (Network-LSA) is as your pseudonode LSP. Our type 1 (router LSA) is very similar to your standard LSP. There are a few oddities. Here is the main one I think: a point-to-point line has two entries: Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 2.2.2.2 (Link Data) Router Interface address: 172.16.1.1 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.1.0 (Link Data) Network Mask: 255.255.255.252 Number of TOS metrics: 0 TOS 0 Metrics: 64 This is a point-to-point line from this router (ID 1.1.1.1) to the neighbour 2.2.2.2 The point-to-point line has local IP address 172.16.1.1. It is reported TWICE in the packet. Once as a point-to-point line and then a second time to attach the IP network. This is all to allow an IP unnumbered interface if required. If unnumbered then the interface in the first block of text is represented by an MIB value. Radia et al plan, configured for OSPF: ************************************** 1.) Use ospf LLS datablock Extended options to locate 2 flags. 2.) One flag (called NS-Bit) signifies to the other neighbors, the compatability with the reduction draft. 3.) DR gets elected and Pseudonode LSP (Network-LSA) is not generated by DR yet. 4.) DR signals to neighbors to move to pseudonode reduction using second flag (SS-Bit). 5.) Neighbors set SS-Bit flag in accordance to signify acceptance. 6.) Router LSA (ISIS normal LSP) shows to the OUTSIDE world a network type of "point-to-multipoint." Represented as lots of Point-to-point lines (see below for example 7.) Routers actually operate on the LAN using DR as normal. However! we already have a special network type called point-to-multipoint that actually reduces the Network LSA anyway. So is the problem solved already? Well partly... Here are the problems not currently solved by P2MP (Point-to-multipoint) alone (as I see it): ***************************************************************** Problem 1: P2MP cant be configured as default, (to avoid configuration issues). This is because a further router might be added to the network that isn't configured to support point-to-multipoint. The hellos would not match and the neighbour would not be established. This is the current state. Problem 2. We cant add flags to dynamically change the network to point-to-multipoint, (on its own without your proposal) because if we did then the DR is removed (as P2MP doesn't use one), so cant change BACK if another router is added that doesn't support point-to-multipoint. (same problem as above). Both of these problems are solved by continuing to use DR as normal, but advertising in the router LSA's the "point-to-multipoint" option, which looks like this below: This LSA is generated by router IS 1.1.1.1 and the neighbors listed are 2.2.2.2, 3.3.3.3, and the network in question is 192.168.1.0 255.255.255.0 LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 80000002 Checksum: 0xB5ED Length: 60 Number of Links: 3 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 2.2.2.2 (Link Data) Router Interface address: 192.168.1.1 Number of TOS metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 3.3.3.3 (Link Data) Router Interface address: 192.168.1.1 Number of TOS metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.1.1 (Link Data) Network Mask: 255.255.255.255 << note mask is 32 Number of TOS metrics: 0 TOS 0 Metrics: 0 Matthew Thomas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: 01 February 2008 18:48 To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Pseudonode minimization thoughts... Here's a compromise proposal. My goals: a) no configuration required b) no pseudonode if you have no router neighbors on the link (whether or not there are endnodes). c) avoid pseudonodes if easy to do so (explain in a minute) when there are just 2 routers (with perhaps endnodes) Before Mike's arithmetic, I was thinking that pseudonodes weren't valuable until maybe 10 neighbors, and just was embarrassed about the whole pseudonode thing in this brave new world where "Ethernets" are usually pt-to-pt links, but now I think it's fine to simply *always* get rid of pseudonodes in the case of one router, and *almost always* in the case of just two routers. So, here's the proposal: a) do not report a pseudonode unless there is at least one *IS* adjacency. This eliminates my nightmare of an unconfigured RBridge with 1000 ports, each with one endnode on it, reporting 1000 pseudonodes. (Les confirmed my nightmare, that all it takes is a single ES adjacency on a port and IS-IS today would create a pseudonode for that port. We *really* have to fix that case, and without requiring configuration) b) if there is just one IS adjacency, and you are the DR, and your other IS is cool with this feature (as signalled in its Hello), don't use a pseudonode. Just have each of the two IS's report a link to the other. If your neighbor IS isn't cool with it, go ahead and make an adjacency. (Note: for TRILL, I'd hope we'd put this feature in from the start, so that all RBridges would be cool with this, so that is simple) c) if there are ever 2 IS adjacencies on the port, create a pseudonode *and remember, as long as you are up, that this link should have a pseudonode as long as there is at least one IS adjacency*. In other words, this is not really a pt-to-pt link, and it won't be wasteful to keep the link with a pseudonode because there might be other IS's that will come up in the future. I would drop the pseudonode (in the case of TRILL especially, maybe not for CLNP), if there is ever no other IS adjacencies. This is kind of like the original proposal but with the threshold of "1" and "3" rather than "2" and "5", except once you hit 3, the threshold becomes "1" and "2". So in this case R1 would do the following a) no IS neighbors: no pseudonode. R1 reports nothing about that port in its LSP, and does not report a pseudonode. b) neighbor R2 comes up: no pseudonode: R1 just reports a link to R2 in its LSP. R2 reports a link to R1 in its LSP. c) R3 comes up (two IS nbrs): R1 says "use pseudonode". R1, R2, and R3 claim neighbor R1.25. R1.25 (the pseudonode name) reports an LSP with neighbors R1, R2, R3. d) R3 dies, leaving just R1 and R2: still pseudonode. R1.25 reissued, with just R1 and R2 reported. R3's LSP dies of old age. e) R2 dies (so there is just R1): no pseudonode. R1 does not report any adjacencies for that port. R1 reissues its LSP without R1.25 in it. R1.25's LSP dies of old age (or is given a premature death by R1) f) R2 comes up: R1 says "use pseudonode". R2 issues its first LSP saying it is connected to R1.25. R1 adds R1.25 to its LSP, and issues R1.25's LSP with neighbors R1 and R2. Note I think pseudonode minimization might not work for OSPF, since if I remember correctly, OSPF reports some things in the pseudonode LSA (type 2?) like the IP prefix for that link, that I think cannot go in a non-pseudonode LSA (type 1?). So I think OSPF needs a pseudonode for every link. (is this true?). But TRILL IS-IS has *no* information in the pseudonode LSP other than reporting router neighbors. Radia mike shand wrote: > On 31/01/2008 mike shand wrote: > >> I'm not even convinced it simplifies the SPF, but since an SPF for a >> several hundred node network takes < 1mS, I don't see this as a big >> issue either way. However for a 15 node LAN, WITH pseudonode you explore >> 1 hop to the PN then 14 hops to the other nodes, then check on back link >> from each of the 14 to the PN (i.e 29 links). In the non PN case you >> explore 14 hops, then another 14 hops back from each of those 14 (i.e. >> 210 links). It would need a better analysis to determine exactly what >> the relative merits are, but at best I would say it is a wash, and it >> >> might even be a pessimisation not to have a PN. >> >> > I couldn't resist conducting the experiment:-) For what its worth, my > simulation seems to indicate that the SPF is faster WITH the pseudonodes > than without, at least for 4 node LANs and above. > > I constructed a network consisting of 4 LANs each containing 4 routers. > The groups of routers were randomly interconnected with point to point > links. > > The average time to run an SPF WITH pseudonodes was 52 uS, and without > pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully meshed > set of pt-pt links... each router connected to the 3 other routers on > the "LAN", was 64uS. > > The absolute values are irrelevant, but it does seem to indicate that, > for 4 node LANs, the SPF is faster with pseudonodes. > > > As I said, I don't think this matters at all; it is lost in the noise, > but it certainly can't be said that it is BETTER not to have the > pseudonodes from the SPF point of view. > > Mike > > _______________________________________________ > 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 mrthom at essex.ac.uk Fri Feb 1 17:39:14 2008 From: mrthom at essex.ac.uk (Thomas, Matthew R) Date: Sat, 2 Feb 2008 01:39:14 -0000 Subject: [rbridge] FW: Pseudonode minimization thoughts... References: <7AC902A40BEDD411A3A800D0B7847B661CCE8679@sernt14.essex.ac.uk> Message-ID: <7AC902A40BEDD411A3A800D0B7847B661CCE867A@sernt14.essex.ac.uk> In terms of threshold, For OSPF a variable would be most useful. The ability to set it to say 5 as standard and then reduce to 3 as described from time to time would be most useful. One of the advantages of this proposal is that the values can be set differently from LAN to LAN without a problem, and there is no requirement to upgrade all of your routers /Rbridges at the same time. MT -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Thomas, Matthew R Sent: 02 February 2008 01:02 To: radia.perlman at sun.com Cc: rbridge at postel.org Subject: [rbridge] FW: Pseudonode minimization thoughts... Hi Radia, Adding v quick tutorial as suggested... I have been involved in looking at this for a bit, but your original solution is significantly more elegant, backwardly compatible, only 2 flags to add etc etc, than ospf-lite and more elegant. Here is a summary as requested of the general discussion / explanation from people so far. I hope I do them justice.. please forgive any errors OSPF language (appologies if anyone not interested) *************************************************************** Ospf works in a very similar way to ISIS. Two types of LSA are generated. OSPF type 1 (router) you would refer to as a normal ISIS LSP. Our type 2 (Network-LSA) is as your pseudonode LSP. Our type 1 (router LSA) is very similar to your standard LSP. There are a few oddities. Here is the main one I think: a point-to-point line has two entries: Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 2.2.2.2 (Link Data) Router Interface address: 172.16.1.1 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.1.0 (Link Data) Network Mask: 255.255.255.252 Number of TOS metrics: 0 TOS 0 Metrics: 64 This is a point-to-point line from this router (ID 1.1.1.1) to the neighbour 2.2.2.2 The point-to-point line has local IP address 172.16.1.1. It is reported TWICE in the packet. Once as a point-to-point line and then a second time to attach the IP network. This is all to allow an IP unnumbered interface if required. If unnumbered then the interface in the first block of text is represented by an MIB value. Radia et al plan, configured for OSPF: ************************************** 1.) Use ospf LLS datablock Extended options to locate 2 flags. 2.) One flag (called NS-Bit) signifies to the other neighbors, the compatability with the reduction draft. 3.) DR gets elected and Pseudonode LSP (Network-LSA) is not generated by DR yet. 4.) DR signals to neighbors to move to pseudonode reduction using second flag (SS-Bit). 5.) Neighbors set SS-Bit flag in accordance to signify acceptance. 6.) Router LSA (ISIS normal LSP) shows to the OUTSIDE world a network type of "point-to-multipoint." Represented as lots of Point-to-point lines (see below for example 7.) Routers actually operate on the LAN using DR as normal. However! we already have a special network type called point-to-multipoint that actually reduces the Network LSA anyway. So is the problem solved already? Well partly... Here are the problems not currently solved by P2MP (Point-to-multipoint) alone (as I see it): ***************************************************************** Problem 1: P2MP cant be configured as default, (to avoid configuration issues). This is because a further router might be added to the network that isn't configured to support point-to-multipoint. The hellos would not match and the neighbour would not be established. This is the current state. Problem 2. We cant add flags to dynamically change the network to point-to-multipoint, (on its own without your proposal) because if we did then the DR is removed (as P2MP doesn't use one), so cant change BACK if another router is added that doesn't support point-to-multipoint. (same problem as above). Both of these problems are solved by continuing to use DR as normal, but advertising in the router LSA's the "point-to-multipoint" option, which looks like this below: This LSA is generated by router IS 1.1.1.1 and the neighbors listed are 2.2.2.2, 3.3.3.3, and the network in question is 192.168.1.0 255.255.255.0 LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 80000002 Checksum: 0xB5ED Length: 60 Number of Links: 3 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 2.2.2.2 (Link Data) Router Interface address: 192.168.1.1 Number of TOS metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 3.3.3.3 (Link Data) Router Interface address: 192.168.1.1 Number of TOS metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.1.1 (Link Data) Network Mask: 255.255.255.255 << note mask is 32 Number of TOS metrics: 0 TOS 0 Metrics: 0 Matthew Thomas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: 01 February 2008 18:48 To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Pseudonode minimization thoughts... Here's a compromise proposal. My goals: a) no configuration required b) no pseudonode if you have no router neighbors on the link (whether or not there are endnodes). c) avoid pseudonodes if easy to do so (explain in a minute) when there are just 2 routers (with perhaps endnodes) Before Mike's arithmetic, I was thinking that pseudonodes weren't valuable until maybe 10 neighbors, and just was embarrassed about the whole pseudonode thing in this brave new world where "Ethernets" are usually pt-to-pt links, but now I think it's fine to simply *always* get rid of pseudonodes in the case of one router, and *almost always* in the case of just two routers. So, here's the proposal: a) do not report a pseudonode unless there is at least one *IS* adjacency. This eliminates my nightmare of an unconfigured RBridge with 1000 ports, each with one endnode on it, reporting 1000 pseudonodes. (Les confirmed my nightmare, that all it takes is a single ES adjacency on a port and IS-IS today would create a pseudonode for that port. We *really* have to fix that case, and without requiring configuration) b) if there is just one IS adjacency, and you are the DR, and your other IS is cool with this feature (as signalled in its Hello), don't use a pseudonode. Just have each of the two IS's report a link to the other. If your neighbor IS isn't cool with it, go ahead and make an adjacency. (Note: for TRILL, I'd hope we'd put this feature in from the start, so that all RBridges would be cool with this, so that is simple) c) if there are ever 2 IS adjacencies on the port, create a pseudonode *and remember, as long as you are up, that this link should have a pseudonode as long as there is at least one IS adjacency*. In other words, this is not really a pt-to-pt link, and it won't be wasteful to keep the link with a pseudonode because there might be other IS's that will come up in the future. I would drop the pseudonode (in the case of TRILL especially, maybe not for CLNP), if there is ever no other IS adjacencies. This is kind of like the original proposal but with the threshold of "1" and "3" rather than "2" and "5", except once you hit 3, the threshold becomes "1" and "2". So in this case R1 would do the following a) no IS neighbors: no pseudonode. R1 reports nothing about that port in its LSP, and does not report a pseudonode. b) neighbor R2 comes up: no pseudonode: R1 just reports a link to R2 in its LSP. R2 reports a link to R1 in its LSP. c) R3 comes up (two IS nbrs): R1 says "use pseudonode". R1, R2, and R3 claim neighbor R1.25. R1.25 (the pseudonode name) reports an LSP with neighbors R1, R2, R3. d) R3 dies, leaving just R1 and R2: still pseudonode. R1.25 reissued, with just R1 and R2 reported. R3's LSP dies of old age. e) R2 dies (so there is just R1): no pseudonode. R1 does not report any adjacencies for that port. R1 reissues its LSP without R1.25 in it. R1.25's LSP dies of old age (or is given a premature death by R1) f) R2 comes up: R1 says "use pseudonode". R2 issues its first LSP saying it is connected to R1.25. R1 adds R1.25 to its LSP, and issues R1.25's LSP with neighbors R1 and R2. Note I think pseudonode minimization might not work for OSPF, since if I remember correctly, OSPF reports some things in the pseudonode LSA (type 2?) like the IP prefix for that link, that I think cannot go in a non-pseudonode LSA (type 1?). So I think OSPF needs a pseudonode for every link. (is this true?). But TRILL IS-IS has *no* information in the pseudonode LSP other than reporting router neighbors. Radia mike shand wrote: > On 31/01/2008 mike shand wrote: > >> I'm not even convinced it simplifies the SPF, but since an SPF for a >> several hundred node network takes < 1mS, I don't see this as a big >> issue either way. However for a 15 node LAN, WITH pseudonode you explore >> 1 hop to the PN then 14 hops to the other nodes, then check on back link >> from each of the 14 to the PN (i.e 29 links). In the non PN case you >> explore 14 hops, then another 14 hops back from each of those 14 (i.e. >> 210 links). It would need a better analysis to determine exactly what >> the relative merits are, but at best I would say it is a wash, and it >> >> might even be a pessimisation not to have a PN. >> >> > I couldn't resist conducting the experiment:-) For what its worth, my > simulation seems to indicate that the SPF is faster WITH the pseudonodes > than without, at least for 4 node LANs and above. > > I constructed a network consisting of 4 LANs each containing 4 routers. > The groups of routers were randomly interconnected with point to point > links. > > The average time to run an SPF WITH pseudonodes was 52 uS, and without > pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully meshed > set of pt-pt links... each router connected to the 3 other routers on > the "LAN", was 64uS. > > The absolute values are irrelevant, but it does seem to indicate that, > for 4 node LANs, the SPF is faster with pseudonodes. > > > As I said, I don't think this matters at all; it is lost in the noise, > but it certainly can't be said that it is BETTER not to have the > pseudonodes from the SPF point of view. > > Mike > > _______________________________________________ > 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 Feb 11 19:29:16 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 11 Feb 2008 19:29:16 -0800 Subject: [rbridge] Revisiting the TRILL header Message-ID: <47B1128C.3020006@sun.com> Now that people are getting into implementing TRILL... An implementor said that he found looking beyond the options for things like VLAN and destination address in the inner header annoying. Don Eastlake had proposed a format moving the VLAN and destination address into the TRILL header (and removing them from the inner packet). I liked it at the time and still do, and thought I'd give it one more chance on the mailing list. The format that the implementor proposed was that without options, all that would change is that the Ethertype would be removed from the 802.1q tag, so the format would be current header + Ethernet DA + Ethernet SA + 16 bits of VLAN info (priority, drop eligibility, VLAN tag) + options (if any) + rest of packet. The arguments, I think, were that then core RBridges don't have to look beyond the TRILL header, and also, that the core RBridges don't have to understand both Ethertypes (IEEE changed the Ethertype on the VLAN tag when changing the meaning of the "format indicator" bit to "drop eligibility". Can other people who are implementing this comment on: a) whether changing the header at this point is really a problem, even if it were a good idea, and b) whether this is a good idea. Thanks, Radia From Donald.Eastlake at motorola.com Wed Feb 13 20:50:07 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 13 Feb 2008 23:50:07 -0500 Subject: [rbridge] Consensus Confirmed: Allow GVRP/MVRP In-Reply-To: <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D97900382FA07@de01exm64.ds.mot.com> The consensus below from the Vancouver meeting is confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, January 07, 2008 1:36 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Allow GVRP/MVRP This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Remove any text prohibiting implementation of GVRP or MVRP on RBridges. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Wed Feb 13 20:51:29 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 13 Feb 2008 23:51:29 -0500 Subject: [rbridge] Consensus Confirmed: Milestone Move In-Reply-To: <3870C46029D1F945B1472F170D2D97900366D3B9@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D97900366D3B1@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D97900366D3B9@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D97900382FA08@de01exm64.ds.mot.com> The following consensus from the Vancouver meeting has been confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Wednesday, January 09, 2008 11:46 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Milestone Move This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Move milestones to March 2008 for Problem Statement and Architecture document. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Wed Feb 13 21:17:07 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 14 Feb 2008 00:17:07 -0500 Subject: [rbridge] Consensus Confirmed: Pseudonode suppression In-Reply-To: <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D97900382FA0E@de01exm64.ds.mot.com> The following consensus from the Vancouver meeting has been confirmed. Donald & Erik PS: There has been a lot of discussion of this but it doesn't affect whether to move it out of the base protocol specification or not. -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Thursday, January 03, 2008 2:14 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Pseudonode suppression This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Move the Pseudonode suppression provisions out of the TRILL base protocol specification into a document closer to IS-IS. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Wed Feb 20 17:32:53 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 20 Feb 2008 20:32:53 -0500 Subject: [rbridge] Last Consensus Confirmations from Vancouver Meeting Message-ID: <3870C46029D1F945B1472F170D2D9790038A6E61@de01exm64.ds.mot.com> There were two consensuses in the TRILL meeting in Vancouver that were posted (perhaps not too articulately) to this list for verification and are pasted at the end of this message. There has been discussion of these topics on the list and the overall consensus of the working group is that (1) there should be a way in TRILL to configure an Rbridge port such that end-station/native frames are not sent on that port and any received are discarded and (2) there should not be a way in TRILL to configure an Rbridge port such that it uses a global fixed source and destination MAC address as being a port to a point-to-point link to another Rbridge. Donald & Erik From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, January 07, 2008 1:34 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Configure ports to disable end station traffic This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Currently broadcast, unknown unicast, and non-IP-derived multicast frames are output to all links. This is wasteful if there are no end stations on the link. Provide that a port can be configured so as to be disabled for end station traffic. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Wednesday, January 09, 2008 11:27 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Against P2P Fixed Addresses Proposal This is a check via the mailing list to confirm or refute an apparent consensus at the Vancouver meeting taken from the minutes of that meeting: Against the proposal presented at IETF-70 for p2p link configuration permitting a fixed source and destination address. If no particular controversy arises over this in the next three weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Donald.Eastlake at motorola.com Wed Feb 20 17:40:03 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 20 Feb 2008 20:40:03 -0500 Subject: [rbridge] On 802.1 Registration Protocols Message-ID: <3870C46029D1F945B1472F170D2D9790038A6E62@de01exm64.ds.mot.com> IEEE 802.1D defines a general attribute registration protocol (GARP). A block of 16 multicast addresses is reserved for different applications of this protocol but only two applications have been defined: registration of multicast addresses (GARP Multicast Registration Protocol, GMRP) and registration of VLANs (GARP VLAN Registration Protocol, GVRP (specified in 802.1Q)). These protocols, speaking very generally, allow a bridge or end station to send a frame which indicates that it wishes to received traffic for a particular multicast group or VLAN or no longer wishes to receive such traffic. The initial version of this allowed only one attribute per request frame but 802.1Q has been amended to require a different format for these messages which can encoding multiple attributes per frame. The amended version is called multiple registration protocol, MRP, and the two applications, when using MRP frames, are called MMRP and MVRP. 802.1 bridges which don't understand GARP/MRP frames are required to forward them like other multicast frames. One could imagine various extremely complex interactions between Rbridges and such GARP/MRP messages. But I think we want to make Rbridge interactions with GARP/MRP that are specified in TRILL as simple as reasonably possible given the constraint that bridges should be incrementally replaceable with Rbridges in realistic scenarios. The current base protocol draft says that such registration frames are treated like any other non-IP-derived multicast. I think this works well enough for multicast registration frames (multicast address 01-80-C2-00-00-20), which are rarely used in practice, and for the 14 reserved registration protocol multicast addresses (01-80-C2-00-00-22 through 01-80-C2-00-00-2F). Frames treated this way are VLAN constrained and no worse than a broadcast frame. However, just treating a VLAN registration frame like other non-IP-derived multicast seems, to me, to have serious problems. The 802.1 standard prohibits VLAN tags on native VLAN registration frames and, since the purpose of such frames is frequently to turn on connectivity for a VLAN, it would make no sense to consider their distribution to be VLAN constrained. However, if VLAN registration frames are just flooded without VLAN constraint, they become, in effect, super-broadcast frames that could easily be used for denial of service. In fact, since VLAN connectivity information for Rbridges is flooded via IS-IS, it is not clear there is any need to forward VLAN registration frames between them at all. VLAN registration is not useful for Rbridge-to-Rbridge links but could be useful if sent to bridges and useful at an ingress Rbridge port if that port is configured to allow dynamic VLAN registration, which is the recommended default configuration for 802.1Q ports (except for VLAN 1 which is fixed enabled in the default). In principal, VLAN registration frames could be recognized by end stations; but use of them in that way is fairly rare. My opinion is that it would be OK to require configuration at an Rbridge to get it to send such frames on a port where it does not see a bridge. So my current thought is that Rbridges which receive a VLAN registration frame and which are configured to pay attention to such frames (which would be the recommended default, as it is with 802.1Q bridges) should, for VLANs which are set to dynamic registration (which should be the recommended default, as it is with 802.1Q bridges), run the registration state machine and appropriately enable/disable VLAN output on that port. This VLAN enablement status will be flooded to all other Rbridges in the link state database so there is no need to encapsulate or forward or generate VLAN registration frames between RBridges. Rbridges that see a bridge out a port should send MVRP messages to that bridge. Of course, it should be possible to configure them per port to not send such messages or to send them on ports where they do not see a bridge (presumably end station ports). Perhaps they should also be configurable to alternatively send the older GVRP messages. Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Radia.Perlman at sun.com Wed Feb 20 21:28:09 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 20 Feb 2008 21:28:09 -0800 Subject: [rbridge] Last Consensus Confirmations from Vancouver Meeting In-Reply-To: <3870C46029D1F945B1472F170D2D9790038A6E61@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790038A6E61@de01exm64.ds.mot.com> Message-ID: <47BD0BE9.9050803@sun.com> That was my understanding on both points. Radia Eastlake III Donald-LDE008 wrote: > There were two consensuses in the TRILL meeting in Vancouver that were > posted (perhaps not too articulately) to this list for verification and > are pasted at the end of this message. There has been discussion of > these topics on the list and the overall consensus of the working group > is that (1) there should be a way in TRILL to configure an Rbridge port > such that end-station/native frames are not sent on that port and any > received are discarded and (2) there should not be a way in TRILL to > configure an Rbridge port such that it uses a global fixed source and > destination MAC address as being a port to a point-to-point link to > another Rbridge. > > Donald & Erik > > > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Monday, January 07, 2008 1:34 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Configure ports to disable end > station traffic > > This is a check via the mailing list to confirm or refute an apparent > consensus at the Vancouver meeting taken from the minutes of that > meeting: > > Currently broadcast, unknown unicast, and > non-IP-derived multicast frames are output to all links. This is > wasteful if there are no end stations on the link. Provide that > a port can be configured so as to be disabled for end station > traffic. > > If no particular controversy arises over this in the next three weeks, > We will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Wednesday, January 09, 2008 11:27 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Against P2P Fixed Addresses Proposal > > This is a check via the mailing list to confirm or refute an apparent > consensus at the Vancouver meeting taken from the minutes of that > meeting: > > Against the proposal presented at IETF-70 > for p2p link configuration permitting a fixed source and > destination address. > > If no particular controversy arises over this in the next three weeks, > We will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > ==================================================== > Donald E. Eastlake 3rd +1-508-786-7554 (work) > Motorola Laboratories > 111 Locke Drive > Marlborough, MA 01752 USA > Donald.Eastlake at motorola.com > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Thu Feb 21 08:44:49 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 21 Feb 2008 10:44:49 -0600 Subject: [rbridge] Proposed changes to the architecture based on IETF-70... Message-ID: <941D5DCD8C42014FAF70FB7424686DCF028072D6@eusrcmw721.eamcs.ericsson.se> Folks, Several people pointed out that the architecture should not assume a DRB election process will be used. This is technically correct, and - for that reason - not directly something that needs consensus to change, at least in theory. Before going into specific proposed changes, I would like to mention (in passing) why this is not a trivial change - as I explicitly said during the meeting. In fact, the reason why use of DRB election is assumed in the protocol specification are manifold and - by not making the same assumption in the architecture - we task the architecture with the onus of expressly stating the reasons why any protocol specification will almost certainly need to use a DRB election. This is quite arguably an appropriate task for the architecture document, which does nothing to make it easy. Interestingly enough, most people did not see this as all that hard to do. One or two people even offered to help. Below is what we've come up with. Given the shortage of time, my default assumption is that these changes should be incorporated in a version to be posted by the dead-line next Monday. ______________________________________________________________________ At a high level, any solution needs not only to deal with ingress and egress of frames traversing the RBridge Campus in the normal case, it must aslo deal with the folowing exception cases: o receiving a frame from an end station previousy not heard from, o flooding frames for unknown destinations, o broadcast of frames to reach all possible end stations - known or unknown. In short it is not simply a matter of determining which RBridge it is that forwards frames in each specific case, it is also a matter of determining which RBridge learns and floods in each specific case - where one has to recognize that it is not always going to be the case that RBridges have a priori knowledge required to make a determination in some arbitrary and as yet undefined determination process. Also, the method of selecting which RBridge is responsible for all of the above cannot be completely arbitrary. As it turns out, in order to maintain compatibility with 802.1Q (or 802.1D) bridges, RBridges must handle ingress onto and egress off of the RBridge Campus in a way that is consistent within a consistent forwarding context used by any local bridges that may be present. And - of course - there is always the consideration of which RBridge sends routing advertisements._________________________________________________________ _____________ Anyway, on to the specific issues and proposed changes... ---------------------------------------------------------------------- So, here are the issues, and my proposed changes to account for them. ______________________________________________________________________ First, there is the definition of Designated RBridge. The definition needs to remain, but it must be changed to reflect the fact that this is merely one way to handle the issue(s) addressed using a DRB. I propose a replacement definition as follows: "Designated RBridge (DRB): one approach to resolving several issues associated with having multiple RBridges as candidate ingress and egress points from a single LAN is to designate an RBridge to act as the ingress and egress in that case. The RBridge designated to handle ingress and egress traffic to a specific Ethernet link (or VLAN associated with that link), having shared access and multiple RBridges is such a link's "Designated RBridge", or DRB. A Designated RBridge may (for example) be determined by an election process among those RBridges having shared access via a single LAN, or may be selected by some other means." ______________________________________________________________________ Also, the definition of Encapsulation Database contains a (what is - in retrospect - probably innappropriate) use of Designated RBridge. I propose a litteral replacement of - "Designated RBridge (ingress)" - with - "Ingress RBridge" ______________________________________________________________________ Section 4.1 has two problem areas. In the second paragraph, the use of DRB as the the primary point of attachment for an end station is assumed. I propose modification as follows: "At an architectural level, it is sufficient to note that every end station attached to a TRILL Campus should have a primary point of attachment to the TRILL Campus, as might be defined (for example) by a Designated RBridge. Furthermore, if it is possible that there are 802.1Q (or 802.1D) bridges in a local LAN, the association of specific RBridges and the end stations to which they act as primary point of attachment must be determined in a way that is consistent with forwarding in an 802.1Q (or 802.1D) network. If a DRB election process were used, each TRILL Link (or VLAN group within a TRILL Link) attached to a TRILL Campus would have a single Designated RBridge (either for the link, or for a subset of the VLANs on the link); using DRBs as an example, the DRB would be where all traffic intended to transit a TRILL Campus enters and exits. "Other approaches might be used as well. For example, the primary point of attachment for each end-station might be configured, or determined in some other way, on a per end station basis. Any such approach must either allow for the possibility of LAN bridges or not be used when such a possibility exists." The last paragraph in section 4.1 ("TRILL Campus Auto-configuration") specifically includes DRB election. I propose a small modification to read as follows: "High-level steps that may be included in auto-configuration are: RBridge peer discovery, topology discovery, determination of end station primary points of attachment (DRB election, for example), learning and forwarding (tunneling) TRILL encapsulated frames." ______________________________________________________________________ Section 4.4 needs to be re-written (and re-titled). I propose: "4.4. Determination of End Station Primary Points of Attachment "The mechanisms and details of how end stations are associated with a specific Rbridge - when multiple RBridges are available - for the purpose of providing ingress to and egress from the RBridge Campus, will be provided by protocol specification(s). A potential approach to be considered is the use of a 'Designated RBridge Election', on either a per link, or per VLAN (set) basis. "Architecturally, it is important to note that this determination must be based on an accurate view of the topology, including the availability of certain links in a given topology for traffic associated with any given VLAN. Otherwise, it is possible to partition a TRILL Link-local LAN (assuming that RBridge may be deployed and configured to replace existing 802.1Q bridges) as a result of a failure - under circumstance in which such a partition would not have occurred with previously deployed 802.1Q bridges. "Protocol specification(s) need to define how accurate VLAN topology is to be determined and applied in determination of end station primary points of attachment. Protocol specification(s) also need to state the limitations that any chosen mechanisms may impose on the solution (in terms of scalability and ease of deployment, for example). Finally protocol specification(s) need to describe how determination is made with respect to which RBridge is responsible for learning new end station information, and for the flooding and broadcast frames for reaching known and unknown end stations on any link or VLAN." ______________________________________________________________________ Section 5.1 use the expression "Designated RBridge Election" in the first paragraph. I propose to replace the first paragraph with: "As described in sections above, operations that apply to all RBridges include peer and topology discovery (including hello messaging, negotiation of RBridge identifiers and link-state routing), determination of RBridge primary point of attachment (for local end stations - possibly via DRB election), shortest path (SPF) computation and either learning or advertising L2 MAC Ethernet destination reach-ability for addresses within a broadcast domain." ______________________________________________________________________ Section 5.2 is intended to describe architectural considerations that apply to ingress and egress operations. These include how learning is expected to occur, and how forwarding onto and off of the RBridge Campus occurs. As such, the section is closely tied in with the presumption of using a DRB (as elected or otherwise determined). One solution to this issue would have been to make the term DRB - in this document - apply effectively on a per end station basis (however complicated this might seem, it is what we must consider to be the minimalist architectural requirement). In order to avoid confusing use of the term DRB, however, I would rather not use that approach (and have not done so in my proposed changes thus far). Instead, I propose changing several of the paragraphs of section 5.2 to read as follows: ______________________________________________________________________ "5.2.Ingress/Egress Operations "Operation specific to edge RBridges involves RBridge learning, advertisement, encapsulation and decapsulation (at ingress and egress RBridges, respectively). "As described previously, RBridge learning is similar to typical bridge learning - i.e. - RBridges listen promiscuously to L2 Frames on each local LAN and acquire end station location information associated with source MAC addresses in L2 frames they observe. "If multiple RBridges are available, a determination must be made as to which RBridge is the primary point of attachment for each end station (or end stations by groups - using, for example, the VLAN associations of VLAN aware end stations) requiring ingress and egress services from an RBridge campus. This is a minimal requirement, and there is no reason why this same determination might not be made in all cases, even including a degenerate case in which only one RBridge may be used. This would be the case, for instance, if DRB election is done in all case, including when the DRB can only be the one and only RBridge to which local end stations might be attached. "In the degenerate case - where only one RBridge is connected to a specific Ethernet LAN - obviously that RBridge will be (or become) the primary point of attachment for local end stations requiring ingress/egress services from the RBridge Campus. "Minimally, only the RBridge determined as the primary point of attachment for a given (set of) end station(s) is required to performs RBridge learning for that (set of) end station(s) while they remain associated with interface(s) connected to the local LAN or VLAN. "Note that - in some cases - the determination of primary points of attachment and learning may be tightly bound operations. This might be the case if - for example - the determination is based on litteral configuration of end station and RBridge attachments. In other cases, learning would occur in a more conventional - and flexible way - if (for example) an automated process of selecting a DRB (such as DRB election) is used on a per link or per VLAN (set) basis. "Assuming learning is required by a specific solution described in any protocol specification(s), as RBridges learn segment-local MAC source addresses, ..." - and further on - "... to limit the scope of advertisement flooding. "If it is desired - in any specific solution - to support discovery of new end station attachments, RBridges may also discover that a new end station has become locally attached (for which they may be or become an edge RBridge) as a result of receiving un-encapsulated frames that require forwarding. Any such solution must specify how a primary end station point of attachment is determined when this occurs. Several possible approaches exist. "If an automated DRB selection process (such as DRB election) is the approach in use for a specific solution (on a per link or per VLAN basis), this determination is automatic for any specific link or VLAN on a local link. If an RBridge is the Designated RBridge for a local link or VLAN, and has not previously learned that the MAC destination for a frame is local (this could be the case for the very first frame an RBridge observes), then the RBridge could be required to forward (or flood) the frame via the TRILL Campus to all other RBridges (potentially within a VLAN scope). "Protocol specifications intended to support recognition of new end station attachments must specify how the determination of a primary point of attachment is to be accomplished for newly discovered end stations. "When a frame is received which must be forwarded across the RBridge Campus, the responsible RBridge would flood the frame unless it has already created a Unicast TRILL Forwarding Database entry for the frame's MAC destination address. If it has a corresponding Unicast TRILL Forwarding Database entry, then it would use that. The RBridge in this instance would be an ingress RBridge for the frame being forwarded across the RBridge Campus. "The encapsulation used by this ingress RBridge would be determined by the Unicast TRILL Forwarding Database - if one exists - or the Unicast TRILL Forwarding Database-equivalent entry for the RBridge Distribution Tree. "When the encapsulated frame arrives at egress RBridge(s), it is decapsulated and forwarded via the egress interface(s) onto the local link (or VLAN on the local link). "In using the approach of learning from the data plane, the egress RBridge stores information related to content of the frame's TRILL encapsulation for use in subsequent reverse traffic in a manner directly analogous to bridge learning. "Note that an egress RBridge will - in most cases - be the RBridge determined to be the primary point of attachment for a destination end station on the local LAN or VLAN accessed via its egress interface(s). Exceptions to this might exist under circumstances in which use of distinct RBridges for ingress and egress for a common (set of) end station(s) does not produce local forwarding ambiguity. Any protocol specification that allows this must also unambiuously describe the precise circumstances under which it is allowed - as well as the limitations and issues this introduces in the solution specified. "Also note that any specific solution in protocol specification(s) will need to document how determination of an end station primary point of attachment (RBridge) occurs for the case where a specific end station has not yet been discovered at any egress or egress interface - except under circumstances where support of discovery of new end stations is not supported, or explicitly disallowed. In the example in which a DRB election is used, this determination should be both trivial and automatic. In an approach where an end station and RBridge attachment/association is configured, this should also be relatively obvious - if inflexible. "For the DRB example, if the destination MAC of a received frame does not correspond to a learned MAC destination address at a specific egress interface, the DRB will forward the frame on all interfaces for which it is the designated RBridge. If a received frame does correspond to a learned MAC destination address at some specific egress interface, the DRB will forward the frame via that interface only. "Any specific solution's protocol specification should also allow for the fact that flooded frames may arrive at a single local LAN (or VLAN) where local end stations may be attached via multiple RBridges, and properly account for how the determination of which RBridge is exclusively responsible for forwarding such frames is to be made. This is essential to avoid having the same frame being delivered at local bridge interfaces multiple times and potentially from widely disparate directions (i.e. - on different interfaces of individual bridges)." ______________________________________________________________________ Section 5.3.2.1 ("Broadcast" - under 5.3.2 "Broadcast, Multicast and Flooding", under 5.3 "Transit Forwarding Operations"), since all broadcast traffic is explicitly intended to reach every attached end station (known or unknown), contains a few peripheral ties to the use of DRB. In a way that is very similar to proposed replacement text in section 5.2, using any approach other than DRB has some very extreme complications associated with it for the broadcast case (the unkown case is already identified and addressed explicitly in the proposed replacement text above). I propose the following change: Replace the fourth, fifth and sixth paragraphs with the following 4 paragraphs - "Note that an interface over which an RBridge may egress frames is any interface for which the RBridge is the primary point of end station attachment for one or more end stations, or the RBridge determined to be responsible for broadcast delivery. "RBridges must not wait to determine that one (or more) Ethernet end stations are present on an interface before deciding to forward decapsulated broadcast frames on that interface. An exception case would exist if RBridges have been configured to treat a local link as a point to point connection between two RBridges, or otherwise configured to ignore the possible presence of end stations in this case. "Forwarding information is selected for each broadcast frame received by any RBridge (based - for example - on identifying the ingress RBridge for the frame) for all corresponding Multi-destination TRILL Forwarding Database entries. Each RBridge may thus be required to replicate one RBridge encapsulated broadcast frame for each interface that is determined from Multi-destination TRILL Forwarding Database entries corresponding to the frame's ingress RBridge. This includes decapsulated broadcast frames for each interface for which the RBridge is responsible for egressing broadcast frames (as might have been determined previously by DRB election, for example). "Note that frame replication and forwarding should be scoped by VLAN if VLAN support is provided. Also note that an egress RBridge may be required to transmit a decapsulated frame on the same interface on which it received the RBridge encapsulated frame." ______________________________________________________________________ And, of course, after making these changes, update the TOC... -- Eric Gray Principal Engineer Ericsson From james.d.carlson at sun.com Fri Feb 22 06:48:12 2008 From: james.d.carlson at sun.com (James Carlson) Date: Fri, 22 Feb 2008 09:48:12 -0500 Subject: [rbridge] Proposed changes to the architecture based on IETF-70... In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF028072D6@eusrcmw721.eamcs.ericsson.se> References: <941D5DCD8C42014FAF70FB7424686DCF028072D6@eusrcmw721.eamcs.ericsson.se> Message-ID: <18366.57516.603679.583262@gargle.gargle.HOWL> Eric Gray writes: > Several people pointed out that the architecture should not assume a > DRB election process will be used. This is technically correct, and > - for that reason - not directly something that needs consensus to > change, at least in theory. Could someone please post the problem statement? Besides just making the DRB election "optional," I think it'd be good to have a summary statement of what problem is solved by making it possible to run without DRB election. (I'm guessing this was discussed somewhere ... but I wasn't able to locate it in the archives.) -- 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 Fri Feb 22 07:44:27 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 22 Feb 2008 09:44:27 -0600 Subject: [rbridge] Proposed changes to the architecture based on IETF-70... In-Reply-To: <18366.57516.603679.583262@gargle.gargle.HOWL> References: <941D5DCD8C42014FAF70FB7424686DCF028072D6@eusrcmw721.eamcs.ericsson.se> <18366.57516.603679.583262@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02834654@eusrcmw721.eamcs.ericsson.se> James, I don't think "problem statement" is the real requirement relating to this issue. Speaking strictly from what shoud be included in an architectural overview, it is a FACT that there is no architectural requirement that a DRB election process is required (emphasis on "election") - or that there necessarily must be a "designated RBridge" in any (unscoped) general sense. In a way, I might have been guilty of laziness because I felt 1) it is obvious we are going to use some sort of election process (why re-invent the wheel?) and 2) it seemed obvious - based on continuing cycles of discussion - that we would most likely end up using existing technical approaches to elect a DRB for some reasonable VLAN-based, or interface-based, basis. The point was made that this is not necessarily a valid assumption to make at the architectural level and that, at that level, what is really needed is to spell out what is required. Having been called on my laziness, I agreed to spell out what the architectural requirements - with respect to what is actually needed when more than one RBridge might act as the ingress and/or egress. They break down into two categories: 1) why there should be - at least in some cases - a designated ingress and/or egress RBridge, under what general conditions this might be required and what are the limitations that we may expect to apply otherwise. 2) what the advantages and disadvantages are for using some form of automated process for handling the scenarios where such a function is required - such as an election process - as opposed to some form of hardwired or configured approach. I believe the changes I've proposed effectively replace the earlier assumption of a DRB election process with the more complicated architectural requirements that - in the end - are very likely going to justify using a DRB election process. I guess - as nearly as I can define such a thing - the "problem statement" is this: in a general sense, there is no particular reason why a DRB election process would be needed in every possible solution to the TRILL problem space. As I have since learned, this breaks down into the 2 specific areas listed above - i.e. - why "election", and why "DRB"? Hopefully this helps... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Friday, February 22, 2008 9:48 AM > To: Eric Gray > Cc: rbridge at postel.org > Subject: Re: [rbridge] Proposed changes to the architecture > based on IETF-70... > Importance: High > > Eric Gray writes: > > Several people pointed out that the architecture should not assume a > > DRB election process will be used. This is technically correct, and > > - for that reason - not directly something that needs consensus to > > change, at least in theory. > > Could someone please post the problem statement? Besides just making > the DRB election "optional," I think it'd be good to have a summary > statement of what problem is solved by making it possible to run > without DRB election. > > (I'm guessing this was discussed somewhere ... but I wasn't able to > locate it in the archives.) > > -- > 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 Fri Feb 22 07:51:12 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 22 Feb 2008 09:51:12 -0600 Subject: [rbridge] Proposed changes to the architecture based on IETF-70... In-Reply-To: <18366.57516.603679.583262@gargle.gargle.HOWL> References: <941D5DCD8C42014FAF70FB7424686DCF028072D6@eusrcmw721.eamcs.ericsson.se> <18366.57516.603679.583262@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0283467B@eusrcmw721.eamcs.ericsson.se> James, Also, from the minutes of the last meeting: "Designated RBridge (DRB) text in architecture document doesn't follow the protocol document in providing for DRB to assign encaps/decaps role. It should describe the constraint - that the protocol must have a mechanism so that a native frame is not encaps by more than one RB. "Eric Gray: I'll change that." Note that - while this part of the minutes provides an "encapsulated" (like the pun?) form of the actual discussion, and is sufficient to justify the need for the changes I proposed - it does not really do justice to the entire discussion. Hopefully it is not actually going to be necessary to repeat the entire discussion at the next meeting. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Friday, February 22, 2008 9:48 AM > To: Eric Gray > Cc: rbridge at postel.org > Subject: Re: [rbridge] Proposed changes to the architecture > based on IETF-70... > Importance: High > > Eric Gray writes: > > Several people pointed out that the architecture should not assume a > > DRB election process will be used. This is technically correct, and > > - for that reason - not directly something that needs consensus to > > change, at least in theory. > > Could someone please post the problem statement? Besides just making > the DRB election "optional," I think it'd be good to have a summary > statement of what problem is solved by making it possible to run > without DRB election. > > (I'm guessing this was discussed somewhere ... but I wasn't able to > locate it in the archives.) > > -- > 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 Fri Feb 22 09:23:36 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Fri, 22 Feb 2008 11:23:36 -0600 Subject: [rbridge] Proposed changes to the architecture based onIETF-70... In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF0283467B@eusrcmw721.eamcs.ericsson.se> References: <941D5DCD8C42014FAF70FB7424686DCF028072D6@eusrcmw721.eamcs.ericsson.se><18366.57516.603679.583262@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF0283467B@eusrcmw721.eamcs.ericsson.se> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0283480F@eusrcmw721.eamcs.ericsson.se> Folks, There was one other change I was asked to make at the last meeting. There were comments about the fact that the Architecture draft assumes IS-IS. Since this was the result of direction from the working group chairs and ADs - as a consequence of removing the "routing requirements" draft from the chartered goals - this was what I was supposed to do. However, there was an action item I did not realize I had picked up out of that discussion until just now re-reading the minutes from the last meeting. The note was as follows: "General opinion seemed to be that the architecture document should pull in some condensed routing requirements information and then have text saying 'looks like we are using IS-IS' or the like. Should be such as to permit other protocols than IS-IS in the future." _____________________________________________________________________ In addressing this note, I propose to add new text - after the following two paragraphs (in the the Introduction section): "Peer information may be acquired via the routing protocol, or may be discovered as a result of RBridge-specific peer discovery mechanisms. Details of specific peer information requirements - as well as how this information will be acquired is specified in protocol specifications (e.g. - [3]). "Topology information is expected to be acquired via the link-state routing protocol." After the above paragraphs, I propose to add the following text: "In addition to the requirement that the routing protocol should be an existing link-state routing protocol, which possibly provides a mechanism for (or re-use of an existing) neighbor/peer discovery, the routing protocol should be able to work with minimal (or no) configuration - using algorithmically derived addressing, for example, assuming the use of addresses is required. "Given the potential choices, IS-IS routing has been chosen at this time, and is assumed in this Architecture. The fact that this is assumed in this architecture is - in no way - intended to preclude use of another link state routing protocol, or any other routing protocol, in any solution not described in this Architecture." -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray > Sent: Friday, February 22, 2008 10:51 AM > To: James Carlson > Cc: rbridge at postel.org > Subject: Re: [rbridge] Proposed changes to the architecture > based onIETF-70... > > James, > > Also, from the minutes of the last meeting: > > "Designated RBridge (DRB) text in architecture document doesn't follow > the protocol document in providing for DRB to assign encaps/decaps > role. It should describe the constraint - that the protocol must have > a mechanism so that a native frame is not encaps by more than one RB. > > "Eric Gray: I'll change that." > > Note that - while this part of the minutes provides an "encapsulated" > (like the pun?) form of the actual discussion, and is sufficient to > justify the need for the changes I proposed - it does not really do > justice to the entire discussion. Hopefully it is not actually going > to be necessary to repeat the entire discussion at the next meeting. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: James Carlson [mailto:james.d.carlson at sun.com] > > Sent: Friday, February 22, 2008 9:48 AM > > To: Eric Gray > > Cc: rbridge at postel.org > > Subject: Re: [rbridge] Proposed changes to the architecture > > based on IETF-70... > > Importance: High > > > > Eric Gray writes: > > > Several people pointed out that the architecture should > not assume a > > > DRB election process will be used. This is technically > correct, and > > > - for that reason - not directly something that needs consensus to > > > change, at least in theory. > > > > Could someone please post the problem statement? Besides > just making > > the DRB election "optional," I think it'd be good to have a summary > > statement of what problem is solved by making it possible to run > > without DRB election. > > > > (I'm guessing this was discussed somewhere ... but I wasn't able to > > locate it in the archives.) > > > > -- > > 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 Sun Feb 24 07:05:48 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 24 Feb 2008 10:05:48 -0500 Subject: [rbridge] TRILL Use of IS-IS Message-ID: <3870C46029D1F945B1472F170D2D9790038A7779@de01exm64.ds.mot.com> Hi, There is an individual submission draft posted at ftp://ftp.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-isis-00. txt. This is essentially an intermediate draft between the TRILL base protocol draft and the expired Dave Ward draft on generic use of IS-IS for Layer 2 forwarding. An archived copy of the Ward draft is at http://www.watersprings.org/pub/id/draft-ward-l2isis-02.txt. The trill-rbridge-isis draft is intended to go with a -07 version of the base protocol specification which I hope will be posted by the deadline tomorrow however, the isis-00 and -07 protocol drafts may turn out to be slightly out of synch with each other. In any case, this isis draft is a -00 draft and probably needs work. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Donald.Eastlake at motorola.com Sun Feb 24 07:06:39 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 24 Feb 2008 10:06:39 -0500 Subject: [rbridge] TRILL Options Message-ID: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com> An individual draft has been posted at ftp://ftp.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options- 00.txt for discussion. It gives an example of a more complete options specification with some example specific options. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From touch at ISI.EDU Sun Feb 24 10:39:35 2008 From: touch at ISI.EDU (Joe Touch) Date: Sun, 24 Feb 2008 10:39:35 -0800 Subject: [rbridge] TRILL PAS update - 02 posted Message-ID: <47C1B9E7.90504@isi.edu> Hi, all, The following addresses changes to the TRILL PAS. Note that there are two current issues, neither of which is critical but both would be useful to confirm (see notes below). An updated ID has been posted and should appear shortly. Joe ---------------------------------- 1 Intro remove caveat about use of terminology; it was needed only while the doc was in process 2.2 convergence under reconfiguration remove question about timescales; this doc does not introduce the issue of convergence timescale in a new context 2.4 other ethernet extensions removed clarification question about 802.1v added note as to which extensions subsume others (D includes w, Q includes v and s) 3.1 no change to link capablities removed question about 802.1v (as per above) changed to lower-case v 3.3 forwarding loop mitigation remove question about serialized / unioned traces, noted that these terms not created by this doc 3.4 spanning tree management the need for pictures here is omitted; the point appears to have been sufficiently made without such pictures 3.5 multiple attachments removed the caveat that this section might be omitted CONSENSUS QUESTION: since no argument to the contrary has been made, I would like to request a consensus check that this section should be retained 3.8 optimizations removed the assertion that more needs to be said here CONSENSUS QUESTION: since no argument to the contrary has been made, I would like to request a consensus check that this section should be used in its current form 3.9 internet architecture issues completed citation for router-router IGMP 5 security considerations completed citation for ipv6 secure nd 7 conclusions this section has been removed as it was vacuous and is not needed ref 6 removed ref to 802.1w, since it is in 802.1D; added note on 802.1D ref replaced rfc 2461 with rfc 4861 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080224/34cc58da/signature.bin From Internet-Drafts at ietf.org Sun Feb 24 10:45:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Sun, 24 Feb 2008 10:45:01 -0800 (PST) Subject: [rbridge] I-D Action:draft-ietf-trill-prob-02.txt Message-ID: <20080224184501.6EBF528C162@core3.amsl.com> ENCODING mime FILE /internet-drafts/draft-ietf-trill-prob-02.txt -------------- next part -------------- From Caitlin.Bestler at neterion.com Mon Feb 25 10:04:28 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Mon, 25 Feb 2008 13:04:28 -0500 Subject: [rbridge] TRILL Options In-Reply-To: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> Not that the list of options described in this document needs to be all inclusive, but I think there is one class of option at least as probable as those cited here: a "pseudo-router" option. This option would allow an RBridge to report congestion as though it were a router, by encoding what a ECN capable router would have encoded -- but without requiring the RBridge to actually modify L3 headers. From james.d.carlson at sun.com Mon Feb 25 10:35:33 2008 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 25 Feb 2008 13:35:33 -0500 Subject: [rbridge] TRILL Options In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com> <78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> Message-ID: <18371.2677.623933.160499@gargle.gargle.HOWL> Caitlin Bestler writes: > Not that the list of options described in this document needs to > be all inclusive, but I think there is one class of option at least > as probable as those cited here: a "pseudo-router" option. > > This option would allow an RBridge to report congestion as though > it were a router, by encoding what a ECN capable router would have > encoded -- but without requiring the RBridge to actually modify > L3 headers. Why would it need to be an option? Since we know about ECN now, why not just reserve a couple of bits for it, and allow the bridges that know how to mark properly do so? (Those that don't know how will just blindly forward the existing bits along, which is what you want for ECN anyway. An ECN-incapable egress would just lose the bits.) Perhaps I'm missing the point, but I think the only reason to have options is that there's something that requires inter-bridge cooperation. If it doesn't require cooperation in order to achieve interoperability, then it doesn't need an option. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Caitlin.Bestler at neterion.com Mon Feb 25 11:11:33 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Mon, 25 Feb 2008 14:11:33 -0500 Subject: [rbridge] TRILL Options In-Reply-To: <18371.2677.623933.160499@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com><78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> <18371.2677.623933.160499@gargle.gargle.HOWL> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter> ECN-like bits *could* be defined in the RBridge header, but they would not be necessary for *RBridge* functionality, but rather for RBridges to provide this bonus info to the host stacks. I would be perfectly happy with ECN-like bits being encoded in the RBridge header, but I can't really make a case as to why the information needs to be there rather than in options. Encoding it in the options will work. If there is enough of a consensus that almost everyone would find ECN-like reporting useful for RBridges then they could be promoted, but like most of the other speculative options that Donald listed, this is just an idea about something that seems likely to be advantageous. It is not a concrete proposal that has been prototype tested or anything like that. > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Monday, February 25, 2008 10:36 AM > To: Caitlin Bestler > Cc: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] TRILL Options > > Caitlin Bestler writes: > > Not that the list of options described in this document needs to > > be all inclusive, but I think there is one class of option at least > > as probable as those cited here: a "pseudo-router" option. > > > > This option would allow an RBridge to report congestion as though > > it were a router, by encoding what a ECN capable router would have > > encoded -- but without requiring the RBridge to actually modify > > L3 headers. > > Why would it need to be an option? > > Since we know about ECN now, why not just reserve a couple of bits for > it, and allow the bridges that know how to mark properly do so? > (Those that don't know how will just blindly forward the existing bits > along, which is what you want for ECN anyway. An ECN-incapable egress > would just lose the bits.) > > Perhaps I'm missing the point, but I think the only reason to have > options is that there's something that requires inter-bridge > cooperation. If it doesn't require cooperation in order to achieve > interoperability, then it doesn't need an option. > > -- > 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 Radia.Perlman at sun.com Mon Feb 25 15:48:22 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 25 Feb 2008 15:48:22 -0800 Subject: [rbridge] TRILL Use of IS-IS In-Reply-To: <3870C46029D1F945B1472F170D2D9790038A7779@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790038A7779@de01exm64.ds.mot.com> Message-ID: <47C353C6.3080309@sun.com> I like this draft, which I'm just saying explicitly because in the past I've not been all that enthusiastic about options. However, I'm still unconvinced about the need for critical options, but it doesn't seem that onerous to provide for them. And as for the integrity protection option in the draft, (section 3.4), why not just protect the inner packet, which does not get modified hop by hop? And furthermore, it seems like security ought to be end-to-end and not ingress-to-egress RBridge, so I'm not sure how useful it is to provide it, especially if computing it is nontrivial. As for congestion indication, or anything else (like flow ID), in theory we could provide for it in the main TRILL header, but there would have to be room for it. Maybe eventually we could do a new version of the header that had some of the options upgraded to be in the main header, and possibly shuffle the header along the lines Don proposed awhile ago (moving the VLAN bits into the TRILL header, for instance. Radia Eastlake III Donald-LDE008 wrote: > Hi, > > There is an individual submission draft posted at > ftp://ftp.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-isis-00. > txt. > > This is essentially an intermediate draft between the TRILL base > protocol draft and the expired Dave Ward draft on generic use of IS-IS > for Layer 2 forwarding. An archived copy of the Ward draft is at > http://www.watersprings.org/pub/id/draft-ward-l2isis-02.txt. > > The trill-rbridge-isis draft is intended to go with a -07 version of the > base protocol specification which I hope will be posted by the deadline > tomorrow however, the isis-00 and -07 protocol drafts may turn out to be > slightly out of synch with each other. In any case, this isis draft is a > -00 draft and probably needs work. > > Thanks, > Donald > > ==================================================== > Donald E. Eastlake 3rd +1-508-786-7554 (work) > Motorola Laboratories > 111 Locke Drive > Marlborough, MA 01752 USA > Donald.Eastlake at motorola.com > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Internet-Drafts at ietf.org Mon Feb 25 16:30:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 25 Feb 2008 16:30:01 -0800 (PST) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-07.txt Message-ID: <20080226003001.314F528C9CA@core3.amsl.com> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : Rbridges: Base Protocol Specification Author(s) : R. Perlman Filename : draft-ietf-trill-rbridge-protocol-07.txt Pages : 84 Date : 2008-2-25 RBridges allow for optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and multipathing for both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 bridges as well as current IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and optimization of the distribution of multi-destination frames based on VLAN and IP derived multicast groups. It also allows forwarding tables to be based on RBridge destinations (rather than end node destinations), which allows internal forwarding tables to be substantially smaller than in conventional bridge systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trill-rbridge-protocol-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Internet-Drafts at ietf.org Mon Feb 25 17:30:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 25 Feb 2008 17:30:01 -0800 (PST) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-05.txt Message-ID: <20080226013001.BEE7D28C230@core3.amsl.com> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : The Architecture of an RBridge Solution to TRILL Author(s) : E. Gray, J. Touch, R. Perlman Filename : draft-ietf-trill-rbridge-arch-05.txt,.pdf Pages : 36 Date : 2008-2-25 RBridges are link layer (L2) devices that use a routing protocol as a control plane. This combines several of the benefits of the link layer with those of the network layer. For example RBridges use existing link state routing, without necessarily requiring configuration, to improve aggregate throughput, for RBridge to RBridge traffic. RBridges also may support IP multicast and IP address resolution optimizations. They are intended to be applicable to L2 network sizes similar to those of conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also support VLANs (although this generally requires configuration) while otherwise attempting to retain as much 'plug and play' as is already available in existing bridges. This document proposes an architecture for RBridge systems as a solution to the TRILL problem, defines terminology, and describes basic components and desired behavior. One (or more) separate documents will specify protocols and mechanisms that satisfy the architecture presented herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trill-rbridge-arch-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Donald.Eastlake at motorola.com Tue Feb 26 07:22:56 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 26 Feb 2008 10:22:56 -0500 Subject: [rbridge] ECN RE: TRILL Options In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com><78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> <18371.2677.623933.160499@gargle.gargle.HOWL> <78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter> Message-ID: <3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com> A few things: Currently there are only two free bits in the TRILL Header. If the intent of the ECN feature is to affect host behavior, how is this communicated to the host? If it uses bits either in the TRILL Header or in a TRILL Option, these are lost at the egress Rbridge. -- Although perhaps affecting Rbridge behavior could also be beneficial. And for IP frames, we could set bits in the IP header... There is also the 802.1 Congestion Management effort perking along... Thanks, Donald -----Original Message----- From: Caitlin Bestler [mailto:Caitlin.Bestler at neterion.com] Sent: Monday, February 25, 2008 2:12 PM To: James Carlson Cc: Eastlake III Donald-LDE008; Rbridge at postel.org Subject: RE: [rbridge] TRILL Options ECN-like bits *could* be defined in the RBridge header, but they would not be necessary for *RBridge* functionality, but rather for RBridges to provide this bonus info to the host stacks. I would be perfectly happy with ECN-like bits being encoded in the RBridge header, but I can't really make a case as to why the information needs to be there rather than in options. Encoding it in the options will work. If there is enough of a consensus that almost everyone would find ECN-like reporting useful for RBridges then they could be promoted, but like most of the other speculative options that Donald listed, this is just an idea about something that seems likely to be advantageous. It is not a concrete proposal that has been prototype tested or anything like that. > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Monday, February 25, 2008 10:36 AM > To: Caitlin Bestler > Cc: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] TRILL Options > > Caitlin Bestler writes: > > Not that the list of options described in this document needs to > > be all inclusive, but I think there is one class of option at least > > as probable as those cited here: a "pseudo-router" option. > > > > This option would allow an RBridge to report congestion as though > > it were a router, by encoding what a ECN capable router would have > > encoded -- but without requiring the RBridge to actually modify > > L3 headers. > > Why would it need to be an option? > > Since we know about ECN now, why not just reserve a couple of bits for > it, and allow the bridges that know how to mark properly do so? > (Those that don't know how will just blindly forward the existing bits > along, which is what you want for ECN anyway. An ECN-incapable egress > would just lose the bits.) > > Perhaps I'm missing the point, but I think the only reason to have > options is that there's something that requires inter-bridge > cooperation. If it doesn't require cooperation in order to achieve > interoperability, then it doesn't need an option. > > -- > 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 Tue Feb 26 08:10:43 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 26 Feb 2008 11:10:43 -0500 Subject: [rbridge] Options... In-Reply-To: <47C353C6.3080309@sun.com> References: <3870C46029D1F945B1472F170D2D9790038A7779@de01exm64.ds.mot.com> <47C353C6.3080309@sun.com> Message-ID: <3870C46029D1F945B1472F170D2D9790038E36A6@de01exm64.ds.mot.com> Hi Radia, See below at @@@ -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman at sun.com] Sent: Monday, February 25, 2008 6:48 PM To: Eastlake III Donald-LDE008 Cc: Rbridge at postel.org Subject: Re: [rbridge] TRILL Use of IS-IS I like this draft, which I'm just saying explicitly because in the past I've not been all that enthusiastic about options. @@@ Thanks. However, I'm still unconvinced about the need for critical options, but it doesn't seem that onerous to provide for them. And as for the integrity protection option in the draft, (section 3.4), why not just protect the inner packet, which does not get modified hop by hop? And furthermore, it seems like security ought to be end-to-end and not ingress-to-egress RBridge, so I'm not sure how useful it is to provide it, especially if computing it is nontrivial. @@@ Sure end-to-end security is best but it is a fallacy to believe that security should be ignored unless it can be the best. That would imply, for example, that 802.11 (Wi-Fi) security is useless because it is just hop by hop. But people at public hot spots really don't want everyone in the vicinity to be able to tell what insecure web sites they are browsing and the like. @@@ The computations for authentication and/or encryption will be nontrivial but how much of a burden that is depends on what hardware assist you have. People in the wireless world generally think of authentication and encryption as being free because there is usually hardware built in that can do it at your maximum transmission rate. That hardware will just be sitting idle if you choose not to use security. As for congestion indication, or anything else (like flow ID), in theory we could provide for it in the main TRILL header, but there would have to be room for it. Maybe eventually we could do a new version of the header that had some of the options upgraded to be in the main header, and possibly shuffle the header along the lines Don proposed awhile ago (moving the VLAN bits into the TRILL header, for instance. Radia @@@ Thanks, @@@ Donald From Donald.Eastlake at motorola.com Tue Feb 26 08:21:28 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 26 Feb 2008 11:21:28 -0500 Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-07.txt In-Reply-To: <20080226003001.314F528C9CA@core3.amsl.com> References: <20080226003001.314F528C9CA@core3.amsl.com> Message-ID: <3870C46029D1F945B1472F170D2D9790038E36B7@de01exm64.ds.mot.com> Hi, just some quick comments on this draft. I believe the list of changes from -06 to -07 in the Appendix is reasonably complete. Section 5, the pseudo-code, has not been fully updated. On Options, there was discussion on the mailing list which didn't seem, to me, to produce a particularly clear consensus. The protocol draft has the critical option summary bits but the separate non-WG options draft which has been posted is written so that, with relatively minor effort, part of it could replace Section 3.5 of the protocol draft without critical option summary bits. This makes little difference for transit Rbridges; they would just have to check that the top two bits of the first byte of the options area are not zero as opposed to checking that the top bit is not one. However, the separate non-WG draft would, under some circumstances, require an egress Rbridge to scan the options present. Thanks, Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Internet-Drafts at ietf.org Sent: Monday, February 25, 2008 7:30 PM To: i-d-announce at ietf.org Cc: rbridge at postel.org Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : Rbridges: Base Protocol Specification Author(s) : R. Perlman Filename : draft-ietf-trill-rbridge-protocol-07.txt Pages : 84 Date : 2008-2-25 RBridges allow for optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and multipathing for both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 bridges as well as current IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and optimization of the distribution of multi-destination frames based on VLAN and IP derived multicast groups. It also allows forwarding tables to be based on RBridge destinations (rather than end node destinations), which allows internal forwarding tables to be substantially smaller than in conventional bridge systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-07 .txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trill-rbridge-protocol-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From james.d.carlson at sun.com Tue Feb 26 08:09:38 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 26 Feb 2008 11:09:38 -0500 Subject: [rbridge] ECN RE: TRILL Options In-Reply-To: <3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com> <78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> <18371.2677.623933.160499@gargle.gargle.HOWL> <78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter> <3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com> Message-ID: <18372.14786.861502.473285@gargle.gargle.HOWL> Eastlake III Donald-LDE008 writes: > A few things: > > Currently there are only two free bits in the TRILL Header. That's a pretty good reason to be hesitant. ;-} > If the intent of the ECN feature is to affect host behavior, how is this > communicated to the host? Note that "hosts" in TRILL terminology are quite likely to be "routers" in the network layer world. In any event, I'd expect the encapsulating TRILL node to copy the ECN bits (likely similar to RFC 3168, but perhaps requiring mapping for non-IP protocols) into the TRILL header, and the decapsulating TRILL node to apply those ECN bits to the encapsulated packet before disgorging it onto the destination network. You then have a record of congestion encountered in the middle of the bridged network. Systems that don't do ECN will generally ignore the bits (and will set 00 on transmit), and those that do it will do the Right Thing. If the TRILL network doesn't support ECN at all, then the bits get copied from input to output unmolested -- meaning that congestion through the larger network is still detected, but that congestion within the TRILL network is invisible. If the TRILL encapsulator doesn't do ECN, then the bits will be zero on input, and the egress can ignore them on output. If the egress doesn't do ECN, then the inner packet will be left unchanged, again meaning that ECN works but that the TRILL network is not visible. Finally, if the carried protocol doesn't support ECN, or the ingress RBridge doesn't know how the next level protocol deals with ECN, then set the bits to zero on entry and thus do nothing on egress. No "intent" needs to be communicated, as best I can tell. It's a best-effort signaling mechanism. > If it uses bits either in the TRILL Header or > in a TRILL Option, these are lost at the egress Rbridge. -- Although > perhaps affecting Rbridge behavior could also be beneficial. And for IP > frames, we could set bits in the IP header... That's it exactly. I think ECN is pretty much worthless otherwise; it's an end-to-end exercise involving the transport layer, or it may as well not be implemented at all. ECN that's consumed by RBridges alone doesn't make any sense to me. > There is also the 802.1 Congestion Management effort perking along... I'm afraid I don't know what they're doing. :-< -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Caitlin.Bestler at neterion.com Tue Feb 26 09:22:56 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Tue, 26 Feb 2008 12:22:56 -0500 Subject: [rbridge] ECN RE: TRILL Options In-Reply-To: <3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com><78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> <18371.2677.623933.160499@gargle.gargle.HOWL> <78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter> <3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77031841F0@nekter> Donald Eastlake wrote: > A few things: > > Currently there are only two free bits in the TRILL Header. > > If the intent of the ECN feature is to affect host behavior, how is > this communicated to the host? Very cleverly. Which is to say, that the RBridge and the hosts it services would have to have some form of local collaboration on traffic flow for this information to be fully useful. Since it would not be universally applicable I had assumed that this usage would have a very poor chance of grabbing the last few bits in the TRILL Header or in getting it to expand by 32 bits. > If it uses bits either in the TRILL Header or > in a TRILL Option, these are lost at the egress Rbridge. -- Although > perhaps affecting Rbridge behavior could also be beneficial. And for IP > frames, we could set bits in the IP header... > My assumption is that having an L2 entity modify L3 headers is something best avoided. Of course, if the group thought this was the best strategy it could add a "MAY modify the IP header for the following reasons" clause. But while an RBridge is more like a Router than a traditional Bridge, I still think that we're better off thinking of it as an L2 device and NOT encouraging it to play with L3 headers. That's a slippery slope that leads all too quickly to trying to standardize PNAT behavior and a dozen other forms of middlebox mischief. > There is also the 802.1 Congestion Management effort perking along... > I'm viewing this more as a supplement to 802.1 Congestion Management. The 802.1Qau effort is more focused on short congestion storms, while IETF efforts have been exploring topics such as admission control. It would be a shame if by enabling larger L2 clouds, RBridges diminished the value of these IETF congestion controls that work over a longer time period than 802.1Qau's methods. From Caitlin.Bestler at neterion.com Tue Feb 26 09:29:35 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Tue, 26 Feb 2008 12:29:35 -0500 Subject: [rbridge] ECN RE: TRILL Options In-Reply-To: <18372.14786.861502.473285@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com><78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter><18371.2677.623933.160499@gargle.gargle.HOWL><78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter><3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com> <18372.14786.861502.473285@gargle.gargle.HOWL> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77031841F9@nekter> James Carlson wrote: > In any event, I'd expect the encapsulating TRILL node to copy the ECN > bits (likely similar to RFC 3168, but perhaps requiring mapping for > non-IP protocols) into the TRILL header, and the decapsulating TRILL > node to apply those ECN bits to the encapsulated packet before > disgorging it onto the destination network. You then have a record of > congestion encountered in the middle of the bridged network. > > Systems that don't do ECN will generally ignore the bits (and will set > 00 on transmit), and those that do it will do the Right Thing. If the > TRILL network doesn't support ECN at all, then the bits get copied > from input to output unmolested -- meaning that congestion through the > larger network is still detected, but that congestion within the TRILL > network is invisible. > > If the TRILL encapsulator doesn't do ECN, then the bits will be zero > on input, and the egress can ignore them on output. If the egress > doesn't do ECN, then the inner packet will be left unchanged, again > meaning that ECN works but that the TRILL network is not visible. > > Finally, if the carried protocol doesn't support ECN, or the ingress > RBridge doesn't know how the next level protocol deals with ECN, then > set the bits to zero on entry and thus do nothing on egress. > > No "intent" needs to be communicated, as best I can tell. It's a > best-effort signaling mechanism. > > > If it uses bits either in the TRILL Header or > > in a TRILL Option, these are lost at the egress Rbridge. -- Although > > perhaps affecting Rbridge behavior could also be beneficial. And for > > IP frames, we could set bits in the IP header... > > That's it exactly. I think ECN is pretty much worthless otherwise; > it's an end-to-end exercise involving the transport layer, or it may > as well not be implemented at all. ECN that's consumed by RBridges > alone doesn't make any sense to me. > A TRILL option with ECN semantics could be used directly by an RBridge that had other traffic control options on its local ports than just PAUSE, Priority-based Flow Control or Drop. If such methods were available, they would be preferable to modifying the L3 header. From james.d.carlson at sun.com Tue Feb 26 09:43:37 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 26 Feb 2008 12:43:37 -0500 Subject: [rbridge] ECN RE: TRILL Options In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77031841F9@nekter> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com> <78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter> <18371.2677.623933.160499@gargle.gargle.HOWL> <78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter> <3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com> <18372.14786.861502.473285@gargle.gargle.HOWL> <78C9135A3D2ECE4B8162EBDCE82CAD77031841F9@nekter> Message-ID: <18372.20425.938082.789131@gargle.gargle.HOWL> Caitlin Bestler writes: > > That's it exactly. I think ECN is pretty much worthless otherwise; > > it's an end-to-end exercise involving the transport layer, or it may > > as well not be implemented at all. ECN that's consumed by RBridges > > alone doesn't make any sense to me. > > > > A TRILL option with ECN semantics could be used directly by an RBridge > that had other traffic control options on its local ports than just > PAUSE, Priority-based Flow Control or Drop. If such methods were > available, they would be preferable to modifying the L3 header. If that's the intent, then I'm just neutral on the proposal. I can see value in ECN behavior that interoperates with existing network layer ECN semantics, but if it's its own independent beast, it's no longer interesting ... at least to me. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Caitlin.Bestler at neterion.com Tue Feb 26 10:26:21 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Tue, 26 Feb 2008 13:26:21 -0500 Subject: [rbridge] ECN RE: TRILL Options In-Reply-To: <18372.20425.938082.789131@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D9790038A777A@de01exm64.ds.mot.com><78C9135A3D2ECE4B8162EBDCE82CAD7703183EAA@nekter><18371.2677.623933.160499@gargle.gargle.HOWL><78C9135A3D2ECE4B8162EBDCE82CAD7703183F15@nekter><3870C46029D1F945B1472F170D2D9790038E3634@de01exm64.ds.mot.com><18372.14786.861502.473285@gargle.gargle.HOWL><78C9135A3D2ECE4B8162EBDCE82CAD77031841F9@nekter> <18372.20425.938082.789131@gargle.gargle.HOWL> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703184240@nekter> > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Tuesday, February 26, 2008 9:44 AM > To: Caitlin Bestler > Cc: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: RE: ECN RE: [rbridge] TRILL Options > > Caitlin Bestler writes: > > > That's it exactly. I think ECN is pretty much worthless otherwise; > > > it's an end-to-end exercise involving the transport layer, or it > may > > > as well not be implemented at all. ECN that's consumed by RBridges > > > alone doesn't make any sense to me. > > > > > > > A TRILL option with ECN semantics could be used directly by an > RBridge > > that had other traffic control options on its local ports than just > > PAUSE, Priority-based Flow Control or Drop. If such methods were > > available, they would be preferable to modifying the L3 header. > > If that's the intent, then I'm just neutral on the proposal. I can > see value in ECN behavior that interoperates with existing network > layer ECN semantics, but if it's its own independent beast, it's no > longer interesting ... at least to me. > There probably are mechanisms where ECN-semantics could supplement the congestion control mechanisms defined by 802.1Qau. But that type of extension would not naturally be developed until the 802.1Qau work was complete. When that happens, it would be a good use of a TRILL option. From Donald.Eastlake at motorola.com Tue Feb 26 15:46:31 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 26 Feb 2008 18:46:31 -0500 Subject: [rbridge] TRILL Monday morning in Philadelphia Message-ID: <3870C46029D1F945B1472F170D2D9790038E39E5@de01exm64.ds.mot.com> The TRILL WG meeting at the Philadelphia IETF meeting next month has been scheduled for 9am Monday morning. See https://datatracker.ietf.org/meeting/71/agenda.html. While such things are not guaranteed, I believe that, at this point, it is very unlikely to change. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com