[rbridge] A "multiple VLAN Hello" proposal

[Eric Gray]

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
>