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

[Silvano Gai]

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 have
different 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 [mailto: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 object
to 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 may
be 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 think
it 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 the
access?

Again see my example at:
http://www.ip6.com/example.ppt

-- Silvano

If so, this
> proposal has never been
> specified, and, as I said, can't be evaluated unless it is specified.
> 
> Anyway, I really want to understand the issue, but you really have to
be
> specific about
> what is being precluded by saying "just use VLAN 1", or even the
> fallback compromise "just use a single
> VLAN that is default=1, but the DRB can tell all the other RBridges to
> use some other VLAN
> number instead". I don't think we should give in and make it
> configurable without understanding
> why it is less work for the customer to configure the RBridges to
change
> to a different VLAN number X
> than for that same customer to reconfigure whatever it was they were
> doing to switch VLAN 1
> with VLAN X, so that RBridges can use VLAN 1.
> 
> Radia
> 
> 
> Silvano Gai wrote:
> > Assuming that you always have connectivity on VLAN 1 is unrealistic.
> > Different installation may use VLAN 1 for different purposes.
> >
> > Forbidding by standard to change this VLAN to another value is not
going
> > to work in products. Products will need to support the capability to
> > change this value to meet customer needs. They will therefore invent
> > proprietary mechanism to support a different value. Result: lack of
> > interoperability.
> >
> > -- Silvano
> >
> >
> >> -----Original Message-----
> >> From: Anoop Ghanwani [mailto:anoop at brocade.com]
> >> Sent: Thursday, October 25, 2007 10:20 AM
> >> To: Radia Perlman; Silvano Gai
> >> Cc: Developing a hybrid router/bridge.
> >> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> >> RBridgepackets?
> >>
> >>
> >> Hi Radia,
> >>
> >> I am fairly comfortable with adopting the single
> >> VLAN hello proposal and forcing that to be VLAN 1.
> >>
> >> I would rather not have to deal with the complexity
> >> of making it configurable because even that can
> >> be subject to misconfiguration and would have its
> >> own set of issues, but I am also not totally
> >> opposed to that if someone else feels strongly
> >> about it.  The main argument for doing that
> >> would be point (b) in your message -- that
> >> VLAN 1 was already being used for something
> >> else and the operator didn't want to use it
> >> for RBridge control traffic.
> >>
> >> As you point out, it looks like the proposal
> >> for sending hellos on multiple VLANs would also
> >> require additional scrutiny/specification before
> >> it can be adopted.  Unless shown to be absolutely
> >> necessary, this approach imposes a significant
> >> processing burden so I would rather see us
> >> solve the problem with the hellos on VLAN 1
> >> only.
> >>
> >> Anoop
> >>
> >>
> >>> -----Original Message-----
> >>> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> >>> Sent: Wednesday, October 24, 2007 2:42 PM
> >>> To: Silvano Gai
> >>> Cc: Anoop Ghanwani; Developing a hybrid router/bridge.
> >>> Subject: Re: [rbridge] Final outcome of outer VLAN tags
> >>> onRBridge-RBridgepackets?
> >>>
> >>> It's always hard to catch up on a thread after being away
> >>> from email for a couple of days, but Silvano --- both the
> >>> tone and (lack of) content of your message below makes it
> >>> really difficult.
> >>>
> >>> In order to do quality engineering, we need to understand
> >>> what all the tradeoffs are, and we have to be able to do
> >>> discourse in an atmosphere of mutual respect.
> >>>
> >>> Saying something like "not doing it my way is 'too weak to be
> >>> practical', or 'holds water like a pasta strainer' is not
> >>> engineering. It is attempting to ridicule anyone who
> >>> disagrees with you, and also is completely uninformative
> >>> because you are not saying what the tradeoffs are, or even
> >>> the details of how the thing you want would work.
> >>>
> >>> I am usually proud of this WG because we usually do explore
> >>> all the options and what the tradoffs are without resorting
> >>> to bullying and ridicule. Let's strive to do engineering that way.
> >>>
> >>> So let me demonstrate by getting back to the thread.
> >>>
> >>> I think the "downsides" of sending all RBridge-RBridge
> >>> messages on a single unconfigurable VLAN (proposal being VLAN 1)
> >>>
> > are:
> >
> >>> a) if VLAN 1 is indeed partitioned, the RBridges will not
> >>> know through IS-IS Hellos that they have RBridge neighbors,
> >>> and multiple DRBs will be elected. But the proposal also
> >>> includes how to prevent multiple DRB, namely by being
> >>> conservative about forwarding data traffic to/from the link
> >>> until we discover, though reporting the bridge root ID in
> >>> LSPs, that it is safe to do so
> >>> b) a customer might want to not use that VLAN for
> >>> RBridge-RBridge traffic. However, if that customer felt so
> >>> strongly about minimizing RBridge-Rbridge traffic, they could
> >>> reconfigure use of the VLANs to move what they were using
> >>> VLAN 1 to, to some other VLAN. So saying "just use 1" might
> >>> inconvenience one customer who is already very savvy and
> >>> likes to do really fancy configuration things, but does not
> >>> prevent them from accomplishing all the exotic things they
> >>> are trying to do -- just means some more configuration. And
> >>> is saves what hopefully is the vast majority of customers
> >>> from having to do any configuration whatsoever, and
> >>> simplifies the spec and prevents misconfiguration.
> >>>
> >>> The upside of saying "just use 1" is extreme simplicity, and
> >>> with the safeguards, will not have any higher probabilty of
> >>> loops than already exists due to repeaters coming up, or
> >>> bridge spanning tree messages getting lost.
> >>>
> >>> The next more complex proposal was to allow configuration to
> >>> still ultimately use one VLAN per cloud, but allow it to be
> >>> configurable to be something other than 1. I gave a proposal
> >>> for doing that in a previous message (the DRB tells all the
> >>> other RBridges what VLAN to use, while the DRB still sends on
> >>> VLAN 1 in addition to the VLAN the DRB tells everyone to send
> >>> one). I think the upside over the simplest "just use 1", is
> >>> that it allows a customer that doesn't want RBridge-RBridge
> >>> traffic being used on VLAN 1, or intentionally wants data
> >>> traffic on VLAN 1 to be partitioned on a cloud, to move to a
> >>> VLAN on that cloud that is OK not to be partitioned. The
> >>> downside is that steady state the DRB will send one more
> >>> Hello (on VLAN 1) than it would have, once the DRB tells all
> >>> the other RBridges what VLAN to send on, and it is one more
> >>> configuration thing to have to explain. And it seems likely
> >>> that the DRB will be misconfigured and declare that RBridges
> >>> will use VLAN k instead of 1, when some other RBridge on the
> >>> cloud is not configured to support k. It won't be fatal
> >>> (since that other RBridge will still hear the DRB on VLAN 1
> >>> and will also know about the other DRB through link state
> >>> messages). My opinion is that this extra complexity over
> >>> "just use 1" is not warranted given the small upside.
> >>>
> >>> If there is another proposal, say "send all Hellos on all
> >>> VLANs", I claim that the details of that have never been
> >>> specified well enough for that proposal to be evaluated. So
> >>> if someone who advocates that can do that, staying technical,
> >>> covering all details like whether in your IS-IS Hello you
> >>> list all the VLAN tags you've heard Hellos from for each
> >>> neighbor, and how you send a multicast data message when you
> >>> have adjacencies with different VLAN tags for different
> >>> subsets of neighbors, I'd like to hear it.
> >>>
> >>> And by all means, if I have missed some of the downsides on
> >>> "just use VLAN 1", or "just use a single VLAN, but it can be
> >>> configured to be something other than 1", then by all means
> >>> add to the arguments.
> >>>
> >>> Radia
> >>>
> >>>
> >>>
> >>>
> >>> Silvano Gai wrote:
> >>>
> >>>> I want to restate that IMHO a design that sends messages on
> >>>>
> >>> a single
> >>>
> >>>> VLAN is so week to be completely useless.
> >>>>
> >>>> I met Anoop on a plane back from a T11 meeting and we discussed
> >>>>
> > the
> >
> >>>> issue of sending messages on all the configured VLANs.
> >>>>
> >>> Anoop pointed
> >>>
> >>>> out that, if these messages are ISIS messages, this can
> >>>>
> >>> overload the
> >>>
> >>>> RBrige supervisor.
> >>>>
> >>>> We identified a possible solution based on two different
> >>>>
> >>> message types:
> >>>
> >>>> - ISIS used on a single VLAN to compute adjacency
> >>>> - simple per-VLAN checking on all the VLANs to verify
> >>>>
> > reachability.
> >
> >>>> The second kind of messages is much simpler and therefore they
> >>>>
> > load
> >
> >>>> less the RBrige supervisor. In the future, per-VLAN checking can
> >>>>
> > be
> >
> >>>> implemented by the port ASIC. This seems a viable solution that
> >>>> requires design effort, but it is promising.
> >>>>
> >>>> Without the per-VLAN checking, running ISIS on a single VLAN
holds
> >>>> water like a pasta-strainer.
> >>>>
> >>>> -- Silvano
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: rbridge-bounces at postel.org
> >>>>>
> >>> [mailto:rbridge-bounces at postel.org]
> >>>
> >>>> On
> >>>>
> >>>>
> >>>>> Behalf Of Anoop Ghanwani
> >>>>> Sent: Monday, October 22, 2007 11:01 AM
> >>>>> To: Radia Perlman; Developing a hybrid router/bridge.
> >>>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags
> >>>>>
> > onRBridge-
> >
> >>>>> RBridgepackets?
> >>>>>
> >>>>>
> >>>>> If we want to make implementations work with only a single
> >>>>>
> >>> Hello for
> >>>
> >>>>> all VLANs than the option is (a).  I think that is what it
> >>>>>
> >>> should be.
> >>>
> >>>>> Basically, as a part of RBridge configuration there should be a
> >>>>> "RBridge Control VLAN" configuration that applies to the whole
> >>>>> device.  It should default to VLAN 1, but an operator can
> >>>>>
> >>> choose to
> >>>
> >>>>> change it.
> >>>>> A RBridge only emits Hellos on that VLAN.  If it receives
> >>>>>
> >>> Hellos on
> >>>
> >>>>> any other VLAN that should be detected as an error condition and
> >>>>> reported.
> >>>>>
> >>>>> There have been some problem corner cases that have been
> >>>>>
> >>> pointed out
> >>>
> >>>>> previously on the list that may result in temporary duplication
> >>>>>
> > of
> >
> >>>>> traffic when there is misconfiguration.  Those should be
> >>>>>
> >>> documented.
> >>>
> >>>>> Anoop
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: rbridge-bounces at postel.org
> >>>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> >>>>>> Sent: Saturday, October 20, 2007 9:47 PM
> >>>>>> To: Developing a hybrid router/bridge.
> >>>>>> Subject: [rbridge] Final outcome of outer VLAN tags on
> >>>>>> RBridge-RBridgepackets?
> >>>>>>
> >>>>>> I'm not sure I understood the final consensus on what we
> >>>>>>
> >>> should do
> >>>
> >>>>>> for outer VLAN tags on inter-RBridge packets.
> >>>>>>
> >>>>>> The possibilities I think the consensus might have been are:
> >>>>>>
> >>>>>> a) only use VLAN 1, explicit tag, no configuration possible.
> >>>>>> b) default is VLAN 1, explicit tag, configuration is possible
to
> >>>>>> change sending with VLAN tag(s) something other than 1.
> >>>>>>
> >>> If this is
> >>>
> >>>>>> what was decided, I don't believe we've worked out the design
> >>>>>> details. I'd assume this would mean RBridges should be willing
> >>>>>>
> > to
> >
> >>>>>> receive packets from other RBridges regardless of outer VLAN
> >>>>>>
> > tag.
> >
> >>>>>> Would we then mark in the Hellos what VLAN tag(s) you've
> >>>>>>
> >>> heard from
> >>>
> >>>>>> what other RBridges with? What do we do with multicast if there
> >>>>>> isn't a single VLAN tag that seems to work to send to everyone?
> >>>>>> Would we allow configuration to send on a set of VLAN
> >>>>>>
> >>> tags, or just
> >>>
> >>>>>> on one at a time (and we allow configuration to say which one
it
> >>>>>> is)?
> >>>>>>
> >>>>>> Certainly a) is simpler. If the consensus was b), we'd
> >>>>>>
> >>> better work
> >>>
> >>>>>> out the details.
> >>>>>>
> >>>>>> 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
> >>>>>
> >>>>>