Subject: [rbridge] Final outcome of outer VLAN tags on RBridge-RBridge packets?

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 20 Oct 2007 21:47:10 -0700

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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 22 Oct 2007 11:01:17 -0700

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

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 23 Oct 2007 03:20:34 -0700

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

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

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 23 Oct 2007 07:20:57 -0700

I agree that using a single VLAN solution for IS-IS DRB is weak.
However, I'm skeptical that another protocol that also just sends Hellos
is much more scalabale or better than IS-IS sending only Hellos on all
configured VLANs. 

Dinesh
-- 
?And those who were seen dancing were thought to be insane by those  
who could not hear the music.? -- Angela Monet

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 23 Oct 2007 10:01:17 -0700

Silvano,

If we require the database synchronization step in Radia's
other email (#e) then we don't really need per VLAN messages.

Even if we have per-VLAN messages there will still be
scenarios that will break and we can at best only
detect them.

The only case where I think the per-VLAN scheme has an
advantage over the database synchronization approach
is when you have 2 ports that come up _simultaneously_
on a LAN and those have the misconfiguration problem
of not being able to see each other on the "RBridge
control VLAN".  In that case, depending on the
size of the network and how long it takes an LSP
to propagate, the per VLAN messages may detect the
problem a bit quicker.

Anoop

> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Tuesday, October 23, 2007 3:21 AM
> To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer VLAN tags 
> onRBridge-RBridgepackets?
> 
> 
> 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.
> 
> 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
> 
> 
> > 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
> > 
> should do 
> > > for outer VLAN tags on inter-RBridge packets.
> > >
> > > 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 
> > > 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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 23 Oct 2007 10:04:12 -0700

> From: Dinesh G Dutt [mailto:ddutt at cisco.com] 
> Sent: Tuesday, October 23, 2007 7:21 AM
> To: Silvano Gai
> Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLAN 
> tagsonRBridge-RBridgepackets?
> 
> However, I'm skeptical that another protocol that also just 
> sends Hellos is much more scalabale or better than IS-IS 
> sending only Hellos on all configured VLANs. 

Dinesh,

The key here is just sending hellos as opposed to maintaining
a full IS-IS adjacency on the VLAN.  As long maintaining the
adjancency and sending LSPs on every VLAN is not required, the
protocol that is used for it doesn't matter.

Anoop

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 23 Oct 2007 10:09:52 -0700

I have always thought that we need only Hellos to be per active VLAN so
that we can achieve reachability. I was not planning on sending LSPs per
VLAN. 

Dinesh

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 23 Oct 2007 16:45:42 -0400

Hi Silvano,

I have two questions:

(1) What exactly is the problem you see with doing adjacency on one
VLAN? It could be that you think that Hellos on one VLAN would be OK but
it is too much of a configuration burden to expect network
administrators to figure out which VLAN and to then configure their
Rbridges. Or it could be that you think that even if each port on each
Rbridge was configured to the "best" single VLAN, the adjacencies found
would be too sparse compared to those potentially possible. Or you could
think that both of these and/or other things are the main problem...

(2) If multiple Hellos on different VLANs, or some other technique, are
used to learn the full VLAN connectivity, what are Rbriges supposed to
do when no single VLAN will get to all the desired destinations? For
example, assume that Rbridge-A is connected as follows:

	On VLAN 2 to B and C
	On VLAN 3 to C, D, and E
	On VLAN 4 to F, G, and H
	On VLAN 5 to D, E, F, and G

If Rbrdige-A wants to send a multi-destination frame to all of B through
H, it would seem that it has to send it at least three times to get to
all the one-Rbridge-hop destinations and to avoid duplication. For
example, multicast on VLANs 3 and 4 and unicast to B. Or, alternatively,
multicast on VLANs 2 and 5 and unicast to H. Or, if the complexity
exceeds some threshold, Rbridge-A could just forget about optimality and
unicast the frame separately to B through H.

How would you suggest handling such situations?

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Silvano Gai
Sent: Tuesday, October 23, 2007 6:21 AM
To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Final outcome of outer VLAN
tagsonRBridge-RBridgepackets?

-- Silvano

On

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 23 Oct 2007 14:10:48 -0700

Anoop,

I spoke to David Ward, an IS-IS expert here at Cisco (and a co-author on
the L2 ISIS draft) and he said that it's perfectly fine to use Hellos on
multiple VLANs for discovery and send LSP only on one VLAN, one of the
common ones.

Can we then conclude that by default we send Hellos on a set of one or
more configured VLANs with the set being equal to the active set of
VLANs on that link by default ?

Thanks,

Dinesh

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 23 Oct 2007 16:42:16 -0700

Hi Dinesh,

It doesn't look like it would be essential at
this point, so if we want to put it in for
faster detection of certain configuration problems
then it should be put in as optional.

Anoop 

> Sent: Tuesday, October 23, 2007 2:11 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Radia Perlman; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer 
> VLANtagsonRBridge-RBridgepackets?
> 
> Anoop,
> 
> I spoke to David Ward, an IS-IS expert here at Cisco (and a 
> co-author on the L2 ISIS draft) and he said that it's 
> perfectly fine to use Hellos on multiple VLANs for discovery 
> and send LSP only on one VLAN, one of the common ones.
> 
> Can we then conclude that by default we send Hellos on a set 
> of one or more configured VLANs with the set being equal to 
> the active set of VLANs on that link by default ?
> 
> Thanks,
> 
> Dinesh
> > > However, I'm skeptical that another protocol that also just sends 
> > > Hellos is much more scalabale or better than IS-IS sending only 
> > > Hellos on all configured VLANs.
> > 
> > Dinesh,
> > 
> > The key here is just sending hellos as opposed to 
> maintaining a full 
> > IS-IS adjacency on the VLAN.  As long maintaining the 
> adjancency and 
> > sending LSPs on every VLAN is not required, the protocol 
> that is used 
> > for it doesn't matter.
> > 
> > Anoop
> --
> "And those who were seen dancing were thought to be insane by 
> those who could not hear the music." -- Angela Monet
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 24 Oct 2007 10:11:19 -0700

Anoop,

I disagree.

We started all this discussion because you said that sending LSP on all
the VLANs was not scalable.

Now we discovered that there is a standard, existing solution that uses
Hellos on multiple VLANs for discovery and send LSP only on one VLAN.

This solution is robust and not subject to the corner cases that are
possible if you don't send Hellos on all the VLANs.

Let's use it, not invent anything new and close this topic.

-- Silvano

> From: Anoop Ghanwani [mailto:anoop at brocade.com]
> Sent: Tuesday, October 23, 2007 4:42 PM
> To: Dinesh G Dutt
> Subject: RE: [rbridge] Final outcome of outer VLANtagsonRBridge-
> RBridgepackets?
> 
> Hi Dinesh,
> 
sends

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 24 Oct 2007 10:13:06 -0700

Donald,

My concern is misconfiguration.

If we don't send at least a simple Hello per VLAN misconfigurations go
undetected and can cause frame duplication.

See also my latest reply to Anoop: we don't need to send an LSP.

Whatever scheme that sends frames only on one VLAN cannot detect VLAN
misconfiguration by definition.

We have a simple and tested solution: "Let's send Hellos on all VLANs
for discovery and LSP only on one VLAN."

This solves the issue of Anoop, of not sending multiple LSPs.

Let's use it

-- Silvano

P.S. I'll not be able to make the December TRILL meeting, since it is at
the same time as T11/FCoE. Dinesh can present a slide set with the most
important issues related to misconfiguration.

> From: Eastlake III Donald-LDE008 [mailto:Donald.Eastlake at motorola.com]
> Sent: Tuesday, October 23, 2007 1:46 PM
> To: Silvano Gai
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Final outcome of outer VLAN tagsonRBridge-
> RBridgepackets?
> 
> Hi Silvano,
> 
> I have two questions:
> 
On

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 24 Oct 2007 14:42:06 -0700

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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 24 Oct 2007 14:42:00 -0700

Silvano,

I am not opposed to using per-VLAN connectivity
detection (which we're saying should be done by
hellos) if it is shown to be absolutely essential.
As long as there is a way around it, I prefer to
avoid having to send them.

We should probably delay the decision until
we understand what scenarios make it an absolute
requirement before we make it such.

Anoop

> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> Sent: Wednesday, October 24, 2007 10:13 AM
> To: Eastlake III Donald-LDE008
> Subject: Re: [rbridge] Final outcome of outer 
> [mailto:rbridge-bounces at postel.org]
> > On
> > > Behalf Of Anoop Ghanwani

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 25 Oct 2007 09:25:26 -0700

Radia,

I am currently in Italy with limited connectivity. I'll write you a more
complete reply next week.

I have also the additional issue that I find hard to discuss these
topics by email. I prefer face-to-face meeting in front of a whiteboard.

Anyhow, let me try

I think that the root of the disagreement is in the priority of the
requirements.

For me and others robustness and interoperability are paramount, because
we look at TRILL in the Enterprise/Datacenter where there is no margin
for errors, even in the presence of misconfigurations. Moreover we want
to use ISIS unmodified with just few TLV added. If the price to pay for
this solution is to use a "robust" CPU for the RBridge supervisor, we
are happy to pay the price. Dinesh will present at the next IETF
robustness and interoperability issues.

For Anoop, loading the supervisor switch as little as possible is
paramount. He seems to look more at green field installation, where
interoperability and robustness to misconfiguration are somehow
important, but not paramount.

This difference in requirements causes differences in the preferred
solution:
- I prefer to use the standard ISIS with Hellos on all VLANs for
discovery and LSP only on one VLAN.
- Anoop prefers to not send the Hellos on all VLANs for discovery and he
is willing to follow your lead to somehow modifying ISIS, adding
additional steps to check Spanning tree roots, synchronize LSP
databases, etc.

When you have done all the changes that you propose to ISIS, I am not
sure that we are using "an existing routing protocol" (as per TRILL
charter), I think we have designed something new.

Summarizing my goals are:
- Robustness
- Interoperability
- Unmodified ISIS (e.g. no synchronization steps)

My solution is to use what ISIS provides, i.e.
- Hellos on all configured VLANs for discovery and LSP only on one VLAN.

-- Silvano

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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 25 Oct 2007 10:19:47 -0700

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

> Subject: Re: [rbridge] Final outcome of outer VLAN tags 
> 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.
> 
> 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.
> 
> 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:
> > 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.
> >
> > 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
> >
> >
> >   
> >> "RBridge Control VLAN" configuration that applies to the whole 
> >> device.  It should default to VLAN 1, but an operator can 
> choose to 
> >> change it.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 25 Oct 2007 11:07:14 -0700

We should definitely arrange a phone call when you get back, though I've 
heard a rumor there
are phones in Italy. :-)

