From Internet-Drafts at ietf.org Mon Mar 5 15:50:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 05 Mar 2007 18:50:02 -0500 Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-03.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-03.txt -------------- next part -------------- From pkoganti at Brocade.COM Tue Mar 6 12:45:09 2007 From: pkoganti at Brocade.COM (Phanidhar Koganti) Date: Tue, 6 Mar 2007 12:45:09 -0800 Subject: [rbridge] RBridge Ingress Address Message-ID: Hi, Went through the below draft briefly and had a basic question. Bear with me if this has already been answered on the list http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 .txt For Known DA Trill.EgressRBridgesAddress = egress RBRIDGE; Trill.IngressRBridgesAddress = ingress RBRIDGE; For Unknown DA / Multicast Traffic Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution Tree Trill.IngressRBridgesAddress = ingress RBRIDGE; In both the above cases the unicast forwarding and the distribution tree to use is conveyed using "Trill.EgressRBridgesAddress". My question is where does the "Trill.IngressRBridgesAddress" play a role? My second question is Learning of L2 end-node addresses are done using ISIS TLVs, why can't we learn from the data-path similar to 802.1D/Q? (Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) In such a case there would be use for the "Trill.IngressRBridgesAddress" Thanks Phanidhar Koganti Brocade From Radia.Perlman at sun.com Tue Mar 6 13:50:11 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 06 Mar 2007 13:50:11 -0800 Subject: [rbridge] RBridge Ingress Address In-Reply-To: References: Message-ID: <45EDE213.7050507@Sun.COM> You've really kind of answered your own question. Originally the shim header only had a single RBridge nickname. For unicast it was "egress". For multicast it was "ingress". Everything is engineering tradeoffs. There's seldom a "right answer", but often two perfectly reasonable choices, and we don't want the WG agonizing forever, se we seem to have chosen having both ingress and egress. The cost of having both ingress and egress is an extra 4 bytes. The advantages of having both are: a) some IEEE things (like BCN -- congestion notification) require knowing where something came from, so could use "ingress RBridge" b) tunneling usually has both source and destination, so it's "more natural" c) we might at some point choose, as you suggested, to learn some or all of the endnodes based on decapsulated traffic (so only the egress RBridge would learn the mapping between the source MAC and the ingress RBridge) d) for multicast, it allows multipathing by having the ingress RBridge R1 choose a different tree (not the one rooted at R1), for distributing the multicast frame e) for multicast, it allows configuring things to compute fewer trees, because instead of requiring all RBridges to compute a tree rooted at every ingress, RBridges can request that they not be tree Roots. (except the RBridges with lowest IS-IS ID -- that one has to be the root of a tree so that there is always at least one tree all the RBridges compute). There might have been other reasons, but these are the ones I could remember off the top of my head. Radia Phanidhar Koganti wrote On 03/06/07 12:45,: >Hi, > >Went through the below draft briefly and had a basic question. Bear with >me if this has already been answered on the list > >http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 >.txt > >For Known DA > > Trill.EgressRBridgesAddress = egress RBRIDGE; > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >For Unknown DA / Multicast Traffic > > Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution >Tree > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >In both the above cases the unicast forwarding and the distribution tree >to use is conveyed using "Trill.EgressRBridgesAddress". > >My question is where does the "Trill.IngressRBridgesAddress" play a >role? > > >My second question is > >Learning of L2 end-node addresses are done using ISIS TLVs, why can't we >learn from the data-path similar to 802.1D/Q? >(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) > >In such a case there would be use for the "Trill.IngressRBridgesAddress" > >Thanks >Phanidhar Koganti >Brocade > >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > From pkoganti at Brocade.COM Tue Mar 6 17:13:31 2007 From: pkoganti at Brocade.COM (Phanidhar Koganti) Date: Tue, 6 Mar 2007 17:13:31 -0800 Subject: [rbridge] RBridge Ingress Address Message-ID: Radia, Thanks for the response. In you point c) if can learn end node addresses from the data-path then why are we not doing it? Wouldn't it be a more scalable solution for the control plane (ISIS). Thanks Phanidhar Koganti Brocade 408 333 5455 -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman at sun.com] Sent: Tuesday, March 06, 2007 1:50 PM To: Phanidhar Koganti Cc: rbridge at postel.org Subject: Re: [rbridge] RBridge Ingress Address You've really kind of answered your own question. Originally the shim header only had a single RBridge nickname. For unicast it was "egress". For multicast it was "ingress". Everything is engineering tradeoffs. There's seldom a "right answer", but often two perfectly reasonable choices, and we don't want the WG agonizing forever, se we seem to have chosen having both ingress and egress. The cost of having both ingress and egress is an extra 4 bytes. The advantages of having both are: a) some IEEE things (like BCN -- congestion notification) require knowing where something came from, so could use "ingress RBridge" b) tunneling usually has both source and destination, so it's "more natural" c) we might at some point choose, as you suggested, to learn some or all of the endnodes based on decapsulated traffic (so only the egress RBridge would learn the mapping between the source MAC and the ingress RBridge) d) for multicast, it allows multipathing by having the ingress RBridge R1 choose a different tree (not the one rooted at R1), for distributing the multicast frame e) for multicast, it allows configuring things to compute fewer trees, because instead of requiring all RBridges to compute a tree rooted at every ingress, RBridges can request that they not be tree Roots. (except the RBridges with lowest IS-IS ID -- that one has to be the root of a tree so that there is always at least one tree all the RBridges compute). There might have been other reasons, but these are the ones I could remember off the top of my head. Radia Phanidhar Koganti wrote On 03/06/07 12:45,: >Hi, > >Went through the below draft briefly and had a basic question. Bear with >me if this has already been answered on the list > >http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0 3 >.txt > >For Known DA > > Trill.EgressRBridgesAddress = egress RBRIDGE; > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >For Unknown DA / Multicast Traffic > > Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution >Tree > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >In both the above cases the unicast forwarding and the distribution tree >to use is conveyed using "Trill.EgressRBridgesAddress". > >My question is where does the "Trill.IngressRBridgesAddress" play a >role? > > >My second question is > >Learning of L2 end-node addresses are done using ISIS TLVs, why can't we >learn from the data-path similar to 802.1D/Q? >(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) > >In such a case there would be use for the "Trill.IngressRBridgesAddress" > >Thanks >Phanidhar Koganti >Brocade > >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > From Radia.Perlman at sun.com Tue Mar 6 17:35:17 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 06 Mar 2007 17:35:17 -0800 Subject: [rbridge] RBridge Ingress Address In-Reply-To: References: Message-ID: <45EE16D5.1020303@Sun.COM> There were various arguments about that as well. Personally, I think it's reasonable either way, and actually there might be a reason for some endnodes to be learned one way and others another. For instance, for access points in which endnodes enroll, it is likely better to send around announcements in IS-IS. Some of the arguments, again, off the top of my head, for why it's good to announce at least some of the endnodes a) sometimes it is clear when an endnode is no longer there (for instance, the access point finds out) in which case it's advantageous to tell everyone b) for IP nodes, it is possible for the RBridge to ping its attached endnodes to make sure they really are there. Perhaps only in response to seeing some other RBridge announce an attached endnode. c) in general only the egress RBridge will find out about S. If lots of people talk to S, then that traffic will be flooded, unless S's RBridge announces where S is. d) there might be a node that only occasionally talks and lots of nodes send it data, in which case traffic to it will often be flooded. e) I think some implementors were telling me that they didn't want to have to learn from decapsulated traffic. f) we probably do want to announce (layer 3, layer 2) pairs based on ARP/ND replies, so as to not require flooding ARP/ND queries. If most nodes are IP nodes, then that would mean most (if not all) would be advertised anyway. One reason I was happy the WG wanted to put in ingress RBridge as well as egress RBridge was because of the possibility of implicitly learning some of the endnodes. Radia Phanidhar Koganti wrote On 03/06/07 17:13,: >Radia, > >Thanks for the response. > >In you point c) if can learn end node addresses from the data-path >then why are we not doing it? Wouldn't it be a more scalable solution >for the control plane (ISIS). > >Thanks >Phanidhar Koganti >Brocade >408 333 5455 > >-----Original Message----- >From: Radia Perlman [mailto:Radia.Perlman at sun.com] >Sent: Tuesday, March 06, 2007 1:50 PM >To: Phanidhar Koganti >Cc: rbridge at postel.org >Subject: Re: [rbridge] RBridge Ingress Address > >You've really kind of answered your own question. Originally the shim >header only >had a single RBridge nickname. For unicast it was "egress". For >multicast it was >"ingress". Everything is engineering tradeoffs. There's seldom a "right > >answer", >but often two perfectly reasonable choices, and we don't want the WG >agonizing forever, >se we seem to have chosen having both ingress and egress. > >The cost of having both ingress and >egress is an extra 4 bytes. > >The advantages of having both are: >a) some IEEE things (like BCN -- congestion notification) require >knowing where something >came from, so could use "ingress RBridge" >b) tunneling usually has both source and destination, so it's "more >natural" >c) we might at some point choose, as you suggested, to learn some or all > >of the endnodes >based on decapsulated traffic (so only the egress RBridge would learn >the mapping between >the source MAC and the ingress RBridge) >d) for multicast, it allows multipathing by having the ingress RBridge >R1 choose a different >tree (not the one rooted at R1), for distributing the multicast frame >e) for multicast, it allows configuring things to compute fewer trees, >because instead of >requiring all RBridges to compute a tree rooted at every ingress, >RBridges can request >that they not be tree Roots. (except the RBridges with lowest IS-IS ID >-- that one has to be the >root of a tree so that there is always at least one tree all the >RBridges compute). > >There might have been other reasons, but these are the ones I could >remember off the top of my head. > >Radia > > > >Phanidhar Koganti wrote On 03/06/07 12:45,: > > > >>Hi, >> >>Went through the below draft briefly and had a basic question. Bear >> >> >with > > >>me if this has already been answered on the list >> >>http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0 >> >> >3 > > >>.txt >> >>For Known DA >> >> Trill.EgressRBridgesAddress = egress RBRIDGE; >> Trill.IngressRBridgesAddress = ingress RBRIDGE; >> >>For Unknown DA / Multicast Traffic >> >> Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution >>Tree >> Trill.IngressRBridgesAddress = ingress RBRIDGE; >> >>In both the above cases the unicast forwarding and the distribution >> >> >tree > > >>to use is conveyed using "Trill.EgressRBridgesAddress". >> >>My question is where does the "Trill.IngressRBridgesAddress" play a >>role? >> >> >>My second question is >> >>Learning of L2 end-node addresses are done using ISIS TLVs, why can't >> >> >we > > >>learn from the data-path similar to 802.1D/Q? >>(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) >> >>In such a case there would be use for the >> >> >"Trill.IngressRBridgesAddress" > > >>Thanks >>Phanidhar Koganti >>Brocade >> >>_______________________________________________ >>rbridge mailing list >>rbridge at postel.org >>http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> >> From erik.nordmark at sun.com Wed Mar 7 10:58:13 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 07 Mar 2007 10:58:13 -0800 Subject: [rbridge] Draft meeting agenda Message-ID: <45EF0B45.6050100@sun.com> The draft agenda is at http://www3.ietf.org/proceedings/07mar/agenda/trill.txt Erik From Radia.Perlman at sun.com Wed Mar 7 18:17:50 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 07 Mar 2007 18:17:50 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees Message-ID: <45EF724E.2040706@sun.com> It isn't totally obvious how to do RPF (reverse path forwarding) checks to make multicast forwarding safer, when we're doing bidirectional trees (ingress is R1, but R1 chooses tree root R2). So after thinking about it, I think this is how it would work, and it introduces a new field that would be nice to add to the core instance IS-IS LSP. The field is "I promise to only choose the following set of RBridges to be tree roots". The only reasons for R1 to choose a distribution tree rooted on an RBridge other than itself are: a) R1 is configured not to ask to be a tree root (so that RBridges don't have to calculate as many trees) b) R1 wants to multipath multicast originating on its attached links. The reason for having R1 preannounce is to simplify creating an RPF database associated with each tree. If tree R1 is used if and only if R1 is the ingress for the data, then the RPF tree for tree R1 would look like this, at some RBridge R in the core: for each "adjacency" (neighbor/port): one of the following: not in tree, in-port, or out-port. The RPF check would discard any incoming data for tree R1 except on the in-port. However, if R1 chooses R2 as the root of the multicast tree, then the RPF database associated with the tree R2, at some core RBridge R looks like this: Let S be the set of RBridges that have announced, in their LSPs, that they might choose R2 as the tree for multicast traffic they are sourcing into the campus. R keeps, for tree R2, and for each adjacency, {set of RBridges that are plausible ingress RBridges for packets received on that adjacency}. The set union of all of those will be S. I hope that's correct, and that I've explained it clearly.... Radia From sanjays at cisco.com Wed Mar 7 23:19:23 2007 From: sanjays at cisco.com (Sanjay Sane (sanjays)) Date: Wed, 7 Mar 2007 23:19:23 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <45EF724E.2040706@sun.com> Message-ID: <7178B7E237F45D45BE404AFF0AF58D8702AA2DBD@xmb-sjc-213.amer.cisco.com> What every rbridge wants to do is -- for every rbridge Rx that could use tree R1, On this tree R1, find which is the interface that leads me towards Rx, or leads Rx towards me. Multicast packets ingressed from Rx, and using tree R1, should be allowed to come in only on this interface. The RPF state per interface could potentially be #ofswitches * #oftrees By announcing this field, are you just trying to reduce the RPF state ? btw, should we use the term "RPF" to denote what's being checked here? What we're really checking is whether the ingress rbridge is really forwarding as per a given R1 tree. -Sanjay -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Wednesday, March 07, 2007 6:18 PM To: rbridge at postel.org Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees It isn't totally obvious how to do RPF (reverse path forwarding) checks to make multicast forwarding safer, when we're doing bidirectional trees (ingress is R1, but R1 chooses tree root R2). So after thinking about it, I think this is how it would work, and it introduces a new field that would be nice to add to the core instance IS-IS LSP. The field is "I promise to only choose the following set of RBridges to be tree roots". The only reasons for R1 to choose a distribution tree rooted on an RBridge other than itself are: a) R1 is configured not to ask to be a tree root (so that RBridges don't have to calculate as many trees) b) R1 wants to multipath multicast originating on its attached links. The reason for having R1 preannounce is to simplify creating an RPF database associated with each tree. If tree R1 is used if and only if R1 is the ingress for the data, then the RPF tree for tree R1 would look like this, at some RBridge R in the core: for each "adjacency" (neighbor/port): one of the following: not in tree, in-port, or out-port. The RPF check would discard any incoming data for tree R1 except on the in-port. However, if R1 chooses R2 as the root of the multicast tree, then the RPF database associated with the tree R2, at some core RBridge R looks like this: Let S be the set of RBridges that have announced, in their LSPs, that they might choose R2 as the tree for multicast traffic they are sourcing into the campus. R keeps, for tree R2, and for each adjacency, {set of RBridges that are plausible ingress RBridges for packets received on that adjacency}. The set union of all of those will be S. I hope that's correct, and that I've explained it clearly.... Radia _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Thu Mar 8 08:29:43 2007 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Thu, 08 Mar 2007 08:29:43 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees Message-ID: Sanjay, We are agreeing on the technical details. As for terminology, I don't care. Is there a better term than "RPF check"? And as you observed, the reason for having R1 announce the set of trees it will select is to avoid having (# of trees) * (# of RBridges) RPF state. The default is "compute a tree based on me" and "I will always choose tree rooted as me", which would result in (# of trees) state. The only RPF state at R2, for tree R1, is to put R1 onto the adjacency from which frames from R1 should arrive, and the null set on the other adjacencies in the R1 tree. The only reasons R1 should choose a tree other than itself are: a) R1 is configured to decline being a tree root, in order to cut down on the number of trees RBridges need to compute, in which case R1 will, in most cases, be configured to just announce one tree, and always select that one b) R1 is sourcing some high volume multicast sources, in which case R1 is likely to be configured to choose perhaps 2, maybe 3, but not "lots of" different trees. So with this announcement of which trees R1 will choose when ingressing packets, it greatly simplifies RPF state. Radia ----- Original Message ----- From: "Sanjay Sane (sanjays)" Date: Wednesday, March 7, 2007 11:19 pm Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees > > What every rbridge wants to do is -- > for every rbridge Rx that could use tree R1, > On this tree R1, find which is the interface that leads me towards Rx, > or leads Rx towards me. > Multicast packets ingressed from Rx, and using tree R1, should be > allowed to come in only on this interface. > > The RPF state per interface could potentially be > #ofswitches * #oftrees > > By announcing this field, are you just trying to reduce the RPF > state ? > > btw, should we use the term "RPF" to denote what's being checked here? > What we're really checking is whether the ingress rbridge is really > forwarding as per a given R1 tree. > > -Sanjay > > > -----Original Message----- > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, March 07, 2007 6:18 PM > To: rbridge at postel.org > Subject: [rbridge] How to do RPF checks for bidirectional RBridge > trees > It isn't totally obvious how to do RPF (reverse path forwarding) > checksto make multicast forwarding safer, when we're doing > bidirectional trees > (ingress is R1, but R1 chooses tree root R2). > > So after thinking about it, I think this is how it would work, and it > introduces a new field that would be nice to add to the core instance > IS-IS LSP. The field is "I promise to only choose the following set of > RBridges to be tree roots". The only reasons for R1 to choose a > distribution tree rooted on an RBridge other than itself are: > > a) R1 is configured not to ask to be a tree root (so that RBridges > don'thave to calculate as many trees) > > b) R1 wants to multipath multicast originating on its attached links. > > The reason for having R1 preannounce is to simplify creating an RPF > database associated with each tree. > > If tree R1 is used if and only if R1 is the ingress for the data, then > the RPF tree for tree R1 would look like this, at some RBridge R in > thecore: > > for each "adjacency" (neighbor/port): one of the following: not in > tree,in-port, or out-port. The RPF check would discard any incoming > data for > tree R1 except on the in-port. > > However, if R1 chooses R2 as the root of the multicast tree, then the > RPF database associated with the tree R2, at some core RBridge R looks > like this: > > Let S be the set of RBridges that have announced, in their LSPs, that > they might choose R2 as the tree for multicast traffic they are > sourcinginto the campus. > > R keeps, for tree R2, and for each adjacency, {set of RBridges that > areplausible ingress RBridges for packets received on that adjacency}. > > The set union of all of those will be S. > > I hope that's correct, and that I've explained it clearly.... > > Radia > > _______________________________________________ > 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 dino at cisco.com Thu Mar 8 09:31:54 2007 From: dino at cisco.com (Dino Farinacci) Date: Thu, 8 Mar 2007 09:31:54 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: References: Message-ID: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> > As for terminology, I don't care. Is there a better term than "RPF > check"? It it not an RPF check, because as you and Sanjay described it, the best-path from an rBridge to a receiver is on the forward path. So an appropriate and less misleading term is "the expected incoming interface check". > And as you observed, the reason for having R1 announce the set of > trees > it will select is to avoid having (# of trees) * (# of RBridges) > RPF state. The dominate state in the forwarding plane is number of group entries, regardless of he number of roots. The forwarding plane forwards on (*,G) entries, so that is the state volume we want to keep an eye on. > The default is "compute a tree based on me" and "I will always choose > tree rooted as me", which would result in (# of trees) state. The only > RPF state at R2, for tree R1, > is to put R1 onto the adjacency from which frames > from R1 should arrive, and the null set on the other adjacencies in > the R1 tree. This doesn't make sense to me. You want to choose one root for a particular (*,G) entry and all rBridges use the same root for this entry. Dino From Radia.Perlman at sun.com Thu Mar 8 09:57:31 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 08 Mar 2007 09:57:31 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> Message-ID: <45F04E8B.5090304@sun.com> We're not talking about G's here, as in specific multicast destination addresses. We're talking about a) Distinct distribution trees: computed by using the link state database to compute a shortest path tree from the named Root b) ingress RBridges, for filtering based on "expected incoming interface (adjacency) check" (Note: when you say "interface" do you mean what I refer to as "adjacency" (which is a (port, neighbor) pair), or do you mean "port"? -- I'll assume you mean "adjacency", and therefore I'll use "interface" because I never really liked the word "adjacency" --- too many syllables, and it's a word I never tend to use in ordinary conversation. Anyway...where G's come in (as well as VLANs), is further filtering information on each interface in the named tree. So the rules are, if R3 receives a multicast packet on interface i, with named tree=R2, and ingress RBridge=R1, then: if R1 is not on the expected source list for interface i, then the packet is dropped passing that check, for each interface other than i, in tree R2, filtering is done based on whether the VLAN specified in the inner frame can be reached downstream on that interface, and for IP multicast group G, whether either IP multicast routers, or receivers for G are reachable downstream on that interface. Radia Dino Farinacci wrote: > > The dominate state in the forwarding plane is number of group > entries, regardless of he number of roots. The forwarding plane > forwards on (*,G) entries, so that is the state volume we want to > keep an eye on. > >> The default is "compute a tree based on me" and "I will always choose >> tree rooted as me", which would result in (# of trees) state. The only >> RPF state at R2, for tree R1, >> is to put R1 onto the adjacency from which frames >> from R1 should arrive, and the null set on the other adjacencies in >> the R1 tree. > > > This doesn't make sense to me. You want to choose one root for a > particular (*,G) entry and all rBridges use the same root for this > entry. > > Dino From dino at cisco.com Thu Mar 8 10:20:36 2007 From: dino at cisco.com (Dino Farinacci) Date: Thu, 8 Mar 2007 10:20:36 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <45F04E8B.5090304@sun.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> Message-ID: <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> > We're not talking about G's here, as in specific multicast > destination addresses. We're talking > about > a) Distinct distribution trees: computed by using the link state > database to compute a shortest path > tree from the named Root > b) ingress RBridges, for filtering based on "expected incoming > interface (adjacency) check" Yes, I understand that. But the state storage cost here is more in control-plane memory which is less of a concern than forwarding-plane memory. That is why I spoke up. > (Note: when you say "interface" do you mean what I refer to as > "adjacency" (which is a (port, neighbor) pair), I meant port, but if you want to do a last-hop neighbor incoming check then you have to do a 6-byte compare and are required to have the last-hop MAC address in the frame. I know the frame formats have been changing, so not sure that the last-hop MAC address is still in the frame (I'm behind on TRILL reading). > or do you mean "port"? -- I'll assume you mean "adjacency", and > therefore I'll use "interface" because I > never really liked the word "adjacency" --- too many syllables, and > it's a word I never tend to use in > ordinary conversation. Right, adjacency tends to be more unicast centric and means downstream. We are talking about upstream interfaces here (closer to the source and not closer towards the destination). > Anyway...where G's come in (as well as VLANs), is further filtering > information on each interface in the > named tree. Right. > So the rules are, if R3 receives a multicast packet on interface > i, with named tree=R2, and ingress RBridge=R1, > then: > > if R1 is not on the expected source list for interface i, then the > packet is dropped Right, said another way if R1 is not the last-hop device on the shortest path from R1 to R3, the packet is dropped. > passing that check, for each interface other than i, in tree R2, > filtering is done based on whether the VLAN Yes. But I mentioned this before. The oif-list for the G is populated based on the receivers downstream. So you actually filter by default and only the ports in the oif-list get packets sent out on. I know why you say filtered, because you are describing a broadcast tree which contains all links in the topology and the membership tree is typically a subset of those links. Doesn't matter, just terms. I think we agree on the concept. > specified in the inner frame can be reached downstream on that > interface, and for IP multicast group G, whether > either IP multicast routers, or receivers for G are reachable > downstream on that interface. Right. But just to reiterate my point, when a packet comes into an rBridge, in fast switching mode, an entry like this exists to be forwarded on if the DA is G: (*,G), incoming-interface: port i, oif-list: port j, k, l So as you say if the packet came in on port i, the packet gets replicated out ports j,k,l. If the packet comes in on any other port, it is dropped. What I describe above could be implemented in a fast hardware implementation. Dino From Radia.Perlman at sun.com Thu Mar 8 10:53:55 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 08 Mar 2007 10:53:55 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> Message-ID: <45F05BC3.5090102@Sun.COM> Yup. The bottom line, for those only skimming, is that you and I are not disagreeing about anything. And the action item from this thread is that the extra announcement "these are the trees I will specify" should go into IS-IS, in the core instance LSP. Also, in the protocol spec, it we should update the forwarding/filtering rules to include "allowed ingress RBridges on this adjacency/port", and make sure the filtering rules really do specify what you and I said, in different words. There is an open question, however, which is whether the "expected incoming interface" check should be SHOULD, MAY or MUST for checking not just port, but neighbor. The downside is the extra 6-byte check, as you point out. The upside is less likely to have bizarre temporary loops. I'd vote for MUST actually. Radia Dino Farinacci wrote On 03/08/07 10:20,: >>We're not talking about G's here, as in specific multicast >>destination addresses. We're talking >>about >>a) Distinct distribution trees: computed by using the link state >>database to compute a shortest path >>tree from the named Root >>b) ingress RBridges, for filtering based on "expected incoming >>interface (adjacency) check" >> >> > >Yes, I understand that. But the state storage cost here is more in >control-plane memory which is less of a concern than forwarding-plane >memory. That is why I spoke up. > > > >>(Note: when you say "interface" do you mean what I refer to as >>"adjacency" (which is a (port, neighbor) pair), >> >> > >I meant port, but if you want to do a last-hop neighbor incoming >check then you have to do a 6-byte compare and are required to have >the last-hop MAC address in the frame. I know the frame formats have >been changing, so not sure that the last-hop MAC address is still in >the frame (I'm behind on TRILL reading). > > > >>or do you mean "port"? -- I'll assume you mean "adjacency", and >>therefore I'll use "interface" because I >>never really liked the word "adjacency" --- too many syllables, and >>it's a word I never tend to use in >>ordinary conversation. >> >> > >Right, adjacency tends to be more unicast centric and means >downstream. We are talking about upstream interfaces here (closer to >the source and not closer towards the destination). > > > >>Anyway...where G's come in (as well as VLANs), is further filtering >>information on each interface in the >>named tree. >> >> > >Right. > > > >>So the rules are, if R3 receives a multicast packet on interface >>i, with named tree=R2, and ingress RBridge=R1, >>then: >> >>if R1 is not on the expected source list for interface i, then the >>packet is dropped >> >> > >Right, said another way if R1 is not the last-hop device on the >shortest path from R1 to R3, the packet is dropped. > > > >>passing that check, for each interface other than i, in tree R2, >>filtering is done based on whether the VLAN >> >> > >Yes. But I mentioned this before. The oif-list for the G is populated >based on the receivers downstream. So you actually filter by default >and only the ports in the oif-list get packets sent out on. > >I know why you say filtered, because you are describing a broadcast >tree which contains all links in the topology and the membership tree >is typically a subset of those links. > >Doesn't matter, just terms. I think we agree on the concept. > > > >>specified in the inner frame can be reached downstream on that >>interface, and for IP multicast group G, whether >>either IP multicast routers, or receivers for G are reachable >>downstream on that interface. >> >> > >Right. > >But just to reiterate my point, when a packet comes into an rBridge, >in fast switching mode, an entry like this exists to be forwarded on >if the DA is G: > > (*,G), incoming-interface: port i, oif-list: port j, k, l > >So as you say if the packet came in on port i, the packet gets >replicated out >ports j,k,l. If the packet comes in on any other port, it is dropped. > >What I describe above could be implemented in a fast hardware >implementation. > >Dino >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > From dino at cisco.com Thu Mar 8 11:49:04 2007 From: dino at cisco.com (Dino Farinacci) Date: Thu, 8 Mar 2007 11:49:04 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <45F05BC3.5090102@Sun.COM> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> Message-ID: <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> > There is an open question, however, which is whether the "expected > incoming interface" check should be > SHOULD, MAY or MUST for checking not just port, but neighbor. The > downside is the extra 6-byte > check, as you point out. The upside is less likely to have bizarre > temporary loops. I'd vote for > MUST actually. I definitely agree with MUST. Dino From Internet-Drafts at ietf.org Thu Mar 8 12:50:03 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Thu, 08 Mar 2007 15:50:03 -0500 Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-trill-rbridge-arch-02.txt -------------- next part -------------- From sgai at nuovasystems.com Thu Mar 8 14:01:00 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 8 Mar 2007 14:01:00 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com><45F04E8B.5090304@sun.com><9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com><45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> I am glad you agree ;-) Will you also agree with me that this technique is useful for network in a steady state, but does not prevent temporary loops when there is a topology change? -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dino Farinacci > Sent: Thursday, March 08, 2007 11:49 AM > To: Radia.Perlman at sun.com > Cc: rbridge at postel.org > Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge > trees > > > There is an open question, however, which is whether the "expected > > incoming interface" check should be > > SHOULD, MAY or MUST for checking not just port, but neighbor. The > > downside is the extra 6-byte > > check, as you point out. The upside is less likely to have bizarre > > temporary loops. I'd vote for > > MUST actually. > > I definitely agree with MUST. > > Dino > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From dino at cisco.com Thu Mar 8 14:34:05 2007 From: dino at cisco.com (Dino Farinacci) Date: Thu, 8 Mar 2007 14:34:05 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com><45F04E8B.5090304@sun.com><9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com><45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> > Will you also agree with me that this technique is useful for > network in > a steady state, but does not prevent temporary loops when there is a > topology change? I agree there will be transient multicast packet looping when there are topology changes. Dino From caitlinb at broadcom.com Fri Mar 9 13:12:11 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Fri, 9 Mar 2007 13:12:11 -0800 Subject: [rbridge] NITS RE: I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt In-Reply-To: Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EA301@NT-IRVA-0750.brcm.ad.broadcom.com> The definition of "CRED" in section 2.2 fails to clarify where the "D" comes from. o CRED: Cooperating RBridges and Encapsulation Tunnels - a topological construct consisting of a set of cooperating RBridges, and the forwarding tunnels connecting them. The CFT-RDT table is not given a distinct long name. This is especially apparent when looking at the headers 3.2.1 and 3.2.2, which differ only by the short names. From erik.nordmark at sun.com Fri Mar 9 14:37:58 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Fri, 09 Mar 2007 14:37:58 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> Message-ID: <45F1E1C6.7060905@sun.com> Dino Farinacci wrote: >> Will you also agree with me that this technique is useful for >> network in >> a steady state, but does not prevent temporary loops when there is a >> topology change? > > I agree there will be transient multicast packet looping when there > are topology changes. Dino, I'm trying to draw an example topology where a change causes a transient multicast loop (with an "expected incoming adjacency" check) and I can't find one. Unicast is sooo much easier ;-) Have you observed temporary IP Multicast loops? (apart from the PIM SM ones before ASSERTS where added). What was the topology and change necessary to trigger those? Erik From dino at cisco.com Fri Mar 9 15:36:03 2007 From: dino at cisco.com (Dino Farinacci) Date: Fri, 9 Mar 2007 15:36:03 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <45F1E1C6.7060905@sun.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> <45F1E1C6.7060905@sun.com> Message-ID: > I'm trying to draw an example topology where a change causes a > transient multicast loop (with an "expected incoming adjacency" > check) and I can't find one. Unicast is sooo much easier ;-) The simplest example is when using multi-access links. The fact that some switches use the multi-access link as an oif and others use the link as an expected-incoming interface. So if the ones that are using the multi-access link as an oif happen to join the root through one of the other switches (which can be many hops away), then the multicast forwarding (and replication) loop occurs. This only happens when the link state database is not in sync among the switches involved because each one thinks the root is located on a different path while still consider the same location of the receivers. > Have you observed temporary IP Multicast loops? (apart from the PIM > SM ones before ASSERTS where added). What was the topology and > change necessary to trigger those? Oh definitely, when two routers think the RP for a (*,G) are different. And this can happen when the topology is in steady state. And this happens due to misconfiguration or in the early days of PIM when you detect one RP down, you move to another one, but others in the topology stayed with the original one. Again, in a steady-state topology. The reason some thought the RP went down is because the network was congested and the RP keepalives were all lost. Those were interesting times. ;-) So this can happen in IS-IS as well if the not everyone is using the same roots. Dino From erik.nordmark at sun.com Fri Mar 9 15:58:42 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Fri, 09 Mar 2007 15:58:42 -0800 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> <45F1E1C6.7060905@sun.com> Message-ID: <45F1F4B2.5040500@sun.com> Dino Farinacci wrote: > The simplest example is when using multi-access links. The fact that > some switches use the multi-access link as an oif and others use the > link as an expected-incoming interface. > > So if the ones that are using the multi-access link as an oif happen to > join the root through one of the other switches (which can be many hops > away), then the multicast forwarding (and replication) loop occurs. With TRILL be clearly have to be careful at the edge (the ingress and egress rbridges) when it comes to the relationship between 802.1D and designated RBridge in order to handle topology changes. In particular since the frames without the TRILL header header doesn't have a TTL. But leaving that aside for a moment, the way Radia described the forwarding check (the "expected incoming adjacency" check), the transit paths between the RBridges would act as point-to-point due to checking both the incoming port and the previous hop RBridge. It was in such a pt-pt topology that I tried to find a simple example of a temporary loop. >> Have you observed temporary IP Multicast loops? (apart from the PIM SM >> ones before ASSERTS where added). What was the topology and change >> necessary to trigger those? > > Oh definitely, when two routers think the RP for a (*,G) are different. > And this can happen when the topology is in steady state. > > And this happens due to misconfiguration or in the early days of PIM > when you detect one RP down, you move to another one, but others in the > topology stayed with the original one. Again, in a steady-state > topology. The reason some thought the RP went down is because the > network was congested and the RP keepalives were all lost. Those were > interesting times. ;-) > > So this can happen in IS-IS as well if the not everyone is using the > same roots. But AFAICT that type of loop can't happen in TRILL since we have an explicit designator for the tree to use in every multi-destination data frame. Erik From erik.nordmark at sun.com Fri Mar 9 16:06:11 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Fri, 09 Mar 2007 16:06:11 -0800 Subject: [rbridge] Global MAC Addresses In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF7B6AF8@eusrcmw721.eamcs.ericsson.se> References: <941D5DCD8C42014FAF70FB7424686DCF7B6AF8@eusrcmw721.eamcs.ericsson.se> Message-ID: <45F1F673.8010702@sun.com> Eric Gray (LO/EUS) wrote: > Interstingly enough, I am really sure that the IPv6 folks > have looked at this before. And I am also sure that at least one > suggested solution has been considered. I do not know if any (of > possibly many) proposals were actually adopted but, if none were, > it would be because the IPv6 people did not see this as a problem. AFAIK the IPv6 folks have not considered this. But as you pointed out, the global IPv6 addresses would still be globally unique since they would have different subnet prefixes. The only issue for IPv6 is that this (and host-side virtualization in general) means that the the semantics of the universal bit in the modified EUI-64 format is even weaker than before. But there is no protocol to date which assumes anything about the semantics of this bit. As RFC 4291 says: The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope. Erik From erik.nordmark at sun.com Fri Mar 9 16:11:25 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Fri, 09 Mar 2007 16:11:25 -0800 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1FBCF62@NT-SJCA-0751.brcm.ad.broadcom.com> References: <54AD0F12E08D1541B826BE97C98F99F1FBCF62@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: <45F1F7AD.3000909@sun.com> Caitlin Bestler wrote: > This suggests three options: > > 1) Require all RBridges to scope on a per-VLAN basis. > The only real flaw in this is that it is a RBridge > requirement that does not apply to conventional bridges. > > 2) Allow all RBridges to have whatever scoping rules they > want, but require that all updates go to all RBridgges. > Each RBridge can judge for itself it the information is > relevant to it, and organize that data however it wants. > > 3) Punt: require the network adminstrator to ensure that naming > scopes enforced by RBRidges are "consistent" and provide > only text-based suggestions on how to achieve this. I didn't see a conclusion on this discussion. I think 802.1D mandates that bridges be capable of doing learning independently for each VLAN (what is called IVL). Thus mandating the same for RBridges (option 1 above) seems natural. I think this means that the link state routing protocol needs to be able to carry in the LSAs instead of just . If that is correct then we should clarify this in the routing requirements. They currently say o layer 2 addresses of nodes within the domain which have transmitted frames but have not transmitted ARP or ND replies and that would need to be the tuple of VLAN tag and L2 address. Erik From Radia.Perlman at sun.com Sat Mar 10 23:25:14 2007 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Sat, 10 Mar 2007 23:25:14 -0800 Subject: [rbridge] VLAN Scoping / MAC Uniqueness Message-ID: <2f2a7526340.45f33e5a@sunlabs.com> I don't agree that we have to explicitly advertise which VLAN a MAC address belongs to, because each VLAN runs its own instance of IS-IS in which endnodes are announced. This could be looked at as implicitly advertising the VLAN. In other words, the endnode information is announced in an instance of IS-IS distinguished by having an inner VLAN tag (I think that's how we differentiate it). Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually store the information. Radia ----- Original Message ----- From: Erik Nordmark Date: Friday, March 9, 2007 4:11 pm Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > Caitlin Bestler wrote: > > > This suggests three options: > > > > 1) Require all RBridges to scope on a per-VLAN basis. > > The only real flaw in this is that it is a RBridge > > requirement that does not apply to conventional bridges. > > > > 2) Allow all RBridges to have whatever scoping rules they > > want, but require that all updates go to all RBridgges. > > Each RBridge can judge for itself it the information is > > relevant to it, and organize that data however it wants. > > > > 3) Punt: require the network adminstrator to ensure that naming > > scopes enforced by RBRidges are "consistent" and provide > > only text-based suggestions on how to achieve this. > > I didn't see a conclusion on this discussion. > > I think 802.1D mandates that bridges be capable of doing learning > independently for each VLAN (what is called IVL). Thus mandating > the > same for RBridges (option 1 above) seems natural. > > I think this means that the link state routing protocol needs to be > able > to carry in the LSAs instead of just address>. If that is correct then we should clarify this in the > routing > requirements. They currently say > o layer 2 addresses of nodes within the domain which have > transmitted frames but have not transmitted ARP or ND replies > and that would need to be the tuple of VLAN tag and L2 address. > > Erik > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From caitlinb at broadcom.com Sun Mar 11 18:25:32 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Sun, 11 Mar 2007 18:25:32 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <2f2a7526340.45f33e5a@sunlabs.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EA534@NT-IRVA-0750.brcm.ad.broadcom.com> Radia.Perlman at sun.com wrote: > I don't agree that we have to explicitly advertise which VLAN > a MAC address belongs to, because each VLAN runs its own > instance of IS-IS in which endnodes are announced. This could > be looked at as implicitly advertising the VLAN. In other > words, the endnode information is announced in an instance of > IS-IS distinguished by having an inner VLAN tag (I think > that's how we differentiate it). > Core RBridges forward it like a multicast packet for that > VLAN. Only border RBridges of that VLAN actually store the > information. > > Radia > VLAN tagging the endnode announcement assumes that the announcement is only relevant within the VLAN. That still leaves the following scenario: RBridge I participates in VLANs R and S. It uses a single (VLAN independent) MAC learning database. It believes the MAC X is on a local port for VLAN R. RBridge J participates in VLANs S and T. It uses a single (VLAN independent) MAC learning database. RBridge K participates in VLAN T It detects MAC X on a local port for VLAN T. It would share that information with RBridge J, but not RBridge I. RBRidge J can now receive contradictory information from I and K. This is avoided if RBridge K does not presume which RBridges need this informaton, or if RBridge I advertises itself as wanting information for all VLANs (that is, it is a member of VLAN T, but only for purposes of getting endnode announcements). As for the more general problem, obviously any CRED which has varying concepts on the scope over which a MAC address is unique is going to have potential problems. But most of that problem is well outside of TRILL's scope. The issue that is within TRILL's scope is ensuring that endnode announcements are distributed everywhere that the information is needed. The prior drafts explicitly assumed that information about MAC Address X was not relevant to any RBridge that was not in the same VLAN. This is only a valid assumption if port learning is being done on a per VLAN basis. The current drafts do not have this problem, because they merely state that distribution might be limited based upon VLAN (which would be appropriate if the RBridges are known to have compatible scoping concepts). The language could be more explicit, but to be realistic, network administrators would generally avoid allowing this problem to exist in the first place. From erik.nordmark at sun.com Mon Mar 12 14:44:19 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Mon, 12 Mar 2007 14:44:19 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <2f2a7526340.45f33e5a@sunlabs.com> References: <2f2a7526340.45f33e5a@sunlabs.com> Message-ID: <45F5C9B3.4010602@sun.com> Radia.Perlman at sun.com wrote: > I don't agree that we have to explicitly advertise which VLAN a MAC address belongs to, because > each VLAN runs its own instance of IS-IS in which endnodes are announced. This could be looked > at as implicitly advertising the VLAN. In other words, the endnode information is announced in > an instance of IS-IS distinguished by having an inner VLAN tag (I think that's how we differentiate it). > Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually > store the information. That is true if you are required to have N IS-IS VLAN instances when there are N VLANs in use. I don't know if that is overkill when all the RBridges are all part of all N VLANs - basically when it is just different subsets of stations/hosts that make up the different VLANs. Erik From Radia.Perlman at sun.com Mon Mar 12 15:49:36 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 12 Mar 2007 15:49:36 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F5C9B3.4010602@sun.com> References: <2f2a7526340.45f33e5a@sunlabs.com> <45F5C9B3.4010602@sun.com> Message-ID: <45F5D900.9070909@sun.com> Yes. There are three ways of sending per-VLAN endnode information: a) a single instance of IS-IS for both "core" information and "endnode" information. Endnode information would be marked as (VLAN ID, {set of endnodes}). RBridges that are not in VLAN A would need to store the VLAN A endnode information, and all endnode information would go to all parts of the campus b) two instances of IS-IS: one for core information (which RBridges are connected to which other RBridges, and which VLANs are attached to which RBridges), and one for endnode information. Not sure what advantage/disadvantage this has over a), since all link state information would go to all RBridges. c) n+1 instance of IS-IS, where n is the number of VLANs that are in use. Each RBridge R1 would run k+1 instances of IS-IS; the core instance, and one for each of the k VLANs that R1 is attached to. The advantage of this is that flooding of endnode information for VLAN A need not be stored by any RBridges except those that attach to VLAN A. Also, because the core instance enables flooding of VLAN multicast just to links that are interested (RBridges that are attached to VLAN A), there is further optimization because this information does not need to traverse all the links in the campus; just those needed to get the packet from the RBridge that originates the LSP for VLAN A endnode information to the RBridges that attach to VLAN A. I prefer c). I don't think there is that much overhead to running n instances. It's really like separating the endnode information into distinct LSPs. Except for...the Hello Protocol. If all RBridges are connected to 4000 VLANs, then they'd all be sending 4000 Hellos, one for each instance. The core instance Hellos are a bit different -- they only go to direct neighbors. But the VLAN instances get flooded by the core to all links throughout the campus attached to that VLAN. We could eliminate the hello protocol for the per-VLAN instance of IS-IS, since there's enough information in the core instance for all VLAN A RBridges to know about each other and decide which should be Designated (for sending out CSNPs). Radia Erik Nordmark wrote: > Radia.Perlman at sun.com wrote: > >> I don't agree that we have to explicitly advertise which VLAN a MAC >> address belongs to, because >> each VLAN runs its own instance of IS-IS in which endnodes are >> announced. This could be looked >> at as implicitly advertising the VLAN. In other words, the endnode >> information is announced in >> an instance of IS-IS distinguished by having an inner VLAN tag (I >> think that's how we differentiate it). >> Core RBridges forward it like a multicast packet for that VLAN. Only >> border RBridges of that VLAN actually >> store the information. > > > That is true if you are required to have N IS-IS VLAN instances when > there are N VLANs in use. > > I don't know if that is overkill when all the RBridges are all part of > all N VLANs - basically when it is just different subsets of > stations/hosts that make up the different VLANs. > > Erik From caitlinb at broadcom.com Mon Mar 12 16:00:25 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 12 Mar 2007 16:00:25 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F5D900.9070909@sun.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EA836@NT-IRVA-0750.brcm.ad.broadcom.com> One suggestion that I think is adequate: RBridge Hello messages would be from the core instance and sent to core instance. It would list the VLAN IDs and whether it maintained a single destination database or a per VLAN database. In the latter case, other RBridges would only forward relevant advertisements to RBridges that advertised the relevant VLAN. An RBridge using an unscoped database would be send all address advertisements. Alternately, we could explicitly require per VLAN scoping. From Radia.Perlman at sun.com Mon Mar 12 18:35:32 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 12 Mar 2007 18:35:32 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D030EA836@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D030EA836@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <45F5FFE4.7080600@sun.com> I'm not sure I understand what you're saying. But I think the issue is how link state information is distributed. The core instance link state information is flooded to all RBridges, but transmitted hop by hop. That means every RBridge, including core RBridges that do not attach to any VLANs, have to store this information, in addition to forwarding it, in case it needs to be retransmitted to a neighbor, or transmitted to a new neighbor that might come up later. As the spec currently is, the endnode information is multicast. So R1, attached to VLAN A, just multicasts a single copy of its VLAN A information, and it gets distributed by the core like any VLAN A multicast data packet. It magically gets received just by RBridges attached to VLAN A. Only RBridges actually attached to VLAN A need to store this information. It is not sent reliably neighbor-to-neighbor. Only R1 has to ensure that all the relevant RBridges have received the link state information about VLAN A. THe intervening RBridges just forward it and forget it. So as I said, you could get rid of running the per-instance IS-IS hellos, by just listing, in the core instance LSP, which VLANs you attach to. There really isn't anything that the per-VLAN instance of the hello protocol needs to know that isn't already in the core instance link state information, so we could eliminate running 4000 Hello and Designated RBridge elections. However, the per-VLAN link state information (listing the endnodes) is potentially large enough that I believe it is useful to avoid having non-VLAN-A RBridges keep track of the VLAN A endnodes (and VLAN A IP groups and multicast routers). And if we are using multicast to distribute, I don't see how R1 can choose which RBridges to send the information to, or to format it differently depending on the recipient. For as many as possible of these sorts of things that are OK to do either this way or that way, I think we should choose, rather than making it a parameter. Radia Caitlin Bestler wrote: >One suggestion that I think is adequate: > >RBridge Hello messages would be from the core instance >and sent to core instance. It would list the VLAN IDs >and whether it maintained a single destination database >or a per VLAN database. > >In the latter case, other RBridges would only forward >relevant advertisements to RBridges that advertised the >relevant VLAN. An RBridge using an unscoped database >would be send all address advertisements. > >Alternately, we could explicitly require per VLAN scoping. > > > > > From jmb at lmdata.es Tue Mar 13 02:23:35 2007 From: jmb at lmdata.es (Jose Morales Barroso) Date: Tue, 13 Mar 2007 10:23:35 +0100 Subject: [rbridge] Global MAC Addresses Message-ID: <45F66D97.1020808@lmdata.es> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20070313/abb531d5/attachment.html From caitlinb at broadcom.com Tue Mar 13 07:23:55 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Tue, 13 Mar 2007 07:23:55 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> The issue is not how the information is relayed, or how it is stored, but who determines what information is relevant. If all RBridges track MAC Addresses scoped within a VLAN scope then everything you suggest works perfectly fine. The only correction needed would be to emphasize that this is indeed a requirement. But any RBridge that uses a global scope for MAC Addresses should be told of new MAC detections on different VLANs because such an RBridge would want to delete the old location. Unless the RBridge that detected the MAC address knows that all other RBridges are using VLAN scoped MAC addresses they should distribute the new information to *all* RBRidges, not just those on the VLAN where the address was discovered. From caitlinb at broadcom.com Tue Mar 13 10:37:09 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Tue, 13 Mar 2007 10:37:09 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F5D900.9070909@sun.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EAABD@NT-IRVA-0750.brcm.ad.broadcom.com> Radia Perlman wrote: > The advantage of this is that flooding of endnode information > for VLAN A need not be stored by any RBridges except those > that attach to VLAN A. That line leapt out at me on re-read. *If* we are going to allow RBridges to have the traditional bridge option of using scoped or global MAC address learning, then we do indeed have to flood endnode information about VLAN A. This is not so that RBridges that are not part of VLAN A can *store* the new endnode information, it is so they can *delete* contradictory information. Alternatively, if we explicitly require scoped learning, then any RBridge that is not part of VLAN A cannot have contradictory information. Then there would be no need to flood endnode advertisements. From Radia.Perlman at sun.com Tue Mar 13 10:40:44 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 13 Mar 2007 10:40:44 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <45F6E21C.2060802@sun.com> Ah. Now I understand the issue, I think. You are saying that if MAC addresses are globally unique, an RBridge attached only to VLAN A should still monitor the endnode membership of the other VLANs, in case one of its endnodes moves and appears elsewhere. So I think we are talking about two alternatives: a) have all RBridges see all endnode memberships on all VLANs b) have RBridges only see endnode memberships for VLANs they are directly attached to. I see the disadvantages of each as: a) extra bandwidth and storage for having endnode membership go everywhere b) less timely noticing an endnode has moved to another VLAN If I understand things correctly, I much prefer b), for the following reasons: 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by pretending to be MAC addresses belonging to VLAN B (so option b is safer and provides more separation between VLANs) 2) option b) greatly lowers the burden on RBridges because they only have to keep information for their own VLANs 3) option b) is likely to save bandwidth on distributing endnode information 4) there might be cases where an endnode might attach to multiple VLANs, and the RBridges will panic unnecessarily Radia Caitlin Bestler wrote: >The issue is not how the information is relayed, or how it is stored, >but who determines what information is relevant. > >If all RBridges track MAC Addresses scoped within a VLAN scope >then everything you suggest works perfectly fine. The only correction >needed would be to emphasize that this is indeed a requirement. > >But any RBridge that uses a global scope for MAC Addresses should >be told of new MAC detections on different VLANs because such >an RBridge would want to delete the old location. > >Unless the RBridge that detected the MAC address knows that all >other RBridges are using VLAN scoped MAC addresses they should >distribute the new information to *all* RBRidges, not just those on >the VLAN where the address was discovered. > > >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > From Radia.Perlman at sun.com Tue Mar 13 10:54:47 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 13 Mar 2007 10:54:47 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D030EAABD@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D030EAABD@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <45F6E567.10006@sun.com> With IS-IS flooding, an RBridge can't simply scan the information for VLAN A and then delete it. It has to store it, since LSPs have to be flooded reliably, so each RBridge would have to keep all endnode information for all VLANs. Radia Caitlin Bestler wrote: >Radia Perlman wrote: > > > >>The advantage of this is that flooding of endnode information >>for VLAN A need not be stored by any RBridges except those >>that attach to VLAN A. >> >> > >That line leapt out at me on re-read. > >*If* we are going to allow RBridges to have the traditional >bridge option of using scoped or global MAC address learning, >then we do indeed have to flood endnode information about >VLAN A. This is not so that RBridges that are not part of >VLAN A can *store* the new endnode information, it is so >they can *delete* contradictory information. > >Alternatively, if we explicitly require scoped learning, >then any RBridge that is not part of VLAN A cannot have >contradictory information. Then there would be no need >to flood endnode advertisements. > > > > From caitlinb at broadcom.com Tue Mar 13 10:59:38 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Tue, 13 Mar 2007 10:59:38 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F6E567.10006@sun.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> Radia Perlman wrote: > With IS-IS flooding, an RBridge can't simply scan the > information for VLAN A and then delete it. > It has to store it, since LSPs have to be flooded reliably, > so each RBridge would have to keep all endnode information for all > VLANs. > I'm not following. If an RBridge is using globally scoped MAC addresses, and it receives endnode information for a VLAN that it does not support, the only thing I can see that it would have to do is to delete any information it had on the same MAC address on a different VLAN. It would never send to VLAN A, so why would it retain any information once the contradictory data was eliminated? A deleted record can be considered to be reliably delected, can't it? If it's knowledge of MAC Addresses is VLAN scoped then nothing about VLAN A is ever relevant. That is why it is a very simple solution, but one that creates an RBridge requirement for scoped learning that does not apply to simple Bridges. From Radia.Perlman at sun.com Tue Mar 13 11:26:11 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 13 Mar 2007 11:26:11 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <45F6ECC3.5070509@sun.com> The current spec (and my understanding) is that membership of VLAN A would be distributed as link state information in IS-IS. If we include this in the link state information in the core instance, then every RBridge has to store it all, since IS-IS flooding requires every RBridge to store all (the most recently generated from each RBridge) link state information. R1 doesn't just look at the link state information and decide what it's interested in and delete the rest. R1 has to keep it in order for the reliable flooding to work. With the way the current spec is written, endnode information is *NOT* distributed in the core instance. Instead, VLAN A information is distributed like a VLAN A multicast data packet, which means the core RBridges distribute it along a tree, filtered so as not to unnecessarily go on branches that don't lead to VLAN A links. With that design, the only RBridges that would see information about VLAN A endnode membership are RBridges attached to VLAN A. The topology that the IS-IS instance for distributing VLAN A sees is as a single hop, with all RBridges attached to VLAN A being neighbors. There is a variant of this design that would have the property you are imagining; that all endnode information goes everywhere, gets seen by all RBridges, and that only RBridges in VLAN A have to actually store the information. That is to have a multicast distribution tree that sends things to *all* RBridges that attach to endnodes. This is a subtly different distribution mechanism than the core instance. If there are core RBridges, not attached to any endnodes, they would just pass the link state information along. And a "border" RBridge R2 (one that does attach to endnodes) would be allowed, if it chose, to simply scan VLAN A information and then delete it, since R2 would never need to forward this link state ifnormation to a neighbor. I still prefer the way the spec is now, since I think the advantage of noticing endnodes moving to a different VLAN is outweighed by the downsides (more cost to distribute endnode information, and the ability for nasty behavior of an endnode in VLAN A to disrupt VLAN B maliciously, and confusion when nonmaliciously an endnode resides on multiple VLANs with the same MAC address. Radia Caitlin Bestler wrote: >Radia Perlman wrote: > > >>With IS-IS flooding, an RBridge can't simply scan the >>information for VLAN A and then delete it. >>It has to store it, since LSPs have to be flooded reliably, >>so each RBridge would have to keep all endnode information for all >>VLANs. >> >> >> > >I'm not following. If an RBridge is using globally scoped MAC >addresses, and it receives endnode information for a VLAN that >it does not support, the only thing I can see that it would have >to do is to delete any information it had on the same MAC address >on a different VLAN. > >It would never send to VLAN A, so why would it retain any information >once the contradictory data was eliminated? A deleted record can be >considered to be reliably delected, can't it? > >If it's knowledge of MAC Addresses is VLAN scoped then nothing >about VLAN A is ever relevant. That is why it is a very simple >solution, but one that creates an RBridge requirement for scoped >learning that does not apply to simple Bridges. > > > From caitlinb at broadcom.com Tue Mar 13 11:36:47 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Tue, 13 Mar 2007 11:36:47 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F6ECC3.5070509@sun.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D031EC0E5@NT-IRVA-0750.brcm.ad.broadcom.com> Radia Perlman wrote: > The current spec (and my understanding) is that membership of > VLAN A would be distributed as link state information in > IS-IS. If we include this in the link state information in > the core instance, then every RBridge has to store it all, > since IS-IS flooding requires every RBridge to store all (the > most recently generated from each RBridge) link state > information. R1 doesn't just look at the link state > information and decide what it's interested in and delete the > rest. R1 has to keep it in order for the reliable flooding to work. > > With the way the current spec is written, endnode information > is *NOT* distributed in the core instance. > Instead, VLAN A information > is distributed like a VLAN A multicast data packet, which > means the core RBridges distribute it along a tree, filtered > so as not to unnecessarily go on branches that don't lead to > VLAN A links. > > With that design, the only RBridges that would see > information about VLAN A endnode membership are RBridges > attached to VLAN A. > The topology that the IS-IS instance for distributing VLAN A > sees is as a single hop, with all RBridges attached to VLAN A being > neighbors. > > There is a variant of this design that would have the > property you are imagining; that all endnode information goes > everywhere, gets seen by all RBridges, and that only RBridges > in VLAN A have to actually store the information. That is to > have a multicast distribution tree that sends things to *all* > RBridges that attach to endnodes. This is a subtly different > distribution mechanism than the core instance. If there are > core RBridges, not attached to any endnodes, they would just > pass the link state information along. And a "border" RBridge > R2 (one that does attach to endnodes) would be allowed, if it > chose, to simply scan VLAN A information and then delete it, > since R2 would never need to forward this link state > ifnormation to a neighbor. > > I still prefer the way the spec is now, since I think the > advantage of noticing endnodes moving to a different VLAN is > outweighed by the downsides (more cost to distribute endnode > information, and the ability for nasty behavior of an endnode > in VLAN A to disrupt VLAN B maliciously, and confusion when > nonmaliciously an endnode resides on multiple VLANs with the > same MAC address. > > Radia > It might be sufficient to merely note that any RBridge attempting to maintain global scoping of MAC Addresses needs to be aware that the distribution of endnode information is optimized for per-VLAN scoping. Because of this it MUST NOT rely on prompt notification of migration of a MAC Address to a new VLAN on a different RBridge. I also agree that it makes sense to optimize the wire protocol on the assumption that typical RBridges will do per-VLAN learning. From uets.jmb at gmail.com Tue Mar 13 12:07:20 2007 From: uets.jmb at gmail.com (Jose Morales Barroso) Date: Tue, 13 Mar 2007 20:07:20 +0100 Subject: [rbridge] Global MAC Addresses Message-ID: <94dba4110703131207j5ea3c94aiebaa564ce970df13@mail.gmail.com> Dear colleagues: UETS/EFR architecture uses locally administered (U/L bit = 1) MAC addresses, "taking advantage of interface identifiers with universal scope", as described at: http://www.lmdata.es/uets/draft/uets-efr-addressing.pdf This technology permits to switch Ethernet frames at the physical layer, making it unnecessary to use routing, bridging, or signaling techniques. The Destination Address has the path information, and does not need tables of switching, look-up or forwarding: http://www.lmdata.es/uets/draft/uets-efr-scenario-wwn.pdf Using MAC-in-MAC or SNAP, each connection support another Ethernet domain. In this case, the addressing will be huge, even bigger than IPv6, making possible to build a "Global Ethernet". You have more information in the UETS/EFR page: http://www.lmdata.es/uets.htm Jose Morales jmb at ieee.org Eric Gray (LO/EUS) wrote: >> Interstingly enough, I am really sure that the IPv6 folks >> have looked at this before. And I am also sure that at least one >> suggested solution has been considered. I do not know if any (of >> possibly many) proposals were actually adopted but, if none were, >> it would be because the IPv6 people did not see this as a problem. > >AFAIK the IPv6 folks have not considered this. >But as you pointed out, the global IPv6 addresses would still be >globally unique since they would have different subnet prefixes. > > The only issue for IPv6 is that this (and host-side virtualization in > general) means that the the semantics of the universal bit in the > modified EUI-64 format is even weaker than before. > But there is no protocol to date which assumes anything about the > semantics of this bit. As RFC 4291 says: > The use of the universal/local bit in the Modified EUI-64 format > identifier is to allow development of future technology that can take > advantage of interface identifiers with universal scope. > Erik From sgai at nuovasystems.com Fri Mar 16 02:16:15 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Fri, 16 Mar 2007 02:16:15 -0700 Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees In-Reply-To: <45F1F4B2.5040500@sun.com> References: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> <45F1E1C6.7060905@sun.com> <45F1F4B2.5040500@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201359E15@nuova-ex1.hq.nuovaimpresa.com> EriK, inline > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark at sun.com] > Sent: Friday, March 09, 2007 3:59 PM > To: Dino Farinacci > Cc: Silvano Gai; rbridge at postel.org; Radia.Perlman at sun.com > Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge > trees > > Dino Farinacci wrote: > > > The simplest example is when using multi-access links. The fact that > > some switches use the multi-access link as an oif and others use the > > link as an expected-incoming interface. > > > > So if the ones that are using the multi-access link as an oif happen to > > join the root through one of the other switches (which can be many hops > > away), then the multicast forwarding (and replication) loop occurs. > > With TRILL be clearly have to be careful at the edge (the ingress and > egress rbridges) when it comes to the relationship between 802.1D and > designated RBridge in order to handle topology changes. In particular > since the frames without the TRILL header header doesn't have a TTL. > > But leaving that aside for a moment, the way Radia described the > forwarding check (the "expected incoming adjacency" check), the transit > paths between the RBridges would act as point-to-point due to checking > both the incoming port and the previous hop RBridge. IMHO you can build the most sophisticated RPF check, but it will always be based on local information. Since it is well known that the local information of two RBridges may be temporary out of sync, due to the way IS-IS works, the possibility of a temporary loop is concrete. Temporary loop == Broadcast Storm -- Silvano > > It was in such a pt-pt topology that I tried to find a simple example of > a temporary loop. > > >> Have you observed temporary IP Multicast loops? (apart from the PIM SM > >> ones before ASSERTS where added). What was the topology and change > >> necessary to trigger those? > > > > Oh definitely, when two routers think the RP for a (*,G) are different. > > And this can happen when the topology is in steady state. > > > > And this happens due to misconfiguration or in the early days of PIM > > when you detect one RP down, you move to another one, but others in the > > topology stayed with the original one. Again, in a steady-state > > topology. The reason some thought the RP went down is because the > > network was congested and the RP keepalives were all lost. Those were > > interesting times. ;-) > > > > So this can happen in IS-IS as well if the not everyone is using the > > same roots. > > But AFAICT that type of loop can't happen in TRILL since we have an > explicit designator for the tree to use in every multi-destination data > frame. > > Erik From sgai at nuovasystems.com Fri Mar 16 02:16:11 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Fri, 16 Mar 2007 02:16:11 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F6ECC3.5070509@sun.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> I think TRILL needs to do exactly what IEEE 802.1Q does. AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. N is never advertised outside the bridge, and the mapping of M to N is never advertised outside the bridge. TRILL must do the same. Learning is done on {VID, MAC-address} pairs. TRILL must do the same. We agreed that bridges learn from data frames and data frames are always associated to a VID and RBridges learn from the per VLAN instance of ISIS. Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically becomes available on VLAN=9. Now the tricky question: should the RBridge announce MAC-A on both VLAN 7 and VLAN 9 or only on VLAN 7? IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e. it must only announce what it has learnt from data frames, not the internal associations it has made. If the information was learnt on data packets, it would only be learnt on VLAN 7! If we do this we are perfectly equivalent to an IEEE 802.1Q bridge. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Tuesday, March 13, 2007 11:26 AM > To: Caitlin Bestler > Cc: rbridge at postel.org; Erik Nordmark > Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > > The current spec (and my understanding) is that membership of VLAN A > would be distributed > as link state information in IS-IS. If we include this in the link state > information in the core instance, > then every RBridge has to store it all, since IS-IS flooding requires > every RBridge to store all (the most > recently generated from each RBridge) link state information. R1 doesn't > just look at the link state > information and decide what it's interested in and delete the rest. R1 > has to keep it in order for > the reliable flooding to work. > > With the way the current spec is written, endnode information is *NOT* > distributed in the core instance. > Instead, VLAN A information > is distributed like a VLAN A multicast data packet, which means the core > RBridges distribute > it along a tree, filtered so as not to unnecessarily go on branches that > don't lead to VLAN A links. > > With that design, the only RBridges that would see information about > VLAN A endnode membership are > RBridges attached to VLAN A. > The topology that the IS-IS instance for distributing VLAN A sees is as > a single hop, with all RBridges > attached to VLAN A being neighbors. > > There is a variant of this design that would have the property you are > imagining; that all endnode information > goes everywhere, gets seen by all RBridges, and that only RBridges in > VLAN A have to actually store the > information. That is to have a multicast distribution tree that sends > things to *all* RBridges that attach to > endnodes. This is a subtly different distribution mechanism than the > core instance. If there are core RBridges, > not attached to any endnodes, they would just pass the link state > information along. And a "border" RBridge R2 > (one that does attach to endnodes) would be allowed, if it chose, to > simply scan VLAN A information and > then delete it, since R2 would never need to forward this link state > ifnormation to a neighbor. > > I still prefer the way the spec is now, since I think the advantage of > noticing endnodes moving to a > different VLAN is outweighed by the downsides (more cost to distribute > endnode information, and > the ability for nasty behavior of an endnode in VLAN A to disrupt VLAN B > maliciously, and confusion > when nonmaliciously an endnode resides on multiple VLANs with the same > MAC address. > > Radia > > > > Caitlin Bestler wrote: > > >Radia Perlman wrote: > > > > > >>With IS-IS flooding, an RBridge can't simply scan the > >>information for VLAN A and then delete it. > >>It has to store it, since LSPs have to be flooded reliably, > >>so each RBridge would have to keep all endnode information for all > >>VLANs. > >> > >> > >> > > > >I'm not following. If an RBridge is using globally scoped MAC > >addresses, and it receives endnode information for a VLAN that > >it does not support, the only thing I can see that it would have > >to do is to delete any information it had on the same MAC address > >on a different VLAN. > > > >It would never send to VLAN A, so why would it retain any information > >once the contradictory data was eliminated? A deleted record can be > >considered to be reliably delected, can't it? > > > >If it's knowledge of MAC Addresses is VLAN scoped then nothing > >about VLAN A is ever relevant. That is why it is a very simple > >solution, but one that creates an RBridge requirement for scoped > >learning that does not apply to simple Bridges. > > > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From iesg-secretary at ietf.org Fri Mar 16 14:52:56 2007 From: iesg-secretary at ietf.org (The IESG) Date: Fri, 16 Mar 2007 17:52:56 -0400 Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC Message-ID: The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Routing Requirements in Support of RBridges ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2007-03-30. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0 From caitlinb at broadcom.com Fri Mar 16 23:26:44 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Fri, 16 Mar 2007 23:26:44 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> -----Original Message----- From: Silvano Gai [mailto:sgai at nuovasystems.com] Sent: Fri 3/16/2007 2:16 AM To: Radia Perlman; Caitlin Bestler Cc: rbridge at postel.org; Erik Nordmark Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness I think TRILL needs to do exactly what IEEE 802.1Q does. AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. N is never advertised outside the bridge, and the mapping of M to N is never advertised outside the bridge. TRILL must do the same. Learning is done on {VID, MAC-address} pairs. TRILL must do the same. We agreed that bridges learn from data frames and data frames are always associated to a VID and RBridges learn from the per VLAN instance of ISIS. Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically becomes available on VLAN=9. Now the tricky question: should the RBridge announce MAC-A on both VLAN 7 and VLAN 9 or only on VLAN 7? IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e. it must only announce what it has learnt from data frames, not the internal associations it has made. If the information was learnt on data packets, it would only be learnt on VLAN 7! If we do this we are perfectly equivalent to an IEEE 802.1Q bridge. -- Silvano -----End Original Message----- My understanding of 802.1 specifications is that the following sequence is acceptable behavior for a bridge: 1) VLAN 7 MAC X is seen on port 1. 2) Bridge learns that MAC X is on port 1 with VLAN 7. 3) VLAN 8 MAC X is seen on port 1. 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X). This is of course undesirable, but a livable quirk. It is best avoided by either ensuring that global MAC Addresses are truly unique, or ensuring that all bridges deployed in one subnet agree on exactly how unique a "globally unique" address is. RBridges do more than merely forward ethernet frames amongst themselves, they collaborate to implement a distributed ARP/ND proxy. That probably justifies stating that for purposes of the shared discovery data that MAC Addresses are assumed to be unique only as scoped within a VLAN, but I think we should acknowledge (and highlight) that we are narrowing the scope of legal behaviors that would have been available to a bridge. From sgai at nuovasystems.com Sat Mar 17 07:50:25 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sat, 17 Mar 2007 07:50:25 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20135A144@nuova-ex1.hq.nuovaimpresa.com> Caitlin, Is you problem with: 1) "Learning" or 2) "ARP/ND discovery"? In my email I was only addressing 1), but I agree with you that we also need to address 2). -- Silvano > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb at broadcom.com] > Sent: Friday, March 16, 2007 11:27 PM > To: Silvano Gai; Radia Perlman > Cc: rbridge at postel.org; Erik Nordmark > Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness > > > > > -----Original Message----- > From: Silvano Gai [mailto:sgai at nuovasystems.com] > Sent: Fri 3/16/2007 2:16 AM > To: Radia Perlman; Caitlin Bestler > Cc: rbridge at postel.org; Erik Nordmark > Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness > > > I think TRILL needs to do exactly what IEEE 802.1Q does. > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. > > N is never advertised outside the bridge, and the mapping of M to N is > never advertised outside the bridge. TRILL must do the same. > > Learning is done on {VID, MAC-address} pairs. TRILL must do the same. > > We agreed that bridges learn from data frames and data frames are always > associated to a VID and RBridges learn from the per VLAN instance of > ISIS. > > Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are > mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically > becomes available on VLAN=9. > > Now the tricky question: should the RBridge announce MAC-A on both VLAN > 7 and VLAN 9 or only on VLAN 7? > > IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e. > it must only announce what it has learnt from data frames, not the > internal associations it has made. If the information was learnt on data > packets, it would only be learnt on VLAN 7! > > If we do this we are perfectly equivalent to an IEEE 802.1Q bridge. > > -- Silvano > > -----End Original Message----- > > > My understanding of 802.1 specifications is that the following sequence > is acceptable behavior for a bridge: > > 1) VLAN 7 MAC X is seen on port 1. > 2) Bridge learns that MAC X is on port 1 with VLAN 7. > 3) VLAN 8 MAC X is seen on port 1. > 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior > information about X). > > This is of course undesirable, but a livable quirk. It is best avoided by > either > ensuring that global MAC Addresses are truly unique, or ensuring that all > bridges > deployed in one subnet agree on exactly how unique a "globally unique" > address is. > > RBridges do more than merely forward ethernet frames amongst themselves, > they collaborate > to implement a distributed ARP/ND proxy. That probably justifies stating > that for purposes > of the shared discovery data that MAC Addresses are assumed to be unique > only as scoped > within a VLAN, but I think we should acknowledge (and highlight) that we > are narrowing > the scope of legal behaviors that would have been available to a bridge. > From caitlinb at broadcom.com Sat Mar 17 12:27:23 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Sat, 17 Mar 2007 12:27:23 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA20135A144@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D031ECE13@NT-IRVA-0750.brcm.ad.broadcom.com> Silvano Gai wrote: > Caitlin, > > Is you problem with: > 1) "Learning" or > 2) "ARP/ND discovery"? > > In my email I was only addressing 1), but I agree with you > that we also need to address 2). > Maybe I'm not playing spec lawyer well enough. But thinking of how I would implement these features in a smart NIC I simply don't see the distinction. It's all information keyed by the L2 Index. From riw at cisco.com Mon Mar 19 12:06:24 2007 From: riw at cisco.com (Russ White) Date: Mon, 19 Mar 2007 15:06:24 -0400 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F6E21C.2060802@sun.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6E21C.2060802@sun.com> Message-ID: <45FEDF30.6000608@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From an IS-IS perspective, if we do a, we only have, I think, a single process, while if we do b, it makes more sense to do multiple processes, right? In reality, the way the TLVs are laid out today, we can advertise each l2 address with a vid, or not, or a group of l2 addresses with a single vid to indicate they are all within this vid, or some other various combinations. :-) Russ Radia Perlman wrote: > Ah. Now I understand the issue, I think. You are saying that if MAC > addresses are globally unique, > an RBridge attached only to VLAN A should still monitor the endnode > membership of the other VLANs, > in case one of its endnodes moves and appears elsewhere. > > So I think we are talking about two alternatives: > a) have all RBridges see all endnode memberships on all VLANs > b) have RBridges only see endnode memberships for VLANs they are > directly attached to. > > I see the disadvantages of each as: > a) extra bandwidth and storage for having endnode membership go everywhere > b) less timely noticing an endnode has moved to another VLAN > > If I understand things correctly, I much prefer b), for the following > reasons: > 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by > pretending to be MAC addresses > belonging to VLAN B (so option b is safer and provides more separation > between VLANs) > 2) option b) greatly lowers the burden on RBridges because they only > have to keep information for > their own VLANs > 3) option b) is likely to save bandwidth on distributing endnode information > 4) there might be cases where an endnode might attach to multiple VLANs, > and the RBridges will > panic unnecessarily > > Radia > > Caitlin Bestler wrote: > >> The issue is not how the information is relayed, or how it is stored, >> but who determines what information is relevant. >> >> If all RBridges track MAC Addresses scoped within a VLAN scope >> then everything you suggest works perfectly fine. The only correction >> needed would be to emphasize that this is indeed a requirement. >> >> But any RBridge that uses a global scope for MAC Addresses should >> be told of new MAC detections on different VLANs because such >> an RBridge would want to delete the old location. >> >> Unless the RBridge that detected the MAC address knows that all >> other RBridges are using VLAN scoped MAC addresses they should >> distribute the new information to *all* RBRidges, not just those on >> the VLAN where the address was discovered. >> >> >> _______________________________________________ >> 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 - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF/t8wER27sUhU9OQRArzYAJ9WuW82Wcaeml5+OVEmb/OAChUO4wCg7cgY 6bS0r3gfLceCcCIUYXFR5HI= =F2tF -----END PGP SIGNATURE----- From jrrivers at nuovasystems.com Mon Mar 19 12:35:51 2007 From: jrrivers at nuovasystems.com (J. R. Rivers) Date: Mon, 19 Mar 2007 12:35:51 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45FEDF30.6000608@cisco.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com><45F6E21C.2060802@sun.com> <45FEDF30.6000608@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B4711@nuova-ex1.hq.nuovaimpresa.com> Seems like Radia's option B is a reasonable option. Just because an RBridge has directly connected hosts on VLAN A doesn't qualify it to understand what should (or shouldn't) be connected on VLAN B. There are many examples of locally assigned Ethernet addresses being used within a subnet. It doesn't seem like there is any fundamental requirement for TRILL to change this. Clearly... there needs to be a policy for handling the same address connected to different RBridges in the SAME VLAN. My $0.02, JR > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White > Sent: Monday, March 19, 2007 12:06 PM > To: Radia Perlman > Cc: rbridge at postel.org > Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > - From an IS-IS perspective, if we do a, we only have, I > think, a single > process, while if we do b, it makes more sense to do multiple > processes, > right? In reality, the way the TLVs are laid out today, we > can advertise > each l2 address with a vid, or not, or a group of l2 addresses with a > single vid to indicate they are all within this vid, or some other > various combinations. > > :-) > > Russ > > Radia Perlman wrote: > > Ah. Now I understand the issue, I think. You are saying that if MAC > > addresses are globally unique, > > an RBridge attached only to VLAN A should still monitor the endnode > > membership of the other VLANs, > > in case one of its endnodes moves and appears elsewhere. > > > > So I think we are talking about two alternatives: > > a) have all RBridges see all endnode memberships on all VLANs > > b) have RBridges only see endnode memberships for VLANs they are > > directly attached to. > > > > I see the disadvantages of each as: > > a) extra bandwidth and storage for having endnode > membership go everywhere > > b) less timely noticing an endnode has moved to another VLAN > > > > If I understand things correctly, I much prefer b), for the > following > > reasons: > > 1) option a offers an endnode in VLAN A the ability to > annoy VLAN B by > > pretending to be MAC addresses > > belonging to VLAN B (so option b is safer and provides > more separation > > between VLANs) > > 2) option b) greatly lowers the burden on RBridges because > they only > > have to keep information for > > their own VLANs > > 3) option b) is likely to save bandwidth on distributing > endnode information > > 4) there might be cases where an endnode might attach to > multiple VLANs, > > and the RBridges will > > panic unnecessarily > > > > Radia > > > > Caitlin Bestler wrote: > > > >> The issue is not how the information is relayed, or how it > is stored, > >> but who determines what information is relevant. > >> > >> If all RBridges track MAC Addresses scoped within a VLAN scope > >> then everything you suggest works perfectly fine. The only > correction > >> needed would be to emphasize that this is indeed a requirement. > >> > >> But any RBridge that uses a global scope for MAC Addresses should > >> be told of new MAC detections on different VLANs because such > >> an RBridge would want to delete the old location. > >> > >> Unless the RBridge that detected the MAC address knows that all > >> other RBridges are using VLAN scoped MAC addresses they should > >> distribute the new information to *all* RBRidges, not just those on > >> the VLAN where the address was discovered. > >> > >> > >> _______________________________________________ > >> 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 > > - -- > riw at cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFF/t8wER27sUhU9OQRArzYAJ9WuW82Wcaeml5+OVEmb/OAChUO4wCg7cgY > 6bS0r3gfLceCcCIUYXFR5HI= > =F2tF > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From caitlinb at broadcom.com Mon Mar 19 14:50:11 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 19 Mar 2007 14:50:11 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> Silvano Gai wrote: > I think TRILL needs to do exactly what IEEE 802.1Q does. > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. > > N is never advertised outside the bridge, and the mapping of > M to N is never advertised outside the bridge. TRILL must do the same. > > Learning is done on {VID, MAC-address} pairs. TRILL must do the same. > My reading of Appendix B is that Shared Learning is allowed, where VID is not a key field (i.e, there is only one FID supported). Appendix B details some of the problems this creates. I believe the problems for RBridges are even greater than for simple Bridges. This probably justifies restricting RBridges to the Independent Learning model, but any such additional restriction should be explicitly stated. From ddutt at cisco.com Mon Mar 19 15:24:56 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 19 Mar 2007 15:24:56 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <45FF0DB8.5010801@cisco.com> Hi Caitlin, Caitlin Bestler wrote: > My understanding of 802.1 specifications is that the following sequence > is acceptable behavior for a bridge: > > 1) VLAN 7 MAC X is seen on port 1. > 2) Bridge learns that MAC X is on port 1 with VLAN 7. > 3) VLAN 8 MAC X is seen on port 1. > 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X). > I don't think it happens this way. 802.1d bridges map the Vlan ID into a separate filtering database ID called FID and learn the MAC addresses along with the FID, not the VID. In independent VLAN learning, FID == VID whereas in shared VLAN learning, multiple VIDs map into a single FID. Therefore in your example above, Bridge learns MAC X on port 1, FID z where z is the same for VLANs 7 & 8 or it learns MAC x, FID z1 and MAC x, FID z2 where Vlan 7 = FID z1 and Vlan 8 = FID z2. ARP/ND based learning is specific to TRILL and needs to decide its behavior. Silvano and I discuss this a bit in our presentation on Wed. Dinesh > This is of course undesirable, but a livable quirk. It is best avoided by either > ensuring that global MAC Addresses are truly unique, or ensuring that all bridges > deployed in one subnet agree on exactly how unique a "globally unique" address is. > > RBridges do more than merely forward ethernet frames amongst themselves, they collaborate > to implement a distributed ARP/ND proxy. That probably justifies stating that for purposes > of the shared discovery data that MAC Addresses are assumed to be unique only as scoped > within a VLAN, but I think we should acknowledge (and highlight) that we are narrowing > the scope of legal behaviors that would have been available to a bridge. > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From ddutt at cisco.com Mon Mar 19 15:29:29 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 19 Mar 2007 15:29:29 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45F6E21C.2060802@sun.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6E21C.2060802@sun.com> Message-ID: <45FF0EC9.3080203@cisco.com> Radia, I prefer option b as well. Just as in regular 802.1d bridges, we need to age out MAC addresses periodically if we don't see them. One important point is that we should set the default age timer to be greater than the default ARP cache timer to avoid flooding due to aging out a MAC entry but with the hosts still retaining the ARP entry. Dinesh Radia Perlman wrote: > Ah. Now I understand the issue, I think. You are saying that if MAC > addresses are globally unique, > an RBridge attached only to VLAN A should still monitor the endnode > membership of the other VLANs, > in case one of its endnodes moves and appears elsewhere. > > So I think we are talking about two alternatives: > a) have all RBridges see all endnode memberships on all VLANs > b) have RBridges only see endnode memberships for VLANs they are > directly attached to. > > I see the disadvantages of each as: > a) extra bandwidth and storage for having endnode membership go everywhere > b) less timely noticing an endnode has moved to another VLAN > > If I understand things correctly, I much prefer b), for the following > reasons: > 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by > pretending to be MAC addresses > belonging to VLAN B (so option b is safer and provides more separation > between VLANs) > 2) option b) greatly lowers the burden on RBridges because they only > have to keep information for > their own VLANs > 3) option b) is likely to save bandwidth on distributing endnode information > 4) there might be cases where an endnode might attach to multiple VLANs, > and the RBridges will > panic unnecessarily > > Radia > > Caitlin Bestler wrote: > > >> The issue is not how the information is relayed, or how it is stored, >> but who determines what information is relevant. >> >> If all RBridges track MAC Addresses scoped within a VLAN scope >> then everything you suggest works perfectly fine. The only correction >> needed would be to emphasize that this is indeed a requirement. >> >> But any RBridge that uses a global scope for MAC Addresses should >> be told of new MAC detections on different VLANs because such >> an RBridge would want to delete the old location. >> >> Unless the RBridge that detected the MAC address knows that all >> other RBridges are using VLAN scoped MAC addresses they should >> distribute the new information to *all* RBRidges, not just those on >> the VLAN where the address was discovered. >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From erik.nordmark at sun.com Tue Mar 20 08:14:09 2007 From: erik.nordmark at sun.com (Erik Nordmark) Date: Tue, 20 Mar 2007 08:14:09 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <45FFFA41.4070106@sun.com> Caitlin Bestler wrote: > My reading of Appendix B is that Shared Learning is allowed, where VID > is not a key field (i.e, there is only one FID supported). Appendix B > details some of the problems this creates. I believe the problems for > RBridges are even greater than for simple Bridges. This probably > justifies > restricting RBridges to the Independent Learning model, but any such > additional restriction should be explicitly stated. My understanding is is that shared learning is useless when VLANs are used for isolation/security. With shared learning a host on VLAN A can trivially cause a DoS attack VLAN B by just sending packets with the source MAC address being the MAC address of another host on another VLAN. Thus I'd be surprised if it is used much in practice with bridges. I don't see it being a reasonable default for RBridges. Erik From caitlinb at broadcom.com Tue Mar 20 08:29:24 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Tue, 20 Mar 2007 08:29:24 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45FFFA41.4070106@sun.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DDFDC@NT-IRVA-0750.brcm.ad.broadcom.com> Erik Nordmark wrote: > Caitlin Bestler wrote: > >> My reading of Appendix B is that Shared Learning is allowed, where >> VID is not a key field (i.e, there is only one FID supported). >> Appendix B details some of the problems this creates. I believe the >> problems for RBridges are even greater than for simple Bridges. This >> probably justifies restricting RBridges to the Independent Learning >> model, but any such additional restriction should be explicitly >> stated. > > My understanding is is that shared learning is useless when > VLANs are used for isolation/security. With shared learning a > host on VLAN A can trivially cause a DoS attack VLAN B by > just sending packets with the source MAC address being the > MAC address of another host on another VLAN. > > Thus I'd be surprised if it is used much in practice with bridges. > > I don't see it being a reasonable default for RBridges. > > Erik It's a perfectly reasonable behavior, as long as the VID is at least checked (i.e., it is an attribute, not a key field). A set of RBridges that *all* used this approach would work perfectly fine. The real issue is whether RBridges that will realistically tend to use Independent Learning can easily accommodate some of their peers doing Shared Learning, and if so, how. For example, the rule could be that you can use Shared Learning as long as no other RBridge can detect that you aren't using Independent Learning. Or Shared/Independent Learning could be a flag that each RBridge advertises. Or each RBridge could advertise it's VID->FID map. All of these work, the question is which are justified. As much as I dislike increasing the key size I can certainly see the advantages to maintaining a distributed database of requiring all RBridges to use Independent Learning. So I'd lean toward simply standardizing on Independent Learning. But any new requirement is best explicitly stated, not inferred from the data descriptions. From jrrivers at nuovasystems.com Tue Mar 20 08:44:35 2007 From: jrrivers at nuovasystems.com (J. R. Rivers) Date: Tue, 20 Mar 2007 08:44:35 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45FFFA41.4070106@sun.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> <45FFFA41.4070106@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B49B9@nuova-ex1.hq.nuovaimpresa.com> If I'm remembering my history correctly, 3Com wanted to use this "mode" to enable a short-cut routing mechanism (whose name escapes me now). JR > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark > Sent: Tuesday, March 20, 2007 8:14 AM > To: Caitlin Bestler > Cc: rbridge at postel.org; Radia Perlman > Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > > Caitlin Bestler wrote: > > > My reading of Appendix B is that Shared Learning is > allowed, where VID > > is not a key field (i.e, there is only one FID supported). > Appendix B > > details some of the problems this creates. I believe the > problems for > > RBridges are even greater than for simple Bridges. This probably > > justifies > > restricting RBridges to the Independent Learning model, but any such > > additional restriction should be explicitly stated. > > My understanding is is that shared learning is useless when VLANs are > used for isolation/security. With shared learning a host on > VLAN A can > trivially cause a DoS attack VLAN B by just sending packets with the > source MAC address being the MAC address of another host on > another VLAN. > > Thus I'd be surprised if it is used much in practice with bridges. > > I don't see it being a reasonable default for RBridges. > > Erik > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Tue Mar 20 09:06:26 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 20 Mar 2007 09:06:26 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <45FFFA41.4070106@sun.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> <45FFFA41.4070106@sun.com> Message-ID: <46000682.7040908@sun.com> Re Erik's: >>I don't see it being a reasonable default for RBridges. Not just not reasonable as default, but *ever*. I'm sure we don't want to have a parameter allowing RBridges to do shared learning. Radia Erik Nordmark wrote: > Caitlin Bestler wrote: > >> My reading of Appendix B is that Shared Learning is allowed, where VID >> is not a key field (i.e, there is only one FID supported). Appendix B >> details some of the problems this creates. I believe the problems for >> RBridges are even greater than for simple Bridges. This probably >> justifies >> restricting RBridges to the Independent Learning model, but any such >> additional restriction should be explicitly stated. > > > My understanding is is that shared learning is useless when VLANs are > used for isolation/security. With shared learning a host on VLAN A can > trivially cause a DoS attack VLAN B by just sending packets with the > source MAC address being the MAC address of another host on another VLAN. > > Thus I'd be surprised if it is used much in practice with bridges. > > I don't see it being a reasonable default for RBridges. > > Erik From sgai at nuovasystems.com Tue Mar 20 09:35:03 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Tue, 20 Mar 2007 09:35:03 -0700 Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC In-Reply-To: References: Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> This document has some issues that need to be corrected before it can pass an IESG last call. In order of importance: 1) The document equates Ethernet with IEEE 802 and this is clearly incorrect, since IEEE 802 includes also technologies like Token Ring, DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet must be equated with IEEE 802.3 2) The document discusses Spanning Tree compatibility in section 1.2 where it claims that BPDUs must be terminated and in Section 4.1 where the term "block" is used. This is clearly in contrast with what discussed in the WG and in the base protocol spec, where BPDUs are at least processed (in one proposal) or even sourced by RBridges (in an alternate proposal). 3) Section 1.1 Terminology is formally incorrect since [TARCH] is not an approved document. It is also substantially incorrect since many terms listed are not used in this document and some are not agreed in the WG. I propose to eliminate this section. 4) The document uses the term "will" that is not compliant with RFC2119. In general a better definition of what is mandatory and what is optional is important in a requirement document. 5) Introduction - Bridging limitation. The first paragraph refers to Ethernet networks used without Spanning Tree. This is irrelevant, since Spanning Tree is always deployed in conjunction with Ethernet. The correct contrast must be between Ethernet with Spanning Tree and Ethernet with TRILL. The claim of a single broadcast/flooding domain is incorrect since VLANs have solved this issue many years ago. -- Silvano Gai > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of The IESG > Sent: Friday, March 16, 2007 2:53 PM > To: IETF-Announce > Cc: rbridge at postel.org > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL > RoutingRequirements in Support of RBridges) to Informational RFC > > The IESG has received a request from the Transparent Interconnection of > Lots of Links WG (trill) to consider the following document: > > - 'TRILL Routing Requirements in Support of RBridges ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf at ietf.org mailing lists by 2007-03-30. Exceptionally, > comments may be sent to iesg at ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 15 > 187&rfc_flag=0 > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From sgai at nuovasystems.com Tue Mar 20 10:06:43 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Tue, 20 Mar 2007 10:06:43 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> References: <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B4A32@nuova-ex1.hq.nuovaimpresa.com> Caitlin, inline > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb at broadcom.com] > Sent: Monday, March 19, 2007 2:50 PM > To: Silvano Gai; Radia Perlman > Cc: rbridge at postel.org; Erik Nordmark > Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness > > Silvano Gai wrote: > > I think TRILL needs to do exactly what IEEE 802.1Q does. > > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. > > > > N is never advertised outside the bridge, and the mapping of > > M to N is never advertised outside the bridge. TRILL must do the same. > > > > Learning is done on {VID, MAC-address} pairs. TRILL must do the same. > > > My reading of Appendix B is that Shared Learning is allowed, where VID > is not a key field (i.e, there is only one FID supported). Appendix B > details some of the problems this creates. I believe the problems for > RBridges are even greater than for simple Bridges. This probably > justifies > restricting RBridges to the Independent Learning model, but any such > additional restriction should be explicitly stated. I am not saying I want to restrict, I am saying that in bridges what triggers learning is always the reception of a frame that has a {VID, MAC-address} pair. The fact that the VID, on that particular bridge, shares the FID with other VIDs is what causes shared learning. But shared learning NEVER propagates. TRILL MUST NOT propagate shared learning. IT MUST always propagate {VID, MAC-address}. Recipients may decide to do individual or shared learning. -- Silvano From caitlinb at broadcom.com Tue Mar 20 10:16:51 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Tue, 20 Mar 2007 10:16:51 -0700 Subject: [rbridge] VLAN Scoping / MAC Uniqueness In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013B4A32@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DE086@NT-IRVA-0750.brcm.ad.broadcom.com> Silvano Gai wrote: > Caitlin, > > inline > >> -----Original Message----- >> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] >> Sent: Monday, March 19, 2007 2:50 PM >> To: Silvano Gai; Radia Perlman >> Cc: rbridge at postel.org; Erik Nordmark >> Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness >> >> Silvano Gai wrote: >>> I think TRILL needs to do exactly what IEEE 802.1Q does. >>> AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >>> =N. >>> >>> N is never advertised outside the bridge, and the mapping of M to N >>> is never advertised outside the bridge. TRILL must do the same. >>> >>> Learning is done on {VID, MAC-address} pairs. TRILL must do the >>> same. >>> >> My reading of Appendix B is that Shared Learning is allowed, where >> VID is not a key field (i.e, there is only one FID supported). >> Appendix B details some of the problems this creates. I believe the >> problems for RBridges are even greater than for simple Bridges. This >> probably justifies restricting RBridges to the Independent Learning >> model, but any such additional restriction should be explicitly >> stated. > > I am not saying I want to restrict, I am saying that in > bridges what triggers learning is always the reception of a > frame that has a {VID, MAC-address} pair. The fact that the > VID, on that particular bridge, shares the FID with other > VIDs is what causes shared learning. But shared learning > NEVER propagates. TRILL MUST NOT propagate shared learning. > IT MUST always propagate {VID, MAC-address}. Recipients may > decide to do individual or shared learning. > > -- Silvano >From a standards point of view I could see stating that all TRILL-related protocols MUST be based on Independent Learning, but that an RBridge MAY use Shared Learning for its local ports when acting as a Bridge. And I suppose if you literally grafted an RBridge as an add-on module to an existing Bridge with shared learning it might even make sense. Effectively, however, it is requiring RBridges to use Independent Learning. I see that requirement as inevitable, and therefore best stated explicitly. From eric.gray at ericsson.com Tue Mar 20 11:30:32 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Tue, 20 Mar 2007 13:30:32 -0500 Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF9EAC18@eusrcmw721.eamcs.ericsson.se> Silvano, Thanks for posting these comments. Please see below. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > Sent: Tuesday, March 20, 2007 12:35 PM > To: ietf at ietf.org > Cc: rbridge at postel.org > Subject: Re: [rbridge] Last Call: > draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in > Support of RBridges) to Informational RFC > > > This document has some issues that need to be corrected before it can > pass an IESG last call. I think as a strict matter of process, we don't get to say what MUST be corrected before a document can pass IESG last call (if there is such a thing). Luckily, I believe this is an IETF Last Call, where the idea is that the IESG is asking for our input before making _their_ decision as to what - if anything - MUST be changed. > > In order of importance: > 1) The document equates Ethernet with IEEE 802 and this is clearly > incorrect, since IEEE 802 includes also technologies like Token Ring, > DQDB, Wireless that are clearly outside the scope of TRILL. Ether