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

[Radia.Perlman@sun.com]

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.

*********************

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. 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?)
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.

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.

************************
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).

Ports X1, X2, X3, and X4 would be configured to send Hellos on either VLAN 7 or 8. 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. 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.

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