I do not understand most of what you said below.

a) unmodified IS-IS: I fail to see why sending IS-IS Hellos on more 
VLANs is "less of a change" to IS-IS. I'm
guessing, but perhaps you are suggesting that if we send Hellos on all 
the VLANs then
we don't need to report the bridge root ID in the LSP or do the
other safeguards (e.g., not decapsulating from ingress R1 unless you 
have checked all the
pseudonodes that R1 is attached to to ensure R1 isn't reporting the same 
root bridge ID).
I believe these safeguards are not complex or expensive and should be
done no matter how many VLANs we send Hellos on.

b) robustness:  I believe that the single VLAN proposal *is* robust.
Furthermore, I believe that if there is a cloud with lots of RBridges 
configured for sending
and receiving on different subsets of VLANs, there is more likelihood of 
problems,
especially if the "multiple VLAN proposal" (details still to be 
specified) does *not* include
the root bridge ID in LSPs and the other safeguards.

c) interoperability goal: I believe making fewer things configurable is 
the greatest way of
enhancing interoperability

That said....I was trying to imagine what a "send on multiple VLANs" 
proposal could possibly be.
TRILL never worked it out -- my fault to a large extent since I hadn't 
been following the
kinds of configuration that have been added to bridges that encourage 
partitioned VLANs on
a cloud. Thank you, Anoop, for noticing. I think what we'd been assuming 
was that you'd
form adjacencies based on VLAN tag, and R1 and R2 might talk with VLAN 
A, and
R2 and R3 might talk with VLAN B, etc., on the same cloud. This not only 
multiplies
the number of pseudonodes, but as Don pointed out, doesn't work with 
forwarding multicast data.

