[rbridge] A "multiple VLAN Hello" proposal

Thu Oct 25 21:43:01 PDT 2007

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