Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 1 Dec 2006 18:35:04 -0500

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)" <dromasca at avaya.com 
> <mailto:dromasca at avaya.com>>
> To: "IESG" <iesg at ietf.org <mailto:iesg at ietf.org>>; <iab at ietf.org 
> <mailto:iab at ietf.org>>
> Cc: < l2vpn at ietf.org <mailto:l2vpn at ietf.org>>; 
> <ccamp-chairs at tools.ietf.org <mailto:ccamp-chairs at tools.ietf.org>>; 
> "Tony Jeffree"
> <tony at jeffree.co.uk <mailto:tony at jeffree.co.uk>>
> 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 
> <http://www.ieee802.org/1/files/public/docs2006/liaison-contri
> 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 <Radia.Perlman at sun.com>
> > 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
>