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

From: Radia.Perlman at sun.com ([email-masked])
Date: Mon, 29 Oct 2007 13:14:09 -0700

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 VLAN 1 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 week and 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 VLAN 1?
> 
> 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

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 29 Oct 2007 15:41:12 -0700

Radia,

I have redrawn

Using more terminology according to your suggestion.

Can you rewrite this email using the terminology of the updated

Thank You

-- Silvano

> From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com]
> Sent: Monday, October 29, 2007 1:14 PM
> To: Silvano Gai
> 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
> 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.
> 
> 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,
> the VLANs to get merged or anything like that. It just means that VLAN
1
> would not be allowed to
> RB1 and RB2's "port y" would not need to be configured, since VLAN 1
would
> already work on the cloud
> Would some number of people like to have a phone call early this week
and
> 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
> 
> 
>

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Tue, 30 Oct 2007 05:34:45 -0500

Radia,

	Unfortunately, some people (myself, for instance) will be in
Paris this week for the MEF meeting.  Meeting at a time convenient
to the US west coast is difficult for people meeting in Europe.

--
Eric Gray
Principal Engineer
Ericsson  

> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com
> Sent: Monday, October 29, 2007 4:14 PM
> To: Silvano Gai
> Cc: Developing a hybrid router/bridge.
> Subject: 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.
> So looking at your picture, note that we have three separate 
> layer 2 clouds. Let's add "port" numbers,
> 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.
> 
> 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,
> to communicate with each other. And it means that all the 
> traffic for RBridge-RBridge communication
> 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).
> 
> the people would include at least you (Silvano), Dinesh, me, 
> Anoop, but I don't mean to exclude anyone.
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>