[rbridge] Ambition with different VLAN configurations

[Radia.Perlman@sun.com]

This goes along with the previous question I just posted, with subject line
"Final outcome of outer VLAN tags on RBridge-RBridge    packets?"

After rereading the thread with this subject line, there were a few 
"Hmm, have to think
about that" comments, and one person who seemed unhappy with
not letting the VLAN be configurable, and then the thread seemed to just
peter out.
So I will
reiterate what I think the details of the proposal are, along with
a counterproposal if people *really* want it configurable. Though I
prefer not configurable. Before editing the spec, I would like people
to explicitly say whether they're happy with the proposal below, or
if not, whether they're happy with the additional proposal below the
line of stars, and perhaps they could say "I could live with either, I
prefer nonconfigurable", or "I could only live with configurable, and
am OK with the proposal below the stars", or "I don't like either one
because....and I'd like to counterpropose ..."

Thanks.....Radia

---------Nonconfigurable proposal-------

a) on each layer 2 cloud, all RBrdge-RBridge communication (including
IS-IS Hellos and encapsulated data packet forwarding) will be sent with

one VLAN tag, VLAN 1, with an explicit outer VLAN tag. This would not be configurable.
Therefore we would not need to worry about the case where there are different
configurations of RBridges on the same cloud.

b) it will be a MUST to listen to spanning tree messages and include the 
root bridge ID
in the pseudonode LSP. Note that "listening to" either STP or RSTP is identical.
In other words, an RBridge does not need to know or care whether the bridges
are running STP or RSTP. As for MSTP, the only spanning tree RBridges need
to listen to is the CIST (common and internal spanning
tree). The only root bridge RBridges would report (in the case of MSTP) is
the root bridge of the CIST.

c) if R1 notices (in the link state database)
a pseudonode with a root bridge that is the same as a 
link that R1 thinks
R1 is designated on, R1 does not forward data to/from that link if R1's 
6-byte IS-IS ID
is less than the ID of  the DRB for that pseudonode

d) if R1 is DRB on a link, R1 will not decapsulate anything onto the 
link from ingress R2 unless
R1 has received an LSP from R2 and all pseudonodes that R2 (in R2's LSP)
claims to be  attached to,
and that R2 claims to be DRB for

e) when R1 first comes up, it waits some amount of time on a link before 
deciding that it is DRB
(several Hello intervals), and after becoming DRB, it still does not 
forward data off the link until
it has synchronized LSP databases with its neighbors. "Synchronizing" 
means that it receives
a CSNP from the neighbor, and winds up with LSPs at least as up-to-date 
as those reported
in that CSNP. (Note: I think it would be a good idea to have a flag in 
the Hello message saying "I'd
like to receive a CSNP from you" in case the neighbor sent one and it 
got lost -- on a LAN,
the DRB should be sending them periodically, but if we have pt-to-pt 
links at least in current IS-IS,
CSNPs are not sent periodically, though we could say RBridges should 
send them periodically
on pt-to-pt links.)

********************

--------Proposal adding configurability-------

If we *had* to make the VLAN in a) configurable, this is a suggestion for
how to do it:
1) steady state on any VLAN cloud, all the RBridges would transmit on
only one VLAN tag, and all would be using the same VLAN tag


2) the default would be VLAN 1

3) all RBridges would be willing to receive IS-IS Hellos with
any VLAN tag (or maybe some subset that is configurable, that must
always contain VLAN 1)

4) The DRB states in its Hello, what VLAN tag is to be used. If the
DRB says "use VLAN 7", then all RBridges must switch to using VLAN tag 7,
until they no longer hear that DRB's hellos. If
they no longer hear the DRB's Hellos, (which means they think they
are DRB at least temporarily) they revert
to whatever they are configured to send on. "use VLAN 7" means
that *all* RBridge-RBridge communication (data packet forwarding and
IS-IS Hellos) will be sent using VLAN tag 7. Except (as noted in 6) below)
the DRB will send its Hellos both on 7 and 1. (The reason I said this is
that I think it might be safer).

5) The default is to send on VLAN 1. If you are configured to send on 7,
then you send on *both* VLAN 1 and VLAN 7, until you are told
by the DRB what to send on, and then you send ONLY on that one (whether
it be 1, 7, or something else)

6) if you are DRB, and you are configured to send on 7, you always send
both on 1 and 7, and report in your Hello "send on 7", which will cause
all the other RBridges to send Hellos *only* on 7, where you will send
on 1 and 7. You only report, in your Hello, the list of other RBridges
on that cloud that you successfully hear Hellos from on 7 (even if
you hear Hellos from them on 1 or some other VLAN tag)

*However* I still recommend making VLAN 1 *not* configurable. I'd think
if a customer is willing to do fancy configuration, and wanted to keep
RBridge-RBridge traffic off VLAN 1, or wanted VLAN 1 to be partitioned
on a layer 2 cloud, then that customer could renumber the use of their VLANs
to make VLAN 1 be one that is not partitioned, and that is OK to send
RBridge traffic on.

But at any rate -- I want to make sure we all agree to one design.

Radia




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20071022/112a453c/attachment.html