[rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?
Radia Perlman
Radia.Perlman at sun.com
Sat Oct 27 20:58:39 PDT 2007
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:
> 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
>>>>>
>>>>>
More information about the rbridge
mailing list