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

Thu Oct 25 11:07:14 PDT 2007

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