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

[Silvano Gai]

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 [mailto: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 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
>