From Radia.Perlman at sun.com Fri Dec 1 11:58:42 2006 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Fri, 01 Dec 2006 11:58:42 -0800 Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized Message-ID: <71a9647c60f2.457018f2@sunlabs.com> Silvano explained a reason for an "outer" vs an "inner" VLAN tag, which is really to accomplish making a 24-bit VLAN tag, hierarchically assigned by 12 bits for customer, and 12 bits for use by that customer. The only changes we'd need to the base spec is as follows: a) the VLAN tag specified in the per-VLAN IS-IS instance would be 24 bits instead of 12 (the per-VLAN instance is the thing where R1 says what endnodes are attached, and whether R1 has an IP multicast router attached, and what IP multicast groups have members attached). b) For unicast traffic: the ingress RBridge R1 looks up the egress RBridge R2 based on the 24-bit VLAN tag, (using the 12 bits in the frame indicating the customer-defined VLAN, plus 12 bits R1 infers based on which port R1 received the frame from) R1 puts the "which customer" portion of the VLAN tag in the outer header. The reason for this is in case R2 has ports to two different customers, and there are overlapping endnode address spaces, R2 will need the outer VLAN tag to determine which port to decapsulate the frame onto. c) for unknown destination/multicast: the ingress RBridge R1 puts the "which customer" portion of the VLAn tag into an outer VLAN tag, and RBridges in the core filter based on the 24-bit VLAN by using both the inner and outer 12 bits. This proposal still treats the infrastructure (all the transit links) as shared by all VLANs, which I like the robustness and simplicity of. Radia ----- Original Message ----- From: Radia Perlman Date: Thursday, November 30, 2006 7:36 pm Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized > There's been a lot of discussion, and I believe this is what is > going > on: In this email I will attempt to just > explain, and not advocate. If I want to express opinions, I'll > reply to > this. > > The first question we have to ask is what things people are doing > with > VLANs. The next is to ask > which subset of these (possibly "all") we want to support with > TRILL, > and to answer that we have > to also answer what the cost/benefit of solving each with TRILL is. > > Things VLANs can provide: > a) separate endnodes into communities, to enforce that only VLAN A > nodes > can talk to VLAN A nodes > b) scoping things like ARP, so an ARP for a VLAN A node only gets > sent > on VLAN A links > c) security -- making sure that VLAN A nodes cannot snoop on VLAN B > trafficd) provisioning -- making sure that the only traffic on a > VLAN A link is > VLAN A traffic, or > perhaps BGP-policy-like, as in, "this link is willing to carry > VLANs A, > B, and Q, but not D". > > Perhaps this is not an exhaustive list, but I hope it's close enough. > > What are the costs of providing these things? > > The solution that I'd been assuming solves a) and b). That solution > is > summarized as follows: > If RBridges R1 and R2 are on the same link, they are neighbors, and > they > can send transit traffic to each other, > regardless of the VLAN on which it originated. This can be thought > of as > RBridges create a cloud, > which keeps VLAN traffic segregated at the endpoints, but is a > single > shared infrastructure for all > VLANs within the cloud. > > That solution does not solve c) and d), though if the transit links > are > all point-to-point links > between RBridges, this is moot. The case that isn't solved is when > a > link is both a transit link > and a shared link with a bunch of endnodes in a VLAN. > > Suppose we want to solve those? > > What I think people would be asking for is to have the VLAN > determine > not just the destination, but what > path the packet takes. So some links would only allow certain VLAN > traffic on them, even for transit. > Which would mean multiple forwarding tables, since paths would have > to > be VLAN-dependent. > > So, I think the basic strategies are: > > a) create as much connectivity as possible between RBridge > neighbors. If > R1, R2, and R3 are on the same > shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" > into > the header, and R1 can only > talk to R3 if it puts "VLAN Y" into the header, R1 discovers this > case > by being configured that the > link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with > both, > and wdiscovers that on the > adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to > stick > "VLAN Y". So R1 does whatever > is necessary to talk to its neighbors, but it is only relevant on > the > hop. R1 reports in its link state packet that > it has a neighbor R2, and R3. All RBridges can use the link for > transit > for all VLANs. > > b) only allow R1 and R2 to be IS-IS neighbors if they can talk to > each > other with a null VLAN tag. A link > that requires a VLAN tag can only be used as an ingress or egress > link > from the cloud. > > c) copy the VLAN tag to the outer header, assume any link that > requires > a particular VLAN tag wants to exclude > transit traffic for all other VLANs, or even for null tags, on the > link > Run separate core instances of IS-IS for > each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN > A > links, plus links that allow > for null tags. > > d) like with c), but allow a link to be configured as "there are > VLAN A > endnodes here, but transit traffic for any VLAN > is fine". > > Solutions c) and d) require separate forwarding tables per VLAN, > and > either separate instances of IS-IS, or > a link attribute that lists legal VLAN tags for the link. VLAN A > segments might become disconnected > because although there is RBridge connectivity, it isn't through > links > that say it's OK to have VLAN A traffic. > > Radia > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From gibanez at it.uc3m.es Fri Dec 1 14:44:14 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Fri, 01 Dec 2006 23:44:14 +0100 Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized In-Reply-To: <71a9647c60f2.457018f2@sunlabs.com> References: <71a9647c60f2.457018f2@sunlabs.com> Message-ID: <4570B03E.4080003@it.uc3m.es> I wonder whether the IEEE position against extending VLANs to 24 bit applies in the RBridges context. See the mail below from the liaison to IETF. Guillermo Extracted text: "The possible concatenation of two 802.1Q VLAN tags (to yield a 24-bit VLAN identifier) has been discussed, is of considerable concern, and is believed to be not just a violation of the 802.1Q standard but also of the architectural principles on which 802.1 standardization is based". From: "Romascanu, Dan (Dan)" > To: "IESG" >; > Cc: < l2vpn at ietf.org >; >; "Tony Jeffree" > Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) __________________________________________________ Radia.Perlman at sun.com escribi?: > Silvano explained a reason for an "outer" vs an "inner" VLAN tag, which is really to accomplish making > a 24-bit VLAN tag, hierarchically assigned by 12 bits for customer, and 12 bits for use by that customer. > > The only changes we'd need to the base spec is as follows: > > a) the VLAN tag specified in the per-VLAN IS-IS instance would be 24 bits instead of 12 (the per-VLAN instance > is the thing where R1 says what endnodes are attached, and whether R1 has an IP multicast router > attached, and what IP multicast groups have members attached). > > b) For unicast traffic: the ingress RBridge R1 looks up the egress RBridge R2 based on > the 24-bit VLAN tag, (using the 12 bits in the frame indicating the customer-defined VLAN, plus 12 bits R1 infers > based on which port R1 received the frame from) > R1 puts the "which customer" portion of the VLAN tag in the outer header. The reason for this is > in case R2 has ports to two different customers, and there are overlapping endnode address spaces, R2 will > need the outer VLAN tag to determine which port to decapsulate the frame onto. > > c) for unknown destination/multicast: the ingress RBridge R1 puts the "which customer" portion of the VLAn > tag into an outer VLAN tag, and RBridges in the core filter based on the 24-bit VLAN by using both the inner > and outer 12 bits. > > This proposal still treats the infrastructure (all the transit links) as shared by all VLANs, which I like the > robustness and simplicity of. > > Radia > > > > ----- Original Message ----- > From: Radia Perlman > Date: Thursday, November 30, 2006 7:36 pm > Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized > > >> There's been a lot of discussion, and I believe this is what is >> going >> on: In this email I will attempt to just >> explain, and not advocate. If I want to express opinions, I'll >> reply to >> this. >> >> The first question we have to ask is what things people are doing >> with >> VLANs. The next is to ask >> which subset of these (possibly "all") we want to support with >> TRILL, >> and to answer that we have >> to also answer what the cost/benefit of solving each with TRILL is. >> >> Things VLANs can provide: >> a) separate endnodes into communities, to enforce that only VLAN A >> nodes >> can talk to VLAN A nodes >> b) scoping things like ARP, so an ARP for a VLAN A node only gets >> sent >> on VLAN A links >> c) security -- making sure that VLAN A nodes cannot snoop on VLAN B >> trafficd) provisioning -- making sure that the only traffic on a >> VLAN A link is >> VLAN A traffic, or >> perhaps BGP-policy-like, as in, "this link is willing to carry >> VLANs A, >> B, and Q, but not D". >> >> Perhaps this is not an exhaustive list, but I hope it's close enough. >> >> What are the costs of providing these things? >> >> The solution that I'd been assuming solves a) and b). That solution >> is >> summarized as follows: >> If RBridges R1 and R2 are on the same link, they are neighbors, and >> they >> can send transit traffic to each other, >> regardless of the VLAN on which it originated. This can be thought >> of as >> RBridges create a cloud, >> which keeps VLAN traffic segregated at the endpoints, but is a >> single >> shared infrastructure for all >> VLANs within the cloud. >> >> That solution does not solve c) and d), though if the transit links >> are >> all point-to-point links >> between RBridges, this is moot. The case that isn't solved is when >> a >> link is both a transit link >> and a shared link with a bunch of endnodes in a VLAN. >> >> Suppose we want to solve those? >> >> What I think people would be asking for is to have the VLAN >> determine >> not just the destination, but what >> path the packet takes. So some links would only allow certain VLAN >> traffic on them, even for transit. >> Which would mean multiple forwarding tables, since paths would have >> to >> be VLAN-dependent. >> >> So, I think the basic strategies are: >> >> a) create as much connectivity as possible between RBridge >> neighbors. If >> R1, R2, and R3 are on the same >> shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" >> into >> the header, and R1 can only >> talk to R3 if it puts "VLAN Y" into the header, R1 discovers this >> case >> by being configured that the >> link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with >> both, >> and wdiscovers that on the >> adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to >> stick >> "VLAN Y". So R1 does whatever >> is necessary to talk to its neighbors, but it is only relevant on >> the >> hop. R1 reports in its link state packet that >> it has a neighbor R2, and R3. All RBridges can use the link for >> transit >> for all VLANs. >> >> b) only allow R1 and R2 to be IS-IS neighbors if they can talk to >> each >> other with a null VLAN tag. A link >> that requires a VLAN tag can only be used as an ingress or egress >> link >> from the cloud. >> >> c) copy the VLAN tag to the outer header, assume any link that >> requires >> a particular VLAN tag wants to exclude >> transit traffic for all other VLANs, or even for null tags, on the >> link >> Run separate core instances of IS-IS for >> each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN >> A >> links, plus links that allow >> for null tags. >> >> d) like with c), but allow a link to be configured as "there are >> VLAN A >> endnodes here, but transit traffic for any VLAN >> is fine". >> >> Solutions c) and d) require separate forwarding tables per VLAN, >> and >> either separate instances of IS-IS, or >> a link attribute that lists legal VLAN tags for the link. VLAN A >> segments might become disconnected >> because although there is RBridge connectivity, it isn't through >> links >> that say it's OK to have VLAN A traffic. >> >> 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 Eric.Gray at marconi.com Fri Dec 1 15:25:58 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Fri, 1 Dec 2006 18:25:58 -0500 Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized Message-ID: <0BF76B30C100624BA997C9CED19D8125F2BC71@uspitsmsgusr08.win.marconi.com> I have no fundamental objections to making this change. However, it may be important to realize that the supposed purpose for this change implies a "service provisioning" model for RBridge/TRILL deployment as opposed to a strictly enterprise model. Even in the case where we're speaking of an enterprise so large that the enterprise's IT functions effectively as a service provider, we potentially open the door to the _general_ service provisioning problem space. I hope this is not the fore-runner to a number of simple changes that might lead us to proposing a solution to a set of problems the IETF is already addressing elsewhere... -- Eric > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com > Sent: Friday, December 01, 2006 2:59 PM > To: Radia Perlman > Cc: rbridge at postel.org > Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized > > Silvano explained a reason for an "outer" vs an "inner" VLAN > tag, which is really to accomplish making > a 24-bit VLAN tag, hierarchically assigned by 12 bits for > customer, and 12 bits for use by that customer. > > The only changes we'd need to the base spec is as follows: > > a) the VLAN tag specified in the per-VLAN IS-IS instance > would be 24 bits instead of 12 (the per-VLAN instance > is the thing where R1 says what endnodes are attached, and > whether R1 has an IP multicast router > attached, and what IP multicast groups have members attached). > > b) For unicast traffic: the ingress RBridge R1 looks up the > egress RBridge R2 based on > the 24-bit VLAN tag, (using the 12 bits in the frame > indicating the customer-defined VLAN, plus 12 bits R1 infers > based on which port R1 received the frame from) > R1 puts the "which customer" portion of the VLAN tag in the > outer header. The reason for this is > in case R2 has ports to two different customers, and there > are overlapping endnode address spaces, R2 will > need the outer VLAN tag to determine which port to > decapsulate the frame onto. > > c) for unknown destination/multicast: the ingress RBridge R1 > puts the "which customer" portion of the VLAn > tag into an outer VLAN tag, and RBridges in the core filter > based on the 24-bit VLAN by using both the inner > and outer 12 bits. > > This proposal still treats the infrastructure (all the > transit links) as shared by all VLANs, which I like the > robustness and simplicity of. > > Radia > > > > ----- Original Message ----- > From: Radia Perlman > Date: Thursday, November 30, 2006 7:36 pm > Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized > > > There's been a lot of discussion, and I believe this is what is > > going > > on: In this email I will attempt to just > > explain, and not advocate. If I want to express opinions, I'll > > reply to > > this. > > > > The first question we have to ask is what things people are doing > > with > > VLANs. The next is to ask > > which subset of these (possibly "all") we want to support with > > TRILL, > > and to answer that we have > > to also answer what the cost/benefit of solving each with TRILL is. > > > > Things VLANs can provide: > > a) separate endnodes into communities, to enforce that only VLAN A > > nodes > > can talk to VLAN A nodes > > b) scoping things like ARP, so an ARP for a VLAN A node only gets > > sent > > on VLAN A links > > c) security -- making sure that VLAN A nodes cannot snoop on VLAN B > > trafficd) provisioning -- making sure that the only traffic on a > > VLAN A link is > > VLAN A traffic, or > > perhaps BGP-policy-like, as in, "this link is willing to carry > > VLANs A, > > B, and Q, but not D". > > > > Perhaps this is not an exhaustive list, but I hope it's > close enough. > > > > What are the costs of providing these things? > > > > The solution that I'd been assuming solves a) and b). That solution > > is > > summarized as follows: > > If RBridges R1 and R2 are on the same link, they are neighbors, and > > they > > can send transit traffic to each other, > > regardless of the VLAN on which it originated. This can be thought > > of as > > RBridges create a cloud, > > which keeps VLAN traffic segregated at the endpoints, but is a > > single > > shared infrastructure for all > > VLANs within the cloud. > > > > That solution does not solve c) and d), though if the transit links > > are > > all point-to-point links > > between RBridges, this is moot. The case that isn't solved is when > > a > > link is both a transit link > > and a shared link with a bunch of endnodes in a VLAN. > > > > Suppose we want to solve those? > > > > What I think people would be asking for is to have the VLAN > > determine > > not just the destination, but what > > path the packet takes. So some links would only allow certain VLAN > > traffic on them, even for transit. > > Which would mean multiple forwarding tables, since paths would have > > to > > be VLAN-dependent. > > > > So, I think the basic strategies are: > > > > a) create as much connectivity as possible between RBridge > > neighbors. If > > R1, R2, and R3 are on the same > > shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" > > into > > the header, and R1 can only > > talk to R3 if it puts "VLAN Y" into the header, R1 discovers this > > case > > by being configured that the > > link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with > > both, > > and wdiscovers that on the > > adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to > > stick > > "VLAN Y". So R1 does whatever > > is necessary to talk to its neighbors, but it is only relevant on > > the > > hop. R1 reports in its link state packet that > > it has a neighbor R2, and R3. All RBridges can use the link for > > transit > > for all VLANs. > > > > b) only allow R1 and R2 to be IS-IS neighbors if they can talk to > > each > > other with a null VLAN tag. A link > > that requires a VLAN tag can only be used as an ingress or egress > > link > > from the cloud. > > > > c) copy the VLAN tag to the outer header, assume any link that > > requires > > a particular VLAN tag wants to exclude > > transit traffic for all other VLANs, or even for null tags, on the > > link > > Run separate core instances of IS-IS for > > each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN > > A > > links, plus links that allow > > for null tags. > > > > d) like with c), but allow a link to be configured as "there are > > VLAN A > > endnodes here, but transit traffic for any VLAN > > is fine". > > > > Solutions c) and d) require separate forwarding tables per VLAN, > > and > > either separate instances of IS-IS, or > > a link attribute that lists legal VLAN tags for the link. VLAN A > > segments might become disconnected > > because although there is RBridge connectivity, it isn't through > > links > > that say it's OK to have VLAN A traffic. > > > > 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 Eric.Gray at marconi.com Fri Dec 1 15:35:04 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Fri, 1 Dec 2006 18:35:04 -0500 Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized Message-ID: <0BF76B30C100624BA997C9CED19D8125F2BC73@uspitsmsgusr08.win.marconi.com> Guillermo, I think I'm missing some context here. I want to understand what you mean by "concatenation of two 802.1Q VLAN tags (to yield a 24-bit VLAN identifier)" - are you speaking of explicit concatenation (in the sense that both 802.1Q VLAN tags are used simultaneously in making a forwarding decision), or are you talking about a general sense of layered 802.1Q (in which only one VLAN tag is used - at a time in the making of a single forwarding decision)? -- Eric > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Guillermo Ib??ez > Sent: Friday, December 01, 2006 5:44 PM > To: Radia.Perlman at sun.com > Cc: rbridge at postel.org > Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized > > > I wonder whether the IEEE position against extending VLANs to 24 bit > applies in the RBridges context. See the mail below from the > liaison to > IETF. > Guillermo > > Extracted text: "The possible concatenation of two 802.1Q > VLAN tags (to > yield a 24-bit VLAN identifier) has > been discussed, is of considerable concern, and is believed to be not > just a violation of the > 802.1Q standard but also of the architectural principles on > which 802.1 > standardization is > based". > > > From: "Romascanu, Dan (Dan)" > > To: "IESG" >; > > Cc: < l2vpn at ietf.org >; > >; > "Tony Jeffree" > > > Sent: Wednesday, September 06, 2006 2:55 PM > Subject: IEEE 802.1 WG liaison letter to the IETF > The IEEE 802.1 Working Group approved the following liaison letter to > the IETF, containing clarifications in response to several queries > related to the use of IEEE 802.1Q VLAN tags. > > http://www.ieee802.org/1/files/public/docs2006/liaison-contrib > -to-ietf-m > ef-dsl-forum-0706.pdf > b-to-ietf-mef-dsl-forum-0706.pdf> > > Please distribute this letter to the interested Working > Groups that are > not included in the distribution list. > > Dan > (wearing the hat of IEEE 802.1 WG liaison to the IETF) > > > __________________________________________________ > > Radia.Perlman at sun.com escribi?: > > Silvano explained a reason for an "outer" vs an "inner" > VLAN tag, which is really to accomplish making > > a 24-bit VLAN tag, hierarchically assigned by 12 bits for > customer, and 12 bits for use by that customer. > > > > The only changes we'd need to the base spec is as follows: > > > > a) the VLAN tag specified in the per-VLAN IS-IS instance > would be 24 bits instead of 12 (the per-VLAN instance > > is the thing where R1 says what endnodes are attached, and > whether R1 has an IP multicast router > > attached, and what IP multicast groups have members attached). > > > > b) For unicast traffic: the ingress RBridge R1 looks up the > egress RBridge R2 based on > > the 24-bit VLAN tag, (using the 12 bits in the frame > indicating the customer-defined VLAN, plus 12 bits R1 infers > > based on which port R1 received the frame from) > > R1 puts the "which customer" portion of the VLAN tag in > the outer header. The reason for this is > > in case R2 has ports to two different customers, and there > are overlapping endnode address spaces, R2 will > > need the outer VLAN tag to determine which port to > decapsulate the frame onto. > > > > c) for unknown destination/multicast: the ingress RBridge > R1 puts the "which customer" portion of the VLAn > > tag into an outer VLAN tag, and RBridges in the core filter > based on the 24-bit VLAN by using both the inner > > and outer 12 bits. > > > > This proposal still treats the infrastructure (all the > transit links) as shared by all VLANs, which I like the > > robustness and simplicity of. > > > > Radia > > > > > > > > ----- Original Message ----- > > From: Radia Perlman > > Date: Thursday, November 30, 2006 7:36 pm > > Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized > > > > > >> There's been a lot of discussion, and I believe this is what is > >> going > >> on: In this email I will attempt to just > >> explain, and not advocate. If I want to express opinions, I'll > >> reply to > >> this. > >> > >> The first question we have to ask is what things people are doing > >> with > >> VLANs. The next is to ask > >> which subset of these (possibly "all") we want to support with > >> TRILL, > >> and to answer that we have > >> to also answer what the cost/benefit of solving each with TRILL is. > >> > >> Things VLANs can provide: > >> a) separate endnodes into communities, to enforce that only VLAN A > >> nodes > >> can talk to VLAN A nodes > >> b) scoping things like ARP, so an ARP for a VLAN A node only gets > >> sent > >> on VLAN A links > >> c) security -- making sure that VLAN A nodes cannot snoop > on VLAN B > >> trafficd) provisioning -- making sure that the only traffic on a > >> VLAN A link is > >> VLAN A traffic, or > >> perhaps BGP-policy-like, as in, "this link is willing to carry > >> VLANs A, > >> B, and Q, but not D". > >> > >> Perhaps this is not an exhaustive list, but I hope it's > close enough. > >> > >> What are the costs of providing these things? > >> > >> The solution that I'd been assuming solves a) and b). That > solution > >> is > >> summarized as follows: > >> If RBridges R1 and R2 are on the same link, they are > neighbors, and > >> they > >> can send transit traffic to each other, > >> regardless of the VLAN on which it originated. This can be thought > >> of as > >> RBridges create a cloud, > >> which keeps VLAN traffic segregated at the endpoints, but is a > >> single > >> shared infrastructure for all > >> VLANs within the cloud. > >> > >> That solution does not solve c) and d), though if the > transit links > >> are > >> all point-to-point links > >> between RBridges, this is moot. The case that isn't solved is when > >> a > >> link is both a transit link > >> and a shared link with a bunch of endnodes in a VLAN. > >> > >> Suppose we want to solve those? > >> > >> What I think people would be asking for is to have the VLAN > >> determine > >> not just the destination, but what > >> path the packet takes. So some links would only allow certain VLAN > >> traffic on them, even for transit. > >> Which would mean multiple forwarding tables, since paths > would have > >> to > >> be VLAN-dependent. > >> > >> So, I think the basic strategies are: > >> > >> a) create as much connectivity as possible between RBridge > >> neighbors. If > >> R1, R2, and R3 are on the same > >> shared/bridged link, and R1 can only talk to R2 if it puts > "VLAN X" > >> into > >> the header, and R1 can only > >> talk to R3 if it puts "VLAN Y" into the header, R1 discovers this > >> case > >> by being configured that the > >> link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with > >> both, > >> and wdiscovers that on the > >> adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to > >> stick > >> "VLAN Y". So R1 does whatever > >> is necessary to talk to its neighbors, but it is only relevant on > >> the > >> hop. R1 reports in its link state packet that > >> it has a neighbor R2, and R3. All RBridges can use the link for > >> transit > >> for all VLANs. > >> > >> b) only allow R1 and R2 to be IS-IS neighbors if they can talk to > >> each > >> other with a null VLAN tag. A link > >> that requires a VLAN tag can only be used as an ingress or egress > >> link > >> from the cloud. > >> > >> c) copy the VLAN tag to the outer header, assume any link that > >> requires > >> a particular VLAN tag wants to exclude > >> transit traffic for all other VLANs, or even for null tags, on the > >> link > >> Run separate core instances of IS-IS for > >> each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN > >> A > >> links, plus links that allow > >> for null tags. > >> > >> d) like with c), but allow a link to be configured as "there are > >> VLAN A > >> endnodes here, but transit traffic for any VLAN > >> is fine". > >> > >> Solutions c) and d) require separate forwarding tables per VLAN, > >> and > >> either separate instances of IS-IS, or > >> a link attribute that lists legal VLAN tags for the link. VLAN A > >> segments might become disconnected > >> because although there is RBridge connectivity, it isn't through > >> links > >> that say it's OK to have VLAN A traffic. > >> > >> 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 > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From erik.nordmark at sun.com Tue Dec 5 09:59:08 2006 From: erik.nordmark at sun.com (Erik Nordmark) Date: Tue, 05 Dec 2006 09:59:08 -0800 Subject: [rbridge] Draft minutes posted Message-ID: <4575B36C.8050500@sun.com> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt Any corrections? Erik From dwfedyk at nortel.com Tue Dec 5 10:16:56 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Tue, 5 Dec 2006 13:16:56 -0500 Subject: [rbridge] Draft minutes posted In-Reply-To: <4575B36C.8050500@sun.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C3ED845@zrtphxm2.corp.nortel.com> Hi Erik In the minutes: 802.1ah header synergy? On this point myself, and I recall Ali Sajassi and Donald Oconnor all stood up and said that 802.1ah is going to be a standard encapsulation header. My point was Trill should see what it could deliver on this encapsulation before inventing similar but different headers. Regards, Don > -----Original Message----- > From: rbridge-bounces at postel.org > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > > Any corrections? > > Erik > From Donald.Eastlake at motorola.com Tue Dec 5 12:17:28 2006 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 5 Dec 2006 15:17:28 -0500 Subject: [rbridge] Extensions In-Reply-To: <6ba8be229d3.456ded1e@sunlabs.com> Message-ID: <3870C46029D1F945B1472F170D2D979001C4956C@de01exm64.ds.mot.com> Hi, See comments below at @@@ -----Original Message----- From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] Sent: Wednesday, November 29, 2006 11:27 PM To: Eastlake III Donald-LDE008 Cc: rbridge at postel.org Subject: Re: [rbridge] Extensions Clearly making the ability to add fields in the future in a compatible way gives flexibility. Having TLV encoding in IS-IS has proven to be really valuable. On the other hand, questions that should be asked are: a) why not? As in, what is the cost of doing this future flexibility? b) what kinds of features might we imagine c) is there any other way of adding features in the future in a compatible way? I'll make a stab at some of these a) Why not? Perhaps complexity of forwarding decision, or perceived complexity of the protocol that might discourage adoption. If all the fields necessary for current functionality are in the fixed portion of the shim, and RBridges that don't do the feature can ignore it, then that would not be a problem. But for instance, if they have to look at the inner header to find the VLAN tag (in order to know whether to filter a multicast), or the inner destination address (for IP derived multicast -- though maybe it's the layer 3 destination address that matters...not sure), then having a variable length shim header could be a cost @@@ There is no getting around the fact that providing extensions makes things more complex. And since extensions can be present or absence, it necessarily leads to a variable length shim in cases where extensions might be present. However, the extension proposal in my presentation, which does incorporate some ideas I got from others, tries to minimize the additional complexity. In particular, it tries to assure that any Rbridge that might be an egress Rbridge will not receive any extension that it does not understand. A goal of the extension design is that an Rbridge the does not understand any extensions would not need any additional code. @@@ If there are fields after the shim in the current design that are clearly needed for normal operation, such as inner VLAN tag for broadcast/multicast filtering, then it seems like it might be a good idea to mirror them in the shim. @@@ But, beyond normal Rbridge operation, there is no obvious limit on how deeply some QoS policy might want to look into a packet. It could certainly want to look at TCP port, for example, which already requires it, in the Rbridge case, to skip over a variable length assortment of 802.1 inserts between the inner MAC addresses and the inner payload. If a feature outside of TRILL already has to do something that complex, it doesn't seem like much of a burden for it to understand a variable length shim due to extensions. Thus, the proposal in my presentation provides an overall extensions size to make it relatively easy to skip them. b) features: LIDs ... any others? @@@ LIDs seem like a nice extension that has the characteristic that you only would want to include it if both end point Rbridges understood it (see comments under "c)" below). @@@ Someone might want a security extension. Even if it turned out to use 802.1AE, it seem like you would need a way to indicate that such information was present in the Rbridge shim. @@@ Of course, the most interesting extensions would be those that are not currently thought of. c) not sure @@@ Adding feature can be done in different ways. I think they may all be logically equivalent but they would have very different implementation impact. For example, instead of extensions, you could have a version number so that when you define extension N, if you use that extension, you have to assert version N. This seems like a bad idea because you have to upgrade all your equipment to know about version N. Possibly that makes sense for an extension that every Rbridge actually has to understand, but maybe such a radical extension is best considered to be a revision of the base protocol. More reasonable extension proposals would provide more or less end-to-end Rbridge extensions in such a way that intervening Rbridges could ignore them. Radia @@@ Thanks, @@@ Donald ----- Original Message ----- From: Eastlake III Donald-LDE008 Date: Wednesday, November 29, 2006 7:58 pm Subject: [rbridge] Extensions > Hi, > > It is not so much that I think that TRILL needs any particular > extension added right now, it is just that if there is ever a reason to > add an extension, it would be good for the extension framework to have > been decided in advance. The presentation that I didn't have time to > make at the TRILL WG meeting in San Diego has now been converted from > MS Power Point and is on the Working Group agendas and presentations > web page for the 67th IETF meeting in HTML and is also available at > http://www.pothole.com/~dee3 in PDF. > > Donald > > -----Original Message----- > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Monday, November 13, 2006 8:01 PM > Cc: rbridge at postel.org > Subject: Re: [rbridge] Should we optimize the common case? > > ...... > > Another thing we haven't talked about on the list (and ran out of time > at the meeting), is Don Eastlake's suggestion of allowing the shim > header to be variable length, so that we can optionally put in thing > like LIDs. > > Radia > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Eric.Gray at marconi.com Tue Dec 5 13:18:32 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Tue, 5 Dec 2006 16:18:32 -0500 Subject: [rbridge] Draft minutes posted Message-ID: <0BF76B30C100624BA997C9CED19D812501016E0E@uspitsmsgusr08.win.marconi.com> Erik, Can I suggest that we should use a different thread - perhaps later (in a few days) - to address issues with the what was said during the meeting, that we might have disagreed with but did not have time to discuss? Meanwhile, we should use this thread only to talk about clarifying or correcting what was reportedly said during the meeting. Does that make sense? -- Eric > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark > Sent: Tuesday, December 05, 2006 12:59 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Draft minutes posted > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > > Any corrections? > > Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From sajassi at cisco.com Tue Dec 5 23:39:00 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Tue, 5 Dec 2006 23:39:00 -0800 Subject: [rbridge] Draft minutes posted Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB027827B3@xmb-sjc-21e.amer.cisco.com> Yes, if there is any reason as to why .1ah encap cannot be used, then I would like to hear it. -Ali > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk > Sent: Tuesday, December 05, 2006 10:17 AM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Draft minutes posted > > Hi Erik > > In the minutes: > 802.1ah header synergy? On this point myself, and I recall > Ali Sajassi and Donald Oconnor all stood up and said that > 802.1ah is going to be a standard encapsulation header. My > point was Trill should see what it could deliver on this > encapsulation before inventing similar but different headers. > > Regards, > Don > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > > > > Any corrections? > > > > Erik > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Eric.Gray at marconi.com Wed Dec 6 05:44:58 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Wed, 6 Dec 2006 08:44:58 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501016EAD@uspitsmsgusr08.win.marconi.com> Ali/Don, The use of 802.1ah encapsulation does not intuitively suggest itself in the TRILL problem domain for at least two reasons: 1) Provider Back-bone Bridging intuitively seems out of place in solutions aimed at enterprise networks - and this would seem to be even more true for solutions aimed at "plug-and-play" applicability. 2) Use of 802.1ah encapsulation assumes "bridging" of the tunneled frame transparently from edge-to-edge - and this would seem to go counter to the idea of using a link-state routing protocol for shortest path routing of MAC frames. That said, the minute that we start suggesting that an enterprise is large enough to require using service provider (like) solutions (in particular, requiring a substantial back-bone capacity, and assuming static configuration as a means to ensure deterministic network behavior) - OR that we might in fact use some form of spanning tree forwarding - it then becomes clear that we should consider using 802.1ah. It is certainly the case that we should not be defining another Ethernet encapsulation explicitly to solve the same problem. -- Eric > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Ali Sajassi (sajassi) > Sent: Wednesday, December 06, 2006 2:39 AM > To: Don Fedyk; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Draft minutes posted > > > > > Yes, if there is any reason as to why .1ah encap cannot be > used, then I > would like to hear it. > > -Ali > > > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk > > Sent: Tuesday, December 05, 2006 10:17 AM > > To: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Draft minutes posted > > > > Hi Erik > > > > In the minutes: > > 802.1ah header synergy? On this point myself, and I recall > > Ali Sajassi and Donald Oconnor all stood up and said that > > 802.1ah is going to be a standard encapsulation header. My > > point was Trill should see what it could deliver on this > > encapsulation before inventing similar but different headers. > > > > Regards, > > Don > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > > > > > > Any corrections? > > > > > > Erik > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From dwfedyk at nortel.com Wed Dec 6 08:14:39 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 6 Dec 2006 11:14:39 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D812501016EAD@uspitsmsgusr08.win.marconi.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C435E0F@zrtphxm2.corp.nortel.com> Hi Eric > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Ali/Don, > > The use of 802.1ah encapsulation does not intuitively > suggest itself in the TRILL problem domain for at least two > reasons: > > 1) Provider Back-bone Bridging intuitively seems out of > place in solutions aimed at enterprise networks - and > this would seem to be even more true for solutions > aimed at "plug-and-play" applicability. Hmmm Trill spent 1.5 years coming up with a header that looks remarkably like 802.1ah. A fact many of us have pointed out before. If you are using an IEEE 802.1 Ethernet data plane your baseline choices are 802.1Q or 802.1ah. > > 2) Use of 802.1ah encapsulation assumes "bridging" of the > tunneled frame transparently from edge-to-edge - and > this would seem to go counter to the idea of using a > link-state routing protocol for shortest path routing > of MAC frames. Encapsulation and the use of link state are orthogonal concepts so I disagree. > > That said, the minute that we start suggesting that an > enterprise is large enough to require using service provider > (like) solutions (in particular, requiring a substantial > back-bone capacity, and assuming static configuration as a > means to ensure deterministic network behavior) - OR that we > might in fact use some form of spanning tree forwarding - it > then becomes clear that we should consider using 802.1ah. It > is certainly the case that we should not be defining another > Ethernet encapsulation explicitly to solve the same problem. What we should be worried about is solutions for commoditized encapsulated header. Ethernet has benefited in the past by having a wide applicability: enterprise to carrier for chips and software that were produced. Regards, Don > > -- > Eric > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Ali > Sajassi (sajassi) > > Sent: Wednesday, December 06, 2006 2:39 AM > > To: Don Fedyk; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Draft minutes posted > > > > > > > > > > Yes, if there is any reason as to why .1ah encap cannot be > > used, then I > > would like to hear it. > > > > -Ali > > > > > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org > > > [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk > > > Sent: Tuesday, December 05, 2006 10:17 AM > > > To: Developing a hybrid router/bridge. > > > Subject: Re: [rbridge] Draft minutes posted > > > > > > Hi Erik > > > > > > In the minutes: > > > 802.1ah header synergy? On this point myself, and I recall > > > Ali Sajassi and Donald Oconnor all stood up and said that > > > 802.1ah is going to be a standard encapsulation header. My > > > point was Trill should see what it could deliver on this > > > encapsulation before inventing similar but different headers. > > > > > > Regards, > > > Don > > > > > > > -----Original Message----- > > > > From: rbridge-bounces at postel.org > > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > > > > > > > > Any corrections? > > > > > > > > Erik From Donald.Eastlake at motorola.com Wed Dec 6 08:51:03 2006 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 6 Dec 2006 11:51:03 -0500 Subject: [rbridge] Draft minutes posted In-Reply-To: <0BF76B30C100624BA997C9CED19D812501016E0E@uspitsmsgusr08.win.marconi.com> Message-ID: <3870C46029D1F945B1472F170D2D979001C90B46@de01exm64.ds.mot.com> Sure, That would be the ideal thing, with messages having this subject only about the accuracy of the minutes is recording what generally happened at the meeting and technical subjects in other threads with different subject lines. But it is usually hard to get people to constrain themselves that way. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Gray, Eric Sent: Tuesday, December 05, 2006 4:19 PM To: Erik Nordmark Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] Draft minutes posted Erik, Can I suggest that we should use a different thread - perhaps later (in a few days) - to address issues with the what was said during the meeting, that we might have disagreed with but did not have time to discuss? Meanwhile, we should use this thread only to talk about clarifying or correcting what was reportedly said during the meeting. Does that make sense? -- Eric > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark > Sent: Tuesday, December 05, 2006 12:59 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Draft minutes posted > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > > Any corrections? > > Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Wed Dec 6 09:25:25 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 06 Dec 2006 09:25:25 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40C435E0F@zrtphxm2.corp.nortel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA40C435E0F@zrtphxm2.corp.nortel.com> Message-ID: <4576FD05.1080807@isi.edu> Don Fedyk wrote: ... > Hmmm Trill spent 1.5 years coming up with a header that looks remarkably > like 802.1ah. Can you - or anyone with easy access to the specs - please post an explicit description of 802.1ah header and fields? Thanks, Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061206/c5b40dbf/signature-0001.bin From stbryant at cisco.com Wed Dec 6 09:49:50 2006 From: stbryant at cisco.com (Stewart Bryant) Date: Wed, 06 Dec 2006 17:49:50 +0000 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D812501016EAD@uspitsmsgusr08.win.marconi.com> References: <0BF76B30C100624BA997C9CED19D812501016EAD@uspitsmsgusr08.win.marconi.com> Message-ID: <457702BE.4050005@cisco.com> Gray, Eric wrote: > Ali/Don, > > The use of 802.1ah encapsulation does not intuitively > suggest itself in the TRILL problem domain for at least two > reasons: > > 1) Provider Back-bone Bridging intuitively seems out of > place in solutions aimed at enterprise networks - and > this would seem to be even more true for solutions > aimed at "plug-and-play" applicability. ... but what has that to do with the encapsulation mechanism? > > 2) Use of 802.1ah encapsulation assumes "bridging" of the > tunneled frame transparently from edge-to-edge - and > this would seem to go counter to the idea of using a > link-state routing protocol for shortest path routing > of MAC frames. Why so? There are many existance proofs that the choice of encap and the choice of topology protocol are othogonal. The only requirement is that the encap carries the necessary per packet information. - Stewart From erik.nordmark at sun.com Wed Dec 6 10:01:53 2006 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 06 Dec 2006 10:01:53 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40C435E0F@zrtphxm2.corp.nortel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA40C435E0F@zrtphxm2.corp.nortel.com> Message-ID: <45770591.7010809@sun.com> Don Fedyk wrote: > Hi Eric > >> -----Original Message----- >> From: Gray, Eric [mailto:Eric.Gray at marconi.com] >> >> Ali/Don, >> >> The use of 802.1ah encapsulation does not intuitively >> suggest itself in the TRILL problem domain for at least two >> reasons: >> >> 1) Provider Back-bone Bridging intuitively seems out of >> place in solutions aimed at enterprise networks - and >> this would seem to be even more true for solutions >> aimed at "plug-and-play" applicability. > Hmmm Trill spent 1.5 years coming up with a header that looks remarkably > like 802.1ah. A fact many of us have pointed out before. If you are > using an IEEE 802.1 Ethernet data plane your baseline choices are 802.1Q > or 802.1ah. Is there a TTL in the 802.1ah header? Erik From erik.nordmark at sun.com Wed Dec 6 10:02:47 2006 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 06 Dec 2006 10:02:47 -0800 Subject: [rbridge] Draft minutes posted In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40C3ED845@zrtphxm2.corp.nortel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA40C3ED845@zrtphxm2.corp.nortel.com> Message-ID: <457705C7.1020706@sun.com> Don Fedyk wrote: > Hi Erik > > In the minutes: > 802.1ah header synergy? On this point myself, and I recall Ali Sajassi > and Donald Oconnor all stood up and said that 802.1ah is going to be a > standard encapsulation header. My point was Trill should see what it > could deliver on this encapsulation before inventing similar but > different headers. I've added this: "802.1ah header synergy? Comments from Don Fedyk, Ali Sajassi and Donald Oconnor that 802.1ah is going to be a standard encapsulation header." which is what I think you said that you said. Erik From sajassi at cisco.com Wed Dec 6 11:15:51 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Wed, 6 Dec 2006 11:15:51 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB0278297C@xmb-sjc-21e.amer.cisco.com> Eric, > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > Sent: Wednesday, December 06, 2006 5:45 AM > To: Ali Sajassi (sajassi); Don Fedyk > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Ali/Don, > > The use of 802.1ah encapsulation does not intuitively > suggest itself in the TRILL problem domain for at least two > reasons: > > 1) Provider Back-bone Bridging intuitively seems out of > place in solutions aimed at enterprise networks - and > this would seem to be even more true for solutions > aimed at "plug-and-play" applicability. 802.1ah can equally be used in enterprise network with the same plug-and-play ease of use. If you think otherwise, please elaborate what part of 802.1ah is not suitable for such applications. > > 2) Use of 802.1ah encapsulation assumes "bridging" of the > tunneled frame transparently from edge-to-edge - and > this would seem to go counter to the idea of using a > link-state routing protocol for shortest path routing > of MAC frames. > 802.1ah primarily specifies the data-plane functionality. The use of link-state control-plane is independent from data-plane specification and one can easily use a link-state routing protocol with 802.1ah encap. As the mater of fact 802.aq is a step in this direction and this would be an area of mutual interest between the two working groups. > That said, the minute that we start suggesting that an > enterprise is large enough to require using service provider > (like) solutions (in particular, requiring a substantial > back-bone capacity, and assuming static configuration as a > means to ensure deterministic network behavior) - OR that we > might in fact use some form of spanning tree forwarding - it > then becomes clear that we should consider using 802.1ah. It > is certainly the case that we should not be defining another > Ethernet encapsulation explicitly to solve the same problem. As mentioned before, the use of 802.1ah does not mandate the use of spanning tree - link-state protocol can be used as well with the same plug-and-play objectives. I think the convergence in here is a good thing and the industry can benefit as whole. -Ali > > -- > Eric > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Ali > Sajassi (sajassi) > > Sent: Wednesday, December 06, 2006 2:39 AM > > To: Don Fedyk; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Draft minutes posted > > > > > > > > > > Yes, if there is any reason as to why .1ah encap cannot be > > used, then I > > would like to hear it. > > > > -Ali > > > > > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org > > > [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk > > > Sent: Tuesday, December 05, 2006 10:17 AM > > > To: Developing a hybrid router/bridge. > > > Subject: Re: [rbridge] Draft minutes posted > > > > > > Hi Erik > > > > > > In the minutes: > > > 802.1ah header synergy? On this point myself, and I recall > > > Ali Sajassi and Donald Oconnor all stood up and said that > > > 802.1ah is going to be a standard encapsulation header. My > > > point was Trill should see what it could deliver on this > > > encapsulation before inventing similar but different headers. > > > > > > Regards, > > > Don > > > > > > > -----Original Message----- > > > > From: rbridge-bounces at postel.org > > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > > > > > > > > Any corrections? > > > > > > > > Erik > > > > > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge at postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > From gibanez at it.uc3m.es Wed Dec 6 11:16:25 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Wed, 06 Dec 2006 20:16:25 +0100 Subject: [rbridge] Draft minutes posted In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB027827B3@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB027827B3@xmb-sjc-21e.amer.cisco.com> Message-ID: <45771709.5050004@it.uc3m.es> There is no TTL field on the 802.1ah, afaik, so the .1ah would require modification. Guillermo Ali Sajassi (sajassi) escribi?: > > > > Yes, if there is any reason as to why .1ah encap cannot be used, then I > would like to hear it. > > -Ali > > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk >> Sent: Tuesday, December 05, 2006 10:17 AM >> To: Developing a hybrid router/bridge. >> Subject: Re: [rbridge] Draft minutes posted >> >> Hi Erik >> >> In the minutes: >> 802.1ah header synergy? On this point myself, and I recall >> Ali Sajassi and Donald Oconnor all stood up and said that >> 802.1ah is going to be a standard encapsulation header. My >> point was Trill should see what it could deliver on this >> encapsulation before inventing similar but different headers. >> >> Regards, >> Don >> >>> -----Original Message----- >>> From: rbridge-bounces at postel.org >>> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt >>> >>> Any corrections? >>> >>> Erik >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From sajassi at cisco.com Wed Dec 6 11:25:54 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Wed, 6 Dec 2006 11:25:54 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02782997@xmb-sjc-21e.amer.cisco.com> > > Can you - or anyone with easy access to the specs - please > post an explicit description of 802.1ah header and fields? I will ask Tony (802.1 chair) to make avail to TRILL WG a copy of .1ah. -Ali > > Thanks, > > Joe > > From sajassi at cisco.com Wed Dec 6 11:28:07 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Wed, 6 Dec 2006 11:28:07 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB0278299B@xmb-sjc-21e.amer.cisco.com> > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark at sun.com] > Sent: Wednesday, December 06, 2006 10:02 AM > To: Don Fedyk > Cc: Gray, Eric; Ali Sajassi (sajassi); Developing a hybrid > router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > Don Fedyk wrote: > > Hi Eric > > > >> -----Original Message----- > >> From: Gray, Eric [mailto:Eric.Gray at marconi.com] > >> > >> Ali/Don, > >> > >> The use of 802.1ah encapsulation does not intuitively > suggest itself > >> in the TRILL problem domain for at least two > >> reasons: > >> > >> 1) Provider Back-bone Bridging intuitively seems out of > >> place in solutions aimed at enterprise networks - and > >> this would seem to be even more true for solutions > >> aimed at "plug-and-play" applicability. > > Hmmm Trill spent 1.5 years coming up with a header that looks > > remarkably like 802.1ah. A fact many of us have pointed out > before. > > If you are using an IEEE 802.1 Ethernet data plane your baseline > > choices are 802.1Q or 802.1ah. > > Is there a TTL in the 802.1ah header? Currently it is not. But if this is an issue, we can try to accommodate it. -Ali > > Erik > From sajassi at cisco.com Wed Dec 6 11:32:07 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Wed, 6 Dec 2006 11:32:07 -0800 Subject: [rbridge] Draft minutes posted Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB027829AD@xmb-sjc-21e.amer.cisco.com> > > There is no TTL field on the 802.1ah, afaik, so the .1ah > would require modification. As mentioned in my previous email, if this is an issue, we can try to accommodate it. Is there anything else ? -Ali > Guillermo > > Ali Sajassi (sajassi) escribi?: > > > > > > > > Yes, if there is any reason as to why .1ah encap cannot be > used, then > > I would like to hear it. > > > > -Ali > > > > > > > >> -----Original Message----- > >> From: rbridge-bounces at postel.org > >> [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk > >> Sent: Tuesday, December 05, 2006 10:17 AM > >> To: Developing a hybrid router/bridge. > >> Subject: Re: [rbridge] Draft minutes posted > >> > >> Hi Erik > >> > >> In the minutes: > >> 802.1ah header synergy? On this point myself, and I recall Ali > >> Sajassi and Donald Oconnor all stood up and said that 802.1ah is > >> going to be a standard encapsulation header. My point was Trill > >> should see what it could deliver on this encapsulation before > >> inventing similar but different headers. > >> > >> Regards, > >> Don > >> > >>> -----Original Message----- > >>> From: rbridge-bounces at postel.org > >>> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt > >>> > >>> Any corrections? > >>> > >>> Erik > >>> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge at postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > >> > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > From dwfedyk at nortel.com Wed Dec 6 11:34:49 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 6 Dec 2006 14:34:49 -0500 Subject: [rbridge] Draft minutes posted In-Reply-To: <457705C7.1020706@sun.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C48B6FD@zrtphxm2.corp.nortel.com> Hi Erik See I addition below: > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark at sun.com] > Sent: Wednesday, December 06, 2006 1:03 PM > > Don Fedyk wrote: > > Hi Erik > > > > In the minutes: > > 802.1ah header synergy? On this point myself, and I recall Ali > > Sajassi and Donald Oconnor all stood up and said that > 802.1ah is going > > to be a standard encapsulation header. My point was Trill > should see > > what it could deliver on this encapsulation before > inventing similar > > but different headers. > > I've added this: > > "802.1ah header synergy? > Comments from Don Fedyk, Ali Sajassi and Donald Oconnor that > 802.1ah is going to be a standard encapsulation header." > > which is what I think you said that you said. Correct and the fact that we think it should be looked at by Trill. Don > > Erik > From stbryant at cisco.com Wed Dec 6 11:35:02 2006 From: stbryant at cisco.com (Stewart Bryant) Date: Wed, 06 Dec 2006 19:35:02 +0000 Subject: [rbridge] Draft minutes posted In-Reply-To: <45771709.5050004@it.uc3m.es> References: <75B2A84D9323BC4CA3977CF378CE75EB027827B3@xmb-sjc-21e.amer.cisco.com> <45771709.5050004@it.uc3m.es> Message-ID: <45771B66.7020009@cisco.com> Guillermo Ib??ez wrote: > There is no TTL field on the 802.1ah, afaik, so the .1ah would require > modification. ... or perhaps extension through the header extension mechanism used to introduce VLANs. i.e. new protocol type that introduces the TTL header which carries the TTL and the next protocol type. - Stewart From Donald.Eastlake at motorola.com Wed Dec 6 12:24:07 2006 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 6 Dec 2006 15:24:07 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40C435E0F@zrtphxm2.corp.nortel.com> Message-ID: <3870C46029D1F945B1472F170D2D979001C90D36@de01exm64.ds.mot.com> Hi Don, See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk Sent: Wednesday, December 06, 2006 11:15 AM To: Gray, Eric; Ali Sajassi (sajassi) Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] Use of 802.1ah Encaps Hi Eric > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Ali/Don, > > The use of 802.1ah encapsulation does not intuitively suggest itself > in the TRILL problem domain for at least two > reasons: > > 1) Provider Back-bone Bridging intuitively seems out of > place in solutions aimed at enterprise networks - and > this would seem to be even more true for solutions > aimed at "plug-and-play" applicability. Hmmm Trill spent 1.5 years coming up with a header that looks remarkably like 802.1ah. A fact many of us have pointed out before. If you are using an IEEE 802.1 Ethernet data plane your baseline choices are 802.1Q or 802.1ah. @@@ That might be the baseline in IEEE 802.1 but I don't think it is in IETF TRILL. I think the TRILL Charter states that our baseline is draft-perlman-rbridge-03.txt, still available at http://www.postel.org/rbridge/draft-perlman-rbridge-03.txt, although that draft is not very specific about the encapsulation format. @@@ Of course we can and have evolved from that baseline. (For example, I assess the WG as leaning very strongly to the inclusion of two rbridge designators.) And if there is an existing encapsulation format that meets our needs, there is no particular reason to invent one. That is why we were planning for a while on using an MPLS format. But 802.1ah does not look much like the Rbridge shim (or Rbridge shim plus following MAC addresses) to me. Perhaps I am just missing something but have the "many" people you say have "pointed out" that we should just use the 802.1ah header actually proposed a specific allocation of its fields? (for current ideas on Rbridge shim fields look at presentations in San Diego such as http://www3.ietf.org/proceedings/06nov/slides/trill-2/sld2.htm or http://www3.ietf.org/proceedings/06nov/slides/trill-3/sld8.htm) @@@ I would point out that, when we were discussing the MPLS encapsulation, some who had originally advocated it as a way of re-using hardware and the like later came to the conclusion that if it had to have a different Ethertype and/or fields that are differently interpreted, there was actually very little saving. @@@ Thanks, @@@ Donald ... > > > Regards, > > > Don From touch at ISI.EDU Wed Dec 6 18:52:33 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 06 Dec 2006 18:52:33 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02782997@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02782997@xmb-sjc-21e.amer.cisco.com> Message-ID: <457781F1.7050103@isi.edu> I'd really rather someone just posted the header / fields, rather than a large document in which that information is buried, if possible ;-) Joe Ali Sajassi (sajassi) wrote: > >> Can you - or anyone with easy access to the specs - please >> post an explicit description of 802.1ah header and fields? > > I will ask Tony (802.1 chair) to make avail to TRILL WG a copy of .1ah. > > -Ali > > >> Thanks, >> >> Joe >> >> -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061206/e7fe113e/signature.bin From touch at ISI.EDU Wed Dec 6 19:23:21 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 06 Dec 2006 19:23:21 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB0278299B@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB0278299B@xmb-sjc-21e.amer.cisco.com> Message-ID: <45778929.2090103@isi.edu> Ali Sajassi (sajassi) wrote: ... >>> Hmmm Trill spent 1.5 years coming up with a header that looks >>> remarkably like 802.1ah. A fact many of us have pointed out >> before. >>> If you are using an IEEE 802.1 Ethernet data plane your baseline >>> choices are 802.1Q or 802.1ah. >> Is there a TTL in the 802.1ah header? > > Currently it is not. But if this is an issue, we can try to accommodate > it. So maybe that 1.5 years wasn't wasted after all? :-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061206/42848512/signature.bin From gibanez at it.uc3m.es Thu Dec 7 05:16:08 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Thu, 07 Dec 2006 14:16:08 +0100 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <45778929.2090103@isi.edu> References: <75B2A84D9323BC4CA3977CF378CE75EB0278299B@xmb-sjc-21e.amer.cisco.com> <45778929.2090103@isi.edu> Message-ID: <45781418.2050405@it.uc3m.es> Attached is a figure on the 802.1ad and .1ah headers, extracted from the Comms. Magazine. You can find also more details on the fields specific of .1ah header, extracted from 802.1ah draft 3.0 Note that I-SID Instance Service ID, has three octets, possibly to overcome the limitation that a single VLAN field (12 bit: 4096) (2 byte type+ 2 byte VLAN tag)) would suppose. Guillermo Joe Touch escribi?: > Ali Sajassi (sajassi) wrote: > ... > >>>> Hmmm Trill spent 1.5 years coming up with a header that looks >>>> remarkably like 802.1ah. A fact many of us have pointed out >>>> >>> before. >>> >>>> If you are using an IEEE 802.1 Ethernet data plane your baseline >>>> choices are 802.1Q or 802.1ah. >>>> >>> Is there a TTL in the 802.1ah header? >>> >> Currently it is not. But if this is an issue, we can try to accommodate >> it. >> > > So maybe that 1.5 years wasn't wasted after all? :-) > > Joe > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8021ah_header.pdf Type: application/pdf Size: 27594 bytes Desc: not available Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061207/1723776f/8021ah_header-0001.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: 8021ah.pdf Type: application/pdf Size: 119704 bytes Desc: not available Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061207/1723776f/8021ah-0001.pdf From dwfedyk at nortel.com Thu Dec 7 05:28:30 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Thu, 7 Dec 2006 08:28:30 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <457781F1.7050103@isi.edu> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C48C019@zrtphxm2.corp.nortel.com> Hi This is the Provider Backbone Header Format reproduced from one of the 802.1ah documents. When I said this is similar to the Trill header this is the version I mentioned. I converted to textographics by hand so I hope I got it right. I put field designators in [] inside the picture for fear they would get wrapped. The encapsulated frame starts after the I-TAG I-SID. | 1 | 2 | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -2 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2 | Backbone Destination Address [B-DA] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Backbone Source Address [B-SA] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | | .1ad Ethertype [B-TAG] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | .1ad B-TAG TCI/VID | .1ah Ethertype [ ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+ 18 | .1ah I-TAG TCI/SID [ - ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+ 22 | Customer Destination Address [ A ] | + +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+ 26 | | [ ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ ] + 30 | Customer Source Address [ ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ ]-+-+-+ 34 | Encap Ethertype | [ ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .1ah I-TAG TCI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P/DE |R1 |R2 | I-SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P/DE 3 Bits Priority 1 bit Drop Eligible R1 Res1 R2 Res2 a) priority - This 3 bit field carries the customer priority (I-PCP) associated with this frame. The provider network operates on the priority associated with the B-TAG. b) drop_eligible - This 1 bit field carries the customer drop eligibility (I-DEI) associated with this frame. The provider network operates on the drop eligibility associated with the B-TAG. c) res1 - This 2 bit field is used for any future format variations. The res2 field is zero on transmit and is ignored on receipt. d) res2 - This 2 bit field is used for any future format variations. The res1 field is zero on transmit and if set on reception the frame is discarded. e) I-SID - This 24 bit field carries the service instance identifier associated with this frame. f) encapsulated C-DA - This field carries the 48 bit Destination MAC Address for an encapsulated Ethernet frame. g) encapsulated C-SA - This field carries the 48 bit Source MAC Address for an encapsulated Ethernet frame. Regards, Don > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Wednesday, December 06, 2006 9:53 PM > To: Ali Sajassi (sajassi) > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid > router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > I'd really rather someone just posted the header / fields, > rather than a large document in which that information is > buried, if possible ;-) > > Joe > > Ali Sajassi (sajassi) wrote: > > > >> Can you - or anyone with easy access to the specs - please post an > >> explicit description of 802.1ah header and fields? > > > > I will ask Tony (802.1 chair) to make avail to TRILL WG a > copy of .1ah. > > > > -Ali > > > > > >> Thanks, > >> > >> Joe > >> > >> > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > From Eric.Gray at marconi.com Thu Dec 7 05:38:08 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 7 Dec 2006 08:38:08 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017107@uspitsmsgusr08.win.marconi.com> Don, Thanks for doing this. As you can probably attest, this is a non-trivial "digging" task to come up with this level of detail. I am not sure why Joe asked for it, but now that you have provided it, perhaps you can explain how values would be derived for the B-TAG TCI/VID and I-TAG TCI/SID fields if we'd like to deploy this technology in "plug-and-play" mode? -- Eric > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk at nortel.com] > Sent: Thursday, December 07, 2006 8:29 AM > To: Joe Touch; Ali Sajassi (sajassi) > Cc: Gray, Eric; Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Hi > > This is the Provider Backbone Header Format reproduced from one of the > 802.1ah documents. When I said this is similar to the Trill > header this > is the version I mentioned. I converted to textographics by hand so I > hope I got it right. I put field designators in [] inside the picture > for fear they would get wrapped. The encapsulated frame > starts after the > I-TAG I-SID. > > > | 1 | 2 | 3 | 4 > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -2 | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > 2 | Backbone Destination Address [B-DA] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 6 | Backbone Source Address [B-SA] | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 10 | | .1ad Ethertype [B-TAG] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 14 | .1ad B-TAG TCI/VID | .1ah Ethertype [ ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+ > 18 | .1ah I-TAG TCI/SID [ - ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+ > 22 | Customer Destination Address [ A ] | > + +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+ > 26 | | [ ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ ] + > 30 | Customer Source Address [ ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ ]-+-+-+ > 34 | Encap Ethertype | [ ] > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > .1ah I-TAG TCI > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P/DE |R1 |R2 | I-SID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > P/DE 3 Bits Priority 1 bit Drop Eligible > R1 Res1 > R2 Res2 > > a) priority - This 3 bit field carries the customer priority (I-PCP) > associated > with this frame. The provider network operates on the priority > associated with > the B-TAG. > > b) drop_eligible - This 1 bit field carries the customer drop > eligibility > (I-DEI) associated with this frame. The provider network > operates on the > drop > eligibility associated with the B-TAG. > > c) res1 - This 2 bit field is used for any future format > variations. The > res2 > field is zero on transmit and is ignored on receipt. > > d) res2 - This 2 bit field is used for any future format > variations. The > res1 > field is zero on transmit and if set on reception the frame is > discarded. > > e) I-SID - This 24 bit field carries the service instance identifier > associated > with this frame. > > f) encapsulated C-DA - This field carries the 48 bit Destination MAC > Address > for an encapsulated Ethernet frame. > > g) encapsulated C-SA - This field carries the 48 bit Source > MAC Address > for an > encapsulated Ethernet frame. > > Regards, > Don > > > > -----Original Message----- > > From: Joe Touch [mailto:touch at ISI.EDU] > > Sent: Wednesday, December 06, 2006 9:53 PM > > To: Ali Sajassi (sajassi) > > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid > > router/bridge. > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > I'd really rather someone just posted the header / fields, > > rather than a large document in which that information is > > buried, if possible ;-) > > > > Joe > > > > Ali Sajassi (sajassi) wrote: > > > > > >> Can you - or anyone with easy access to the specs - > please post an > > >> explicit description of 802.1ah header and fields? > > > > > > I will ask Tony (802.1 chair) to make avail to TRILL WG a > > copy of .1ah. > > > > > > -Ali > > > > > > > > >> Thanks, > > >> > > >> Joe > > >> > > >> > > > > -- > > ---------------------------------------- > > Joe Touch > > Sr. Network Engineer, USAF TSAT Space Segment > > > > > From Eric.Gray at marconi.com Thu Dec 7 05:48:15 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 7 Dec 2006 08:48:15 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017114@uspitsmsgusr08.win.marconi.com> Joe/Ali, It is not as simple as this. The IETF has already established a precedent for Ethernet encapsulation of SHIM-encapsulated Ethernet. It's only trying to see this as a single encapsulation, that causes people to conclude we are inventing a new form of Ethernet encapsulation. Other than inappropriate "designing committee" discussion at the last IETF meeting, we have not been attempting to design any new Ethernet encapsulation. And I believe we should safely conclude, at this point, that the discussion that took place on this topic at the TRILL meeting last month can be closed and considered to have been completely unproductive. Big surprise... -- Eric > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch > Sent: Wednesday, December 06, 2006 10:23 PM > To: Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From gibanez at it.uc3m.es Thu Dec 7 06:22:31 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Thu, 07 Dec 2006 15:22:31 +0100 Subject: [rbridge] Draft minutes posted In-Reply-To: <45771B66.7020009@cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB027827B3@xmb-sjc-21e.amer.cisco.com> <45771709.5050004@it.uc3m.es> <45771B66.7020009@cisco.com> Message-ID: <457823A7.20709@it.uc3m.es> Yes but, could you be a bit more precise ? (there are so many "VLANs" in the headers :-) ). Do you mean a different protocol type than .1ah (81a8)? Guillermo Stewart Bryant escribi?: > Guillermo Ib??ez wrote: > >> There is no TTL field on the 802.1ah, afaik, so the .1ah would >> require modification. > > ... or perhaps extension through the header extension mechanism > used to introduce VLANs. i.e. new protocol type that introduces > the TTL header which carries the TTL and the next protocol type. > > - Stewart > From dwfedyk at nortel.com Thu Dec 7 06:32:53 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Thu, 7 Dec 2006 09:32:53 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D812501017107@uspitsmsgusr08.win.marconi.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C48C210@zrtphxm2.corp.nortel.com> Hi Eric > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > Sent: Thursday, December 07, 2006 8:38 AM > Don, > > Thanks for doing this. As you can probably attest, > this is a non-trivial "digging" task to come up with this > level of detail. I am not sure why Joe asked for it, but now > that you have provided it, perhaps you can explain how values > would be derived for the B-TAG TCI/VID and I-TAG TCI/SID > fields if we'd like to deploy this technology in "plug-and-play" mode? I have not given much thought to plug-and-play. My advice would be learn the current semantics of the fields and see what they offer. I don't see why these fields, which offer encapsulation, backwards compatibility, Connectivity Fault Management (CFM) frames etc are any worse than similar alternatives. Don > > -- > Eric > > From Eric.Gray at marconi.com Thu Dec 7 08:00:36 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 7 Dec 2006 11:00:36 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D8125010171C1@uspitsmsgusr08.win.marconi.com> Don, And yet, someone (Ali Sajassi) asserted (in his message dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues or additional complications with using 802.1ah in enterprises for plug-and-play applicability. Perhaps Ali can answer my question then. But, to more directly address your earlier comments: The TRILL WG has NOT come up with an encapsulation that "looks like" 802.1ah - unless someone squints really hard and tries to pretend that two separate Ethernet encapsulations - separated by a SHIM header - are one single encapsulation. That is not to say that the WG has done anything that could be said to disallow the use of 802.1ah encapsulation. It is just not obviously consistent with all of the WG goals to use _only_ 802.1ah encapsulation. -- Eric > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk at nortel.com] > Sent: Thursday, December 07, 2006 9:33 AM > To: Gray, Eric; Joe Touch; Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Hi Eric > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Sent: Thursday, December 07, 2006 8:38 AM > > Don, > > > > Thanks for doing this. As you can probably attest, > > this is a non-trivial "digging" task to come up with this > > level of detail. I am not sure why Joe asked for it, but now > > that you have provided it, perhaps you can explain how values > > would be derived for the B-TAG TCI/VID and I-TAG TCI/SID > > fields if we'd like to deploy this technology in > "plug-and-play" mode? > > I have not given much thought to plug-and-play. My advice > would be learn > the current semantics of the fields and see what they offer. I don't > see why these fields, which offer encapsulation, backwards > compatibility, Connectivity Fault Management (CFM) frames etc are any > worse than similar alternatives. > > Don > > > > > -- > > Eric > > > > > From Donald.Eastlake at motorola.com Thu Dec 7 08:24:47 2006 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 7 Dec 2006 11:24:47 -0500 Subject: [rbridge] Use of 802.11s Encaps Message-ID: <3870C46029D1F945B1472F170D2D979001C9121C@de01exm64.ds.mot.com> As long as people are looking at encapsulations, how about the encapsulation currently in the 802.11s draft? It has lots of nifty fields including six addresses and a TTL! Although the Draft is restricted, see ftp://ftp.802wirelessworld.com/11/06/11-06-1464-02-000s-6-address-scheme -tgs-mesh.doc. Donald From dwfedyk at nortel.com Thu Dec 7 09:20:52 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Thu, 7 Dec 2006 12:20:52 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D8125010171C1@uspitsmsgusr08.win.marconi.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C4E6F67@zrtphxm2.corp.nortel.com> Hi Eric > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Don, > > And yet, someone (Ali Sajassi) asserted (in his message > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues > or additional complications with using 802.1ah in enterprises > for plug-and-play applicability. > > Perhaps Ali can answer my question then. > > But, to more directly address your earlier comments: > > The TRILL WG has NOT come up with an encapsulation that > "looks like" 802.1ah - unless someone squints really hard and > tries to pretend that two separate Ethernet encapsulations - > separated by a SHIM header - are one single encapsulation. To be fair Point to Point header that was discussed without one of the shims was very close "functionally" (colloquial looks like) to 802.1ah. My opinion is still we don't need several variations of headers doing similar things. This was the slide that looked a lot like what I posted. http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm Regards, Don > > That is not to say that the WG has done anything that > could be said to disallow the use of 802.1ah encapsulation. > It is just not obviously consistent with all of the WG goals > to use _only_ 802.1ah encapsulation. > > -- > Eric > From Eric.Gray at marconi.com Thu Dec 7 10:34:06 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Thu, 7 Dec 2006 13:34:06 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017272@uspitsmsgusr08.win.marconi.com> Don, I think we're not disagreeing with each other. Where people make proposals that look like an existing encapsulation, the complexity associated with defining a new encapsulation that is marginally different has to be weighed very carefully against what we expect to gain in doing so. I think it is clear to me that the complexity is not justified. Moreover, I don't see anyone continuing to make the case that we should do this - so it may be the case that many people are of a similar opinion. The issue of whether or not it makes sense to use the specific encapsulation proposed - or an existing similar encapsulation - in the RBridge problem domain is a horse of a different color. I am not sure that we've achieved any level of agreement on this issue, consequently this entire discussion could be considered simply as a distraction. -- Eric > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk at nortel.com] > Sent: Thursday, December 07, 2006 12:21 PM > To: Gray, Eric; Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge.; Joe Touch > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Hi Eric > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > Don, > > > > And yet, someone (Ali Sajassi) asserted (in his message > > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues > > or additional complications with using 802.1ah in enterprises > > for plug-and-play applicability. > > > > Perhaps Ali can answer my question then. > > > > But, to more directly address your earlier comments: > > > > The TRILL WG has NOT come up with an encapsulation that > > "looks like" 802.1ah - unless someone squints really hard and > > tries to pretend that two separate Ethernet encapsulations - > > separated by a SHIM header - are one single encapsulation. > > To be fair Point to Point header that was discussed without one of the > shims was very close "functionally" (colloquial looks like) > to 802.1ah. > My opinion is still we don't need several variations of headers doing > similar things. > > This was the slide that looked a lot like what I posted. > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > Regards, > Don > > > > That is not to say that the WG has done anything that > > could be said to disallow the use of 802.1ah encapsulation. > > It is just not obviously consistent with all of the WG goals > > to use _only_ 802.1ah encapsulation. > > > > -- > > Eric > > > From sgai at nuovasystems.com Thu Dec 7 17:35:54 2006 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 7 Dec 2006 17:35:54 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2D115D5@nuova-ex1.hq.nuovaimpresa.com> IMO it is technically possible for TRILL to adopt IEEE 802.1ah. There are advantages and disadvantages. The disadvantages are: 1) Lack of Next-Hop addresses. We discussed this at length during the last meeting and we didn't reach consensus on a way to eliminate them. 2) Lack of a TTL field (it may be added, but it is not there today). 3) Many unneeded fields and therefore larger frame overhead. The advantages are: 1) Larger addressable market for TRILL IMO if we stick with the WG charter the disadvantages clearly outweigh the advantages. The WG can be re-chartered, but if we consider the Enterprise and Data Center market, IEEE 802.1ah is an overkill. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Don Fedyk > Sent: Thursday, December 07, 2006 9:21 AM > To: Gray, Eric; Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge.; Joe Touch > Subject: Re: [rbridge] Use of 802.1ah Encaps > > Hi Eric > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > Don, > > > > And yet, someone (Ali Sajassi) asserted (in his message > > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues > > or additional complications with using 802.1ah in enterprises > > for plug-and-play applicability. > > > > Perhaps Ali can answer my question then. > > > > But, to more directly address your earlier comments: > > > > The TRILL WG has NOT come up with an encapsulation that > > "looks like" 802.1ah - unless someone squints really hard and > > tries to pretend that two separate Ethernet encapsulations - > > separated by a SHIM header - are one single encapsulation. > > To be fair Point to Point header that was discussed without one of the > shims was very close "functionally" (colloquial looks like) to 802.1ah. > My opinion is still we don't need several variations of headers doing > similar things. > > This was the slide that looked a lot like what I posted. > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > Regards, > Don > > > > That is not to say that the WG has done anything that > > could be said to disallow the use of 802.1ah encapsulation. > > It is just not obviously consistent with all of the WG goals > > to use _only_ 802.1ah encapsulation. > > > > -- > > Eric > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From sajassi at cisco.com Thu Dec 7 20:39:17 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Thu, 7 Dec 2006 20:39:17 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02782FB0@xmb-sjc-21e.amer.cisco.com> Attached is the extraction from the 802.1ah spec. regarding header format. -Ali > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk at nortel.com] > Sent: Thursday, December 07, 2006 5:29 AM > To: Joe Touch; Ali Sajassi (sajassi) > Cc: Gray, Eric; Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Hi > > This is the Provider Backbone Header Format reproduced from > one of the 802.1ah documents. When I said this is similar to > the Trill header this is the version I mentioned. I > converted to textographics by hand so I hope I got it right. > I put field designators in [] inside the picture for fear > they would get wrapped. The encapsulated frame starts after > the I-TAG I-SID. > > > | 1 | 2 | 3 | 4 > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -2 | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > 2 | Backbone Destination Address [B-DA] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 6 | Backbone Source Address [B-SA] | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 10 | | .1ad Ethertype [B-TAG] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 14 | .1ad B-TAG TCI/VID | .1ah Ethertype [ ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+ > 18 | .1ah I-TAG TCI/SID [ - ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+ > 22 | Customer Destination Address [ A ] | > + +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+ > 26 | | [ ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ ] + > 30 | Customer Source Address [ ] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ ]-+-+-+ > 34 | Encap Ethertype | [ ] > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > .1ah I-TAG TCI > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P/DE |R1 |R2 | I-SID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > P/DE 3 Bits Priority 1 bit Drop Eligible > R1 Res1 > R2 Res2 > > a) priority - This 3 bit field carries the customer priority > (I-PCP) associated with this frame. The provider network > operates on the priority associated with the B-TAG. > > b) drop_eligible - This 1 bit field carries the customer drop > eligibility > (I-DEI) associated with this frame. The provider network > operates on the drop eligibility associated with the B-TAG. > > c) res1 - This 2 bit field is used for any future format > variations. The > res2 > field is zero on transmit and is ignored on receipt. > > d) res2 - This 2 bit field is used for any future format > variations. The > res1 > field is zero on transmit and if set on reception the frame > is discarded. > > e) I-SID - This 24 bit field carries the service instance > identifier associated with this frame. > > f) encapsulated C-DA - This field carries the 48 bit > Destination MAC Address for an encapsulated Ethernet frame. > > g) encapsulated C-SA - This field carries the 48 bit Source > MAC Address for an encapsulated Ethernet frame. > > Regards, > Don > > > > -----Original Message----- > > From: Joe Touch [mailto:touch at ISI.EDU] > > Sent: Wednesday, December 06, 2006 9:53 PM > > To: Ali Sajassi (sajassi) > > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid > > router/bridge. > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > I'd really rather someone just posted the header / fields, > rather than > > a large document in which that information is buried, if > possible ;-) > > > > Joe > > > > Ali Sajassi (sajassi) wrote: > > > > > >> Can you - or anyone with easy access to the specs - > please post an > > >> explicit description of 802.1ah header and fields? > > > > > > I will ask Tony (802.1 chair) to make avail to TRILL WG a > > copy of .1ah. > > > > > > -Ali > > > > > > > > >> Thanks, > > >> > > >> Joe > > >> > > >> > > > > -- > > ---------------------------------------- > > Joe Touch > > Sr. Network Engineer, USAF TSAT Space Segment > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 802-1ah-header.doc Type: application/msword Size: 167424 bytes Desc: 802-1ah-header.doc Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061207/5de0cf30/802-1ah-header-0001.doc From sajassi at cisco.com Thu Dec 7 20:47:33 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Thu, 7 Dec 2006 20:47:33 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02782FB4@xmb-sjc-21e.amer.cisco.com> Gray, With respect to plug-and-play operation, it is similar to 802.1Q or 802.1ad operation; where, at the UNI you decide which interfaces belong to which VLANs in case of 802.1Q or which pair belong to S-tag in case of 802.1ad (e.g., point-to-cloud config model). In case of 802.1ah, you also decide at the UNI which interfaces or which pair belong to which pair. Again the model in 802.1ah is point-to-cloud model just like 802.1Q and 802.1ad and that's what makes it plug-and-play. -Ali > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > Sent: Thursday, December 07, 2006 5:38 AM > To: Don Fedyk; Joe Touch; Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Don, > > Thanks for doing this. As you can probably attest, > this is a non-trivial "digging" task to come up with this > level of detail. I am not sure why Joe asked for it, but now > that you have provided it, perhaps you can explain how values > would be derived for the B-TAG TCI/VID and I-TAG TCI/SID > fields if we'd like to deploy this technology in "plug-and-play" mode? > > -- > Eric > > > -----Original Message----- > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > Sent: Thursday, December 07, 2006 8:29 AM > > To: Joe Touch; Ali Sajassi (sajassi) > > Cc: Gray, Eric; Developing a hybrid router/bridge. > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Hi > > > > This is the Provider Backbone Header Format reproduced from > one of the > > 802.1ah documents. When I said this is similar to the Trill header > > this is the version I mentioned. I converted to > textographics by hand > > so I hope I got it right. I put field designators in [] inside the > > picture for fear they would get wrapped. The encapsulated > frame starts > > after the I-TAG I-SID. > > > > > > | 1 | 2 | 3 | 4 > > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > -2 | | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + > > 2 | Backbone Destination Address > [B-DA] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 6 | Backbone Source Address > [B-SA] | > > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 10 | | .1ad Ethertype > [B-TAG] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 14 | .1ad B-TAG TCI/VID | .1ah Ethertype [ > ] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ > I ]-+-+-+ > > 18 | .1ah I-TAG TCI/SID [ > - ] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ > T ]-+-+-+ > > 22 | Customer Destination Address [ > A ] | > > + +-+-+-+-+-+-+-+-+-+-+-[ > G ]-+-+-+ > > 26 | | [ > ] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ > ] + > > 30 | Customer Source Address [ > ] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ > ]-+-+-+ > > 34 | Encap Ethertype | [ ] > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > .1ah I-TAG TCI > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | P/DE |R1 |R2 | I-SID > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > P/DE 3 Bits Priority 1 bit Drop Eligible > > R1 Res1 > > R2 Res2 > > > > a) priority - This 3 bit field carries the customer > priority (I-PCP) > > associated with this frame. The provider network operates on the > > priority associated with the B-TAG. > > > > b) drop_eligible - This 1 bit field carries the customer drop > > eligibility > > (I-DEI) associated with this frame. The provider network > operates on > > the drop eligibility associated with the B-TAG. > > > > c) res1 - This 2 bit field is used for any future format > variations. > > The > > res2 > > field is zero on transmit and is ignored on receipt. > > > > d) res2 - This 2 bit field is used for any future format > variations. > > The > > res1 > > field is zero on transmit and if set on reception the frame is > > discarded. > > > > e) I-SID - This 24 bit field carries the service instance > identifier > > associated with this frame. > > > > f) encapsulated C-DA - This field carries the 48 bit > Destination MAC > > Address for an encapsulated Ethernet frame. > > > > g) encapsulated C-SA - This field carries the 48 bit Source MAC > > Address for an encapsulated Ethernet frame. > > > > Regards, > > Don > > > > > > > -----Original Message----- > > > From: Joe Touch [mailto:touch at ISI.EDU] > > > Sent: Wednesday, December 06, 2006 9:53 PM > > > To: Ali Sajassi (sajassi) > > > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid > > > router/bridge. > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > I'd really rather someone just posted the header / fields, rather > > > than a large document in which that information is buried, if > > > possible ;-) > > > > > > Joe > > > > > > Ali Sajassi (sajassi) wrote: > > > > > > > >> Can you - or anyone with easy access to the specs - > > please post an > > > >> explicit description of 802.1ah header and fields? > > > > > > > > I will ask Tony (802.1 chair) to make avail to TRILL WG a > > > copy of .1ah. > > > > > > > > -Ali > > > > > > > > > > > >> Thanks, > > > >> > > > >> Joe > > > >> > > > >> > > > > > > -- > > > ---------------------------------------- > > > Joe Touch > > > Sr. Network Engineer, USAF TSAT Space Segment > > > > > > > > > From sajassi at cisco.com Thu Dec 7 20:59:25 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Thu, 7 Dec 2006 20:59:25 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02782FBF@xmb-sjc-21e.amer.cisco.com> > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > Sent: Thursday, December 07, 2006 5:48 AM > To: Joe Touch; Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Joe/Ali, > > It is not as simple as this. > > The IETF has already established a precedent for > Ethernet encapsulation of SHIM-encapsulated Ethernet. It's > only trying to see this as a single encapsulation, that > causes people to conclude we are inventing a new form of > Ethernet encapsulation. > > Other than inappropriate "designing committee" > discussion at the last IETF meeting, we have not been > attempting to design any new Ethernet encapsulation. And I > believe we should safely conclude, at this point, that the > discussion that took place on this topic at the TRILL meeting > last month can be closed and considered to have been > completely unproductive. I think it is always good to have discussions among ourselves to see how we can leverage each other expertise and technology and whether what you are doing can be leveraged in other applications. The basic premise in here is that there is a good level of overlap among different areas that are being worked on by different WGs, and we will do each other as well as industry a great service if we can come up with a common solution jointly. -Ali > > Big surprise... > > -- > Eric > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch > > Sent: Wednesday, December 06, 2006 10:23 PM > > To: Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > From sajassi at cisco.com Thu Dec 7 21:02:21 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Thu, 7 Dec 2006 21:02:21 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02782FC1@xmb-sjc-21e.amer.cisco.com> Gray, Please let me know if my previous email doesn't answer your question and if it doesn't, then let me know which portion needs further clarification. -Ali > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > Sent: Thursday, December 07, 2006 8:01 AM > To: Don Fedyk; Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge.; Joe Touch > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Don, > > And yet, someone (Ali Sajassi) asserted (in his message > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues > or additional complications with using 802.1ah in enterprises > for plug-and-play applicability. > > Perhaps Ali can answer my question then. > > But, to more directly address your earlier comments: > > The TRILL WG has NOT come up with an encapsulation that > "looks like" 802.1ah - unless someone squints really hard and > tries to pretend that two separate Ethernet encapsulations - > separated by a SHIM header - are one single encapsulation. > > That is not to say that the WG has done anything that > could be said to disallow the use of 802.1ah encapsulation. > It is just not obviously consistent with all of the WG goals > to use _only_ 802.1ah encapsulation. > > -- > Eric > > > -----Original Message----- > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > Sent: Thursday, December 07, 2006 9:33 AM > > To: Gray, Eric; Joe Touch; Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge. > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Hi Eric > > > > > -----Original Message----- > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > Sent: Thursday, December 07, 2006 8:38 AM Don, > > > > > > Thanks for doing this. As you can probably attest, this is a > > > non-trivial "digging" task to come up with this level of > detail. I > > > am not sure why Joe asked for it, but now that you have > provided it, > > > perhaps you can explain how values would be derived for the B-TAG > > > TCI/VID and I-TAG TCI/SID fields if we'd like to deploy this > > > technology in > > "plug-and-play" mode? > > > > I have not given much thought to plug-and-play. My advice would be > > learn the current semantics of the fields and see what they > offer. I > > don't see why these fields, which offer encapsulation, backwards > > compatibility, Connectivity Fault Management (CFM) frames > etc are any > > worse than similar alternatives. > > > > Don > > > > > > > > -- > > > Eric > > > > > > > > > From sajassi at cisco.com Thu Dec 7 21:23:26 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Thu, 7 Dec 2006 21:23:26 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02782FC2@xmb-sjc-21e.amer.cisco.com> Silvano, > -----Original Message----- > From: Silvano Gai [mailto:sgai at nuovasystems.com] > Sent: Thursday, December 07, 2006 5:36 PM > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi) > Cc: Developing a hybrid router/bridge.; Joe Touch > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. > There are advantages and disadvantages. > > The disadvantages are: > 1) Lack of Next-Hop addresses. We discussed this at length > during the last meeting and we didn't reach consensus on a > way to eliminate them. Can you refresh my memory for why we need a next-hop address when the header carries both source and destination PE addresses and when these addresses are learned in control plane ? > 2) Lack of a TTL field (it may be added, but it is not there today). Can probably be accommodated. > 3) Many unneeded fields and therefore larger frame overhead. > Such as ? > The advantages are: > 1) Larger addressable market for TRILL > > IMO if we stick with the WG charter the disadvantages clearly > outweigh the advantages. > > The WG can be re-chartered, but if we consider the Enterprise > and Data Center market, IEEE 802.1ah is an overkill. > If by overkill you mean a bit bigger header, then I agree but look at all the other advantages that you get from using standard IEEE header and shim including: - security Mgmt: MACSec/KeySec - Congestion Mgmt - Connectivity Fault Mgmt Has it been considered how these are going to work with TRILL shim header or are these outside of WG charter :-) -Ali > -- Silvano > > > > -----Original Message----- > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > On > > Behalf Of Don Fedyk > > Sent: Thursday, December 07, 2006 9:21 AM > > To: Gray, Eric; Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge.; Joe Touch > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > Hi Eric > > > > > -----Original Message----- > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > Don, > > > > > > And yet, someone (Ali Sajassi) asserted (in his message > dated Wed > > > 12/6/2006 at 2:16 PM EST) that there were no issues or additional > > > complications with using 802.1ah in enterprises for plug-and-play > > > applicability. > > > > > > Perhaps Ali can answer my question then. > > > > > > But, to more directly address your earlier comments: > > > > > > The TRILL WG has NOT come up with an encapsulation that "looks > > > like" 802.1ah - unless someone squints really hard and tries to > > > pretend that two separate Ethernet encapsulations - > separated by a > > > SHIM header - are one single encapsulation. > > > > To be fair Point to Point header that was discussed without > one of the > > shims was very close "functionally" (colloquial looks like) to > 802.1ah. > > My opinion is still we don't need several variations of > headers doing > > similar things. > > > > This was the slide that looked a lot like what I posted. > > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > > > Regards, > > Don > > > > > > That is not to say that the WG has done anything that > could be said > > > to disallow the use of 802.1ah encapsulation. > > > It is just not obviously consistent with all of the WG > goals to use > > > _only_ 802.1ah encapsulation. > > > > > > -- > > > Eric > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Thu Dec 7 21:56:01 2006 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Fri, 08 Dec 2006 10:56:01 +0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <85f1b57d508e.457944c1@sunlabs.com> Travelling again, so extremely limited access to email (as in, about 10 minutes here and there on a SLOW connection). Anyway, I'll answer some of these: a) why "next hop" and "previous hop" in addition to "ultimate" source and destination At least one of the reasons is that if there are three RBridges on the same link, R1, R2, and R3, it is useful for R1 to choose which of R2 or R3 should receive the packet. It isn't obvious from the destination address because it could be that either R2 or R3 would be logical, and R1 is load splitting. Also, it helps focus traffic on the link, and ensure it doesn't get filtered, if the bridges on the link only need to learn R1, R2, and R3, especially since traffic from outside RBridges might arrive from different entry points onto the link. b) congestion management was explained to us, and it was what convinced us we needed "ultimate source RBridge" in order to know where to send the congestion notification. If you could explain the other things, we could see if there is a problem, but if they are similar to congestion notification, then having the ingress RBridge will accommodate them. Sorry for ignoring all the other messages for now, but I only had a chance to read and respond to one message. Radia ----- Original Message ----- From: "Ali Sajassi (sajassi)" Date: Friday, December 8, 2006 10:53 am Subject: Re: [rbridge] Use of 802.1ah Encaps > > Silvano, > > > -----Original Message----- > > From: Silvano Gai [sgai at nuovasystems.com] > > Sent: Thursday, December 07, 2006 5:36 PM > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge.; Joe Touch > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. > > There are advantages and disadvantages. > > > > The disadvantages are: > > 1) Lack of Next-Hop addresses. We discussed this at length > > during the last meeting and we didn't reach consensus on a > > way to eliminate them. > > Can you refresh my memory for why we need a next-hop address when the > header carries both source and destination PE addresses and when these > addresses are learned in control plane ? > > > 2) Lack of a TTL field (it may be added, but it is not there today). > > Can probably be accommodated. > > > 3) Many unneeded fields and therefore larger frame overhead. > > > > Such as ? > > > The advantages are: > > 1) Larger addressable market for TRILL > > > > IMO if we stick with the WG charter the disadvantages clearly > > outweigh the advantages. > > > > The WG can be re-chartered, but if we consider the Enterprise > > and Data Center market, IEEE 802.1ah is an overkill. > > > > If by overkill you mean a bit bigger header, then I agree but look at > all the other advantages that you get from using standard IEEE header > and shim including: > - security Mgmt: MACSec/KeySec > - Congestion Mgmt > - Connectivity Fault Mgmt > > Has it been considered how these are going to work with TRILL shim > header or are these outside of WG charter :-) > > -Ali > > > > -- Silvano > > > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] > > On > > > Behalf Of Don Fedyk > > > Sent: Thursday, December 07, 2006 9:21 AM > > > To: Gray, Eric; Ali Sajassi (sajassi) > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > Hi Eric > > > > > > > -----Original Message----- > > > > From: Gray, Eric [Eric.Gray at marconi.com] > > > > > > > > Don, > > > > > > > > And yet, someone (Ali Sajassi) asserted (in his message > > dated Wed > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or > additional > > > > complications with using 802.1ah in enterprises for plug-and- > play > > > > applicability. > > > > > > > > Perhaps Ali can answer my question then. > > > > > > > > But, to more directly address your earlier comments: > > > > > > > > The TRILL WG has NOT come up with an encapsulation that > "looks > > > > like" 802.1ah - unless someone squints really hard and tries > to > > > > pretend that two separate Ethernet encapsulations - > > separated by a > > > > SHIM header - are one single encapsulation. > > > > > > To be fair Point to Point header that was discussed without > > one of the > > > shims was very close "functionally" (colloquial looks like) to > > 802.1ah. > > > My opinion is still we don't need several variations of > > headers doing > > > similar things. > > > > > > This was the slide that looked a lot like what I posted. > > > > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > > > > > Regards, > > > Don > > > > > > > > That is not to say that the WG has done anything that > > could be said > > > > to disallow the use of 802.1ah encapsulation. > > > > It is just not obviously consistent with all of the WG > > goals to use > > > > _only_ 802.1ah encapsulation. > > > > > > > > -- > > > > Eric > > > > > > > > > > _______________________________________________ > > > 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 touch at ISI.EDU Thu Dec 7 22:59:39 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 07 Dec 2006 22:59:39 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <85f1b57d508e.457944c1@sunlabs.com> References: <85f1b57d508e.457944c1@sunlabs.com> Message-ID: <45790D5B.2050601@isi.edu> Radia.Perlman at sun.com wrote: > Travelling again, so extremely limited access to email (as in, about 10 minutes here and there > on a SLOW connection). Anyway, I'll answer some of these: > > a) why "next hop" and "previous hop" in addition to "ultimate" source and destination > > At least one of the reasons is that if there are three RBridges on the same link, R1, R2, and R3, > it is useful for R1 to choose which of R2 or R3 should receive the packet. It isn't obvious from > the destination address because it could be that either R2 or R3 would be logical, and R1 is > load splitting. Also, it helps focus traffic on the link, and ensure it doesn't get filtered, if > the bridges on the link only need to learn R1, R2, and R3, especially since traffic from outside > RBridges might arrive from different entry points onto the link. The ultimate destination (and source, for that matter) should be sufficiently indicated by the inner ethernet packet. The outer header is already hop-by-hop inside the rbridge anyway. What additional information is required? The next/previous hop information sounds like a source route with record-route option. While that's useful for debugging, it doesn't seem necessary. > b) congestion management was explained to us, and it was what convinced us we needed "ultimate > source RBridge" in order to know where to send the congestion notification. If you could explain the > other things, we could see if there is a problem, but if they are similar to congestion notification, then > having the ingress RBridge will accommodate them. Why doesn't the source ethernet address indicate this already? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061207/79d12213/signature.bin From sgai at nuovasystems.com Fri Dec 8 06:59:17 2006 From: sgai at nuovasystems.com (Silvano Gai) Date: Fri, 8 Dec 2006 06:59:17 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2D11648@nuova-ex1.hq.nuovaimpresa.com> Joe, TRILL will never scale if you mandate to keep the forwarding table for the inner addresses on all RBridges, especially in a IEEE 802.1ah environment!!! It is only the ingress Rbridge that looks at the inner address and put the egress RBridge address in the frame. -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Thursday, December 07, 2006 11:00 PM > To: Radia.Perlman at sun.com > Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric; Developing > a hybrid router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > Radia.Perlman at sun.com wrote: > > Travelling again, so extremely limited access to email (as in, about 10 > minutes here and there > > on a SLOW connection). Anyway, I'll answer some of these: > > > > a) why "next hop" and "previous hop" in addition to "ultimate" source > and destination > > > > At least one of the reasons is that if there are three RBridges on the > same link, R1, R2, and R3, > > it is useful for R1 to choose which of R2 or R3 should receive the > packet. It isn't obvious from > > the destination address because it could be that either R2 or R3 would > be logical, and R1 is > > load splitting. Also, it helps focus traffic on the link, and ensure it > doesn't get filtered, if > > the bridges on the link only need to learn R1, R2, and R3, especially > since traffic from outside > > RBridges might arrive from different entry points onto the link. > > The ultimate destination (and source, for that matter) should be > sufficiently indicated by the inner ethernet packet. The outer header is > already hop-by-hop inside the rbridge anyway. What additional > information is required? > > The next/previous hop information sounds like a source route with > record-route option. While that's useful for debugging, it doesn't seem > necessary. > > > b) congestion management was explained to us, and it was what convinced > us we needed "ultimate > > source RBridge" in order to know where to send the congestion > notification. If you could explain the > > other things, we could see if there is a problem, but if they are > similar to congestion notification, then > > having the ingress RBridge will accommodate them. > > Why doesn't the source ethernet address indicate this already? > > Joe From sgai at nuovasystems.com Fri Dec 8 07:07:25 2006 From: sgai at nuovasystems.com (Silvano Gai) Date: Fri, 8 Dec 2006 07:07:25 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2D1164A@nuova-ex1.hq.nuovaimpresa.com> Ali, Inline: > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > Sent: Thursday, December 07, 2006 9:23 PM > To: Silvano Gai; Don Fedyk; Gray, Eric > Cc: Developing a hybrid router/bridge.; Joe Touch > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > Silvano, > > > -----Original Message----- > > From: Silvano Gai [mailto:sgai at nuovasystems.com] > > Sent: Thursday, December 07, 2006 5:36 PM > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge.; Joe Touch > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. > > There are advantages and disadvantages. > > > > The disadvantages are: > > 1) Lack of Next-Hop addresses. We discussed this at length > > during the last meeting and we didn't reach consensus on a > > way to eliminate them. > > Can you refresh my memory for why we need a next-hop address when the > header carries both source and destination PE addresses and when these > addresses are learned in control plane ? > Radia did in her reply > > 2) Lack of a TTL field (it may be added, but it is not there today). > > Can probably be accommodated. > > > 3) Many unneeded fields and therefore larger frame overhead. > > > > Such as ? The I-tag is not useful in TRILL and in contrast two addresses and the TTL are missing. > > > The advantages are: > > 1) Larger addressable market for TRILL > > > > IMO if we stick with the WG charter the disadvantages clearly > > outweigh the advantages. > > > > The WG can be re-chartered, but if we consider the Enterprise > > and Data Center market, IEEE 802.1ah is an overkill. > > > > If by overkill you mean a bit bigger header, then I agree but look at > all the other advantages that you get from using standard IEEE header > and shim including: > - security Mgmt: MACSec/KeySec > - Congestion Mgmt > - Connectivity Fault Mgmt > > Has it been considered how these are going to work with TRILL shim > header or are these outside of WG charter :-) > > -Ali > > > > -- Silvano > > > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > > On > > > Behalf Of Don Fedyk > > > Sent: Thursday, December 07, 2006 9:21 AM > > > To: Gray, Eric; Ali Sajassi (sajassi) > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > Hi Eric > > > > > > > -----Original Message----- > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > > > Don, > > > > > > > > And yet, someone (Ali Sajassi) asserted (in his message > > dated Wed > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or additional > > > > complications with using 802.1ah in enterprises for plug-and-play > > > > applicability. > > > > > > > > Perhaps Ali can answer my question then. > > > > > > > > But, to more directly address your earlier comments: > > > > > > > > The TRILL WG has NOT come up with an encapsulation that "looks > > > > like" 802.1ah - unless someone squints really hard and tries to > > > > pretend that two separate Ethernet encapsulations - > > separated by a > > > > SHIM header - are one single encapsulation. > > > > > > To be fair Point to Point header that was discussed without > > one of the > > > shims was very close "functionally" (colloquial looks like) to > > 802.1ah. > > > My opinion is still we don't need several variations of > > headers doing > > > similar things. > > > > > > This was the slide that looked a lot like what I posted. > > > > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > > > > > Regards, > > > Don > > > > > > > > That is not to say that the WG has done anything that > > could be said > > > > to disallow the use of 802.1ah encapsulation. > > > > It is just not obviously consistent with all of the WG > > goals to use > > > > _only_ 802.1ah encapsulation. > > > > > > > > -- > > > > Eric > > > > > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge at postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > From touch at ISI.EDU Fri Dec 8 07:28:47 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 08 Dec 2006 07:28:47 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2D11648@nuova-ex1.hq.nuovaimpresa.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2D11648@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <457984AF.3020501@isi.edu> Silvano Gai wrote: > Joe, > > TRILL will never scale if you mandate to keep the forwarding table for > the inner addresses on all RBridges, especially in a IEEE 802.1ah > environment!!! Sorry; let me backup: Here's where we were at the last IETF: - the shim indicates the source (ingress) and dest (egress) (originally this was just dest for unicast, source for mcast but we agreed in San Diego to include both) i.e., agreed with the point above; those are the addresses on which packets are forwarded the ultimate source is indicated in the shim already - the outer header already indicates the previous/next-hop rbridge What's the reason for needing any further information? As per below, if R1 (current rbridge) wants to pick from among multiple next-hops R2 and R3, it does so with the outermost ethernet header. If they're logical (R2/R3 both on the same NIC), then just assign separate ethernet addresses to the same interface. What's left? Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch at ISI.EDU] >> Sent: Thursday, December 07, 2006 11:00 PM >> To: Radia.Perlman at sun.com >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric; > Developing >> a hybrid router/bridge. >> Subject: Re: [rbridge] Use of 802.1ah Encaps >> >> >> >> Radia.Perlman at sun.com wrote: >>> Travelling again, so extremely limited access to email (as in, about > 10 >> minutes here and there >>> on a SLOW connection). Anyway, I'll answer some of these: >>> >>> a) why "next hop" and "previous hop" in addition to "ultimate" > source >> and destination >>> At least one of the reasons is that if there are three RBridges on > the >> same link, R1, R2, and R3, >>> it is useful for R1 to choose which of R2 or R3 should receive the >> packet. It isn't obvious from >>> the destination address because it could be that either R2 or R3 > would >> be logical, and R1 is >>> load splitting. Also, it helps focus traffic on the link, and ensure > it >> doesn't get filtered, if >>> the bridges on the link only need to learn R1, R2, and R3, > especially >> since traffic from outside >>> RBridges might arrive from different entry points onto the link. >> The ultimate destination (and source, for that matter) should be >> sufficiently indicated by the inner ethernet packet. The outer header > is >> already hop-by-hop inside the rbridge anyway. What additional >> information is required? >> >> The next/previous hop information sounds like a source route with >> record-route option. While that's useful for debugging, it doesn't > seem >> necessary. >> >>> b) congestion management was explained to us, and it was what > convinced >> us we needed "ultimate >>> source RBridge" in order to know where to send the congestion >> notification. If you could explain the >>> other things, we could see if there is a problem, but if they are >> similar to congestion notification, then >>> having the ingress RBridge will accommodate them. >> Why doesn't the source ethernet address indicate this already? >> >> Joe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061208/8858692d/signature.bin From sgai at nuovasystems.com Fri Dec 8 07:39:28 2006 From: sgai at nuovasystems.com (Silvano Gai) Date: Fri, 8 Dec 2006 07:39:28 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2D11652@nuova-ex1.hq.nuovaimpresa.com> Joe, Inline: > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Friday, December 08, 2006 7:29 AM > To: Silvano Gai > Cc: Radia.Perlman at sun.com; Ali Sajassi (sajassi); Don Fedyk; Gray, Eric; > Developing a hybrid router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > Silvano Gai wrote: > > Joe, > > > > TRILL will never scale if you mandate to keep the forwarding table for > > the inner addresses on all RBridges, especially in a IEEE 802.1ah > > environment!!! > > Sorry; let me backup: > > Here's where we were at the last IETF: > > - the shim indicates the source (ingress) and dest (egress) > (originally this was just dest for unicast, source for mcast > but we agreed in San Diego to include both) > i.e., agreed with the point above; those are the > addresses on which packets are forwarded > > the ultimate source is indicated in the shim already > > - the outer header already indicates the previous/next-hop rbridge > > What's the reason for needing any further information? We don't. My comment is that IEEE 802.1ah has no space for both the ultimate source/dest and the next hop source/dest. IEEE 802.1ah is designed for multiple enterprises to share a common metro backbone. It does a fine job in that area. It does not support well an arbitrary intermixing of Bridges and Rbridges. In contrast Trill does a fine job in supporting arbitrary topologies and mixing of RBridges and Bridges thanks to the availability of both the ultimate source/dest and the next hop source/dest. In TRILL the network between the "ingress" and "egress" RBridge isn't a single Ethernet (like in 802.1ah), but rather a sequence of RBridges that may be connected by Ethernets. Things look similar, but are substantially different. -- Silvano > > As per below, if R1 (current rbridge) wants to pick from among multiple > next-hops R2 and R3, it does so with the outermost ethernet header. If > they're logical (R2/R3 both on the same NIC), then just assign separate > ethernet addresses to the same interface. > > What's left? > > Joe > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch at ISI.EDU] > >> Sent: Thursday, December 07, 2006 11:00 PM > >> To: Radia.Perlman at sun.com > >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric; > > Developing > >> a hybrid router/bridge. > >> Subject: Re: [rbridge] Use of 802.1ah Encaps > >> > >> > >> > >> Radia.Perlman at sun.com wrote: > >>> Travelling again, so extremely limited access to email (as in, about > > 10 > >> minutes here and there > >>> on a SLOW connection). Anyway, I'll answer some of these: > >>> > >>> a) why "next hop" and "previous hop" in addition to "ultimate" > > source > >> and destination > >>> At least one of the reasons is that if there are three RBridges on > > the > >> same link, R1, R2, and R3, > >>> it is useful for R1 to choose which of R2 or R3 should receive the > >> packet. It isn't obvious from > >>> the destination address because it could be that either R2 or R3 > > would > >> be logical, and R1 is > >>> load splitting. Also, it helps focus traffic on the link, and ensure > > it > >> doesn't get filtered, if > >>> the bridges on the link only need to learn R1, R2, and R3, > > especially > >> since traffic from outside > >>> RBridges might arrive from different entry points onto the link. > >> The ultimate destination (and source, for that matter) should be > >> sufficiently indicated by the inner ethernet packet. The outer header > > is > >> already hop-by-hop inside the rbridge anyway. What additional > >> information is required? > >> > >> The next/previous hop information sounds like a source route with > >> record-route option. While that's useful for debugging, it doesn't > > seem > >> necessary. > >> > >>> b) congestion management was explained to us, and it was what > > convinced > >> us we needed "ultimate > >>> source RBridge" in order to know where to send the congestion > >> notification. If you could explain the > >>> other things, we could see if there is a problem, but if they are > >> similar to congestion notification, then > >>> having the ingress RBridge will accommodate them. > >> Why doesn't the source ethernet address indicate this already? > >> > >> Joe > > From touch at ISI.EDU Fri Dec 8 08:08:44 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 08 Dec 2006 08:08:44 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2D11652@nuova-ex1.hq.nuovaimpresa.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2D11652@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <45798E0C.7010704@isi.edu> Silvano Gai wrote: > Joe, > > Inline: > >> -----Original Message----- >> From: Joe Touch [mailto:touch at ISI.EDU] >> Sent: Friday, December 08, 2006 7:29 AM >> To: Silvano Gai >> Cc: Radia.Perlman at sun.com; Ali Sajassi (sajassi); Don Fedyk; Gray, > Eric; >> Developing a hybrid router/bridge. >> Subject: Re: [rbridge] Use of 802.1ah Encaps >> >> >> >> Silvano Gai wrote: >>> Joe, >>> >>> TRILL will never scale if you mandate to keep the forwarding table > for >>> the inner addresses on all RBridges, especially in a IEEE 802.1ah >>> environment!!! >> Sorry; let me backup: >> >> Here's where we were at the last IETF: >> >> - the shim indicates the source (ingress) and dest (egress) >> (originally this was just dest for unicast, source for mcast >> but we agreed in San Diego to include both) >> i.e., agreed with the point above; those are the >> addresses on which packets are forwarded >> >> the ultimate source is indicated in the shim already >> >> - the outer header already indicates the previous/next-hop rbridge >> >> What's the reason for needing any further information? > > We don't. > > My comment is that IEEE 802.1ah has no space for both the ultimate > source/dest and the next hop source/dest. > > IEEE 802.1ah is designed for multiple enterprises to share a common > metro backbone. It does a fine job in that area. It does not support > well an arbitrary intermixing of Bridges and Rbridges. > > In contrast Trill does a fine job in supporting arbitrary topologies and > mixing of RBridges and Bridges thanks to the availability of both the > ultimate source/dest and the next hop source/dest. > > In TRILL the network between the "ingress" and "egress" RBridge isn't a > single Ethernet (like in 802.1ah), but rather a sequence of RBridges > that may be connected by Ethernets. > > Things look similar, but are substantially different. Agreed! Joe > -- Silvano > > >> As per below, if R1 (current rbridge) wants to pick from among > multiple >> next-hops R2 and R3, it does so with the outermost ethernet header. If >> they're logical (R2/R3 both on the same NIC), then just assign > separate >> ethernet addresses to the same interface. >> >> What's left? >> >> Joe >> >> >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch at ISI.EDU] >>>> Sent: Thursday, December 07, 2006 11:00 PM >>>> To: Radia.Perlman at sun.com >>>> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric; >>> Developing >>>> a hybrid router/bridge. >>>> Subject: Re: [rbridge] Use of 802.1ah Encaps >>>> >>>> >>>> >>>> Radia.Perlman at sun.com wrote: >>>>> Travelling again, so extremely limited access to email (as in, > about >>> 10 >>>> minutes here and there >>>>> on a SLOW connection). Anyway, I'll answer some of these: >>>>> >>>>> a) why "next hop" and "previous hop" in addition to "ultimate" >>> source >>>> and destination >>>>> At least one of the reasons is that if there are three RBridges on >>> the >>>> same link, R1, R2, and R3, >>>>> it is useful for R1 to choose which of R2 or R3 should receive the >>>> packet. It isn't obvious from >>>>> the destination address because it could be that either R2 or R3 >>> would >>>> be logical, and R1 is >>>>> load splitting. Also, it helps focus traffic on the link, and > ensure >>> it >>>> doesn't get filtered, if >>>>> the bridges on the link only need to learn R1, R2, and R3, >>> especially >>>> since traffic from outside >>>>> RBridges might arrive from different entry points onto the link. >>>> The ultimate destination (and source, for that matter) should be >>>> sufficiently indicated by the inner ethernet packet. The outer > header >>> is >>>> already hop-by-hop inside the rbridge anyway. What additional >>>> information is required? >>>> >>>> The next/previous hop information sounds like a source route with >>>> record-route option. While that's useful for debugging, it doesn't >>> seem >>>> necessary. >>>> >>>>> b) congestion management was explained to us, and it was what >>> convinced >>>> us we needed "ultimate >>>>> source RBridge" in order to know where to send the congestion >>>> notification. If you could explain the >>>>> other things, we could see if there is a problem, but if they are >>>> similar to congestion notification, then >>>>> having the ingress RBridge will accommodate them. >>>> Why doesn't the source ethernet address indicate this already? >>>> >>>> Joe > -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061208/dfd98e79/signature-0001.bin From Radia.Perlman at sun.com Fri Dec 8 11:25:21 2006 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Sat, 09 Dec 2006 00:25:21 +0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <881865d13f9.457a0271@sunlabs.com> There's 3 sets of addresses: a) original frame: endnode source and destination MACs. b) shim: ingress and egress RBridges c) outer: next hop, previous hop. Forwarding is to egress RBridge in order to make RBridges inside not have to know about all the endnodes, especially in VLANs they are not connected to. So forwarding by Rbridges between the ingress and egress is solely by "egress RBridge", not by the source/destination in the inner frame Outer header (nxt hop/previous hop) is for shared media....if there's a cloud in the middle with multiple nodes, including multiple RBridges, the "next hop" lets any bridges on that cloud know where to send it, and won't have them fallaciously filtering. Radia -------------- next part -------------- Radia.Perlman at sun.com wrote: > Travelling again, so extremely limited access to email (as in, about 10 minutes here and there > on a SLOW connection). Anyway, I'll answer some of these: > > a) why "next hop" and "previous hop" in addition to "ultimate" source and destination > > At least one of the reasons is that if there are three RBridges on the same link, R1, R2, and R3, > it is useful for R1 to choose which of R2 or R3 should receive the packet. It isn't obvious from > the destination address because it could be that either R2 or R3 would be logical, and R1 is > load splitting. Also, it helps focus traffic on the link, and ensure it doesn't get filtered, if > the bridges on the link only need to learn R1, R2, and R3, especially since traffic from outside > RBridges might arrive from different entry points onto the link. The ultimate destination (and source, for that matter) should be sufficiently indicated by the inner ethernet packet. The outer header is already hop-by-hop inside the rbridge anyway. What additional information is required? The next/previous hop information sounds like a source route with record-route option. While that's useful for debugging, it doesn't seem necessary. > b) congestion management was explained to us, and it was what convinced us we needed "ultimate > source RBridge" in order to know where to send the congestion notification. If you could explain the > other things, we could see if there is a problem, but if they are similar to congestion notification, then > having the ingress RBridge will accommodate them. Why doesn't the source ethernet address indicate this already? Joe From sajassi at cisco.com Sun Dec 10 15:06:58 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Sun, 10 Dec 2006 15:06:58 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB027833A5@xmb-sjc-21e.amer.cisco.com> > -----Original Message----- > From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] > Sent: Thursday, December 07, 2006 9:56 PM > To: Ali Sajassi (sajassi) > Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid > router/bridge.; Joe Touch > Subject: Re: [rbridge] Use of 802.1ah Encaps > > Travelling again, so extremely limited access to email (as > in, about 10 minutes here and there on a SLOW connection). > Anyway, I'll answer some of these: Also sorry for not being able to respond to your email earlier due to my schedule/meetings (specially on Friday). > > a) why "next hop" and "previous hop" in addition to > "ultimate" source and destination > > At least one of the reasons is that if there are three > RBridges on the same link, R1, R2, and R3, it is useful for > R1 to choose which of R2 or R3 should receive the packet. It > isn't obvious from the destination address because it could > be that either R2 or R3 would be logical, and R1 is load > splitting. Also, it helps focus traffic on the link, and > ensure it doesn't get filtered, if the bridges on the link > only need to learn R1, R2, and R3, especially since traffic > from outside RBridges might arrive from different entry > points onto the link. O.K., I remember now the discussion that we had during the IETF meeting on load balancing and next hop address. However, there are couple of ways for achieving the same result. I mentioned briefly during the meeting the use of VLAN for this purpose and someone else mentioned using part of 48-bit provider MAC address for this purpose. > > b) congestion management was explained to us, and it was what > convinced us we needed "ultimate source RBridge" in order to > know where to send the congestion notification. If you could > explain the other things, we could see if there is a problem, > but if they are similar to congestion notification, then > having the ingress RBridge will accommodate them. > With respect to CFM, connectivity fault mgmt is done in a hierarchical way and it can be performed at the provider service instance level (e.g., on a per I-SID basis) or it can be performed for group of I-SIDs on a per B-VLAN level. In both cases, provider MAC addresses are used which makes the provider OAM control for customer data-traffic very tight. You cannot get the same result by using OAM messages that use customer MAC addresses and if you try to do it will be very cumbersome. Basically what I am trying to point out is that by using non-IEEE conformance frame format, you assume the responsibility for all the features developed by IEEE; where as, if you use IEEE conformant frame, then one can concentrate on the control plane issues which I thought was the main objective of TRILL. -Ali > Sorry for ignoring all the other messages for now, but I only > had a chance to read and respond to one message. > > Radia > > ----- Original Message ----- > From: "Ali Sajassi (sajassi)" > Date: Friday, December 8, 2006 10:53 am > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > Silvano, > > > > > -----Original Message----- > > > From: Silvano Gai [sgai at nuovasystems.com] > > > Sent: Thursday, December 07, 2006 5:36 PM > > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi) > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. > > > There are advantages and disadvantages. > > > > > > The disadvantages are: > > > 1) Lack of Next-Hop addresses. We discussed this at length during > > > the last meeting and we didn't reach consensus on a way > to eliminate > > > them. > > > > Can you refresh my memory for why we need a next-hop > address when the > > header carries both source and destination PE addresses and > when these > > addresses are learned in control plane ? > > > > > 2) Lack of a TTL field (it may be added, but it is not > there today). > > > > Can probably be accommodated. > > > > > 3) Many unneeded fields and therefore larger frame overhead. > > > > > > > Such as ? > > > > > The advantages are: > > > 1) Larger addressable market for TRILL > > > > > > IMO if we stick with the WG charter the disadvantages clearly > > > outweigh the advantages. > > > > > > The WG can be re-chartered, but if we consider the Enterprise and > > > Data Center market, IEEE 802.1ah is an overkill. > > > > > > > If by overkill you mean a bit bigger header, then I agree > but look at > > all the other advantages that you get from using standard > IEEE header > > and shim including: > > - security Mgmt: MACSec/KeySec > > - Congestion Mgmt > > - Connectivity Fault Mgmt > > > > Has it been considered how these are going to work with TRILL shim > > header or are these outside of WG charter :-) > > > > -Ali > > > > > > > -- Silvano > > > > > > > > > > -----Original Message----- > > > > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] > > > On > > > > Behalf Of Don Fedyk > > > > Sent: Thursday, December 07, 2006 9:21 AM > > > > To: Gray, Eric; Ali Sajassi (sajassi) > > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > > > Hi Eric > > > > > > > > > -----Original Message----- > > > > > From: Gray, Eric [Eric.Gray at marconi.com] > > > > > > > > > > Don, > > > > > > > > > > And yet, someone (Ali Sajassi) asserted (in his message > > > dated Wed > > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or > > additional > > > > > complications with using 802.1ah in enterprises for plug-and- > > play > > > > > applicability. > > > > > > > > > > Perhaps Ali can answer my question then. > > > > > > > > > > But, to more directly address your earlier comments: > > > > > > > > > > The TRILL WG has NOT come up with an encapsulation that > > "looks > > > > > like" 802.1ah - unless someone squints really hard and tries > > to > > > > > pretend that two separate Ethernet encapsulations - > > > separated by a > > > > > SHIM header - are one single encapsulation. > > > > > > > > To be fair Point to Point header that was discussed without > > > one of the > > > > shims was very close "functionally" (colloquial looks like) to > > > 802.1ah. > > > > My opinion is still we don't need several variations of > > > headers doing > > > > similar things. > > > > > > > > This was the slide that looked a lot like what I posted. > > > > > > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > > > > > > > Regards, > > > > Don > > > > > > > > > > That is not to say that the WG has done anything that > > > could be said > > > > > to disallow the use of 802.1ah encapsulation. > > > > > It is just not obviously consistent with all of the WG > > > goals to use > > > > > _only_ 802.1ah encapsulation. > > > > > > > > > > -- > > > > > Eric > > > > > > > > > > > > > _______________________________________________ > > > > 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 sajassi at cisco.com Sun Dec 10 15:24:48 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Sun, 10 Dec 2006 15:24:48 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB027833A7@xmb-sjc-21e.amer.cisco.com> Hi Silvano, > > > > > 3) Many unneeded fields and therefore larger frame overhead. > > > > > > > Such as ? > > The I-tag is not useful in TRILL and in contrast two > addresses and the TTL are missing. I-tag my not be useful in data-center applications but it is useful in large Enterprise applications. I acknowledge that TTL is missing but if needed we (at IEEE) can try to accommodate it. And by two addresses, if you mean next hop addresses, then those can be inferred by B-MAC addresses (and possibly B-VLAN if needed) in .1ah encap. -Ali > > > > > > The advantages are: > > > 1) Larger addressable market for TRILL > > > > > > IMO if we stick with the WG charter the disadvantages clearly > > > outweigh the advantages. > > > > > > The WG can be re-chartered, but if we consider the Enterprise and > > > Data Center market, IEEE 802.1ah is an overkill. > > > > > > > If by overkill you mean a bit bigger header, then I agree > but look at > > all the other advantages that you get from using standard > IEEE header > > and shim including: > > - security Mgmt: MACSec/KeySec > > - Congestion Mgmt > > - Connectivity Fault Mgmt > > > > Has it been considered how these are going to work with TRILL shim > > header or are these outside of WG charter :-) > > > > -Ali > > > > > > > -- Silvano > > > > > > > > > > -----Original Message----- > > > > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] > > > On > > > > Behalf Of Don Fedyk > > > > Sent: Thursday, December 07, 2006 9:21 AM > > > > To: Gray, Eric; Ali Sajassi (sajassi) > > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > > > Hi Eric > > > > > > > > > -----Original Message----- > > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > > > > > Don, > > > > > > > > > > And yet, someone (Ali Sajassi) asserted (in his message > > > dated Wed > > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or > additional > > > > > complications with using 802.1ah in enterprises for > plug-and-play > > > > > applicability. > > > > > > > > > > Perhaps Ali can answer my question then. > > > > > > > > > > But, to more directly address your earlier comments: > > > > > > > > > > The TRILL WG has NOT come up with an encapsulation that > "looks > > > > > like" 802.1ah - unless someone squints really hard > and tries to > > > > > pretend that two separate Ethernet encapsulations - > > > separated by a > > > > > SHIM header - are one single encapsulation. > > > > > > > > To be fair Point to Point header that was discussed without > > > one of the > > > > shims was very close "functionally" (colloquial looks like) to > > > 802.1ah. > > > > My opinion is still we don't need several variations of > > > headers doing > > > > similar things. > > > > > > > > This was the slide that looked a lot like what I posted. > > > > > > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > > > > > > > Regards, > > > > Don > > > > > > > > > > That is not to say that the WG has done anything that > > > could be said > > > > > to disallow the use of 802.1ah encapsulation. > > > > > It is just not obviously consistent with all of the WG > > > goals to use > > > > > _only_ 802.1ah encapsulation. > > > > > > > > > > -- > > > > > Eric > > > > > > > > > > > > > _______________________________________________ > > > > rbridge mailing list > > > > rbridge at postel.org > > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > From sajassi at cisco.com Sun Dec 10 15:34:14 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Sun, 10 Dec 2006 15:34:14 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB027833A8@xmb-sjc-21e.amer.cisco.com> > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Friday, December 08, 2006 7:29 AM > To: Silvano Gai > Cc: Radia.Perlman at sun.com; Ali Sajassi (sajassi); Don Fedyk; > Gray, Eric; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > Silvano Gai wrote: > > Joe, > > > > TRILL will never scale if you mandate to keep the > forwarding table for > > the inner addresses on all RBridges, especially in a IEEE 802.1ah > > environment!!! > > Sorry; let me backup: > > Here's where we were at the last IETF: > > - the shim indicates the source (ingress) and dest (egress) > (originally this was just dest for unicast, source for mcast > but we agreed in San Diego to include both) > i.e., agreed with the point above; those are the > addresses on which packets are forwarded > > the ultimate source is indicated in the shim already > > - the outer header already indicates the previous/next-hop rbridge > > What's the reason for needing any further information? > > As per below, if R1 (current rbridge) wants to pick from > among multiple next-hops R2 and R3, it does so with the > outermost Ethernet header. If they're logical (R2/R3 both on > the same NIC), then just assign separate ethernet addresses > to the same interface. > > What's left? If the outer Ethernet addresses represent the link Ether addresses for the current/next-hop rbriges and the shim header represent the source/dest rbridge addresses, then why not just do IP encap using L2TPv3/GRE and be done with !! -Ali > > Joe > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch at ISI.EDU] > >> Sent: Thursday, December 07, 2006 11:00 PM > >> To: Radia.Perlman at sun.com > >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric; > > Developing > >> a hybrid router/bridge. > >> Subject: Re: [rbridge] Use of 802.1ah Encaps > >> > >> > >> > >> Radia.Perlman at sun.com wrote: > >>> Travelling again, so extremely limited access to email > (as in, about > > 10 > >> minutes here and there > >>> on a SLOW connection). Anyway, I'll answer some of these: > >>> > >>> a) why "next hop" and "previous hop" in addition to "ultimate" > > source > >> and destination > >>> At least one of the reasons is that if there are three RBridges on > > the > >> same link, R1, R2, and R3, > >>> it is useful for R1 to choose which of R2 or R3 should receive the > >> packet. It isn't obvious from > >>> the destination address because it could be that either R2 or R3 > > would > >> be logical, and R1 is > >>> load splitting. Also, it helps focus traffic on the link, > and ensure > > it > >> doesn't get filtered, if > >>> the bridges on the link only need to learn R1, R2, and R3, > > especially > >> since traffic from outside > >>> RBridges might arrive from different entry points onto the link. > >> The ultimate destination (and source, for that matter) should be > >> sufficiently indicated by the inner ethernet packet. The > outer header > > is > >> already hop-by-hop inside the rbridge anyway. What additional > >> information is required? > >> > >> The next/previous hop information sounds like a source route with > >> record-route option. While that's useful for debugging, it doesn't > > seem > >> necessary. > >> > >>> b) congestion management was explained to us, and it was what > > convinced > >> us we needed "ultimate > >>> source RBridge" in order to know where to send the congestion > >> notification. If you could explain the > >>> other things, we could see if there is a problem, but if they are > >> similar to congestion notification, then > >>> having the ingress RBridge will accommodate them. > >> Why doesn't the source ethernet address indicate this already? > >> > >> Joe > > > > From sajassi at cisco.com Sun Dec 10 15:48:19 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Sun, 10 Dec 2006 15:48:19 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB027833A9@xmb-sjc-21e.amer.cisco.com> Silvano, > > My comment is that IEEE 802.1ah has no space for both the > ultimate source/dest and the next hop source/dest. > Yes, it doesn't but if next hop source/dest is needed, it can be derived through other means as discussed briefly during last IETF meeting. > IEEE 802.1ah is designed for multiple enterprises to share a > common metro backbone. It does a fine job in that area. It > does not support well an arbitrary intermixing of Bridges and > Rbridges. IEEE 802.1ah is designed to work with a mix of 802.1Q, 802.1ad, and 802.1ah bridges. > > In contrast Trill does a fine job in supporting arbitrary > topologies and mixing of RBridges and Bridges thanks to the > availability of both the ultimate source/dest and the next > hop source/dest. > > In TRILL the network between the "ingress" and "egress" > RBridge isn't a single Ethernet (like in 802.1ah), but rather > a sequence of RBridges that may be connected by Ethernets. 802.1ah doesn't assume that the network between ingress and egress edge bridges is a single Ethernet. It assume a bridged-LAN network (e.g., 802.1Q network). -Ali > > Things look similar, but are substantially different. > > -- Silvano > > > > > > As per below, if R1 (current rbridge) wants to pick from among > multiple > > next-hops R2 and R3, it does so with the outermost ethernet > header. If > > they're logical (R2/R3 both on the same NIC), then just assign > separate > > ethernet addresses to the same interface. > > > > What's left? > > > > Joe > > > > > > >> -----Original Message----- > > >> From: Joe Touch [mailto:touch at ISI.EDU] > > >> Sent: Thursday, December 07, 2006 11:00 PM > > >> To: Radia.Perlman at sun.com > > >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric; > > > Developing > > >> a hybrid router/bridge. > > >> Subject: Re: [rbridge] Use of 802.1ah Encaps > > >> > > >> > > >> > > >> Radia.Perlman at sun.com wrote: > > >>> Travelling again, so extremely limited access to email (as in, > about > > > 10 > > >> minutes here and there > > >>> on a SLOW connection). Anyway, I'll answer some of these: > > >>> > > >>> a) why "next hop" and "previous hop" in addition to "ultimate" > > > source > > >> and destination > > >>> At least one of the reasons is that if there are three > RBridges on > > > the > > >> same link, R1, R2, and R3, > > >>> it is useful for R1 to choose which of R2 or R3 should > receive the > > >> packet. It isn't obvious from > > >>> the destination address because it could be that either R2 or R3 > > > would > > >> be logical, and R1 is > > >>> load splitting. Also, it helps focus traffic on the link, and > ensure > > > it > > >> doesn't get filtered, if > > >>> the bridges on the link only need to learn R1, R2, and R3, > > > especially > > >> since traffic from outside > > >>> RBridges might arrive from different entry points onto the link. > > >> The ultimate destination (and source, for that matter) should be > > >> sufficiently indicated by the inner ethernet packet. The outer > header > > > is > > >> already hop-by-hop inside the rbridge anyway. What additional > > >> information is required? > > >> > > >> The next/previous hop information sounds like a source > route with > > >> record-route option. While that's useful for debugging, > it doesn't > > > seem > > >> necessary. > > >> > > >>> b) congestion management was explained to us, and it was what > > > convinced > > >> us we needed "ultimate > > >>> source RBridge" in order to know where to send the congestion > > >> notification. If you could explain the > > >>> other things, we could see if there is a problem, but > if they are > > >> similar to congestion notification, then > > >>> having the ingress RBridge will accommodate them. > > >> Why doesn't the source ethernet address indicate this already? > > >> > > >> Joe > > > > From touch at ISI.EDU Sun Dec 10 22:55:32 2006 From: touch at ISI.EDU (Joe Touch) Date: Sun, 10 Dec 2006 22:55:32 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB027833A8@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB027833A8@xmb-sjc-21e.amer.cisco.com> Message-ID: <457D00E4.7070906@isi.edu> Ali Sajassi (sajassi) wrote: > > >> -----Original Message----- >> From: Joe Touch [mailto:touch at ISI.EDU] >> Sent: Friday, December 08, 2006 7:29 AM >> To: Silvano Gai >> Cc: Radia.Perlman at sun.com; Ali Sajassi (sajassi); Don Fedyk; >> Gray, Eric; Developing a hybrid router/bridge. >> Subject: Re: [rbridge] Use of 802.1ah Encaps >> >> >> >> Silvano Gai wrote: >>> Joe, >>> >>> TRILL will never scale if you mandate to keep the >> forwarding table for >>> the inner addresses on all RBridges, especially in a IEEE 802.1ah >>> environment!!! >> Sorry; let me backup: >> >> Here's where we were at the last IETF: >> >> - the shim indicates the source (ingress) and dest (egress) >> (originally this was just dest for unicast, source for mcast >> but we agreed in San Diego to include both) >> i.e., agreed with the point above; those are the >> addresses on which packets are forwarded >> >> the ultimate source is indicated in the shim already >> >> - the outer header already indicates the previous/next-hop rbridge >> >> What's the reason for needing any further information? >> >> As per below, if R1 (current rbridge) wants to pick from >> among multiple next-hops R2 and R3, it does so with the >> outermost Ethernet header. If they're logical (R2/R3 both on >> the same NIC), then just assign separate ethernet addresses >> to the same interface. >> >> What's left? > > If the outer Ethernet addresses represent the link Ether addresses for > the current/next-hop rbriges and the shim header represent the > source/dest rbridge addresses, then why not just do IP encap using > L2TPv3/GRE and be done with !! Can you please describe the header you're considering an alternative, e.g, where the current one is: [outer ether [6-byte shim] [inner ether [payload]]] The above adds 20 bytes (14 outer ether + 6 byte shim), and allows TTL management inside the rbridge without affecting the payload TTL (required for correct operation). I'm not exactly sure what you mean you L2TPv3/GRE, but I'm wondering if that comes out to 42 bytes of header, and whether it provides an L2 solution. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061210/67d004f5/signature.bin From sajassi at cisco.com Mon Dec 11 01:18:03 2006 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Mon, 11 Dec 2006 01:18:03 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02783424@xmb-sjc-21e.amer.cisco.com> > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Sunday, December 10, 2006 10:56 PM > To: Ali Sajassi (sajassi) > Cc: Silvano Gai; Radia.Perlman at sun.com; Don Fedyk; Gray, > Eric; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > Ali Sajassi (sajassi) wrote: > > > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch at ISI.EDU] > >> Sent: Friday, December 08, 2006 7:29 AM > >> To: Silvano Gai > >> Cc: Radia.Perlman at sun.com; Ali Sajassi (sajassi); Don Fedyk; Gray, > >> Eric; Developing a hybrid router/bridge. > >> Subject: Re: [rbridge] Use of 802.1ah Encaps > >> > >> > >> > >> Silvano Gai wrote: > >>> Joe, > >>> > >>> TRILL will never scale if you mandate to keep the > >> forwarding table for > >>> the inner addresses on all RBridges, especially in a IEEE 802.1ah > >>> environment!!! > >> Sorry; let me backup: > >> > >> Here's where we were at the last IETF: > >> > >> - the shim indicates the source (ingress) and dest (egress) > >> (originally this was just dest for unicast, source for mcast > >> but we agreed in San Diego to include both) > >> i.e., agreed with the point above; those are the > >> addresses on which packets are forwarded > >> > >> the ultimate source is indicated in the shim already > >> > >> - the outer header already indicates the previous/next-hop rbridge > >> > >> What's the reason for needing any further information? > >> > >> As per below, if R1 (current rbridge) wants to pick from among > >> multiple next-hops R2 and R3, it does so with the > outermost Ethernet > >> header. If they're logical (R2/R3 both on the same NIC), then just > >> assign separate ethernet addresses to the same interface. > >> > >> What's left? > > > > If the outer Ethernet addresses represent the link Ether > addresses for > > the current/next-hop rbriges and the shim header represent the > > source/dest rbridge addresses, then why not just do IP encap using > > L2TPv3/GRE and be done with !! > > Can you please describe the header you're considering an > alternative, e.g, where the current one is: > [outer ether [6-byte shim] [inner ether [payload]]] > [outer ether][20-byte IP header][4 or 8 byte L2TPv3/GRE shim] [inner Ether [payload]] The draw back is the additional 20 bytes of IP header but the advantage is that you can use the IGP as is :-) > The above adds 20 bytes (14 outer ether + 6 byte shim), and > allows TTL management inside the rbridge without affecting > the payload TTL (required for correct operation). > > I'm not exactly sure what you mean you L2TPv3/GRE, but I'm > wondering if that comes out to 42 bytes of header, and > whether it provides an L2 solution. It is an L2 solution. I did a draft on it long time ago in context of L2VPN: http://ietfreport.isoc.org/idref/draft-sajassi-mvpls/ -Ali > > Joe > > > From sgai at nuovasystems.com Mon Dec 11 07:19:04 2006 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 11 Dec 2006 07:19:04 -0800 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2D1190A@nuova-ex1.hq.nuovaimpresa.com> Ali, Inline: > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > Sent: Sunday, December 10, 2006 3:48 PM > To: Silvano Gai; Joe Touch > Cc: Radia.Perlman at sun.com; Don Fedyk; Gray, Eric; Developing a hybrid > router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > Silvano, > > > > > > My comment is that IEEE 802.1ah has no space for both the > > ultimate source/dest and the next hop source/dest. > > > > Yes, it doesn't but if next hop source/dest is needed, it can be derived > through other means as discussed briefly during last IETF meeting. > > > IEEE 802.1ah is designed for multiple enterprises to share a > > common metro backbone. It does a fine job in that area. It > > does not support well an arbitrary intermixing of Bridges and > > Rbridges. > > IEEE 802.1ah is designed to work with a mix of 802.1Q, 802.1ad, and > 802.1ah bridges. > > > > > > In contrast Trill does a fine job in supporting arbitrary > > topologies and mixing of RBridges and Bridges thanks to the > > availability of both the ultimate source/dest and the next > > hop source/dest. > > > > In TRILL the network between the "ingress" and "egress" > > RBridge isn't a single Ethernet (like in 802.1ah), but rather > > a sequence of RBridges that may be connected by Ethernets. > > 802.1ah doesn't assume that the network between ingress and egress edge > bridges is a single Ethernet. It assume a bridged-LAN network (e.g., > 802.1Q network). You are absolutely right, but TRILL does more, it assumes a sequence of RBridges interconnected by bridged-LAN network. -- Silvano > > -Ali > > > > > Things look similar, but are substantially different. > > > > -- Silvano > > > > > > > > > > As per below, if R1 (current rbridge) wants to pick from among > > multiple > > > next-hops R2 and R3, it does so with the outermost ethernet > > header. If > > > they're logical (R2/R3 both on the same NIC), then just assign > > separate > > > ethernet addresses to the same interface. > > > > > > What's left? > > > > > > Joe > > > > > > > > > >> -----Original Message----- > > > >> From: Joe Touch [mailto:touch at ISI.EDU] > > > >> Sent: Thursday, December 07, 2006 11:00 PM > > > >> To: Radia.Perlman at sun.com > > > >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric; > > > > Developing > > > >> a hybrid router/bridge. > > > >> Subject: Re: [rbridge] Use of 802.1ah Encaps > > > >> > > > >> > > > >> > > > >> Radia.Perlman at sun.com wrote: > > > >>> Travelling again, so extremely limited access to email (as in, > > about > > > > 10 > > > >> minutes here and there > > > >>> on a SLOW connection). Anyway, I'll answer some of these: > > > >>> > > > >>> a) why "next hop" and "previous hop" in addition to "ultimate" > > > > source > > > >> and destination > > > >>> At least one of the reasons is that if there are three > > RBridges on > > > > the > > > >> same link, R1, R2, and R3, > > > >>> it is useful for R1 to choose which of R2 or R3 should > > receive the > > > >> packet. It isn't obvious from > > > >>> the destination address because it could be that either R2 or R3 > > > > would > > > >> be logical, and R1 is > > > >>> load splitting. Also, it helps focus traffic on the link, and > > ensure > > > > it > > > >> doesn't get filtered, if > > > >>> the bridges on the link only need to learn R1, R2, and R3, > > > > especially > > > >> since traffic from outside > > > >>> RBridges might arrive from different entry points onto the link. > > > >> The ultimate destination (and source, for that matter) should be > > > >> sufficiently indicated by the inner ethernet packet. The outer > > header > > > > is > > > >> already hop-by-hop inside the rbridge anyway. What additional > > > >> information is required? > > > >> > > > >> The next/previous hop information sounds like a source > > route with > > > >> record-route option. While that's useful for debugging, > > it doesn't > > > > seem > > > >> necessary. > > > >> > > > >>> b) congestion management was explained to us, and it was what > > > > convinced > > > >> us we needed "ultimate > > > >>> source RBridge" in order to know where to send the congestion > > > >> notification. If you could explain the > > > >>> other things, we could see if there is a problem, but > > if they are > > > >> similar to congestion notification, then > > > >>> having the ingress RBridge will accommodate them. > > > >> Why doesn't the source ethernet address indicate this already? > > > >> > > > >> Joe > > > > > > From touch at ISI.EDU Tue Dec 12 09:10:15 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 12 Dec 2006 09:10:15 -0800 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02783424@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02783424@xmb-sjc-21e.amer.cisco.com> Message-ID: <457EE277.4070203@isi.edu> Ali Sajassi (sajassi) wrote: >... >> Can you please describe the header you're considering an >> alternative, e.g, where the current one is: >> [outer ether [6-byte shim] [inner ether [payload]]] > > [outer ether][20-byte IP header][4 or 8 byte L2TPv3/GRE shim] > [inner Ether [payload]] > > The draw back is the additional 20 bytes of IP header but the advantage > is that you can use the IGP as is :-) That's a fairly large drawback. Also, how might this affect an IP protocol running on links over which rbridge nodes communicate? I.e., don't you have to de-conflict the IP addresses and possibly also the IGP to avoid interference between the two? Our system has a shim just inside the outer ether, i.e., using a different ethertype; that effectively forces non-rbridge systems to ignore the packets. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061212/6e7e22b6/signature.bin From Eric.Gray at marconi.com Tue Dec 12 12:59:11 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Tue, 12 Dec 2006 15:59:11 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017A7F@uspitsmsgusr08.win.marconi.com> Ali, I am confused. What does it mean to say "at the UNI you decide ... [and] you also decide at the UNI ..." if it does not mean that the network operator determines these things a priori and configures the equipment accordingly. If there is a requirement for configuration - possibly on an interface-by-interface basis - how is that plug and play? -- Eric > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > Sent: Thursday, December 07, 2006 11:48 PM > To: Gray, Eric; Don Fedyk; Joe Touch > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Gray, > > With respect to plug-and-play operation, it is similar to 802.1Q or > 802.1ad operation; where, at the UNI you decide which interfaces belong > to which VLANs in case of 802.1Q or which pair belong > to S-tag in case of 802.1ad (e.g., point-to-cloud config model). In case > of 802.1ah, you also decide at the UNI which interfaces or which > pair belong to which pair. Again the > model in 802.1ah is point-to-cloud model just like 802.1Q and 802.1ad > and that's what makes it plug-and-play. > > -Ali > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Sent: Thursday, December 07, 2006 5:38 AM > > To: Don Fedyk; Joe Touch; Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge. > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Don, > > > > Thanks for doing this. As you can probably attest, > > this is a non-trivial "digging" task to come up with this > > level of detail. I am not sure why Joe asked for it, but now > > that you have provided it, perhaps you can explain how values > > would be derived for the B-TAG TCI/VID and I-TAG TCI/SID > > fields if we'd like to deploy this technology in > "plug-and-play" mode? > > > > -- > > Eric > > > > > -----Original Message----- > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > > Sent: Thursday, December 07, 2006 8:29 AM > > > To: Joe Touch; Ali Sajassi (sajassi) > > > Cc: Gray, Eric; Developing a hybrid router/bridge. > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > Hi > > > > > > This is the Provider Backbone Header Format reproduced from > > one of the > > > 802.1ah documents. When I said this is similar to the > Trill header > > > this is the version I mentioned. I converted to > > textographics by hand > > > so I hope I got it right. I put field designators in [] > inside the > > > picture for fear they would get wrapped. The encapsulated > > frame starts > > > after the I-TAG I-SID. > > > > > > > > > | 1 | 2 | 3 | 4 > > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > -2 | | > > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + > > > 2 | Backbone Destination Address > > [B-DA] | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 6 | Backbone Source Address > > [B-SA] | > > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 10 | | .1ad Ethertype > > [B-TAG] | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 14 | .1ad B-TAG TCI/VID | .1ah Ethertype [ > > ] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ > > I ]-+-+-+ > > > 18 | .1ah I-TAG TCI/SID [ > > - ] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ > > T ]-+-+-+ > > > 22 | Customer Destination Address [ > > A ] | > > > + +-+-+-+-+-+-+-+-+-+-+-[ > > G ]-+-+-+ > > > 26 | | [ > > ] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ > > ] + > > > 30 | Customer Source Address [ > > ] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ > > ]-+-+-+ > > > 34 | Encap Ethertype | [ ] > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > .1ah I-TAG TCI > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | P/DE |R1 |R2 | I-SID > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > P/DE 3 Bits Priority 1 bit Drop Eligible > > > R1 Res1 > > > R2 Res2 > > > > > > a) priority - This 3 bit field carries the customer > > priority (I-PCP) > > > associated with this frame. The provider network operates on the > > > priority associated with the B-TAG. > > > > > > b) drop_eligible - This 1 bit field carries the customer drop > > > eligibility > > > (I-DEI) associated with this frame. The provider network > > operates on > > > the drop eligibility associated with the B-TAG. > > > > > > c) res1 - This 2 bit field is used for any future format > > variations. > > > The > > > res2 > > > field is zero on transmit and is ignored on receipt. > > > > > > d) res2 - This 2 bit field is used for any future format > > variations. > > > The > > > res1 > > > field is zero on transmit and if set on reception the frame is > > > discarded. > > > > > > e) I-SID - This 24 bit field carries the service instance > > identifier > > > associated with this frame. > > > > > > f) encapsulated C-DA - This field carries the 48 bit > > Destination MAC > > > Address for an encapsulated Ethernet frame. > > > > > > g) encapsulated C-SA - This field carries the 48 bit Source MAC > > > Address for an encapsulated Ethernet frame. > > > > > > Regards, > > > Don > > > > > > > > > > -----Original Message----- > > > > From: Joe Touch [mailto:touch at ISI.EDU] > > > > Sent: Wednesday, December 06, 2006 9:53 PM > > > > To: Ali Sajassi (sajassi) > > > > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid > > > > router/bridge. > > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > > > I'd really rather someone just posted the header / > fields, rather > > > > than a large document in which that information is buried, if > > > > possible ;-) > > > > > > > > Joe > > > > > > > > Ali Sajassi (sajassi) wrote: > > > > > > > > > >> Can you - or anyone with easy access to the specs - > > > please post an > > > > >> explicit description of 802.1ah header and fields? > > > > > > > > > > I will ask Tony (802.1 chair) to make avail to TRILL WG a > > > > copy of .1ah. > > > > > > > > > > -Ali > > > > > > > > > > > > > > >> Thanks, > > > > >> > > > > >> Joe > > > > >> > > > > >> > > > > > > > > -- > > > > ---------------------------------------- > > > > Joe Touch > > > > Sr. Network Engineer, USAF TSAT Space Segment > > > > > > > > > > > > > > From Eric.Gray at marconi.com Tue Dec 12 13:16:47 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Tue, 12 Dec 2006 16:16:47 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017A88@uspitsmsgusr08.win.marconi.com> Ali, No argument. But this is what you do in a break-out or interim meeting - not what you do in a working group meeting where the intention is to summarize results. There are things that were pointed out that we should consider. There are also other projects that are in the works. There are incentives to induce us toward a common solution. And there is a time and a place to go into the details, consider alternatives, etc. The minute you have 10-20 people standing at a microphone waiting for their turn to comment on the latest gyration (with a change taking place as each person steps up to take his/her turn), you're designing in committee. I think it's wrong (in many ways) to treat anything suggested during that portion of the discussion as anything other than brain-storming. It seems obvious at this point that people have had some time to think about the suggestions and eliminate many of them. I have seen only one change that appears consistently to have been agreed on over previous iterations of considering the use of a SHIM header and that has been to include both the ingress and egress RBridge "nick-names" in the SHIM. Other than for reasons of interoperability - which tends to require us to agree on a minimal set of common encapsulations that MUST be supported by all RBridges - it is actually only a diversion for us to spend time in discussion of how we might modify IEEE-defined encapsulations to support TRILL directly. It may be interesting and inspiring to talk about these things, but does it help us to get the job done? -- Eric > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > Sent: Thursday, December 07, 2006 11:59 PM > To: Gray, Eric; Joe Touch > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Sent: Thursday, December 07, 2006 5:48 AM > > To: Joe Touch; Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge. > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Joe/Ali, > > > > It is not as simple as this. > > > > The IETF has already established a precedent for > > Ethernet encapsulation of SHIM-encapsulated Ethernet. It's > > only trying to see this as a single encapsulation, that > > causes people to conclude we are inventing a new form of > > Ethernet encapsulation. > > > > Other than inappropriate "designing committee" > > discussion at the last IETF meeting, we have not been > > attempting to design any new Ethernet encapsulation. And I > > believe we should safely conclude, at this point, that the > > discussion that took place on this topic at the TRILL meeting > > last month can be closed and considered to have been > > completely unproductive. > > > I think it is always good to have discussions among ourselves > to see how > we can leverage each other expertise and technology and > whether what you > are doing can be leveraged in other applications. The basic premise in > here is that there is a good level of overlap among different > areas that > are being worked on by different WGs, and we will do each > other as well > as industry a great service if we can come up with a common solution > jointly. > > -Ali > > > > > Big surprise... > > > > -- > > Eric > > > > > -----Original Message----- > > > From: rbridge-bounces at postel.org > > > [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch > > > Sent: Wednesday, December 06, 2006 10:23 PM > > > To: Ali Sajassi (sajassi) > > > Cc: Developing a hybrid router/bridge. > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge at postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > From Eric.Gray at marconi.com Tue Dec 12 13:17:51 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Tue, 12 Dec 2006 16:17:51 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017A8C@uspitsmsgusr08.win.marconi.com> Ali, Plug-and-play usually means configuration-free operation. -- Eric > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > Sent: Friday, December 08, 2006 12:02 AM > To: Gray, Eric; Don Fedyk > Cc: Developing a hybrid router/bridge.; Joe Touch > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Gray, > > Please let me know if my previous email doesn't answer your > question and > if it doesn't, then let me know which portion needs further > clarification. > > -Ali > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Sent: Thursday, December 07, 2006 8:01 AM > > To: Don Fedyk; Ali Sajassi (sajassi) > > Cc: Developing a hybrid router/bridge.; Joe Touch > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Don, > > > > And yet, someone (Ali Sajassi) asserted (in his message > > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues > > or additional complications with using 802.1ah in enterprises > > for plug-and-play applicability. > > > > Perhaps Ali can answer my question then. > > > > But, to more directly address your earlier comments: > > > > The TRILL WG has NOT come up with an encapsulation that > > "looks like" 802.1ah - unless someone squints really hard and > > tries to pretend that two separate Ethernet encapsulations - > > separated by a SHIM header - are one single encapsulation. > > > > That is not to say that the WG has done anything that > > could be said to disallow the use of 802.1ah encapsulation. > > It is just not obviously consistent with all of the WG goals > > to use _only_ 802.1ah encapsulation. > > > > -- > > Eric > > > > > -----Original Message----- > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > > Sent: Thursday, December 07, 2006 9:33 AM > > > To: Gray, Eric; Joe Touch; Ali Sajassi (sajassi) > > > Cc: Developing a hybrid router/bridge. > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > Hi Eric > > > > > > > -----Original Message----- > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > Sent: Thursday, December 07, 2006 8:38 AM Don, > > > > > > > > Thanks for doing this. As you can probably > attest, this is a > > > > non-trivial "digging" task to come up with this level of > > detail. I > > > > am not sure why Joe asked for it, but now that you have > > provided it, > > > > perhaps you can explain how values would be derived for > the B-TAG > > > > TCI/VID and I-TAG TCI/SID fields if we'd like to deploy this > > > > technology in > > > "plug-and-play" mode? > > > > > > I have not given much thought to plug-and-play. My advice > would be > > > learn the current semantics of the fields and see what they > > offer. I > > > don't see why these fields, which offer encapsulation, backwards > > > compatibility, Connectivity Fault Management (CFM) frames > > etc are any > > > worse than similar alternatives. > > > > > > Don > > > > > > > > > > > -- > > > > Eric > > > > > > > > > > > > > > From Eric.Gray at marconi.com Tue Dec 12 13:29:19 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Tue, 12 Dec 2006 16:29:19 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017AA0@uspitsmsgusr08.win.marconi.com> Silvano, IFF we were going to use 802.1ah, it could allow us to use the "back-bone" DA/SA for next-hop/previous-hop and the "customer" DA/SA for egress/ingress RBridges. But that would be using it in a way that is not consistent with the intended use of 802.1ah - simply because that usage would make use of the fields in a way that matches the way that your proposed "short-hand" SHIM header would use them. If you did that, there would be room for using the B-tag and I-tag as analogues of your I-VLAN and O-VLAN tags. I think this is a VERY BAD idea. -- Eric > -----Original Message----- > From: Silvano Gai [mailto:sgai at nuovasystems.com] > Sent: Friday, December 08, 2006 10:07 AM > To: Ali Sajassi (sajassi); Don Fedyk; Gray, Eric > Cc: Developing a hybrid router/bridge.; Joe Touch > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Ali, > > Inline: > > > -----Original Message----- > > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > > Sent: Thursday, December 07, 2006 9:23 PM > > To: Silvano Gai; Don Fedyk; Gray, Eric > > Cc: Developing a hybrid router/bridge.; Joe Touch > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > Silvano, > > > > > -----Original Message----- > > > From: Silvano Gai [mailto:sgai at nuovasystems.com] > > > Sent: Thursday, December 07, 2006 5:36 PM > > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi) > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. > > > There are advantages and disadvantages. > > > > > > The disadvantages are: > > > 1) Lack of Next-Hop addresses. We discussed this at length > > > during the last meeting and we didn't reach consensus on a > > > way to eliminate them. > > > > Can you refresh my memory for why we need a next-hop > address when the > > header carries both source and destination PE addresses and > when these > > addresses are learned in control plane ? > > > > Radia did in her reply > > > > 2) Lack of a TTL field (it may be added, but it is not > there today). > > > > Can probably be accommodated. > > > > > 3) Many unneeded fields and therefore larger frame overhead. > > > > > > > Such as ? > > The I-tag is not useful in TRILL and in contrast two addresses and the > TTL are missing. > > > > > > The advantages are: > > > 1) Larger addressable market for TRILL > > > > > > IMO if we stick with the WG charter the disadvantages clearly > > > outweigh the advantages. > > > > > > The WG can be re-chartered, but if we consider the Enterprise > > > and Data Center market, IEEE 802.1ah is an overkill. > > > > > > > If by overkill you mean a bit bigger header, then I agree > but look at > > all the other advantages that you get from using standard > IEEE header > > and shim including: > > - security Mgmt: MACSec/KeySec > > - Congestion Mgmt > > - Connectivity Fault Mgmt > > > > Has it been considered how these are going to work with TRILL shim > > header or are these outside of WG charter :-) > > > > -Ali > > > > > > > -- Silvano > > > > > > > > > > -----Original Message----- > > > > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] > > > On > > > > Behalf Of Don Fedyk > > > > Sent: Thursday, December 07, 2006 9:21 AM > > > > To: Gray, Eric; Ali Sajassi (sajassi) > > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > > > Hi Eric > > > > > > > > > -----Original Message----- > > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > > > > > Don, > > > > > > > > > > And yet, someone (Ali Sajassi) asserted (in his message > > > dated Wed > > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or > additional > > > > > complications with using 802.1ah in enterprises for > plug-and-play > > > > > applicability. > > > > > > > > > > Perhaps Ali can answer my question then. > > > > > > > > > > But, to more directly address your earlier comments: > > > > > > > > > > The TRILL WG has NOT come up with an encapsulation that > "looks > > > > > like" 802.1ah - unless someone squints really hard > and tries to > > > > > pretend that two separate Ethernet encapsulations - > > > separated by a > > > > > SHIM header - are one single encapsulation. > > > > > > > > To be fair Point to Point header that was discussed without > > > one of the > > > > shims was very close "functionally" (colloquial looks like) to > > > 802.1ah. > > > > My opinion is still we don't need several variations of > > > headers doing > > > > similar things. > > > > > > > > This was the slide that looked a lot like what I posted. > > > > > > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > > > > > > > Regards, > > > > Don > > > > > > > > > > That is not to say that the WG has done anything that > > > could be said > > > > > to disallow the use of 802.1ah encapsulation. > > > > > It is just not obviously consistent with all of the WG > > > goals to use > > > > > _only_ 802.1ah encapsulation. > > > > > > > > > > -- > > > > > Eric > > > > > > > > > > > > > _______________________________________________ > > > > rbridge mailing list > > > > rbridge at postel.org > > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > From Eric.Gray at marconi.com Tue Dec 12 13:37:59 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Tue, 12 Dec 2006 16:37:59 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017ABC@uspitsmsgusr08.win.marconi.com> Ali, I agree with your argument below in every sense. But I fail to see why that argument leads to a recommendation to use 802.1ah encapsulation. We were initially expecting to use 802.3 Ethernet encapsulation of a SHIM-encapsulated, tunneled Ethernet frame. That is a use of IEEE-conformant frame formats. -- Eric > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] > Sent: Sunday, December 10, 2006 6:07 PM > To: Radia.Perlman at sun.com > Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid > router/bridge.; Joe Touch > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > -----Original Message----- > > From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] > > Sent: Thursday, December 07, 2006 9:56 PM > > To: Ali Sajassi (sajassi) > > Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid > > router/bridge.; Joe Touch > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > Travelling again, so extremely limited access to email (as > > in, about 10 minutes here and there on a SLOW connection). > > Anyway, I'll answer some of these: > > Also sorry for not being able to respond to your email > earlier due to my > schedule/meetings (specially on Friday). > > > > > a) why "next hop" and "previous hop" in addition to > > "ultimate" source and destination > > > > At least one of the reasons is that if there are three > > RBridges on the same link, R1, R2, and R3, it is useful for > > R1 to choose which of R2 or R3 should receive the packet. It > > isn't obvious from the destination address because it could > > be that either R2 or R3 would be logical, and R1 is load > > splitting. Also, it helps focus traffic on the link, and > > ensure it doesn't get filtered, if the bridges on the link > > only need to learn R1, R2, and R3, especially since traffic > > from outside RBridges might arrive from different entry > > points onto the link. > > O.K., I remember now the discussion that we had during the > IETF meeting > on load balancing and next hop address. However, there are couple of > ways for achieving the same result. I mentioned briefly during the > meeting the use of VLAN for this purpose and someone else mentioned > using part of 48-bit provider MAC address for this purpose. > > > > > b) congestion management was explained to us, and it was what > > convinced us we needed "ultimate source RBridge" in order to > > know where to send the congestion notification. If you could > > explain the other things, we could see if there is a problem, > > but if they are similar to congestion notification, then > > having the ingress RBridge will accommodate them. > > > > With respect to CFM, connectivity fault mgmt is done in a hierarchical > way and it can be performed at the provider service instance level > (e.g., on a per I-SID basis) or it can be performed for group > of I-SIDs > on a per B-VLAN level. In both cases, provider MAC addresses are used > which makes the provider OAM control for customer data-traffic very > tight. You cannot get the same result by using OAM messages that use > customer MAC addresses and if you try to do it will be very > cumbersome. > > Basically what I am trying to point out is that by using non-IEEE > conformance frame format, you assume the responsibility for all the > features developed by IEEE; where as, if you use IEEE > conformant frame, > then one can concentrate on the control plane issues which I > thought was > the main objective of TRILL. > > -Ali > > > Sorry for ignoring all the other messages for now, but I only > > had a chance to read and respond to one message. > > > > Radia > > > > ----- Original Message ----- > > From: "Ali Sajassi (sajassi)" > > Date: Friday, December 8, 2006 10:53 am > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > > > Silvano, > > > > > > > -----Original Message----- > > > > From: Silvano Gai [sgai at nuovasystems.com] > > > > Sent: Thursday, December 07, 2006 5:36 PM > > > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi) > > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > > > > > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. > > > > There are advantages and disadvantages. > > > > > > > > The disadvantages are: > > > > 1) Lack of Next-Hop addresses. We discussed this at > length during > > > > the last meeting and we didn't reach consensus on a way > > to eliminate > > > > them. > > > > > > Can you refresh my memory for why we need a next-hop > > address when the > > > header carries both source and destination PE addresses and > > when these > > > addresses are learned in control plane ? > > > > > > > 2) Lack of a TTL field (it may be added, but it is not > > there today). > > > > > > Can probably be accommodated. > > > > > > > 3) Many unneeded fields and therefore larger frame overhead. > > > > > > > > > > Such as ? > > > > > > > The advantages are: > > > > 1) Larger addressable market for TRILL > > > > > > > > IMO if we stick with the WG charter the disadvantages clearly > > > > outweigh the advantages. > > > > > > > > The WG can be re-chartered, but if we consider the > Enterprise and > > > > Data Center market, IEEE 802.1ah is an overkill. > > > > > > > > > > If by overkill you mean a bit bigger header, then I agree > > but look at > > > all the other advantages that you get from using standard > > IEEE header > > > and shim including: > > > - security Mgmt: MACSec/KeySec > > > - Congestion Mgmt > > > - Connectivity Fault Mgmt > > > > > > Has it been considered how these are going to work with > TRILL shim > > > header or are these outside of WG charter :-) > > > > > > -Ali > > > > > > > > > > -- Silvano > > > > > > > > > > > > > -----Original Message----- > > > > > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] > > > > On > > > > > Behalf Of Don Fedyk > > > > > Sent: Thursday, December 07, 2006 9:21 AM > > > > > To: Gray, Eric; Ali Sajassi (sajassi) > > > > > Cc: Developing a hybrid router/bridge.; Joe Touch > > > > > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > > > > > > > Hi Eric > > > > > > > > > > > -----Original Message----- > > > > > > From: Gray, Eric [Eric.Gray at marconi.com] > > > > > > > > > > > > Don, > > > > > > > > > > > > And yet, someone (Ali Sajassi) asserted (in his message > > > > dated Wed > > > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or > > > additional > > > > > > complications with using 802.1ah in enterprises for > plug-and- > > > play > > > > > > applicability. > > > > > > > > > > > > Perhaps Ali can answer my question then. > > > > > > > > > > > > But, to more directly address your earlier comments: > > > > > > > > > > > > The TRILL WG has NOT come up with an encapsulation that > > > "looks > > > > > > like" 802.1ah - unless someone squints really hard and tries > > > to > > > > > > pretend that two separate Ethernet encapsulations - > > > > separated by a > > > > > > SHIM header - are one single encapsulation. > > > > > > > > > > To be fair Point to Point header that was discussed without > > > > one of the > > > > > shims was very close "functionally" (colloquial looks like) to > > > > 802.1ah. > > > > > My opinion is still we don't need several variations of > > > > headers doing > > > > > similar things. > > > > > > > > > > This was the slide that looked a lot like what I posted. > > > > > > > > > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm > > > > > > > > > > Regards, > > > > > Don > > > > > > > > > > > > That is not to say that the WG has done anything that > > > > could be said > > > > > > to disallow the use of 802.1ah encapsulation. > > > > > > It is just not obviously consistent with all of the WG > > > > goals to use > > > > > > _only_ 802.1ah encapsulation. > > > > > > > > > > > > -- > > > > > > Eric > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Eric.Gray at marconi.com Tue Dec 12 13:51:37 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Tue, 12 Dec 2006 16:51:37 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017AC8@uspitsmsgusr08.win.marconi.com> Joe, It's a huge drawback, and it requires configuration of at least IP addresses - possibly per-interface. That is not going to work very well as a plug-and-play solution. In addition, as you hint at, you're effectively now a part of the routing L3 network - as opposed to part of the bridging L2 network. It would make little sense - at that point - to try to differentiate RBridges from routers as it is already established that routers can be built and used in real networks. If you're building a box that acts like a router, then build a router. Nothing much for us to do in that case. -- Eric > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Tuesday, December 12, 2006 12:10 PM > To: Ali Sajassi (sajassi) > Cc: Silvano Gai; Radia.Perlman at sun.com; Don Fedyk; Gray, > Eric; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Use of 802.1ah Encaps > > > > Ali Sajassi (sajassi) wrote: > >... > >> Can you please describe the header you're considering an > >> alternative, e.g, where the current one is: > >> [outer ether [6-byte shim] [inner ether [payload]]] > > > > [outer ether][20-byte IP header][4 or 8 byte L2TPv3/GRE shim] > > [inner Ether [payload]] > > > > The draw back is the additional 20 bytes of IP header but > the advantage > > is that you can use the IGP as is :-) > > That's a fairly large drawback. > > Also, how might this affect an IP protocol running on links over which > rbridge nodes communicate? I.e., don't you have to de-conflict the IP > addresses and possibly also the IGP to avoid interference > between the two? > > Our system has a shim just inside the outer ether, i.e., using a > different ethertype; that effectively forces non-rbridge systems to > ignore the packets. > > Joe > > From gjc at inescporto.pt Wed Dec 13 08:34:48 2006 From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro) Date: Wed, 13 Dec 2006 16:34:48 +0000 Subject: [rbridge] IP data plane (Was: Use of 802.1ah Encaps) In-Reply-To: <0BF76B30C100624BA997C9CED19D812501017AC8@uspitsmsgusr08.win.marconi.com> References: <0BF76B30C100624BA997C9CED19D812501017AC8@uspitsmsgusr08.win.marconi.com> Message-ID: <1166027688.6321.16.camel@localhost> Hello, Sorry to intrude, I just wanted to play devil's advocate here.. ;-) On Ter, 2006-12-12 at 16:51 -0500, Gray, Eric wrote: > Joe, > > It's a huge drawback, and it requires configuration of > at least IP addresses - possibly per-interface. That is not > going to work very well as a plug-and-play solution. An IP based data plane does not imply that you need configuration, not even IP addresses on interfaces. Think of IP adhoc protocols (AODV/OLSR/etc.); they derive IP addresses from the L2 MAC address, or simply generate a random IP. > In addition, as you hint at, you're effectively now a > part of the routing L3 network - as opposed to part of the > bridging L2 network. It would make little sense - at that > point - to try to differentiate RBridges from routers as it > is already established that routers can be built and used > in real networks. There is still some advantage: normal routers need configuration, RBridges don't. But at the same time you can reuse existing IP forwarding blocks of routers. But if you are really looking for arguments against IP data plane: 1. Larger header size; 2. Larger (32-bits) addresses (vs. 16-bits of rbridge nick names); 3. Obfuscation, e.g. some fields are there but not used by RBridges (like fragmentation control). Regards, -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. From touch at ISI.EDU Wed Dec 13 09:14:53 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 13 Dec 2006 09:14:53 -0800 Subject: [rbridge] IP data plane (Was: Use of 802.1ah Encaps) In-Reply-To: <1166027688.6321.16.camel@localhost> References: <0BF76B30C100624BA997C9CED19D812501017AC8@uspitsmsgusr08.win.marconi.com> <1166027688.6321.16.camel@localhost> Message-ID: <4580350D.7030006@isi.edu> Gustavo J. A. M. Carneiro wrote: > Hello, > > Sorry to intrude, I just wanted to play devil's advocate here.. ;-) > > On Ter, 2006-12-12 at 16:51 -0500, Gray, Eric wrote: >> Joe, >> >> It's a huge drawback, and it requires configuration of >> at least IP addresses - possibly per-interface. That is not >> going to work very well as a plug-and-play solution. > > An IP based data plane does not imply that you need configuration, not > even IP addresses on interfaces. Think of IP adhoc protocols > (AODV/OLSR/etc.); they derive IP addresses from the L2 MAC address, or > simply generate a random IP. That works only if there is NO other IP traffic on that plane. We don't know that rbridges will talk to each other over dedicated paths that don't involve non-rbridge to non-rbridge traffic. In that case, the IP addresses sent on certain link addresses - notably multicast and broadcast - could interfere between rbridge use of those addresses and non-rbridge use of those addresses. -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061213/c292cfd8/signature.bin From dwfedyk at nortel.com Wed Dec 13 09:18:08 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 13 Dec 2006 12:18:08 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D812501017AA0@uspitsmsgusr08.win.marconi.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C6B7737@zrtphxm2.corp.nortel.com> Hi Eric This argument says if you use ANY standard header then it would be a bad idea. So you are creating a new forwarding paradigm and the down side of that as Ali pointed out is now you have to create most of the other things that go along with new forwarding paradigm. Don > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > Sent: Tuesday, December 12, 2006 4:29 PM > > Silvano, > > IFF we were going to use 802.1ah, it could allow us to > use the "back-bone" DA/SA for next-hop/previous-hop and the > "customer" DA/SA for egress/ingress RBridges. But that would > be using it in a way that is not consistent with the intended > use of 802.1ah - simply because that usage would make use of > the fields in a way that matches the way that your proposed > "short-hand" SHIM header would use them. > > If you did that, there would be room for using the B-tag > and I-tag as analogues of your I-VLAN and O-VLAN tags. > > I think this is a VERY BAD idea. > > -- > Eric From Eric.Gray at marconi.com Wed Dec 13 09:29:10 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Wed, 13 Dec 2006 12:29:10 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017BF4@uspitsmsgusr08.win.marconi.com> Don, I don't follow your reasoning. I certainly am not saying that using "ANY standard header" is a bad idea. As for "creating a new forwarding paradigm" - yes, we're doing a little bit of that. Ideally, we'll be doing as little of that as we can get away with. The "little bit" we have to do is to use some additional header information to: 1) forward frames on the shortest path between RBridges, and 2) reduce or eliminate potential looping of frames during a perturbation of the shortest path. This may be somewhat of a simplification, but that's fair in light of the general trend for casual observers to do the opposite. Currently, we define a SHIM to carry this information and we expect to use one or more "standard headers" to encapsulate frames being forwarded between RBridges. Does this make things clearer? -- Eric > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk at nortel.com] > Sent: Wednesday, December 13, 2006 12:18 PM > To: Gray, Eric; Silvano Gai > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > Sajassi (sajassi) > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Hi Eric > > This argument says if you use ANY standard header then it would be a bad > idea. > > So you are creating a new forwarding paradigm and the down side of that > as Ali pointed out is now you have to create most of the other things > that go along with new forwarding paradigm. > > Don > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Sent: Tuesday, December 12, 2006 4:29 PM > > > > Silvano, > > > > IFF we were going to use 802.1ah, it could allow us to > > use the "back-bone" DA/SA for next-hop/previous-hop and the > > "customer" DA/SA for egress/ingress RBridges. But that would > > be using it in a way that is not consistent with the intended > > use of 802.1ah - simply because that usage would make use of > > the fields in a way that matches the way that your proposed > > "short-hand" SHIM header would use them. > > > > If you did that, there would be room for using the B-tag > > and I-tag as analogues of your I-VLAN and O-VLAN tags. > > > > I think this is a VERY BAD idea. > > > > -- > > Eric > > From gjc at inescporto.pt Wed Dec 13 09:57:03 2006 From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro) Date: Wed, 13 Dec 2006 17:57:03 +0000 Subject: [rbridge] IP data plane (Was: Use of 802.1ah Encaps) In-Reply-To: <4580350D.7030006@isi.edu> References: <0BF76B30C100624BA997C9CED19D812501017AC8@uspitsmsgusr08.win.marconi.com> <1166027688.6321.16.camel@localhost> <4580350D.7030006@isi.edu> Message-ID: <1166032623.6321.24.camel@localhost> On Qua, 2006-12-13 at 09:14 -0800, Joe Touch wrote: > > Gustavo J. A. M. Carneiro wrote: > > Hello, > > > > Sorry to intrude, I just wanted to play devil's advocate here.. ;-) > > > > On Ter, 2006-12-12 at 16:51 -0500, Gray, Eric wrote: > >> Joe, > >> > >> It's a huge drawback, and it requires configuration of > >> at least IP addresses - possibly per-interface. That is not > >> going to work very well as a plug-and-play solution. > > > > An IP based data plane does not imply that you need configuration, not > > even IP addresses on interfaces. Think of IP adhoc protocols > > (AODV/OLSR/etc.); they derive IP addresses from the L2 MAC address, or > > simply generate a random IP. > > That works only if there is NO other IP traffic on that plane. We don't > know that rbridges will talk to each other over dedicated paths that > don't involve non-rbridge to non-rbridge traffic. > > In that case, the IP addresses sent on certain link addresses - notably > multicast and broadcast - could interfere between rbridge use of those > addresses and non-rbridge use of those addresses. Also not a problem: RBridges could use an IP data plane, but using a different EtherType, different from the usual 0x0800. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. From dwfedyk at nortel.com Wed Dec 13 10:19:23 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Wed, 13 Dec 2006 13:19:23 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D812501017BF4@uspitsmsgusr08.win.marconi.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C6B7864@zrtphxm2.corp.nortel.com> Hi Eric > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Don, > > I don't follow your reasoning. That's OK I cant follow you sometimes either ;-) > > I certainly am not saying that using "ANY standard header" > is a bad idea. Then why not start from ah? The bit that Silvano said was we could use ah and you said it is a bad idea. Please describe "BAD idea" then. > > As for "creating a new forwarding paradigm" - yes, we're > doing a little bit of that. Ideally, we'll be doing as little > of that as we can get away with. The "little bit" we have to > do is to use some additional header information to: > > 1) forward frames on the shortest path between RBridges, > and > 2) reduce or eliminate potential looping of frames during > a perturbation of the shortest path. You have so far chosen to do this in a mode that optimizes for mixed bridges at the cost of ignoring the effciencies you could get between directly connected Rbridges. 802.1ah opimizes forwarding for connected Provider Backbone Bridges and interworks with legacy at a common denominator. > > This may be somewhat of a simplification, but that's fair in > light of the general trend for casual observers to do the > opposite. > > Currently, we define a SHIM to carry this information and > we expect to use one or more "standard headers" to encapsulate > frames being forwarded between RBridges. > > Does this make things clearer? Eric I understand what is proposed but I still question if a greater synergy cannot be achieved between encapsulating headers. A shim is a not a typical solution but encapsulations are. Regards, Don > > -- > Eric > > > -----Original Message----- > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > Sent: Wednesday, December 13, 2006 12:18 PM > > To: Gray, Eric; Silvano Gai > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > > Sajassi (sajassi) > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Hi Eric > > > > This argument says if you use ANY standard header then it > would be a bad > > idea. > > > > So you are creating a new forwarding paradigm and the down > side of that > > as Ali pointed out is now you have to create most of the > other things > > that go along with new forwarding paradigm. > > > > Don > > > > > -----Original Message----- > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > Sent: Tuesday, December 12, 2006 4:29 PM > > > > > > Silvano, > > > > > > IFF we were going to use 802.1ah, it could allow us to > > > use the "back-bone" DA/SA for next-hop/previous-hop and the > > > "customer" DA/SA for egress/ingress RBridges. But that would > > > be using it in a way that is not consistent with the intended > > > use of 802.1ah - simply because that usage would make use of > > > the fields in a way that matches the way that your proposed > > > "short-hand" SHIM header would use them. > > > > > > If you did that, there would be room for using the B-tag > > > and I-tag as analogues of your I-VLAN and O-VLAN tags. > > > > > > I think this is a VERY BAD idea. > > > > > > -- > > > Eric > > > > > From Eric.Gray at marconi.com Wed Dec 13 16:00:39 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Wed, 13 Dec 2006 19:00:39 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D812501017CE3@uspitsmsgusr08.win.marconi.com> Don, I think you've garbled the discussion, somewhat. Please see below... -- Eric > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk at nortel.com] > Sent: Wednesday, December 13, 2006 1:19 PM > To: Gray, Eric > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > Sajassi (sajassi); Silvano Gai > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Hi Eric > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > Don, > > > > I don't follow your reasoning. > That's OK I cant follow you sometimes either ;-) > > > > > I certainly am not saying that using "ANY standard header" > > is a bad idea. > Then why not start from ah? The bit that Silvano said was we > could use ah and you said it is a bad idea. I don't think I am quoting too much out of context, when I quote the following from Silvano's reply to Joe Touch: SILVANO > My comment is that IEEE 802.1ah has no space for both SILVANO > the ultimate source/dest and the next hop source/dest. SILVANO > IEEE 802.1ah is designed for multiple enterprises to SILVANO > share a common metro backbone. It does a fine job in SILVANO > that area. It does not support well an arbitrary SILVANO > intermixing of Bridges and Rbridges. SILVANO > In contrast Trill does a fine job in supporting SILVANO > arbitrary topologies and mixing of RBridges and SILVANO > Bridges thanks to the availability of both the SILVANO > ultimate source/dest and the next hop source/dest. SILVANO > In TRILL the network between the "ingress" and SILVANO > "egress" RBridge isn't a single Ethernet (like in SILVANO > 802.1ah), but rather a sequence of RBridges that SILVANO > may be connected by Ethernets. SILVANO > Things look similar, but are substantially different. Given that this is what (I believe, at least) Silvano said about using 802.1ah, where do you get the impression that Silvano has said that "we could use ah"? > > Please describe "BAD idea" then. In this, I think quite a few of us are now in agreement. It is rarely a good idea to use a header format just because most of the bits look similar to one proposal that has all of the information you require. Suppose you started to think that using 802.1ah - because it is similar to an abbreviated combination of (MAC+SHIM)-in-MAC - was an example of one of the rare instances in which this might be a good idea. Wouldn't you suspect that the need to consider potentially adding a TTL field to the header might be an indication that you are probably wrong? So, to answer your question, a "BAD idea" is one that takes valuable resources to explore and offers no believable cause to suspect that it will work better than other ideas already on the table. In this case, we have reason to believe (MAC+SHIM)-in-MAC will work and no reason to believe that 802.1ah will work better - even assuming we went down that rat-hole. > > > > > As for "creating a new forwarding paradigm" - yes, we're > > doing a little bit of that. Ideally, we'll be doing as little > > of that as we can get away with. The "little bit" we have to > > do is to use some additional header information to: > > > > 1) forward frames on the shortest path between RBridges, > > and > > 2) reduce or eliminate potential looping of frames during > > a perturbation of the shortest path. > > You have so far chosen to do this in a mode that optimizes for mixed > bridges at the cost of ignoring the effciencies you could get between > directly connected Rbridges. 802.1ah opimizes forwarding for connected > Provider Backbone Bridges and interworks with legacy at a common > denominator. Right, and 802.1ah assumes either a green-field deployment, or a firmware modifiable deployment of PBB-(enabled/compatible) bridges. This is not consistent with our goals. > > > > > This may be somewhat of a simplification, but that's fair in > > light of the general trend for casual observers to do the > > opposite. > > > > Currently, we define a SHIM to carry this information and > > we expect to use one or more "standard headers" to encapsulate > > frames being forwarded between RBridges. > > > > Does this make things clearer? > > Eric I understand what is proposed but I still question if a greater > synergy cannot be achieved between encapsulating headers. A shim is a > not a typical solution but encapsulations are. Greater synergy is always demonstrably possible if you're willing to wait long enough. That's - for example - why we only have one link-state routing protocol, and why Ethernet was the one and only MAC-like format for L2 frames ever to have been used. What planet are we on? :-) > > Regards, > Don > > > > > > -- > > Eric > > > > > -----Original Message----- > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > > Sent: Wednesday, December 13, 2006 12:18 PM > > > To: Gray, Eric; Silvano Gai > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > > > Sajassi (sajassi) > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > Hi Eric > > > > > > This argument says if you use ANY standard header then it > > would be a bad > > > idea. > > > > > > So you are creating a new forwarding paradigm and the down > > side of that > > > as Ali pointed out is now you have to create most of the > > other things > > > that go along with new forwarding paradigm. > > > > > > Don > > > > > > > -----Original Message----- > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > Sent: Tuesday, December 12, 2006 4:29 PM > > > > > > > > Silvano, > > > > > > > > IFF we were going to use 802.1ah, it could allow us to > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the > > > > "customer" DA/SA for egress/ingress RBridges. But that would > > > > be using it in a way that is not consistent with the intended > > > > use of 802.1ah - simply because that usage would make use of > > > > the fields in a way that matches the way that your proposed > > > > "short-hand" SHIM header would use them. > > > > > > > > If you did that, there would be room for using the B-tag > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags. > > > > > > > > I think this is a VERY BAD idea. > > > > > > > > -- > > > > Eric > > > > > > > > > From gibanez at it.uc3m.es Wed Dec 13 22:33:57 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Thu, 14 Dec 2006 07:33:57 +0100 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D812501017CE3@uspitsmsgusr08.win.marconi.com> References: <0BF76B30C100624BA997C9CED19D812501017CE3@uspitsmsgusr08.win.marconi.com> Message-ID: <4580F055.2010800@it.uc3m.es> Just a side comment. I think the ongoing discussion is not about encapsulation but about the fundamentals of RBridges approach versus 802.1ah's. So, while agreeing on the great sinergies of a common encapsulation, lack of TTL is an essential point that reflects the essential difference in the deployment fields assumed. If we assume a deployment field as for 802.1ah, encapsulations and proposals much simpler than 802.1ah are possible (one is described in my ABridges draft). If this is the case we should restart WG discussion from the beguinning. Encapsulation for RBridges is not simple, and 802.1ah isn't simple either, specially considering the campus networks of moderate sizes that are the target for RBridges. Guillermo Gray, Eric escribi?: > Don, > > I think you've garbled the discussion, somewhat. > > Please see below... > > -- > Eric > > >> -----Original Message----- >> From: Don Fedyk [mailto:dwfedyk at nortel.com] >> Sent: Wednesday, December 13, 2006 1:19 PM >> To: Gray, Eric >> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali >> Sajassi (sajassi); Silvano Gai >> Subject: RE: [rbridge] Use of 802.1ah Encaps >> >> Hi Eric >> >> >>> -----Original Message----- >>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] >>> >>> Don, >>> >>> I don't follow your reasoning. >>> >> That's OK I cant follow you sometimes either ;-) >> >> >>> I certainly am not saying that using "ANY standard header" >>> is a bad idea. >>> >> Then why not start from ah? The bit that Silvano said was we >> could use ah and you said it is a bad idea. >> > > I don't think I am quoting too much out of context, when I quote > the following from Silvano's reply to Joe Touch: > > SILVANO > My comment is that IEEE 802.1ah has no space for both > SILVANO > the ultimate source/dest and the next hop source/dest. > > SILVANO > IEEE 802.1ah is designed for multiple enterprises to > SILVANO > share a common metro backbone. It does a fine job in > SILVANO > that area. It does not support well an arbitrary > SILVANO > intermixing of Bridges and Rbridges. > > SILVANO > In contrast Trill does a fine job in supporting > SILVANO > arbitrary topologies and mixing of RBridges and > SILVANO > Bridges thanks to the availability of both the > SILVANO > ultimate source/dest and the next hop source/dest. > > SILVANO > In TRILL the network between the "ingress" and > SILVANO > "egress" RBridge isn't a single Ethernet (like in > SILVANO > 802.1ah), but rather a sequence of RBridges that > SILVANO > may be connected by Ethernets. > > SILVANO > Things look similar, but are substantially different. > > Given that this is what (I believe, at least) Silvano said > about using 802.1ah, where do you get the impression that > Silvano has said that "we could use ah"? > > >> Please describe "BAD idea" then. >> > > In this, I think quite a few of us are now in agreement. > > It is rarely a good idea to use a header format just because > most of the bits look similar to one proposal that has all > of the information you require. > > Suppose you started to think that using 802.1ah - because it > is similar to an abbreviated combination of (MAC+SHIM)-in-MAC > - was an example of one of the rare instances in which this > might be a good idea. Wouldn't you suspect that the need to > consider potentially adding a TTL field to the header might > be an indication that you are probably wrong? > > So, to answer your question, a "BAD idea" is one that takes > valuable resources to explore and offers no believable cause > to suspect that it will work better than other ideas already > on the table. > > In this case, we have reason to believe (MAC+SHIM)-in-MAC > will work and no reason to believe that 802.1ah will work > better - even assuming we went down that rat-hole. > > >>> As for "creating a new forwarding paradigm" - yes, we're >>> doing a little bit of that. Ideally, we'll be doing as little >>> of that as we can get away with. The "little bit" we have to >>> do is to use some additional header information to: >>> >>> 1) forward frames on the shortest path between RBridges, >>> and >>> 2) reduce or eliminate potential looping of frames during >>> a perturbation of the shortest path. >>> >> You have so far chosen to do this in a mode that optimizes for mixed >> bridges at the cost of ignoring the effciencies you could get between >> directly connected Rbridges. 802.1ah opimizes forwarding for connected >> Provider Backbone Bridges and interworks with legacy at a common >> denominator. >> > > Right, and 802.1ah assumes either a green-field deployment, or a > firmware modifiable deployment of PBB-(enabled/compatible) bridges. > > This is not consistent with our goals. > > >>> This may be somewhat of a simplification, but that's fair in >>> light of the general trend for casual observers to do the >>> opposite. >>> >>> Currently, we define a SHIM to carry this information and >>> we expect to use one or more "standard headers" to encapsulate >>> frames being forwarded between RBridges. >>> >>> Does this make things clearer? >>> >> Eric I understand what is proposed but I still question if a greater >> synergy cannot be achieved between encapsulating headers. A shim is a >> not a typical solution but encapsulations are. >> > > Greater synergy is always demonstrably possible if you're willing > to wait long enough. > > That's - for example - why we only have one link-state routing > protocol, and why Ethernet was the one and only MAC-like format > for L2 frames ever to have been used. > > What planet are we on? :-) > > >> Regards, >> Don >> >> >> >>> -- >>> Eric >>> >>> >>>> -----Original Message----- >>>> From: Don Fedyk [mailto:dwfedyk at nortel.com] >>>> Sent: Wednesday, December 13, 2006 12:18 PM >>>> To: Gray, Eric; Silvano Gai >>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali >>>> Sajassi (sajassi) >>>> Subject: RE: [rbridge] Use of 802.1ah Encaps >>>> >>>> Hi Eric >>>> >>>> This argument says if you use ANY standard header then it >>>> >>> would be a bad >>> >>>> idea. >>>> >>>> So you are creating a new forwarding paradigm and the down >>>> >>> side of that >>> >>>> as Ali pointed out is now you have to create most of the >>>> >>> other things >>> >>>> that go along with new forwarding paradigm. >>>> >>>> Don >>>> >>>> >>>>> -----Original Message----- >>>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] >>>>> Sent: Tuesday, December 12, 2006 4:29 PM >>>>> >>>>> Silvano, >>>>> >>>>> IFF we were going to use 802.1ah, it could allow us to >>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the >>>>> "customer" DA/SA for egress/ingress RBridges. But that would >>>>> be using it in a way that is not consistent with the intended >>>>> use of 802.1ah - simply because that usage would make use of >>>>> the fields in a way that matches the way that your proposed >>>>> "short-hand" SHIM header would use them. >>>>> >>>>> If you did that, there would be room for using the B-tag >>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags. >>>>> >>>>> I think this is a VERY BAD idea. >>>>> >>>>> -- >>>>> Eric >>>>> >>>> >>>> >>>> > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From dwfedyk at nortel.com Thu Dec 14 07:47:53 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Thu, 14 Dec 2006 10:47:53 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <0BF76B30C100624BA997C9CED19D812501017CE3@uspitsmsgusr08.win.marconi.com> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C70CE79@zrtphxm2.corp.nortel.com> Hi Eric > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > Don, > > I think you've garbled the discussion, somewhat. > > Please see below... I'll answer inline here specifically. Thanks for providing more context. > > -- > Eric > > > -----Original Message----- > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > Sent: Wednesday, December 13, 2006 1:19 PM > > To: Gray, Eric > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > > Sajassi (sajassi); Silvano Gai > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > Hi Eric > > > > > -----Original Message----- > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > Don, > > > > > > I don't follow your reasoning. > > That's OK I cant follow you sometimes either ;-) > > > > > > > > I certainly am not saying that using "ANY standard header" > > > is a bad idea. > > Then why not start from ah? The bit that Silvano said was we > > could use ah and you said it is a bad idea. > > I don't think I am quoting too much out of context, when I quote > the following from Silvano's reply to Joe Touch: > > SILVANO > My comment is that IEEE 802.1ah has no space for both > SILVANO > the ultimate source/dest and the next hop source/dest. > > SILVANO > IEEE 802.1ah is designed for multiple enterprises to > SILVANO > share a common metro backbone. It does a fine job in > SILVANO > that area. It does not support well an arbitrary > SILVANO > intermixing of Bridges and Rbridges. > > SILVANO > In contrast Trill does a fine job in supporting > SILVANO > arbitrary topologies and mixing of RBridges and > SILVANO > Bridges thanks to the availability of both the > SILVANO > ultimate source/dest and the next hop source/dest. > > SILVANO > In TRILL the network between the "ingress" and > SILVANO > "egress" RBridge isn't a single Ethernet (like in > SILVANO > 802.1ah), but rather a sequence of RBridges that > SILVANO > may be connected by Ethernets. > > SILVANO > Things look similar, but are substantially different. > > Given that this is what (I believe, at least) Silvano said > about using 802.1ah, where do you get the impression that > Silvano has said that "we could use ah"? > > > > > Please describe "BAD idea" then. > > In this, I think quite a few of us are now in agreement. > > It is rarely a good idea to use a header format just because > most of the bits look similar to one proposal that has all > of the information you require. I agree. Bits on the wire looking just like other bits on the wire having different context are not good. > > Suppose you started to think that using 802.1ah - because it > is similar to an abbreviated combination of (MAC+SHIM)-in-MAC > - was an example of one of the rare instances in which this > might be a good idea. Wouldn't you suspect that the need to > consider potentially adding a TTL field to the header might > be an indication that you are probably wrong? Ahh this is what you mean. TTL is one method for a number of things, Loop mitigation, tracing, fault monitoring etc. It has pluses and minuses. Personally speaking as an individual I like TTL. Although I am also aware of many systems and I also built systems that are operational without TTL. TTL has shortcommings as well even in IP. It is not a bad tool for some applications. I know this group values it, I'm not suggesting you drop that goal or requirement. But a requiremetn for TTL alone does not mandate a licence to change everything either IMHO. > > So, to answer your question, a "BAD idea" is one that takes > valuable resources to explore and offers no believable cause > to suspect that it will work better than other ideas already > on the table. > > In this case, we have reason to believe (MAC+SHIM)-in-MAC > will work and no reason to believe that 802.1ah will work > better - even assuming we went down that rat-hole. > > > > > > > > > As for "creating a new forwarding paradigm" - yes, we're > > > doing a little bit of that. Ideally, we'll be doing as little > > > of that as we can get away with. The "little bit" we have to > > > do is to use some additional header information to: > > > > > > 1) forward frames on the shortest path between RBridges, > > > and > > > 2) reduce or eliminate potential looping of frames during > > > a perturbation of the shortest path. > > > > You have so far chosen to do this in a mode that optimizes for mixed > > bridges at the cost of ignoring the effciencies you could > get between > > directly connected Rbridges. 802.1ah opimizes forwarding > for connected > > Provider Backbone Bridges and interworks with legacy at a common > > denominator. > > Right, and 802.1ah assumes either a green-field deployment, or a > firmware modifiable deployment of PBB-(enabled/compatible) bridges. > > This is not consistent with our goals. But as Ali pointed out 802.1ah is backwards compatible with everything. On goals one goal of RBridge was to improve spanning tree by breaking up a large spanning tree with Rbridges providing interconnection of these smaller trees. A certain amount of insertion of Rbridges on shortest paths is required before this goal is realizable. I agree large provider networks are not your goal. And perhaps you are right that this justifies different technology but Ethernet did not get to high scale comodization by changing the forwarding paradigm. > > > > > > > > > This may be somewhat of a simplification, but that's fair in > > > light of the general trend for casual observers to do the > > > opposite. > > > > > > Currently, we define a SHIM to carry this information and > > > we expect to use one or more "standard headers" to encapsulate > > > frames being forwarded between RBridges. > > > > > > Does this make things clearer? > > > > Eric I understand what is proposed but I still question if a greater > > synergy cannot be achieved between encapsulating headers. > A shim is a > > not a typical solution but encapsulations are. > > Greater synergy is always demonstrably possible if you're willing > to wait long enough. > > That's - for example - why we only have one link-state routing > protocol, and why Ethernet was the one and only MAC-like format > for L2 frames ever to have been used. > > What planet are we on? :-) As an engineer I have to ask the question. "Is this the best we can do?" So even though history has proven that multiple implementations often result the question has to be asked never the less. Regards, Don > > > > > Regards, > > Don > > > > > > > > > > -- > > > Eric > > > > > > > -----Original Message----- > > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > > > Sent: Wednesday, December 13, 2006 12:18 PM > > > > To: Gray, Eric; Silvano Gai > > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > > > > Sajassi (sajassi) > > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > > > Hi Eric > > > > > > > > This argument says if you use ANY standard header then it > > > would be a bad > > > > idea. > > > > > > > > So you are creating a new forwarding paradigm and the down > > > side of that > > > > as Ali pointed out is now you have to create most of the > > > other things > > > > that go along with new forwarding paradigm. > > > > > > > > Don > > > > > > > > > -----Original Message----- > > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > Sent: Tuesday, December 12, 2006 4:29 PM > > > > > > > > > > Silvano, > > > > > > > > > > IFF we were going to use 802.1ah, it could allow us to > > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the > > > > > "customer" DA/SA for egress/ingress RBridges. But that would > > > > > be using it in a way that is not consistent with the intended > > > > > use of 802.1ah - simply because that usage would make use of > > > > > the fields in a way that matches the way that your proposed > > > > > "short-hand" SHIM header would use them. > > > > > > > > > > If you did that, there would be room for using the B-tag > > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags. > > > > > > > > > > I think this is a VERY BAD idea. > > > > > > > > > > -- > > > > > Eric > > > > > > > > > > > > > > From gibanez at it.uc3m.es Fri Dec 15 03:27:03 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Fri, 15 Dec 2006 12:27:03 +0100 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <4580F055.2010800@it.uc3m.es> References: <0BF76B30C100624BA997C9CED19D812501017CE3@uspitsmsgusr08.win.marconi.com> <4580F055.2010800@it.uc3m.es> Message-ID: <45828687.3050707@it.uc3m.es> My previous message perhaps was not too clear. Please bear with me and my english :-) - 802.1ah assumes no legacy bridges in the middle. - AFAK, 802.1ah does not assume routing between nodes. If so, it would likely require TTL field. - TRILL does assume legacy bridges between RBridges - TRILL is not a subset of 802.1ah, it is different thing - 802.1ah is not a example of simplicity. - It is too late to question TRILL basic assumptions and try to merge 802.1ah with TRILL encapsulation. - If the whole TRILL approach is questioned (I assume it is not the case), 802.1ah does not seem the way to go regarding simplicity in campus networks. Guillermo Guillermo Ib??ez escribi?: > Just a side comment. > I think the ongoing discussion is not about encapsulation but about the > fundamentals of RBridges approach versus 802.1ah's. So, while agreeing > on the great sinergies of a common encapsulation, lack of TTL is an > essential point that reflects the essential difference in the deployment > fields assumed. > If we assume a deployment field as for 802.1ah, encapsulations and > proposals much simpler than 802.1ah are possible (one is described in my > ABridges draft). If this is the case we should restart WG discussion > from the beguinning. > Encapsulation for RBridges is not simple, and 802.1ah isn't simple > either, specially considering the campus networks of moderate sizes that > are the target for RBridges. > Guillermo > > > Gray, Eric escribi?: >> Don, >> >> I think you've garbled the discussion, somewhat. >> >> Please see below... >> >> -- >> Eric >> >> >>> -----Original Message----- >>> From: Don Fedyk [mailto:dwfedyk at nortel.com] >>> Sent: Wednesday, December 13, 2006 1:19 PM >>> To: Gray, Eric >>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali >>> Sajassi (sajassi); Silvano Gai >>> Subject: RE: [rbridge] Use of 802.1ah Encaps >>> >>> Hi Eric >>> >>> >>>> -----Original Message----- >>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] >>>> >>>> Don, >>>> >>>> I don't follow your reasoning. >>>> >>> That's OK I cant follow you sometimes either ;-) >>> >>> >>>> I certainly am not saying that using "ANY standard header" >>>> is a bad idea. >>>> >>> Then why not start from ah? The bit that Silvano said was we >>> could use ah and you said it is a bad idea. >>> >> I don't think I am quoting too much out of context, when I quote >> the following from Silvano's reply to Joe Touch: >> >> SILVANO > My comment is that IEEE 802.1ah has no space for both >> SILVANO > the ultimate source/dest and the next hop source/dest. >> >> SILVANO > IEEE 802.1ah is designed for multiple enterprises to >> SILVANO > share a common metro backbone. It does a fine job in >> SILVANO > that area. It does not support well an arbitrary >> SILVANO > intermixing of Bridges and Rbridges. >> >> SILVANO > In contrast Trill does a fine job in supporting >> SILVANO > arbitrary topologies and mixing of RBridges and >> SILVANO > Bridges thanks to the availability of both the >> SILVANO > ultimate source/dest and the next hop source/dest. >> >> SILVANO > In TRILL the network between the "ingress" and >> SILVANO > "egress" RBridge isn't a single Ethernet (like in >> SILVANO > 802.1ah), but rather a sequence of RBridges that >> SILVANO > may be connected by Ethernets. >> >> SILVANO > Things look similar, but are substantially different. >> >> Given that this is what (I believe, at least) Silvano said >> about using 802.1ah, where do you get the impression that >> Silvano has said that "we could use ah"? >> >> >>> Please describe "BAD idea" then. >>> >> In this, I think quite a few of us are now in agreement. >> >> It is rarely a good idea to use a header format just because >> most of the bits look similar to one proposal that has all >> of the information you require. >> >> Suppose you started to think that using 802.1ah - because it >> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC >> - was an example of one of the rare instances in which this >> might be a good idea. Wouldn't you suspect that the need to >> consider potentially adding a TTL field to the header might >> be an indication that you are probably wrong? >> >> So, to answer your question, a "BAD idea" is one that takes >> valuable resources to explore and offers no believable cause >> to suspect that it will work better than other ideas already >> on the table. >> >> In this case, we have reason to believe (MAC+SHIM)-in-MAC >> will work and no reason to believe that 802.1ah will work >> better - even assuming we went down that rat-hole. >> >> >>>> As for "creating a new forwarding paradigm" - yes, we're >>>> doing a little bit of that. Ideally, we'll be doing as little >>>> of that as we can get away with. The "little bit" we have to >>>> do is to use some additional header information to: >>>> >>>> 1) forward frames on the shortest path between RBridges, >>>> and >>>> 2) reduce or eliminate potential looping of frames during >>>> a perturbation of the shortest path. >>>> >>> You have so far chosen to do this in a mode that optimizes for mixed >>> bridges at the cost of ignoring the effciencies you could get between >>> directly connected Rbridges. 802.1ah opimizes forwarding for connected >>> Provider Backbone Bridges and interworks with legacy at a common >>> denominator. >>> >> Right, and 802.1ah assumes either a green-field deployment, or a >> firmware modifiable deployment of PBB-(enabled/compatible) bridges. >> >> This is not consistent with our goals. >> >> >>>> This may be somewhat of a simplification, but that's fair in >>>> light of the general trend for casual observers to do the >>>> opposite. >>>> >>>> Currently, we define a SHIM to carry this information and >>>> we expect to use one or more "standard headers" to encapsulate >>>> frames being forwarded between RBridges. >>>> >>>> Does this make things clearer? >>>> >>> Eric I understand what is proposed but I still question if a greater >>> synergy cannot be achieved between encapsulating headers. A shim is a >>> not a typical solution but encapsulations are. >>> >> Greater synergy is always demonstrably possible if you're willing >> to wait long enough. >> >> That's - for example - why we only have one link-state routing >> protocol, and why Ethernet was the one and only MAC-like format >> for L2 frames ever to have been used. >> >> What planet are we on? :-) >> >> >>> Regards, >>> Don >>> >>> >>> >>>> -- >>>> Eric >>>> >>>> >>>>> -----Original Message----- >>>>> From: Don Fedyk [mailto:dwfedyk at nortel.com] >>>>> Sent: Wednesday, December 13, 2006 12:18 PM >>>>> To: Gray, Eric; Silvano Gai >>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali >>>>> Sajassi (sajassi) >>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps >>>>> >>>>> Hi Eric >>>>> >>>>> This argument says if you use ANY standard header then it >>>>> >>>> would be a bad >>>> >>>>> idea. >>>>> >>>>> So you are creating a new forwarding paradigm and the down >>>>> >>>> side of that >>>> >>>>> as Ali pointed out is now you have to create most of the >>>>> >>>> other things >>>> >>>>> that go along with new forwarding paradigm. >>>>> >>>>> Don >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] >>>>>> Sent: Tuesday, December 12, 2006 4:29 PM >>>>>> >>>>>> Silvano, >>>>>> >>>>>> IFF we were going to use 802.1ah, it could allow us to >>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the >>>>>> "customer" DA/SA for egress/ingress RBridges. But that would >>>>>> be using it in a way that is not consistent with the intended >>>>>> use of 802.1ah - simply because that usage would make use of >>>>>> the fields in a way that matches the way that your proposed >>>>>> "short-hand" SHIM header would use them. >>>>>> >>>>>> If you did that, there would be room for using the B-tag >>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags. >>>>>> >>>>>> I think this is a VERY BAD idea. >>>>>> >>>>>> -- >>>>>> Eric >>>>>> >>>>> >>>>> >>>>> >> _______________________________________________ >> 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 Eric.Gray at marconi.com Fri Dec 15 08:54:45 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Fri, 15 Dec 2006 11:54:45 -0500 Subject: [rbridge] TTL use - (was Use of 802.1ah Encaps) Message-ID: <0BF76B30C100624BA997C9CED19D8125010E01E1@uspitsmsgusr08.win.marconi.com> Don, I believe the key reason why we've more or less locked on to using TTL for loop mitigation of (at least) unicast frame forwarding is that the formation of temporary loops is hard to avoid using existing link state routing protocols. We've agreed - at least in principle - to adopt whatever comes out of the routing working group's efforts to avoid loop formation (micro- loop formation in particular), but this does not appear to rid us of that problem. Yes, other loop mitigation techniques have been discussed previously but TTL is the one with which most of us have more experience. There are also loop-prevention techniques such as may be achieved using STP and/or one of various signaling approaches. At present, we are not - on the whole - considering any of these approaches for work by the TRILL working group. Most exist now but would require (potentially major) modification, or are in progress elsewhere (for other - possibly incompatible - purposes). -- Eric (part of your previous message is included below) > > Ahh this is what you mean. TTL is one method for a number of things, > Loop mitigation, tracing, fault monitoring etc. It has pluses and > minuses. Personally speaking as an individual I like TTL. Although > I am > also aware of many systems and I also built systems that are > operational without TTL. TTL has shortcommings as well even in IP. > It is not a bad tool for some applications. I know this group values > it, I'm not suggesting you drop that goal or requirement. But a > [requirement] for TTL alone does not mandate a licence to change > everything either IMHO. > From Eric.Gray at marconi.com Fri Dec 15 08:54:29 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Fri, 15 Dec 2006 11:54:29 -0500 Subject: [rbridge] Use of 802.1ah Encaps Message-ID: <0BF76B30C100624BA997C9CED19D8125010E01E0@uspitsmsgusr08.win.marconi.com> Don, I will reply to your points in separate threads: - TTL Use - Breaking up Spanning Trees - Synergy > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk at nortel.com] > Sent: Thursday, December 14, 2006 10:48 AM > To: Gray, Eric > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > Sajassi (sajassi); Silvano Gai > Subject: RE: [rbridge] Use of 802.1ah Encaps > > Hi Eric > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > Don, > > > > I think you've garbled the discussion, somewhat. > > > > Please see below... > I'll answer inline here specifically. Thanks for providing > more context. > > > > > -- > > Eric > > > > > -----Original Message----- > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > > Sent: Wednesday, December 13, 2006 1:19 PM > > > To: Gray, Eric > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > > > Sajassi (sajassi); Silvano Gai > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > Hi Eric > > > > > > > -----Original Message----- > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > > > Don, > > > > > > > > I don't follow your reasoning. > > > That's OK I cant follow you sometimes either ;-) > > > > > > > > > > > I certainly am not saying that using "ANY > standard header" > > > > is a bad idea. > > > Then why not start from ah? The bit that Silvano said was we > > > could use ah and you said it is a bad idea. > > > > I don't think I am quoting too much out of context, when I quote > > the following from Silvano's reply to Joe Touch: > > > > SILVANO > My comment is that IEEE 802.1ah has no space for both > > SILVANO > the ultimate source/dest and the next hop source/dest. > > > > SILVANO > IEEE 802.1ah is designed for multiple enterprises to > > SILVANO > share a common metro backbone. It does a fine job in > > SILVANO > that area. It does not support well an arbitrary > > SILVANO > intermixing of Bridges and Rbridges. > > > > SILVANO > In contrast Trill does a fine job in supporting > > SILVANO > arbitrary topologies and mixing of RBridges and > > SILVANO > Bridges thanks to the availability of both the > > SILVANO > ultimate source/dest and the next hop source/dest. > > > > SILVANO > In TRILL the network between the "ingress" and > > SILVANO > "egress" RBridge isn't a single Ethernet (like in > > SILVANO > 802.1ah), but rather a sequence of RBridges that > > SILVANO > may be connected by Ethernets. > > > > SILVANO > Things look similar, but are substantially different. > > > > Given that this is what (I believe, at least) Silvano said > > about using 802.1ah, where do you get the impression that > > Silvano has said that "we could use ah"? > > > > > > > > Please describe "BAD idea" then. > > > > In this, I think quite a few of us are now in agreement. > > > > It is rarely a good idea to use a header format just because > > most of the bits look similar to one proposal that has all > > of the information you require. > > I agree. Bits on the wire looking just like other bits on the wire > having different context are not good. > > > > > Suppose you started to think that using 802.1ah - because it > > is similar to an abbreviated combination of (MAC+SHIM)-in-MAC > > - was an example of one of the rare instances in which this > > might be a good idea. Wouldn't you suspect that the need to > > consider potentially adding a TTL field to the header might > > be an indication that you are probably wrong? > > Ahh this is what you mean. TTL is one method for a number of things, > Loop mitigation, tracing, fault monitoring etc. It has pluses and > minuses. Personally speaking as an individual I like TTL. > Although I am > also aware of many systems and I also built systems that are > operational > without TTL. TTL has shortcommings as well even in IP. It is > not a bad > tool for some applications. I know this group values it, I'm not > suggesting you drop that goal or requirement. But a > requiremetn for TTL > alone does not mandate a licence to change everything either IMHO. > > > > > So, to answer your question, a "BAD idea" is one that takes > > valuable resources to explore and offers no believable cause > > to suspect that it will work better than other ideas already > > on the table. > > > > In this case, we have reason to believe (MAC+SHIM)-in-MAC > > will work and no reason to believe that 802.1ah will work > > better - even assuming we went down that rat-hole. > > > > > > > > > > > > > As for "creating a new forwarding paradigm" - yes, we're > > > > doing a little bit of that. Ideally, we'll be doing as little > > > > of that as we can get away with. The "little bit" we have to > > > > do is to use some additional header information to: > > > > > > > > 1) forward frames on the shortest path between RBridges, > > > > and > > > > 2) reduce or eliminate potential looping of > frames during > > > > a perturbation of the shortest path. > > > > > > You have so far chosen to do this in a mode that > optimizes for mixed > > > bridges at the cost of ignoring the effciencies you could > > get between > > > directly connected Rbridges. 802.1ah opimizes forwarding > > for connected > > > Provider Backbone Bridges and interworks with legacy at a common > > > denominator. > > > > Right, and 802.1ah assumes either a green-field deployment, or a > > firmware modifiable deployment of PBB-(enabled/compatible) bridges. > > > > This is not consistent with our goals. > > But as Ali pointed out 802.1ah is backwards compatible with > everything. > On goals one goal of RBridge was to improve spanning tree by > breaking up > a large spanning tree with Rbridges providing interconnection of these > smaller trees. A certain amount of insertion of Rbridges on shortest > paths is required before this goal is realizable. I agree large > provider networks are not your goal. And perhaps you are > right that this > justifies different technology but Ethernet did not get to high scale > comodization by changing the forwarding paradigm. > > > > > > > > > > > > > This may be somewhat of a simplification, but that's fair in > > > > light of the general trend for casual observers to do the > > > > opposite. > > > > > > > > Currently, we define a SHIM to carry this > information and > > > > we expect to use one or more "standard headers" to encapsulate > > > > frames being forwarded between RBridges. > > > > > > > > Does this make things clearer? > > > > > > Eric I understand what is proposed but I still question > if a greater > > > synergy cannot be achieved between encapsulating headers. > > A shim is a > > > not a typical solution but encapsulations are. > > > > Greater synergy is always demonstrably possible if you're willing > > to wait long enough. > > > > That's - for example - why we only have one link-state routing > > protocol, and why Ethernet was the one and only MAC-like format > > for L2 frames ever to have been used. > > > > What planet are we on? :-) > As an engineer I have to ask the question. "Is this the best > we can do?" > So even though history has proven that multiple implementations often > result the question has to be asked never the less. > > Regards, > Don > > > > > > > > > > Regards, > > > Don > > > > > > > > > > > > > > -- > > > > Eric > > > > > > > > > -----Original Message----- > > > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > > > > Sent: Wednesday, December 13, 2006 12:18 PM > > > > > To: Gray, Eric; Silvano Gai > > > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > > > > > Sajassi (sajassi) > > > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > > > > > Hi Eric > > > > > > > > > > This argument says if you use ANY standard header then it > > > > would be a bad > > > > > idea. > > > > > > > > > > So you are creating a new forwarding paradigm and the down > > > > side of that > > > > > as Ali pointed out is now you have to create most of the > > > > other things > > > > > that go along with new forwarding paradigm. > > > > > > > > > > Don > > > > > > > > > > > -----Original Message----- > > > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > Sent: Tuesday, December 12, 2006 4:29 PM > > > > > > > > > > > > Silvano, > > > > > > > > > > > > IFF we were going to use 802.1ah, it could allow us to > > > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the > > > > > > "customer" DA/SA for egress/ingress RBridges. But > that would > > > > > > be using it in a way that is not consistent with > the intended > > > > > > use of 802.1ah - simply because that usage would > make use of > > > > > > the fields in a way that matches the way that your proposed > > > > > > "short-hand" SHIM header would use them. > > > > > > > > > > > > If you did that, there would be room for using the B-tag > > > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags. > > > > > > > > > > > > I think this is a VERY BAD idea. > > > > > > > > > > > > -- > > > > > > Eric > > > > > > > > > > > > > > > > > > > > From Eric.Gray at marconi.com Fri Dec 15 08:54:59 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Fri, 15 Dec 2006 11:54:59 -0500 Subject: [rbridge] Synergy - (Was Use of 802.1ah Encaps) Message-ID: <0BF76B30C100624BA997C9CED19D8125010E01E3@uspitsmsgusr08.win.marconi.com> Don, For good or bad, we don't live in a world ruled by engineering goals. It is arguable that - if we did - we would _almost_ have perfected the wheel by now... :-) -- Eric (part of our earlier dialogue is included below I said: > > Greater synergy is always demonstrably possible if you're willing > > to wait long enough. > > > > That's - for example - why we only have one link-state routing > > protocol, and why Ethernet was the one and only MAC-like format > > for L2 frames ever to have been used. > > > > What planet are we on? :-) You said: > As an engineer I have to ask the question. "Is this the best we can do?" > So even though history has proven that multiple implementations often > result the question has to be asked never the less. > From Eric.Gray at marconi.com Fri Dec 15 08:54:56 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Fri, 15 Dec 2006 11:54:56 -0500 Subject: [rbridge] Breaking up of Spanning Trees - (Was Use of 802.1ah Encaps) Message-ID: <0BF76B30C100624BA997C9CED19D8125010E01E2@uspitsmsgusr08.win.marconi.com> Don, We (the TRILL working group) are not completely decided on this, and how we can make it work in the face of other things we also have to make work. Yes, we want to break up the spanning trees, but we also are being asked to address certain issues that arise as a result of doing so. In particular, there is a "wiring closet" problem that we have been assured is one we MUST solve. The (currently?) leading proposal for how to deal with that is to have (some?) RBridges participate in spanning tree protocol in such a way as to cause "wiring closet" bridges to see (at least part of) the RBridge "CRED" as a single bridge (with that bridge set up to be the root bridge). I am pretty sure (at this point) that this will be a configurable option which will not be "on" by default. I think the reasoning for this is that it would be okay to have a configuration requirement that would only require configuration if it is necessary to solve this problem - hence it remains possible to have a plug-and-play solution. However, this particular problem points out a potential "general class" of problems relating to breaking up spanning trees. And we do not currently have a "correctness proof" - or even a good try at one - that might lead us to believe that we do not have further issues to address, except by turning this "breaking up" feature off. For example, one model for RBridge interactions - that has been considered from very early on - is one where a "CRED" appears to existing 802. bridges as a single bridge. This model does not suffer from the above "general class" of problems, because it does not actually break up the spanning trees. All of the fractional LANs separated by RBridges will see each other in spanning tree protocol if this model is used. As a direct consequence, it may turn out that we will be required to support - at least as a configurable option - that RBridges do not break up spanning trees. I believe there is a lot of work that needs to be done if this is the case... -- Eric (part of your earlier message included the following) > > But as Ali pointed out 802.1ah is backwards compatible with > everything. On goals one goal of RBridge was to improve > spanning tree by breaking up a large spanning tree with > Rbridges providing interconnection of these smaller trees. > A certain amount of insertion of Rbridges on shortest paths > is required before this goal is realizable. I agree large > provider networks are not your goal. And perhaps you are > right that this justifies different technology but Ethernet > did not get to high scale [commoditization] by changing the > forwarding paradigm. > > > > > > > > > > > > > This may be somewhat of a simplification, but that's fair in > > > > light of the general trend for casual observers to do the > > > > opposite. > > > > > > > > Currently, we define a SHIM to carry this > information and > > > > we expect to use one or more "standard headers" to encapsulate > > > > frames being forwarded between RBridges. > > > > > > > > Does this make things clearer? > > > > > > Eric I understand what is proposed but I still question > if a greater > > > synergy cannot be achieved between encapsulating headers. > > A shim is a > > > not a typical solution but encapsulations are. > > > > Greater synergy is always demonstrably possible if you're willing > > to wait long enough. > > > > That's - for example - why we only have one link-state routing > > protocol, and why Ethernet was the one and only MAC-like format > > for L2 frames ever to have been used. > > > > What planet are we on? :-) > As an engineer I have to ask the question. "Is this the best > we can do?" > So even though history has proven that multiple implementations often > result the question has to be asked never the less. > > Regards, > Don > > > > > > > > > > Regards, > > > Don > > > > > > > > > > > > > > -- > > > > Eric > > > > > > > > > -----Original Message----- > > > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] > > > > > Sent: Wednesday, December 13, 2006 12:18 PM > > > > > To: Gray, Eric; Silvano Gai > > > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > > > > > Sajassi (sajassi) > > > > > Subject: RE: [rbridge] Use of 802.1ah Encaps > > > > > > > > > > Hi Eric > > > > > > > > > > This argument says if you use ANY standard header then it > > > > would be a bad > > > > > idea. > > > > > > > > > > So you are creating a new forwarding paradigm and the down > > > > side of that > > > > > as Ali pointed out is now you have to create most of the > > > > other things > > > > > that go along with new forwarding paradigm. > > > > > > > > > > Don > > > > > > > > > > > -----Original Message----- > > > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] > > > > > > Sent: Tuesday, December 12, 2006 4:29 PM > > > > > > > > > > > > Silvano, > > > > > > > > > > > > IFF we were going to use 802.1ah, it could allow us to > > > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the > > > > > > "customer" DA/SA for egress/ingress RBridges. But > that would > > > > > > be using it in a way that is not consistent with > the intended > > > > > > use of 802.1ah - simply because that usage would > make use of > > > > > > the fields in a way that matches the way that your proposed > > > > > > "short-hand" SHIM header would use them. > > > > > > > > > > > > If you did that, there would be room for using the B-tag > > > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags. > > > > > > > > > > > > I think this is a VERY BAD idea. > > > > > > > > > > > > -- > > > > > > Eric > > > > > > > > > > > > > > > > > > > > From dwfedyk at nortel.com Fri Dec 15 09:37:11 2006 From: dwfedyk at nortel.com (Don Fedyk) Date: Fri, 15 Dec 2006 12:37:11 -0500 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <45828687.3050707@it.uc3m.es> Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40C75D3E1@zrtphxm2.corp.nortel.com> Hi Guillermo See Inline. > -----Original Message----- > From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] > > > My previous message perhaps was not too clear. Please bear > with me and > my english :-) > - 802.1ah assumes no legacy bridges in the middle. This is false. 802.1ah is backwards compatible with legacy bridges. However I think it would be safe to say this is not a plug and play option. 802.1ah would need to be configured to know the legacy bridges capabilities. But 802.1ah header is compatible with 802.1Q header for forwarding. The same trick that a TRILL RBridge uses. > - AFAK, 802.1ah does not assume routing between nodes. If so, > it would > likely require TTL field. 802.1ah bridges from ingress to egress PBB nodes. Whether the service is IP or Ethernet on the ingress/egress PBB is a box question not outside the scope of 802.1ah architecture. > - TRILL does assume legacy bridges between Rbridges > - TRILL is not a subset of 802.1ah, it is different thing I don't think people ever said TRILL was a subset of 802.1ah. What I said was certain versions of the TRILL header look remarkably like the 802.1ah header. Following this logic I then said start from 802.1ah. This has not yielded any results because the part that looks like 802.1ah is hop by hop part and 802.1ah does not have a hop by hop DA part. > - 802.1ah is not a example of simplicity. I don't think this type of generalization adds any value. We are talking headers and every field in 802.1ah has a purpose and good value for the bits. > - It is too late to question TRILL basic assumptions and try to merge > 802.1ah with TRILL encapsulation. If you asked me if I see value in merging right now I would say no since the point to point header is not mainstream TRILL. > - If the whole TRILL approach is questioned (I assume it is not the > case), 802.1ah does not seem the way to go regarding simplicity in > campus networks. No one suggested you put a provider backbone bridge in place of an Rbridge. The comment was could you use the same Frame format for the packet encaps and related functions? And that is not looking promising. Regards, Don > Guillermo > > Guillermo Ib??ez escribi?: > > Just a side comment. > > I think the ongoing discussion is not about encapsulation > but about the > > fundamentals of RBridges approach versus 802.1ah's. So, > while agreeing > > on the great sinergies of a common encapsulation, lack of > TTL is an > > essential point that reflects the essential difference in > the deployment > > fields assumed. > > If we assume a deployment field as for 802.1ah, encapsulations and > > proposals much simpler than 802.1ah are possible (one is > described in my > > ABridges draft). If this is the case we should restart WG > discussion > > from the beguinning. > > Encapsulation for RBridges is not simple, and 802.1ah isn't simple > > either, specially considering the campus networks of > moderate sizes that > > are the target for RBridges. > > Guillermo > > > > > > Gray, Eric escribi?: > >> Don, > >> > >> I think you've garbled the discussion, somewhat. > >> > >> Please see below... > >> > >> -- > >> Eric > >> > >> > >>> -----Original Message----- > >>> From: Don Fedyk [mailto:dwfedyk at nortel.com] > >>> Sent: Wednesday, December 13, 2006 1:19 PM > >>> To: Gray, Eric > >>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > >>> Sajassi (sajassi); Silvano Gai > >>> Subject: RE: [rbridge] Use of 802.1ah Encaps > >>> > >>> Hi Eric > >>> > >>> > >>>> -----Original Message----- > >>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] > >>>> > >>>> Don, > >>>> > >>>> I don't follow your reasoning. > >>>> > >>> That's OK I cant follow you sometimes either ;-) > >>> > >>> > >>>> I certainly am not saying that using "ANY standard header" > >>>> is a bad idea. > >>>> > >>> Then why not start from ah? The bit that Silvano said was we > >>> could use ah and you said it is a bad idea. > >>> > >> I don't think I am quoting too much out of context, when I quote > >> the following from Silvano's reply to Joe Touch: > >> > >> SILVANO > My comment is that IEEE 802.1ah has no space for both > >> SILVANO > the ultimate source/dest and the next hop source/dest. > >> > >> SILVANO > IEEE 802.1ah is designed for multiple enterprises to > >> SILVANO > share a common metro backbone. It does a fine job in > >> SILVANO > that area. It does not support well an arbitrary > >> SILVANO > intermixing of Bridges and Rbridges. > >> > >> SILVANO > In contrast Trill does a fine job in supporting > >> SILVANO > arbitrary topologies and mixing of RBridges and > >> SILVANO > Bridges thanks to the availability of both the > >> SILVANO > ultimate source/dest and the next hop source/dest. > >> > >> SILVANO > In TRILL the network between the "ingress" and > >> SILVANO > "egress" RBridge isn't a single Ethernet (like in > >> SILVANO > 802.1ah), but rather a sequence of RBridges that > >> SILVANO > may be connected by Ethernets. > >> > >> SILVANO > Things look similar, but are substantially different. > >> > >> Given that this is what (I believe, at least) Silvano said > >> about using 802.1ah, where do you get the impression that > >> Silvano has said that "we could use ah"? > >> > >> > >>> Please describe "BAD idea" then. > >>> > >> In this, I think quite a few of us are now in agreement. > >> > >> It is rarely a good idea to use a header format just because > >> most of the bits look similar to one proposal that has all > >> of the information you require. > >> > >> Suppose you started to think that using 802.1ah - because it > >> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC > >> - was an example of one of the rare instances in which this > >> might be a good idea. Wouldn't you suspect that the need to > >> consider potentially adding a TTL field to the header might > >> be an indication that you are probably wrong? > >> > >> So, to answer your question, a "BAD idea" is one that takes > >> valuable resources to explore and offers no believable cause > >> to suspect that it will work better than other ideas already > >> on the table. > >> > >> In this case, we have reason to believe (MAC+SHIM)-in-MAC > >> will work and no reason to believe that 802.1ah will work > >> better - even assuming we went down that rat-hole. > >> > >> > >>>> As for "creating a new forwarding paradigm" - yes, we're > >>>> doing a little bit of that. Ideally, we'll be doing as little > >>>> of that as we can get away with. The "little bit" we have to > >>>> do is to use some additional header information to: > >>>> > >>>> 1) forward frames on the shortest path between RBridges, > >>>> and > >>>> 2) reduce or eliminate potential looping of frames during > >>>> a perturbation of the shortest path. > >>>> > >>> You have so far chosen to do this in a mode that > optimizes for mixed > >>> bridges at the cost of ignoring the effciencies you could > get between > >>> directly connected Rbridges. 802.1ah opimizes forwarding > for connected > >>> Provider Backbone Bridges and interworks with legacy at a common > >>> denominator. > >>> > >> Right, and 802.1ah assumes either a green-field deployment, or a > >> firmware modifiable deployment of PBB-(enabled/compatible) bridges. > >> > >> This is not consistent with our goals. > >> > >> > >>>> This may be somewhat of a simplification, but that's fair in > >>>> light of the general trend for casual observers to do the > >>>> opposite. > >>>> > >>>> Currently, we define a SHIM to carry this information and > >>>> we expect to use one or more "standard headers" to encapsulate > >>>> frames being forwarded between RBridges. > >>>> > >>>> Does this make things clearer? > >>>> > >>> Eric I understand what is proposed but I still question > if a greater > >>> synergy cannot be achieved between encapsulating headers. > A shim is a > >>> not a typical solution but encapsulations are. > >>> > >> Greater synergy is always demonstrably possible if you're willing > >> to wait long enough. > >> > >> That's - for example - why we only have one link-state routing > >> protocol, and why Ethernet was the one and only MAC-like format > >> for L2 frames ever to have been used. > >> > >> What planet are we on? :-) > >> > >> > >>> Regards, > >>> Don > >>> > >>> > >>> > >>>> -- > >>>> Eric > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Don Fedyk [mailto:dwfedyk at nortel.com] > >>>>> Sent: Wednesday, December 13, 2006 12:18 PM > >>>>> To: Gray, Eric; Silvano Gai > >>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali > >>>>> Sajassi (sajassi) > >>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps > >>>>> > >>>>> Hi Eric > >>>>> > >>>>> This argument says if you use ANY standard header then it > >>>>> > >>>> would be a bad > >>>> > >>>>> idea. > >>>>> > >>>>> So you are creating a new forwarding paradigm and the down > >>>>> > >>>> side of that > >>>> > >>>>> as Ali pointed out is now you have to create most of the > >>>>> > >>>> other things > >>>> > >>>>> that go along with new forwarding paradigm. > >>>>> > >>>>> Don > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] > >>>>>> Sent: Tuesday, December 12, 2006 4:29 PM > >>>>>> > >>>>>> Silvano, > >>>>>> > >>>>>> IFF we were going to use 802.1ah, it could allow us to > >>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the > >>>>>> "customer" DA/SA for egress/ingress RBridges. But that would > >>>>>> be using it in a way that is not consistent with the intended > >>>>>> use of 802.1ah - simply because that usage would make use of > >>>>>> the fields in a way that matches the way that your proposed > >>>>>> "short-hand" SHIM header would use them. > >>>>>> > >>>>>> If you did that, there would be room for using the B-tag > >>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags. > >>>>>> > >>>>>> I think this is a VERY BAD idea. > >>>>>> > >>>>>> -- > >>>>>> Eric > >>>>>> > >>>>> > >>>>> > >>>>> > >> _______________________________________________ > >> 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 gibanez at it.uc3m.es Fri Dec 15 10:16:04 2006 From: gibanez at it.uc3m.es (=?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?=) Date: Fri, 15 Dec 2006 19:16:04 +0100 Subject: [rbridge] Use of 802.1ah Encaps In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40C75D3E1@zrtphxm2.corp.nortel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA40C75D3E1@zrtphxm2.corp.nortel.com> Message-ID: <4582E664.5040105@it.uc3m.es> Don, See inline Guillermo Don Fedyk escribi?: > Hi Guillermo > > See Inline. > > >> -----Original Message----- >> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] >> >> >> My previous message perhaps was not too clear. Please bear >> with me and >> my english :-) >> - 802.1ah assumes no legacy bridges in the middle. >> > This is false. 802.1ah is backwards compatible with legacy bridges. However I think it would be safe to say this is not a plug and play option. 802.1ah would need to be configured to know the legacy bridges capabilities. But 802.1ah header is compatible with 802.1Q header for forwarding. The same trick that a TRILL RBridge uses. > > I am not at all expert on 802.1ah , but I does not look simple to manage legacy bridges interposed. And away from the zero configuration target. >> - AFAK, 802.1ah does not assume routing between nodes. If so, >> it would >> likely require TTL field. >> > 802.1ah bridges from ingress to egress PBB nodes. Whether the service is IP or Ethernet on the ingress/egress PBB is a box question not outside the scope of 802.1ah architecture. > > 802.1ah bridges, does not route. >> - TRILL does assume legacy bridges between Rbridges >> - TRILL is not a subset of 802.1ah, it is different thing >> > I don't think people ever said TRILL was a subset of 802.1ah. > What I said was certain versions of the TRILL header look remarkably like the 802.1ah header. Following this logic I then said start from 802.1ah. This has not yielded any results because the part that looks like 802.1ah is hop by hop part and 802.1ah does not have a hop by hop DA part. > > That is the key point. Hop by hop part, directly related to handle the intermediate legacy bridges problem. >> - 802.1ah is not a example of simplicity. >> > I don't think this type of generalization adds any value. We are talking headers and every field in 802.1ah has a purpose and good value for the bits. > > Sorry. I meant "in the campus networks context". >> - It is too late to question TRILL basic assumptions and try to merge >> 802.1ah with TRILL encapsulation. >> > If you asked me if I see value in merging right now I would say no since the point to point header is not mainstream TRILL. > > Agree. The key point again. >> - If the whole TRILL approach is questioned (I assume it is not the >> case), 802.1ah does not seem the way to go regarding simplicity in >> campus networks. >> > No one suggested you put a provider backbone bridge in place of an Rbridge. The comment was could you use the same Frame format for the packet encaps and related functions? And that is not looking promising. > > Regards, > Don > > > >> Guillermo >> >> Guillermo Ib??ez escribi?: >> >>> Just a side comment. >>> I think the ongoing discussion is not about encapsulation >>> >> but about the >> >>> fundamentals of RBridges approach versus 802.1ah's. So, >>> >> while agreeing >> >>> on the great sinergies of a common encapsulation, lack of >>> >> TTL is an >> >>> essential point that reflects the essential difference in >>> >> the deployment >> >>> fields assumed. >>> If we assume a deployment field as for 802.1ah, encapsulations and >>> proposals much simpler than 802.1ah are possible (one is >>> >> described in my >> >>> ABridges draft). If this is the case we should restart WG >>> >> discussion >> >>> from the beguinning. >>> Encapsulation for RBridges is not simple, and 802.1ah isn't simple >>> either, specially considering the campus networks of >>> >> moderate sizes that >> >>> are the target for RBridges. >>> Guillermo >>> >>> >>> Gray, Eric escribi?: >>> >>>> Don, >>>> >>>> I think you've garbled the discussion, somewhat. >>>> >>>> Please see below... >>>> >>>> -- >>>> Eric >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Don Fedyk [mailto:dwfedyk at nortel.com] >>>>> Sent: Wednesday, December 13, 2006 1:19 PM >>>>> To: Gray, Eric >>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali >>>>> Sajassi (sajassi); Silvano Gai >>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps >>>>> >>>>> Hi Eric >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] >>>>>> >>>>>> Don, >>>>>> >>>>>> I don't follow your reasoning. >>>>>> >>>>>> >>>>> That's OK I cant follow you sometimes either ;-) >>>>> >>>>> >>>>> >>>>>> I certainly am not saying that using "ANY standard header" >>>>>> is a bad idea. >>>>>> >>>>>> >>>>> Then why not start from ah? The bit that Silvano said was we >>>>> could use ah and you said it is a bad idea. >>>>> >>>>> >>>> I don't think I am quoting too much out of context, when I quote >>>> the following from Silvano's reply to Joe Touch: >>>> >>>> SILVANO > My comment is that IEEE 802.1ah has no space for both >>>> SILVANO > the ultimate source/dest and the next hop source/dest. >>>> >>>> SILVANO > IEEE 802.1ah is designed for multiple enterprises to >>>> SILVANO > share a common metro backbone. It does a fine job in >>>> SILVANO > that area. It does not support well an arbitrary >>>> SILVANO > intermixing of Bridges and Rbridges. >>>> >>>> SILVANO > In contrast Trill does a fine job in supporting >>>> SILVANO > arbitrary topologies and mixing of RBridges and >>>> SILVANO > Bridges thanks to the availability of both the >>>> SILVANO > ultimate source/dest and the next hop source/dest. >>>> >>>> SILVANO > In TRILL the network between the "ingress" and >>>> SILVANO > "egress" RBridge isn't a single Ethernet (like in >>>> SILVANO > 802.1ah), but rather a sequence of RBridges that >>>> SILVANO > may be connected by Ethernets. >>>> >>>> SILVANO > Things look similar, but are substantially different. >>>> >>>> Given that this is what (I believe, at least) Silvano said >>>> about using 802.1ah, where do you get the impression that >>>> Silvano has said that "we could use ah"? >>>> >>>> >>>> >>>>> Please describe "BAD idea" then. >>>>> >>>>> >>>> In this, I think quite a few of us are now in agreement. >>>> >>>> It is rarely a good idea to use a header format just because >>>> most of the bits look similar to one proposal that has all >>>> of the information you require. >>>> >>>> Suppose you started to think that using 802.1ah - because it >>>> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC >>>> - was an example of one of the rare instances in which this >>>> might be a good idea. Wouldn't you suspect that the need to >>>> consider potentially adding a TTL field to the header might >>>> be an indication that you are probably wrong? >>>> >>>> So, to answer your question, a "BAD idea" is one that takes >>>> valuable resources to explore and offers no believable cause >>>> to suspect that it will work better than other ideas already >>>> on the table. >>>> >>>> In this case, we have reason to believe (MAC+SHIM)-in-MAC >>>> will work and no reason to believe that 802.1ah will work >>>> better - even assuming we went down that rat-hole. >>>> >>>> >>>> >>>>>> As for "creating a new forwarding paradigm" - yes, we're >>>>>> doing a little bit of that. Ideally, we'll be doing as little >>>>>> of that as we can get away with. The "little bit" we have to >>>>>> do is to use some additional header information to: >>>>>> >>>>>> 1) forward frames on the shortest path between RBridges, >>>>>> and >>>>>> 2) reduce or eliminate potential looping of frames during >>>>>> a perturbation of the shortest path. >>>>>> >>>>>> >>>>> You have so far chosen to do this in a mode that >>>>> >> optimizes for mixed >> >>>>> bridges at the cost of ignoring the effciencies you could >>>>> >> get between >> >>>>> directly connected Rbridges. 802.1ah opimizes forwarding >>>>> >> for connected >> >>>>> Provider Backbone Bridges and interworks with legacy at a common >>>>> denominator. >>>>> >>>>> >>>> Right, and 802.1ah assumes either a green-field deployment, or a >>>> firmware modifiable deployment of PBB-(enabled/compatible) bridges. >>>> >>>> This is not consistent with our goals. >>>> >>>> >>>> >>>>>> This may be somewhat of a simplification, but that's fair in >>>>>> light of the general trend for casual observers to do the >>>>>> opposite. >>>>>> >>>>>> Currently, we define a SHIM to carry this information and >>>>>> we expect to use one or more "standard headers" to encapsulate >>>>>> frames being forwarded between RBridges. >>>>>> >>>>>> Does this make things clearer? >>>>>> >>>>>> >>>>> Eric I understand what is proposed but I still question >>>>> >> if a greater >> >>>>> synergy cannot be achieved between encapsulating headers. >>>>> >> A shim is a >> >>>>> not a typical solution but encapsulations are. >>>>> >>>>> >>>> Greater synergy is always demonstrably possible if you're willing >>>> to wait long enough. >>>> >>>> That's - for example - why we only have one link-state routing >>>> protocol, and why Ethernet was the one and only MAC-like format >>>> for L2 frames ever to have been used. >>>> >>>> What planet are we on? :-) >>>> >>>> >>>> >>>>> Regards, >>>>> Don >>>>> >>>>> >>>>> >>>>> >>>>>> -- >>>>>> Eric >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Don Fedyk [mailto:dwfedyk at nortel.com] >>>>>>> Sent: Wednesday, December 13, 2006 12:18 PM >>>>>>> To: Gray, Eric; Silvano Gai >>>>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali >>>>>>> Sajassi (sajassi) >>>>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps >>>>>>> >>>>>>> Hi Eric >>>>>>> >>>>>>> This argument says if you use ANY standard header then it >>>>>>> >>>>>>> >>>>>> would be a bad >>>>>> >>>>>> >>>>>>> idea. >>>>>>> >>>>>>> So you are creating a new forwarding paradigm and the down >>>>>>> >>>>>>> >>>>>> side of that >>>>>> >>>>>> >>>>>>> as Ali pointed out is now you have to create most of the >>>>>>> >>>>>>> >>>>>> other things >>>>>> >>>>>> >>>>>>> that go along with new forwarding paradigm. >>>>>>> >>>>>>> Don >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com] >>>>>>>> Sent: Tuesday, December 12, 2006 4:29 PM >>>>>>>> >>>>>>>> Silvano, >>>>>>>> >>>>>>>> IFF we were going to use 802.1ah, it could allow us to >>>>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the >>>>>>>> "customer" DA/SA for egress/ingress RBridges. But that would >>>>>>>> be using it in a way that is not consistent with the intended >>>>>>>> use of 802.1ah - simply because that usage would make use of >>>>>>>> the fields in a way that matches the way that your proposed >>>>>>>> "short-hand" SHIM header would use them. >>>>>>>> >>>>>>>> If you did that, there would be room for using the B-tag >>>>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags. >>>>>>>> >>>>>>>> I think this is a VERY BAD idea. >>>>>>>> >>>>>>>> -- >>>>>>>> Eric >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> _______________________________________________ >>>> 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 erik.nordmark at sun.com Wed Dec 20 10:55:21 2006 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 20 Dec 2006 10:55:21 -0800 Subject: [rbridge] Suggested updates to our milestones Message-ID: <45898719.2010405@sun.com> The current milestones remaining (i.e. not already marked as DONE) are: Aug 2006 Submit architecture document to IEEE/IETF expert review Aug 2006 Submit routing protocol requirements to the IESG for publication as an Informational RFC Aug 2006 Submit problem statement and applicability to IESG for Informational RFC Nov 2006 Submit architecture document to the IESG for publication as an Informational RFC Dec 2006 Choose routing protocol(s) that can meet the requirements Dec 2006 Submit base protocol specification to IEEE/IETF expert review Mar 2007 Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Jul 2007 Re-charter or shut down the WG Suggested new milestone dates: Jan 2007 Submit architecture document to IEEE/IETF expert review Jan 2007 Submit routing protocol requirements to the IESG for publication as an Informational RFC Mar 2007 Choose routing protocol(s) that can meet the requirements Mar 2007 Submit architecture document to the IESG for publication as an Informational RFC Apr 2007 Submit problem statement and applicability to IESG for Informational RFC May 2007 Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Jul 2007 Re-charter or shut down the WG Erik & Donald From Donald.Eastlake at motorola.com Thu Dec 21 20:41:15 2006 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 21 Dec 2006 23:41:15 -0500 Subject: [rbridge] Draft-trill-rbridge-protocol-01.txt Message-ID: <3870C46029D1F945B1472F170D2D979001D9CD35@de01exm64.ds.mot.com> Hi, I just noticed that no message from the Secretariat seems to have gotten through to the working group mailing list when this draft was uploaded into the ID directories. Anyway, its been there for a bit over a week. Below are some quick comments on it. Thanks, Donald ------------------------------------------------------------------ Quick Comments on draft-ietf-trill-rbridge-protocol-01.txt Section 1, next to last bullet point at bottom of page 4: Text has not been updated for the designation of two Rbridges in the shim. Section 1, third paragraph at the top of page 5: I would think there would also be cases where the VLAN tag was removed by the endnode. Section 2.1.1, on page 7: The 2nd and 3rd paragraphs of this section have a significant amount of redundancy between them. Section 2.1.1, near the top of page 8: The list of core-Rbridge information seems to be missing the Rbridge nickname. Section 2.3, first paragraph on page 11: "the specified Rbridge in the shim" sounds like wording from when there was only one. Suggest rewording this. Section 2.3, first bullet point on page 11: Should that be "IP multicast routers"? Section 2.5, first paragraph, page 13: Suggest changing "it is desirable" to "it may be desirable". Section 2.5 second paragraph, Page 11: Typo: B2-B2-R1 should be B2-B1-R1. Section 28.1, first normative reference on page 22: The D should be capitalized in 802.1D. Perhaps a reference to 802.1Q should be added. From Radia.Perlman at sun.com Fri Dec 22 22:35:44 2006 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 22 Dec 2006 22:35:44 -0800 Subject: [rbridge] Multiple instance/hierarchical RBridge topologies Message-ID: <458CCE40.4050403@sun.com> After talking to a bunch of people, I think I understand a feature, and here are thoughts on how to implement it. The two problems we might solve: a) ensure that two different RBridged clouds don't accidentally merge b) allow a hierarchy of RBridged clouds (yes, similar to L2VPN or provider backbone bridges) In the case of b) it would be useful to encapsulate data packets with a customer ID, whereas such a field would not be necessary for a customer campus/CRED/RBridged-cloud. IS-IS already has a field "area address" that can be configured to keep two IS-IS instances separate. So, for instance, the default can be area=0, but if there are two different RBridged clouds that are intended to be kept separate, but they are physically close enough that someone is afraid they might accidentally merge, then you can configure the area address in all of the RBridges in at least one of the clouds to prevent two alien RBridges from talking to each other. For hierarchy, we could do the same thing (configure the higher layer RBridge cloud to have an area address something other than 0). That way customer RBridged nets would not accidentally merge with the core instance. But as I'll explain, I think the backbone RBridges would need to be slightly different from the lower-level RBridges. There are two "community" things that we want to keep separate, and let's call them "customers" and "VLANs within customer". RBridges as currently specified keep VLANs separated. However, if we have a higher level of RBridges connecting customers, each of whom are using VLANs, the core RBridges need to keep separate communities of (customer, VLAN) pairs. So let's think of a "community" as having a hierarchically assigned "community" name, which would be "customer ID" concatenated with VLAN tag, or (customer, VLAN). The rule is that two endnodes can only talk to each other if they are in the same tuple (customer, VLAN). This really results in all the same algorithms as RBridges already do in terms of filtering so that multicasts within a VLAN stay within a VLAN, except that it's a bigger field: it's (customer, VLAN) now. Therefore, the difference between case a) and b) above is that RBridges also have to know how many components are in the community tag. In a) RBridges assume the community is specified by the VLAN tag in the inner packet. In b), we need for RBridges in the backbone to add another field to specify another level of hierarchy in the tag. In an earlier note, we were suggesting using a VLAN tag in the outer header. But perhaps it would be more cleanly expressed as another field in the shim header used by the backbone RBridges. So, here is a suggestion: Make the "area address" in IS-IS have two parts: (level of hierarchy | name). The default is level=0, and name=0. Backbone RBridges would use level=1, and name could be anything, but all RBridges in the same cloud all have to be configured with the same name (0 would work). RBridges at level 1 will encapsulate data packets with an extra field (say 16-bits), that separates communities. So at level 1, we'd add to the shim a 16-bit field, that we could think of as "customer ID". So if the shim header is 6 bytes at level 0, it would be 8 bytes at level 1, since it would also have the extra "customer" field. I don't think we'd ever need more than 2 levels, but we might want to think about that -- I'd guess we'd assume 2 "customer ID" fields in the shim at level 2. At level 1, in the per-VLAN instance which passes around endnode information and IP multicast membership, the only difference would be like having a VLAN tag which is 28 bits (12 plus 16), and in theory, one could have 2^28 instances of IS-IS passing around endnode information across the backbone. Comments? I hope I'm being reasonably clear. Radia