[rbridge] VLAN tags, inner/outer, revisted and summarized
Guillermo Ibáñez
gibanez at it.uc3m.es
Fri Dec 1 14:44:14 PST 2006
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-contrib-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
>
More information about the rbridge
mailing list