[rbridge] Preview of changes for VLANs, etc.
Radia Perlman
Radia.Perlman at sun.com
Mon Nov 5 14:52:29 PST 2007
Based on talking to people, here is how I'm assuming the VLAN stuff
will look. The main points are
a) single DRB per link (rather than DRB election per VLAN).
b) that DRB can delegate to another RBridge on the link the
job of forwarding VLAN-x data to/from the link.
c) RBridges MAY be configured to send Hellos on a set of VLANs,
though VLAN 1 is the default. They are also configured with a single
preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other RBridges
on the link to send ALL RBridge-Rbridge traffic (Hellos, LSPs,
forwarded encapsulated data traffic) with outer VLAN tag "V".
d) For safety, the DRB RB1 continues to send Hellos not only on V,
but on all the VLANs that RB1 is configured to send Hellos on.
e) The set of VLANs that RB1 is configured to support on the link
may be greater than the set of VLANs that RB1 is configured to
send Hellos on
f) We use all the link-avoidance stuff we'd discussed before (don't
decapsulate from ingress RBx unless you have RBx's LSP and all pseudonodes
that RBx claims to be attached to, and can verify that none of them
have the same root bridge ID as the link you are about to decapsulate
onto -- also, be conservative about when you start encapsulting data
off the link by waiting a few Hello intervals, and waiting until
you've synchornized LSP databases with your neighbors).
g) IS-IS Hellos list the set of neighbors from which Hellos are heard.
Once the DRB RB1 specifies "V" as the VLAN, the only neighbors listed
in IS-IS Hellos are those from which a Hello is received on VLAN V.
More information about the rbridge
mailing list