[rbridge] Preview of changes for VLANs, etc.

[Radia.Perlman@sun.com]

Russ,

The way to look at it is that the VLAN tag with which RBridges talk to each other on one link is
irrelevant outside the link. So really...one pseudonode, and one VLAN per link
for interRBridge communication is a simplification. Really. Though I'm
not surprised if my sketch of a design might have not been self-explanatory.

Let me try to explain a bit more, and from an IS-IS point of view. If this isn't
clear, or if you still have concerns,
then we (you and I) can have a quick phone call (are you available tomorrow afternoon?),
or you can wait until
you see the details in the spec. Or you can ask another question on the list.

a) all RBridges on a link can talk to each other using a single (outer) VLAN tag, and
that VLAN is not allowed to be partitioned. If it is, whichever RBridges can't talk
to the DRB on that VLAN are just orphaned. All the other RBridges send IS-IS
messages (Hellos, LSPs, CSNPs) on that link tagged with the one VLAN tag.

b) All RBridge-RBridge links can be used as transit for data that
belongs on any VLAN. So a data packet from VLAN x on one link destined
to VLAN x on some other link in the campus can transit any RBridge-RBridge
link (say from R2 to R3) regardless of what VLAN tag R2 has to slap on the
outside of the frame in order to carry the frame from R2 to R3.

c) the only time VLANs are relevant, in terms of IS-IS forwarding, is when
pruning multicast (you don't have to send down a branch if none of the links
at the end of that branch support that VLAN. But for sending unicast...you
are sending to the specified egress RBridge. The forwarding RBridge
does not care at all what the inner VLAN is. It also doesn't care
what VLAN tag R3 has to tack on in order to forward it across the next
hop to R4.

e) A LAN will have a single DRB. A single pseudonode. No VLANs or
endnodes are
associated with the pseudonode.  Endnodes and VLANs are
only associated with RBridges. If R1 is DRB for pseudonode R1.25,
then R1.25's LSP only lists the other RBridges attached to R1.25.
Whatever RBridge R2 is appointed by R1 to forward VLAN x traffic
to/from pseudonode R1.25 will specify in R2's LSP, "I, R2, am
attached to VLAN x". R2 might even have lots of links attached
to VLAN x. But R2 just says in R2's LSP "I am attached to VLAN x".

f) Hellos shouldn't have to be bigger with this proposal. What's in a Hello?
. my ID
. my priority for becoming DRB
. name of the pseudonode if I am DRB
. VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB
. set of neighbors I've heard Hellos from on the specified
VLAN tag (V)
. flag "please send CSNP" used when starting up, to ensure that
you have synchronized LSP databases with your neighbors

Now there might also be the following in the Hello:
. "Bidding for VLANs": If I'm not DRB, set of (priority, {set of VLAN tags}) that I would like
to be assigned to en/decapsulate for
. "VLAN assignments" If I am DRB, en/decapsulator assignments, of the form
(RBridge neighbor ID, {set of VLANs}) that I want that RBridge
to encapsulate/decapsulate for.

I think we could come up with reasonably compact encodings for those. Though
they don't really have to be in the Hello. Instead, especially the "bidding"
part could be in a separate message to the DRB.  I like having the
DRB specify assignments in its Hello, though, to ensure there is no confusion.
I'd think that 99% of the time there would be no assignments, and the DRB itself
would be the encapsulator/decapsulator for all VLANs on that link.


Hope that's clearer...

Radia

----- Original Message -----
From: Russ White <riw at cisco.com>
Date: Monday, November 5, 2007 5:53 pm
Subject: Re: [rbridge] Preview of changes for VLANs, etc.

> -----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-
> pointlinks, but not across Ethernet, for instance.... Is that an 
> acceptabletradeoff?
> 
> 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 
> pathit 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 
> throughouta 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 
> hoursof 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 
> goingto 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 
> intothe virtualization that rbridges will open up as possibilities.
> 
> Finally, I see a lot of stuff about welding together vlans with the 
> sameid 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-----
>