[rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?

[Silvano Gai]

Radia,

inline

> -----Original Message-----
> From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com]
> Sent: Monday, October 29, 2007 7:46 PM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> Subject: Re: RE: RE: [rbridge] Final outcome of outer VLAN tags
onRBridge-
> RBridgepackets?
> 
> 1) I suggested a phone call sometime this week, but it was buried in
the
> end of my message. I'd particularly hope that (at least) you
(Silvano),
> Dinesh, Anoop, me, and Don Eastlake attend, but nobody would be
excluded.
> Send me email with all
> your availability for this week (and time zones) and I'll try to pick
a
> time.
> 
> 2) As for the updated picture, and talking through how I think
> it all would work -- I think all the three clouds are completely
> independent. So I think
> we could just as well be talking about a single layer 2 cloud with a
bunch
> of RBridges
> attached. But I'll use your picture.

A single cloud or three separate clouds are not the same thing. 

Let's assume that cloud L is located in Manhattan (main data center),
cloud R is located in New Jersey (backup data center) and Cloud G is
some form of public/private fiber connectivity with Ethernet switches
connected at the ends. Cloud G is run by central IT. Let's also assume
that the finance department has been assigned two VLANs (7 and 8) on the
Green Cloud and can use only that two VLANs. Originally the finance
department was using routers (instead of RBridges in
http://www.ip6.com/example.ppt), but now it is thinking to replace them
with RBridges. With routers finance needs at least two separate IP
subnets on VLAN 3, one on Cloud L, one on Cloud R. Replacing the routers
with RBridges, finance can use the same IP subnet for VLAN 3 in Cloud L
and Cloud R.

> 
> *********************
> 
> First: let's talk through what happens with the "use VLAN 1, no
> configuration" strategy:
> 
> The rule is that on every layer 2 cloud (R, G, and L in your picture),
> bridges inside each cloud must allow VLAN-1-tagged traffic to pass. 

This is impossible in our scenario. Finance has only VLAN 7 and 8 on the
Green Cloud. Finance is not the only department that wants to deploy
RBridges, also Marketing and Sales want to do the same. The requests of
Finance, Marketing, and Sales to own VLAN 1 on the Green Cloud conflict.
There is a strong corporate policy that the departments cannot share
VLANs (and believe me, on Wall Street these rules are enforced).

On Cloud R also we have an issue; Finance does not own VLAN 1.

Therefore allowing VLAN 1 traffic to pass on Cloud G and R is impossible
from a deployment perspective.

That
> would mean that
> VLAN 1 would not partitioned on that cloud. Also every RBridge port
must
> be configured to allow
> sending and receiving of VLAN 1 tagged traffic.
> 
> The way I read your picture (http://www.ip6.com/example.ppt): As
> configured, RB3, for
> instance, is only able to send/receive frames tagged
> with VLANs 2 and 3 on its port Y3, and send/receive VLANs 7 and 8 on
its
> port X3.
> (Is that a correct interpretation of your picture?)

YES

> So, assuming my interpretation is correct, if you started with an
> installation configured that
> way, then ports X3, Y3, X4, Y4, X1, and X2 would have to be
reconfigured
> to allow use of VLAN 1, and any
> bridges in between these ports (e.g., inside cloud G or cloud R), if
they
> were configured to partition VLAN 1,
> would have to be configured to allow traffic marked with VLAN 1 to be
> forwarded.

In this example, this is impossible, as I explained you above.

> 
> Consequences of not doing the reconfiguration as just stated are:
> If an RBridge R *cannot* send/receive on VLAN 1 on a port, R will not
send
> any Hellos (which might be fine -- perhaps
> there are no other RBridges on the link -- just endnodes, but my
> preference would
> be to discourage and possibly
> disallow having an RBridge port with VLAN 1 turned off). If VLAN 1 is
> partitioned on
> the cloud, the same consequence happens. R will not
> form any RBridge-RBridge adjacencies on that port, so no encapsulated
> traffic will be forwarded across that cloud. With
> the safeguards specified in my earlier emails, R will be conservative
> about encapsulating/decapsulating data traffic
> to/from that link, so that there won't be loops.
> 
> If VLAN 1 is not partitioned and all RBridges can send/receive VLAN 1,
> then everything works very smoothly. Other than
> having had to reconfigure things, I don't see what functionality the
> customer is giving up by allowing RBridges
> to talk on VLAN 1.

You are assuming that a customer "owns" the whole network. This is often
not the case. Departments own pieces of the network. This often is a
complex and painful process that results from merger and acquisition and
from complex security policy inside the corporation.


> 
> ************************
> Now let's talk about the "single VLAN, but we can configure which VLAN
it
> is" strategy:
> 
> The customer *could* reconfigure things to allow VLAN 1 for RBridge-
> RBridge communication, and then
> everything would work as above. But if for some reason they wanted to
only
> allow VLANs 7 and 8 in cloud G,
> and 2 and 3 in cloud R, then they could do the following:
> 
> Ports Y1 and Y2 will not require any configuration -- they already
support
> VLAN 1 (the default).
> 

OK

> Ports X1, X2, X3, and X4 would be configured to send Hellos on either
VLAN
> 7 or 8. 

OK

I'd recommend, if the VLAN
> for Hellos is configurable, that you *accept* Hellos on any of the
VLANs
> for which you can receive traffic. 

This is a detail we can work later.

Whoever
> gets elected DRB (say RB1) specifies, in its Hello, "use VLAN 8", and
then
> X2, X3, and X4, as long as they continue
> to receive Hellos from RB1, send their Hellos on VLAN 8. Furthermore,
LSPs
> on cloud G are transmitted tagged with
> outer VLAN 8. Encapsulated data traffic being forwarded across cloud G
> would also have outer VLAN tag of 8.
> 
> If RB2 were DRB instead of RB1, and RB2 was configured to transmit on
VLAN
> 7, then it would tell all the RBridges to tag
> their RBridge-RBridge traffic with 7. If there are different
priorities,
> say RB1 is DRB for VLAN 7, and wants to
> tag RBridge-RBridge traffic with 7,  and RB2 is DRB for VLAN 8, and
wants
> to tag RBridge-RBridge traffic with "8", then you wind up with two
DRBs
> (one for VLAN 7, and one for VLAN 8). If RB1 tells everyone "use VLAN
7"
> and RB2
> tells everyone "use VLAN 8", then you'll get twice as many Hellos on
the
> link as you'd need.
> So perhaps as an optimization, the RBridges could notice this and if
you
> are DRB for some
> of the VLANs on a cloud, and some other DRB (for a different set of
VLANs
> on the same cloud) is
> telling the RBridges to send Hellos on a different, lower numbered
VLAN,
> then I think it would
> be reasonable to agree to using that VLAN.
> 
> Something that's perhaps a bit subtle, but does indeed work, is to
realize
> what happens if you have
> multiple DRBs as a consequence of load splitting the VLANs. What
happens
> is:
> 
> a) you'll have multiple DRBs, and each DRB will create a different
> pseudonode for that cloud
> 
> b) the pseudonodes will have the same root bridge in the LSP, but with
a
> different, nonoverlapping
> set of VLANs
> 
> c) a multicast packet will not get sent twice on the cloud, because
the
> multicast data packet
> will be (inner) tagged with some VLAN tag, and will only get delivered
to
> the pseudonode that
> includes that VLAN tag.
> 
> Anyway, I'm optimistic at this point that we will converge on either
"VLAN
> 1--nonconfigurable"
> or "single VLAN per layer 2 cloud, but which VLAN is configurable",
but
> that if there really
> is a problem with this, I think a phone call would be the best thing
at
> this point.
> 

