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

[Radia.Perlman@sun.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 <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
>