So, I'll write a separate note with a proposal for multiple VLANs that 
might be palatable.

Radia

Silvano Gai wrote:
>> It's always hard to catch up on a thread after being away from email
>>     
> for
>   
>> a couple of days, but
>> and also is completely uninformative because you are not saying what
>>     
> the
>   
>> tradeoffs are, or
>> tradoffs are without resorting to bullying and ridicule. Let's strive
>>     
> to
>   
>> do engineering that way.
>>
>> traffic, they could reconfigure use of the VLANs to move what they
>>     
> were
>   
>> using VLAN 1
>> prevent them from accomplishing all the exotic things they are trying
>>     
> to
>   
>> do -- just means
>> 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
>   
>> have to explain. And it seems likely that the DRB will be
>>     
> misconfigured
>   
>> and declare that
>> 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
>> "just use a single VLAN, but it can be configured to be something
>>     
> other
>   
>> than 1", then
>>> 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:
>   
> less
> requires
> water

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 26 Oct 2007 02:16:13 -0700

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

> Sent: Thursday, October 25, 2007 10:20 AM
> To: Radia Perlman; Silvano Gai
> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-
> RBridgepackets?
> 
> 
> Hi Radia,
> 
onRBridge-

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 27 Oct 2007 20:58:39 -0700

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

Are you saying that you don't want to require customers to have *any* 
VLAN number that
isn't partitioned, and you want a solution that somehow finds all 
possible ways of having
RBridges talk to each other using every possible VLAN? 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:
>>> messages on a single unconfigurable VLAN (proposal being VLAN 1)
>>>       
> are:
>   
>>>> I want to restate that IMHO a design that sends messages on
>>>>         
>>> a single
>>>       
>>>> I met Anoop on a plane back from a T11 meeting and we discussed
>>>>         
> the
>   
>>>> We identified a possible solution based on two different
>>>>         
>>> message types:
>>>       
>>>> - 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
>   
>>>>> A RBridge only emits Hellos on that VLAN.  If it receives
>>>>>           
>>> Hellos on
>>>       
>>>>> previously on the list that may result in temporary duplication
>>>>>           
> of
>   
>>>>> traffic when there is misconfiguration.  Those should be
>>>>>           
>>> documented.
>>>       
>>>>> Anoop
>>>>>
>>>>>
>>>>>           
>>>>>> details. I'd assume this would mean RBridges should be willing
>>>>>>             
> to
>   
>>>>>> receive packets from other RBridges regardless of outer VLAN
>>>>>>             
> tag.
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 28 Oct 2007 04:49:05 -0700

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:

> Sent: Saturday, October 27, 2007 8:59 PM
> To: Silvano Gai
> 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
> 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.

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

> 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
> >>>> Without the per-VLAN checking, running ISIS on a single VLAN
holds
to