[rbridge] A "multiple VLAN Hello" proposal

[Silvano Gai]

Donald,

We need to face the reality that the only solution that works is to send
a Hello per VLAN.

We are in the version one of the protocol, we should use well know
solutions and look at optimizations in future versions, when we have
implementation experience.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, October 28, 2007 1:02 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Eric,
> 
> There is currently no provision for fragmenting Hellos. If different
> Rbridges are gong to have different priorities for becoming DRB for
> different VLANs the current IS-IS election style would say that that
> information has to go into the Hello PDUs. If bits maps are better
than
> ranges, we could use those.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray [mailto:eric.gray at ericsson.com]
> Sent: Sunday, October 28, 2007 1:29 PM
> To: Radia Perlman; Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] A "multiple VLAN Hello" proposal
> 
> Radia,
> 
> 	Using sets of VLANs as a range of values is likely to force
> sub-optimality on load-sharing - possibly to the extent that load
> sharing becomes useless.
> 
> 	It is not a trivial exercise to make VLAN topologies line up
> conveniently with VLAN ID assignments.  In fact, assuming that it
> is possible to modify VLAN topologies, it's most likely infeasible
> to do so in some scenarios.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org
> > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> > Sent: Friday, October 26, 2007 1:26 AM
> > To: Eastlake III Donald-LDE008
> > Cc: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> >
> > Right...I was not intending to preclude having R1 be DRB for (inner)
> > VLANs (v1, v2, v3) and
> > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you
> > point out, if
> > each RBridge can
> > be configured with a different priority for each of the 4000
> > VLANs, the
> > IS-IS Hello would
> > get too large. The only reason for different priorities is to do
some
> > load splitting. I'd argue
> > that with just a tiny bit of flexibility customers can get enough
> > functionality. So I'd suggest
> > limiting multiple priorities to some reasonable number, like
> > 3, and sets
> > of VLANs to ranges.
> > That would mean that R1 can claim to have priority P1 for the
> > VLANs in
> > range (n1-n2), and
> > priority P2 for the VLANs in range (n3-n4), and priority P3 for
VLANs
> > betwen (n5-n6).
> > This would require (for 3 different priorities) 18 bytes in
> > the Hello.
> > For instance, "I have
> > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and
> > priority 2 for
> > VLANs (101-115). Perhaps another 500 bytes to do a bit mask
> > of all the
> > VLANs that
> > you support at all (or alternatively you can't claim to have
> > a priority
> > for a range of VLANs unless
> > you support all the VLANs in that range).
> >
> > Likewise, in the pseudonode, we'd have to say the range of VLANs
that
> > that pseudonode
> > refers to.
> >
> > And it's NOT a DRB collision if there is a pseudonode, say R1,17,
> > for which R1 is DRB, reporting root bridge X
> > and R2 is DRB on a link with root bridge X as long as the set
> > of VLANs
> > reported
> > in R1.17's LSP does not overlap with the set of VLANs that R2
> > is DRB for
> > on that link.
> >
> > And actually, R2 really only needs to decline to forward data (act
as
> > DRB) for the set of
> > VLANs in R1.17's pseudonode that overlaps with R2's. It could
> > be that R2
> > has some
> > other VLANs that are not in R1.17's pseudonode.
> >
> > So that's an additional refinement on the rules that should be
added.
> >
> > Perhaps we should start a different thread on whether people can
live
> > with having a single
> > DRB be configured with at most 3 priorities on a port, and
> > require the
> > set of VLANs for
> > each priority to be expressible in a range (rather than having to
> > enumerate each of the
> > VLAN tags individually).
> >
> > Radia
> >
> >
> >
> > Eastlake III Donald-LDE008 wrote:
> > > Hi Radia,
> > >
> > > The proposal below appears to be written from the "one DRB per
link"
> > > point of view while the current draft claims to support "one DRB
per
> > > VLAN per link". Even if you have complete VLAN 1
> > connectivity and use
> > > single Hellos, I'm not quite sure how the one DRB per VLAN per
link
> > > would work. In principle, the per VLAN priority for a
> > Rbridge port for
> > > all its configured VLANs might not fit into a Hello...
> > >
> > > Thanks,
> > > Donald
> > >
> > > -----Original Message-----
> > > From: rbridge-bounces at postel.org
> > [mailto:rbridge-bounces at postel.org] On
> > > Behalf Of Radia Perlman
> > > Sent: Thursday, October 25, 2007 2:56 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] A "multiple VLAN Hello" proposal
> > >
> > > It's a bit difficult to argue on the list about proposals
> > when one of
> > > them has not been specified, especially
> > > since I can imagine lots of variations on multiple VLANs,
> > and lots of
> > > questions about choices for
> > > the details.
> > >
> > > Here's an attempt to specify a "send Hellos on multiple
> > VLANs" proposal.
> > >
> > > I've chosen details
> > > where in many cases there are other options I could have
> > chosen. But I
> > > think we need some
> > > tangible proposal with details worked out before advocating for
it.
> > > People should feel free
> > > to suggest modifications to the details below, but I, as I
> > said, cannot
> > > argue between proposals
> > > if the proposals aren't concrete. I've tried to make it as
> > simple as
> > > possible, as low overhead
> > > as possible, while adding the ability to configure sending
> > Hellos on
> > > lots of VLANs.
> > >
> > >
> > > a) RBridges send and receive IS-IS Hellos on VLAN 1
> > >
> > > b) In addition, RBridges MAY be configured to send and
> > receive Hellos on
> > >
> > > some set of
> > > VLANs in addition to 1
> > >
> > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all
> > the VLANs that
> > > R1 is
> > > configured to send (and receive) on. To clarify, as long as
> > R1 thinks
> > > itself is DRB, it will
> > > send Hellos on the complete set of VLANs that R1 is
> > configured to send
> > > on. In addition (see
> > > point "e"), R1 may wind up having to send Hellos on some
> > set of VLANs in
> > >
> > > addition
> > > to those it was configured to send on.
> > >
> > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1
has
> > > heard Hellos from. In addition,
> > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN
> > that R1 hears
> > >
> > > hellos from R2 on.
> > > The one VLAN that R1 reports is the lowest numbered VLAN
> > that R1 hears a
> > >
> > > Hello from R2 on.
> > >
> > > e) If R1 does not hear a Hello from R2 on any of R1's
> > configured VLANs,
> > > but does hear on some other VLAN, say VLAN x, then R1 adds
> > "x" to the
> > > set of VLANs that
> > > R1 transmits on, as long as it continues to hear Hellos on
> > VLAN x (and
> > > no
> > > other VLANs) from R2. Note that if R2's Hello gives R2
> > better priority
> > > for
> > > being DRB, then R1 will not be DRB any more, but MUST
> > continue sending
> > > Hellos on
> > > VLAN x (even though x is not in the set of VLANs
> > > that R1 was configured to send on) to ensure that R2
> > continues to send
> > > its Hellos on VLAN x.
> > >
> > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus
> > the VLAN
> > > that the DRB reports
> > > that it has heard from you on. This cuts down on Hellos
> > since it means
> > > that non-DRB RBridges
> > > will send on at most two VLANs.
> > > {Note: An alternate option would have had every RBridge send
Hellos
> > > always on all VLANs they
> > > have been configured to send on}.
> > >
> > > f) all RBridge-RBridge traffic (other than Hellos) is
> > always sent on
> > > VLAN 1. So if R2 cannot
> > > reach the DRB via VLAN 1, then R2 cannot forward data to/from that
> > > cloud, or receive
> > > LSPs on that cloud. In other words, that link will be
> > broken for R2. The
> > >
> > > purpose
> > > of the Hellos is only to notice (through a means *in
> > addition* to the
> > > safeguards in the other
> > > proposals)  that R2 is not DRB for the link.
> > >
> > > g) We do the same safeguards as in the other proposals (report the
> > > bridge root ID in the pseudonode LSP, don't decapsulate
> > from ingress Ra
> > > unless
> > > you have all the relevant pseudonode LSPs attached to Ra to
> > ensure that
> > > none of them have
> > > the same root RBridge, and that you delay before
> > encapsulating data off
> > > the link until you've
> > > been DRB for enough time to synchronize LSP databases with your
> > > neighbors)
> > >
> > > **************
> > > My thoughts on this:
> > >
> > > a) I assume the only reason to send Hellos on multiple VLANs is to
> > > minimize the probability
> > > of accidentally having two DRBs, and therefore loops. I'm
> > not convinced
> > > this adds safety
> > > over the safeguards in the single VLAN proposals.
> > >
> > > b) this winds up with sending lots more Hellos, but does not
create
> > > additional pseudonodes,
> > > or complicate data forwarding, because the Hellos is only to find
> > > neighbors, not to repair
> > > use of the link for forwarding data (or propagating LSPs)
> > if VLAN 1 is
> > > partitioned on the link
> > >
> > > c) This is a lot more complicated. It might seem simpler to
> > not try to
> > > optimize the number of
> > > Hellos (like I did in point e), but there seem to be scary
> > corner cases
> > > where all the VLANs
> > > common to R1 and R2 are partitioned. Saying there must be an
> > > unpartitioned VLAN 1 seems
> > > the safest.
> > >
> > > So, I still like the "just use VLAN 1" proposal.
> > > _______________________________________________
> > > 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
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge