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

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

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 <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
>