[rbridge] A "multiple VLAN Hello" proposal

[Radia Perlman]

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
>