[rbridge] Preview of changes for VLANs, etc.

[Russ White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Based on talking to people, here is how I'm assuming the VLAN stuff
> will look. The main points are

I'm a bit confused by this entire thread, and these changes....

> a) single DRB per link (rather than DRB election per VLAN).

I assume this is to reduce overhead by reducing the number of
hello's.... But, then we turn around and make the hellos significantly
larger, and change the format significantly, and we change their
processing significantly.... I don't think there's any savings here.

Further, how does this look in SPF to other devices? Suppose you have
one pnode per link, with multiple vlans:

o Do all the devices on the link advertise themselves as connected to
the pnode? How does the pnode indicate all the vlans it transits, so the
SPF tree will work correctly? Does the pnode advertise one lsp per vlan?
If so, then how does this one pnode per link really save anything?

o What if there is no device that's actually on every vlan on the
segment? Does it act as the pnode for vlans in which it doesn't
participate? How do other is' build a tree in this situation--do they
route through a pnode that's not on the vlan they're building a tree for?

> b) that DRB can delegate to another RBridge on the link the
> job of forwarding VLAN-x data to/from the link.

I think this kills all thoughts of load sharing through any sort of
multiaccess medium. You'll still be able to load share on point-to-point
links, but not across Ethernet, for instance.... Is that an acceptable
tradeoff?

What if an rbridge sends some traffic to the only path on which it can
send traffic for a specific vlan, and the exit point finds the only path
it has is through the rbridge that just sent it the traffic? How do we
resolve this? Do we need ICMP redirects for TRILL?

> 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".

Doesn't this concept of a single "management" vlan on any given link
destroy the ability to see what's going on on a specific vlan throughout
a network? IE, if I want to look at the neighbor adjacencies for vlan x,
I must look at debugs for vlan y, because the hellos are only sent on
vlan y. I find this confusing--it will probably contribute to many hours
of lost network time as engineers try to figure out what "vlan v" is so
they can see what's actually going on.

> 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.

Which kills off any advantages from not sending all those hellos and
doing dis election on all those vlans, doesn't it?

> 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).

This is a lot of complex stuff at layer 2.... Are current chipsets going
to be able to handle all of this? Or have we abandoned the idea of minor
or no modifications in hardware?

> 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.

What if someone's not configured to run on vlan v? What if a box has a
limited number of vlans it can support, and already has that number of
vlans configured? There will probably be an upper limit on support on
any given box, after all, so this is always a possibility as we get into
the virtualization that rbridges will open up as possibilities.

Finally, I see a lot of stuff about welding together vlans with the same
id no matter where they are in the network. I consider this to be a huge
"surprise" problem, at the least, and extremely dangerous, at the
worst.... Just because two vlans are configured with the same id does
not mean they were intended to be in the same broadcast domain.

So, can someone explain why we are doing all of this work, changing
fundamental principles of IS-IS, changing SPF operation, etc.?

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHL8kaER27sUhU9OQRAjcEAKCFZEHG7u6OzBc8ysqc6h5u7IQMIACg9tCG
RBP6jhPZ0HtaYae+XAYg+5A=
=J+a1
-----END PGP SIGNATURE-----