"VLAN 1--nonconfigurable" is a non-starter for me, I hope to have
explained why.

"single VLAN per layer 2 cloud" may be workable, but I need to see the
details of the algorithm to see if there are corner cases.

If we can agree to concentrate our focus on a "single VLAN per layer 2
cloud" we have made some progress.

-- Silvano

> Thanks,
> 
> Radia
> 
> ----- Original Message -----
> From: Silvano Gai <sgai at nuovasystems.com>
> Date: Monday, October 29, 2007 3:41 pm
> Subject: RE: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> > Radia,
> >
> > I have redrawn
> > http://www.ip6.com/example.ppt
> >
> > Using more terminology according to your suggestion.
> >
> > Can you rewrite this email using the terminology of the updated
> > > http://www.ip6.com/example.ppt
> >
> > Thank You
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Radia.Perlman at sun.com [Radia.Perlman at sun.com]
> > > Sent: Monday, October 29, 2007 1:14 PM
> > > To: Silvano Gai
> > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > > Subject: Re: RE: [rbridge] Final outcome of outer VLAN tags
> > onRBridge-
> > > RBridgepackets?
> > >
> > > Silvano,
> > > Based on your message, I think a lot of the controversy here is
> > simply> miscommunication, which is actually great news.
> > > The VLAN number we have been talking about is solely a local
> > matter on
> > a
> > > single layer 2 cloud. It
> > > is only the outer VLAN number used for RBridge-RBridge
> > communication.>
> > > So looking at your picture, note that we have three separate
> > layer 2
> > > clouds. Let's add "port" numbers,
> > > so that for each of the RBridges, their top port will be called
"x"
> > and
> > > their bottom port would
> > > be called "y".
> > >
> > > Let's call the clouds "G" for the top one (because it is green).
And
> > "L"
> > > for the lower left, and "R" for the
> > > lower right.
> > >
> > > if we went with the "VLAN 1 unconfigurable" strategy, then we'd
have
> > to
> > > tell that customer to open up VLAN 1 on the G cloud and R cloud
(and
> > I'm
> > > sure I'm using the wrong word,
> > > but by "open up", I mean make it so that the RBridges are capable
of
> > > sending and receiving traffic
> > > on VLAN 1, and that VLAN 1 is not partitioned in the green
> > cloud). It
> > > wouldn't cause
> > > the VLANs to get merged or anything like that. It just means that
> > VLAN1
> > > would not be allowed to
> > > be partitioned on any of those 3 clouds, and that the RBridges
> > must be
> > > able to use VLAN 1
> > > to communicate with each other. And it means that all the traffic
> > for> RBridge-RBridge communication
> > > (which consists of IS-IS Hellos, LSP forwarding, and encapsulated
> > > data packet forwarding across the cloud between RBridges)
> > > would be sent with an outer VLAN tag of 1.
> > >
> > > If we instead went with
> > > the "single VLAN, but configurable", then all the RBridges would
be
> > > configured to use, say, VLAN 7
> > > for RBridge-RBridge communication on their "port x" which
> > connects to
> > > cloud G.
> > > RB1 and RB2's "port y" would not need to be configured, since
> > VLAN 1
> > would
> > > already work on the cloud
> > > attached to that port. RB3 and RB4 would need to be configured to
> > use,> say, VLAN 3, on their "y" port (the
> > > one to cloud R).
> > >
> > > Would some number of people like to have a phone call early this
> > weekand
> > > resolve it? I'd hope that
> > > the people would include at least you (Silvano), Dinesh, me,
Anoop,
> > but I
> > > don't mean to exclude anyone.
> > >
> > > Radia
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Silvano Gai <sgai at nuovasystems.com>
> > > Date: Sunday, October 28, 2007 4:49 am
> > > Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> > > RBridgepackets?
> > >
> > > >
> > > > Radia,
> > > >
> > > > Can you explain me if your solution supports the example that I
> > have> > drawn in PowerPoint at:
> > > > http://www.ip6.com/example.ppt
> > > > ?
> > > >
> > > > Thank You
> > > >
> > > > Answering your email:
> > > >
> > > > I have seen customers deploying VLANs in a variety of ways.
> > > >
> > > > Some customers have VLAN 1 end-to-end and they use it for
control
> > and
> > > > data traffic. Some customers use VLAN 1 only for control
traffic.
> > Some
> > > > customers wants all VLANs (including VLAN 1) being local (not
> > > > end-to-end). Some customers prefer to move some control
> > protocol to
> > > > another VLAN. I have seen multiple different approaches.
> > > >
> > > > You ask for rational, "tangible reasons". Each customer has its
> > own> > reasons that don't match the ones of other customers. There
> > are no
> > > > universal tangible reasons, you just need to realize that IEEE
> > 802.1Q
> > > > allows VLANs to be deployed in many different way.  Any solution
> > that
> > > > poses restrictions is going to be OK for some customers and KO
for
> > > > others.
> > > >
> > > > Over the years I have learned to live with the fact that
customers
> > > > havedifferent deployment approaches that are perfectly valid
> > > > because allowed
> > > > by IEEE 802.1Q and by the products.
> > > >
> > > > In TRILL we often speak about plug-and-play. If we consider
> > > > plug-and-play, VLAN 1 is the only one enabled by default and
> > therefore
> > > > it seems a reasonable default solution.
> > > >
> > > > While this is a valid concept in the consumer space, it is
> > absolutely
> > > > not valid in Enterprise/Datacenter. Enterprise/Datacenter
> > customers> > request that all the new boxes are shipped with all
> > the ports
> > > > disabled,because they realized that the switches will be
connected
> > > > in complex
> > > > configurations in which plug-and-play is very dangerous.
> > > >
> > > > I expect the same to be true for RBridges, where customers will
> > > > carefully design, test in a separate environment and bring-up a
> > > > configuration that will match the existing VLAN deployment they
> > have.
> > > >
> > > > Inline for you specific questions:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Radia Perlman [Radia.Perlman at sun.com]
> > > > > Sent: Saturday, October 27, 2007 8:59 PM
> > > > > To: Silvano Gai
> > > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> > > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags
> > onRBridge-
> > > > > RBridgepackets?
> > > > >
> > > > > I'm anxious to close on this issue, but
> > > > > Silvano...you always speak in such absolutes: words like
> > > > > "unrealistic" without giving tangible reasons what the
> > > > > problem is. Again, everything is engineering tradeoffs, and we
> > > > have to
> > > > > understand what the specific
> > > > > pros and cons are (not phrases like
> > > > > "won't work" "unrealistic" "not flexible enough", but instead
> > "won't
> > > > allow
> > > > > this *particular* scenario")
> > > > >
> > > > > Question: Is the problem picking specifically VLAN 1 as
> > > > > our chosen single VLAN number? If we picked a different
> > > > (unconfigurable)
> > > > > VLAN number would that be OK?
> > > >
> > > > I think that VLAN 1 is probably our best default choice. I don't
> > > > objectto have VLAN 1 to be the default VLAN.
> > > >
> > > > If so, what number? If you are arguing that
> > > > > it's OK to require one VLAN not to be partitioned, and that
all
> > > > > RBridge-RBridge
> > > > > communication be done over that VLAN, then I really don't
> > > > understand.
> > > > I am not sure what you are asking. If you are speaking of the
> > backbone
> > > > between RBridges, the outer VLAN tag for sure may not be the
same
> > > > end-to-end.
> > > >
> > > > A department of a large corporation may want to deploy RBridges
> > in 5
> > > > different sites. The VLAN they have available from site_1 to
> > site_2> > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3
> > to site_4
> > > > VLAN 4.
> > > >
> > > > If you want all this VLANs to be a single VLAN end-to-end,
> > there is
> > a
> > > > significant change that needs to happen in the communication
> > > > infrastructure that may be considered difficult or impossible.
> > > >
> > > > If instead you are discussing the access to the RBridge clouds,
I
> > > > thinkit is reasonable to require that the RBridges that perform
> > TRILL
> > > > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1
may
> > > > be the
> > > > default, but I think that the value should be programmable.
> > > >
> > > >
> > > > > If that were the case, why can't we (TRILL) put a stake in the
> > > > ground> and say "RBridges will
> > > > > use VLAN 1", and if the customer wanted to use VLAN 1 for
> > something
> > > > > else, but was willing
> > > > > to configure RBridges to use, say, VLAN 57, why can't that
> > customer
> > > > > renumber their own
> > > > > VLANs so that they switch their uses of VLAN 57 and VLAN 1,
and
> > let
> > > > the
> > > > > rest of
> > > > > the world have the simplicity of an unconfigurable choice of
> > VLAN1?
> > > >
> > > > I don't think this is acceptable for many customers. You are
> > > > putting a
> > > > stake in the ground that IEEE has never put.
> > > >
> > > > >
> > > > > Are you saying that you don't want to require customers to
have
> > > > *any*> VLAN number that
> > > > > isn't partitioned,
> > > >
> > > > I am not sure what you mean with "*any* VLAN number that isn't
> > > > partitioned", are you speaking of inner VLAN or outer VLAN?
> > > >
> > > > In most installation the numbering spaces of the Backbone VLANs
> > and> > Access VLANs are disjoint. I don't think this is an issue
> > since the
> > > > access VLANs appears in the inner VLAN tag, while the backbone
> > VLANs> > appears in the outer VLAN tag.
> > > >
> > > >
> > > > and you want a solution that somehow finds all
> > > > > possible ways of having
> > > > > RBridges talk to each other using every possible VLAN?
> > > >
> > > > Again, when you are saying "RBridges talk to each other" are you
> > > > speaking of the TRILL encapsulated frames or of the DRB
> > election on
> > > > theaccess?
> > > >
> > > > Again see my example at:
> > > > http://www.ip6.com/example.ppt
> > > >
> > > > -- Silvano
> > >
> >
> >