[rbridge] VLAN tags, inner/outer, revisted and summarized
Gray, Eric
Eric.Gray at marconi.com
Fri Dec 1 15:35:04 PST 2006
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
>
More information about the rbridge
mailing list