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

[Silvano Gai]

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