Subject: [rbridge] Preview of changes for VLANs, etc.

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 05 Nov 2007 14:52:29 -0800

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.

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 5 Nov 2007 15:28:17 -0800

Hi Radia,

I think the proposal is reasonable in that per-VLAN
hellos are now optional (and can be made use of in
certain scenarios).  However, what is not specified
is the recipient behavior.  Can an RBridge choose
to ignore hellos from all other VLANs except the
one it is configured to send hellos on?  It seems
like that should be allowed because it won't do 
anything other than detect misconfigurations that
can also be detected by other means (although 
perhaps taking slightly longer to be detected).

If that recipient behavior is not allowed, we will
still get into scaling issues with having to receive
and process hellos from potentially all VLANs 
configured on a port.

Anoop 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Monday, November 05, 2007 2:52 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Preview of changes for VLANs, etc.
> 
> Based on talking to people, here is how I'm assuming the VLAN 
> stuff will look. The main points are
> 
> 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 
> 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.
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 05 Nov 2007 17:14:53 -0800

Good question. Once an RBridge knows it isn't the DRB, it seems like the 
only
VLAN it should need to send or receive Hellos on is the one that the DRB 
specifies
should be used for interbridge communication.

I think the "safety" case is to maximize the probability that RB1 and 
RB2 can hear
each other if they both believe they are DRB. That was why I was suggesting
that the DRB continue to send Hellos on all the VLANs that it is 
configured to
send Hellos on, which is hopefully a much smaller set than the set of 
VLANs it supports.
In other words, even if an RBridge is configured to accept frames with 
any of the
4000 VLANs on a link, that doesn't mean it would send Hellos on all 
4000. It would
have to be separately configured for the set of VLANs to send Hellos on, 
and hopefully
it would only be configured to send Hellos on a handful of VLANs (3 or 4).

But...if an RBridge is configured to accept frames with any VLAN tag, is 
it burdensome
for it to accept Hellos on any of those VLANs?

Radia

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 5 Nov 2007 17:17:28 -0800

> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Monday, November 05, 2007 5:15 PM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.

> But...if an RBridge is configured to accept frames with any 
> VLAN tag, is it burdensome for it to accept Hellos on any of 
> those VLANs?

It most certainly would be.  Data frames are all processed
in hardware while the hellos would have to make their
way through system bus up the software stack to IS-IS.

Anoop

---

From: riw at cisco.com (Russ White)
Date: Mon, 05 Nov 2007 20:53:30 -0500

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

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

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

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

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

> 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