Subject: [rbridge] Ambition with different VLAN configurations

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 12 Sep 2007 10:43:37 -0700

The list has had discussions on how to do hellos with VLANs, and the 
discussion makes me wonder whether we have agreement on the level of 
ambition with various unusual VLAN configuration in the bridged LANs.

By "ambition" I mean whether in a particular case we should:
1. Make RBridges provide full connectivity for all the nodes in the 
bridged LAN
2. Make RBridges at least detect that there is something odd about the 
VLAN configuration and ensure that no permanent loops can be formed. But 
it would be ok to orphan some nodes from communicating.

One can ask that question for different VLAN scenarios.
One interesting case that Donald brought up is when there isn't a single 
VLAN tag on which all the RBridges can communicate.
For instance, RB0 and RB1 can only send and receive using VLAN tag 3.
RB2 can only send and receive using VLAN tag 4.
RB3 and RB4 can send and receive using both VLAN tag 3 and 4.

There are different schemes for making hellos detect the connectivity in 
this case. So let's ignore that and instead look at the implications on 
the data plane if we want ambition #1.

Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag 
should it use? There isn't a single VLAN tag that it can use whichever 
reach all RBridge neighbors. But RB4 can't treat the port as two 
logically different ports (one for VLAN tag 3 and a separate one for 4) 
either, since RB2 is a neighbor for both VLANs.
Thus if we wanted this case to provide full connectivity it would seem 
like the data plane would need to be able to duplicate packets and send 
some unicast; a possible strategy would be to multicast with tag 3, and 
then unicast a copy to RB2 (with tag 4). That way all the neighboring 
RBridges would receive the frame.

That sounds complex.

There might be other examples of odd VLAN configuration (such as bridges 
which untag and then add some other tag when forwarding the frame) which 
are complex to fully support. What level of ambition should we have for 
the odd cases?

    Erik

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 14 Sep 2007 12:17:39 -0700

. I think we should only make sure that in odd configurations there are 
no loops. We should
not worry about partitions caused by nontransitive connectivity.

. I think we should go to some amount of trouble to ensure there are not 
even temporary loops (not
just "no permanent loops".

. It would be nice to say "never ever have any loops", but I don't think 
that's possible, given
repeaters coming up, messages getting lost, a bridge or RBridge 
exhibiting bizarre behavior
due to some bug, etc. That has nothing to do with TRILL -- any design 
might occasionally
wind up with a loop in low probability events, and we should make sure 
that the probability
is very low and minimize the length of time/effect if things go wrong.

. I prefer a design in which there should be one VLAN tag (the default 
one) that
is not partitioned on a layer 2 cloud, and all RBridge-RBridge 
communication on that cloud
(including Hello messages)
should have that VLAN tag on the outside, and if that VLAN is indeed 
partitioned, then
all but one RBridge, even if elected to be DRB on some set of VLANs, 
will refrain from
forwarding data to/from the link.

Radia

Erik Nordmark wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 14 Sep 2007 16:39:28 -0700

I concur with Radia on all points.

Anoop 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Friday, September 14, 2007 12:18 PM
> To: Erik Nordmark
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 15 Sep 2007 07:50:07 -0700

In the spirit of making progress, I am OK with this with the addition
that:

1) we don't generate BPDUs trying to become the root of the Spanning
Tree.

2) we don't care about temporary loops generated by repeaters (repeaters
don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops.

3) Frame duplication is also a big deal, clearly unacceptable in steady
state, need to be analyzed carefully in transient: better to drop than
to duplicate.

-- Silvano

> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Sat, 15 Sep 2007 17:24:01 -0700

I agree to Radia's points with the addition of Silvano's points,

Dinesh
Silvano Gai wrote:
>> . I think we should only make sure that in odd configurations there
>>     
> are
>   
>> no loops. We should
>> . I think we should go to some amount of trouble to ensure there are
>>     
> not
>   
>> . It would be nice to say "never ever have any loops", but I don't
>>     
> think
>   
>> that's possible, given
>>> ambition with various unusual VLAN configuration in the bridged
>>>       
> LANs.
>   
>>> 2. Make RBridges at least detect that there is something odd about
>>>       
> the
>   
>>> VLAN configuration and ensure that no permanent loops can be formed.
>>>       
> But
>   
>>> One interesting case that Donald brought up is when there isn't a
>>>       
> single
>   
>>> For instance, RB0 and RB1 can only send and receive using VLAN tag
>>>       
> 3.
>   
>>> There are different schemes for making hellos detect the
>>>       
> connectivity in
>   
>>> this case. So let's ignore that and instead look at the implications
>>>       
> on
>   
>>> should it use? There isn't a single VLAN tag that it can use
>>>       
> whichever
>   
>>> logically different ports (one for VLAN tag 3 and a separate one for
>>>       
> 4)
>   
>>> Thus if we wanted this case to provide full connectivity it would
>>>       
> seem
>   
>>> like the data plane would need to be able to duplicate packets and
>>>       
> send
>   
>>> some unicast; a possible strategy would be to multicast with tag 3,
>>>       
> and
>   
>>> then unicast a copy to RB2 (with tag 4). That way all the
>>>       
> neighboring
>   
>>> There might be other examples of odd VLAN configuration (such as
>>>       
> bridges
>   
>>> which untag and then add some other tag when forwarding the frame)
>>>       
> which
>   
>>> are complex to fully support. What level of ambition should we have
>>>       
> for
>   
>>> the odd cases?
>>>
>>>     Erik
>>>

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 17 Sep 2007 20:23:53 -0700

So, just to summarize what I think the proposed solution is, plus a 
couple of questions
interspersed, marked
with ???

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.

???question: Which VLAN tag?  untagged? VLAN 1? Something else? And is 
that the
*only* VLAN tag, or is it a default, and RBridges could be configured to 
send on a different
VLAN tag? (I'd prefer picking one and not have it be configurable)???

b) it will be a MUST to listen to spanning tree messages and include the 
root bridge ID
in the pseudonode LSP. Also,

c) if R1 notices 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 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.)

So...is this pretty much everyone's understanding of how it should work?

Radia

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 18 Sep 2007 07:18:48 -0700

Radia,

I need to sudy your proposal in details, but the answer to your question
is easy: " By default is VLAN 1 and it is configurable".

VLAN 1 is the default of IEEE, and you cannot forbid with a standard to
config it.

-- Silvano

On
> Behalf Of Radia Perlman
> Sent: Monday, September 17, 2007 8:24 PM
> To: Developing a hybrid router/bridge.
[mailto:rbridge-bounces at postel.org]

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 18 Sep 2007 08:04:18 -0700

Hi Radia,

Some comments.

> VLAN tag? (I'd prefer picking one and not have it be configurable)???
VLAN 1 and I prefer it to be the only one, but maybe configurable. The 
frame must be tagged, not untagged as it leads to all kinds of corner 
cases.
> in the pseudonode LSP. Also,
Will it need to support both (three if you include the currently 
dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP 
(Cisco's PVST is IEEE's STP run per VLAN).
> is less than the ID of  the DRB for that pseudonode
Need to think through this one.
> and that R2 claims to be DRB for
Need to think through this one.
> it has synchronized LSP databases with its neighbors. "Synchronizing" 
This could cause a significant delay in bringing an RBridge up and how 
things work when a network is powered down and comes up. I'm not sure 
about this part yet.

Dinesh

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 18 Sep 2007 18:12:15 -0700

> (Cisco's PVST is IEEE's STP run per VLAN).
How different are these? How much trouble is it to listen to all the 
variants? I assumed they
were all interoperable. What happens if there is a bridged network with 
bridges that
support different of these variants?

 From what I remember of "original STP" and "RSTP", listening to them 
should be identical.
RSTP uses the same message formats, and is the same protocol other than 
adding loop prevention
messages. So I'd assume if you are listening, it wouldn't matter if it 
was STP vs RSTP.

MSTP, if I understand it correctly, involves noticing that different 
bridges are root for different
VLANs. However, maybe we can ignore that, and only listen to messages 
for the spanning
tree for VLAN 1. I'm assuming we can do that -- someone should correct 
me if I'm wrong. The
other plausible alternative is to listen to all the spanning trees, and 
if you're doing load splitting
of DRBs (one for VLANs 1-50, and the other for VLANs 51-79, say), then 
in the pseudonode
representing VLANs 1-50, you'd list the root bridges for the spanning 
tree associated with
each of the VLANs 1 through 50.

As for your description of "PVST" -- again, the implication might be 
that if you have a pseudonode
representing all the VLANs, you'd have to list, in that pseudonode, a 
different bridge ID since
(if I understand what PVST is from your one phrase above), there might 
be a different root
bridge ID for each of those.

But...I *thought* that the spanning tree is guaranteed not to be 
partitioned, so listing just the
root of the spanning tree corresponding to VLAN 1 should be all you need 
in order to detect
that there's an RBridge on the same link that you're not hearing Hellos 
from, right?

*****************
And as for allowing configuration to be some other VLAN other than 1 -- 
that makes things
complicated, because what do you do if some of the RBridges on a cloud 
are configured differently
from others?

Radia

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 19 Sep 2007 18:40:29 -0700

> Sent: Tuesday, September 18, 2007 6:12 PM
> To: Dinesh G Dutt
> How different are these? How much trouble is it to listen to 
> all the variants? I assumed they were all interoperable. What 
> happens if there is a bridged network with bridges that 
>  From what I remember of "original STP" and "RSTP", listening 
> to them should be identical.
> RSTP uses the same message formats, and is the same protocol 
> other than adding loop prevention messages. So I'd assume if 
> you are listening, it wouldn't matter if it was STP vs RSTP.

This is correct.

> MSTP, if I understand it correctly, involves noticing that 
> different bridges are root for different VLANs. However, 
> maybe we can ignore that, and only listen to messages for the 
> spanning tree for VLAN 1. I'm assuming we can do that -- 
> someone should correct me if I'm wrong. The other plausible 
> alternative is to listen to all the spanning trees, and if 
> you're doing load splitting of DRBs (one for VLANs 1-50, and 
> the other for VLANs 51-79, say), then in the pseudonode 
> representing VLANs 1-50, you'd list the root bridges for the 
> spanning tree associated with each of the VLANs 1 through 50.

And so is this.  Basically, from the perspective of what
we are trying to accomplish with MSTP, we could just listen
to the messages for the CIST (common and internal spanning
tree) which is the spanning tree that goes across all
spanning tree regions and forwards traffic to VLANs that is
not mapped to any of the other instances.
 
> As for your description of "PVST" -- again, the implication 
> might be that if you have a pseudonode representing all the 
> VLANs, you'd have to list, in that pseudonode, a different 
> bridge ID since (if I understand what PVST is from your one 
> phrase above), there might be a different root bridge ID for 
> each of those.
>
> But...I *thought* that the spanning tree is guaranteed not to 
> be partitioned, so listing just the root of the spanning tree 
> corresponding to VLAN 1 should be all you need in order to 
> detect that there's an RBridge on the same link that you're 
> not hearing Hellos from, right?
> 
> *****************
> And as for allowing configuration to be some other VLAN other 
> than 1 -- that makes things complicated, because what do you 
> do if some of the RBridges on a cloud are configured 
> differently from others?

The only problem with using VLAN 1 only is that it
may require an operator to renumber their VLAN 
configuration if VLAN 1 is being used for something
other than what we would like it to be used for.

One way to handle misconfiguration would be to 
say that, if this condition is detected, then we
use the lower numbered VLAN and the one with the
higher numbered VLAN logs a misconfiguration error
and goes silent.  A misconfiguration is detected
if the root/VLAN combination reported for the same
pseudonode by 2 RBridges is different.

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 19 Sep 2007 18:59:24 -0700

> So, just to summarize what I think the proposed solution is, 
> plus a couple of questions interspersed, marked with ???
> 
> 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.
> 
> ???question: Which VLAN tag?  untagged? VLAN 1? Something 
> else? And is that the
> *only* VLAN tag, or is it a default, and RBridges could be 
> configured to send on a different VLAN tag? (I'd prefer 
> picking one and not have it be configurable)???
> 
> b) it will be a MUST to listen to spanning tree messages and 
> include the root bridge ID in the pseudonode LSP. Also,

And the root bridge ID in the case where MSTP is enabled
is that of the CIST.

It must also include in the list of VLANs reachable on
that pseudonode and what is configured as the "RBridge 
control VLAN".  The list of VLANs reachable is later 
used for doing DRB election.

> c) if R1 notices 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 
> 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.)
>

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 19 Sep 2007 22:51:35 -0700

Hi Radia,

Radia Perlman wrote:
> were all interoperable. What happens if there is a bridged network 
> with bridges that
Don't know how different things are. MSTP/RSTP can interoperate with 
older STP, I believe.
> RSTP uses the same message formats, and is the same protocol other 
> than adding loop prevention
The PDUs look different between MSTP and regular STP.
> other plausible alternative is to listen to all the spanning trees, 
> and if you're doing load splitting
> root of the spanning tree corresponding to VLAN 1 should be all you 
> need in order to detect
> that there's an RBridge on the same link that you're not hearing 
> Hellos from, right?
I think you maybe right here.
>
> *****************
> And as for allowing configuration to be some other VLAN other than 1 
> -- that makes things
I agree. I prefer to not provide a configurable option on this, but I 
can foresee people complain,

Dinesh

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 19 Sep 2007 23:31:38 -0700

Anoop,

> not mapped to any of the other instances.
What you're saying then is that the DRB must be the root of CIST, not of 
VLAN 1. Am I right ?

Dinesh

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 20 Sep 2007 07:58:09 -0700

... snip ...

> can foresee people complain,

Let's be realistic, if a customer has access to an existing VLAN 7 on a
backbone and he wants to connect two RBridges to it, we are going to
disallow it?

Disallowing reasonable configuration by standard is never an option.

-- Silvano

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 20 Sep 2007 07:59:42 -0700

On
> Behalf Of Dinesh G Dutt
> Sent: Wednesday, September 19, 2007 11:32 PM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.; Radia Perlman

I disagree that the DRB must be the root of the CIST.
This imposes severe restrictions on interoperability.

-- Silvano

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Thu, 20 Sep 2007 08:09:17 -0700

The statement pertained to which VLAN the DRB election is held on, not 
the VLAN on which the traffic is transported. I think this was for the 
case of doing DRB on a single VLAN,

Dinesh
Silvano Gai wrote:
>>> complicated, because what do you do if some of the RBridges on a
>>>       
> cloud
>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 20 Sep 2007 09:05:18 -0700

> From: Dinesh G Dutt [mailto:ddutt at cisco.com] 
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> > And so is this.  Basically, from the perspective of what we 
> are trying 
> > to accomplish with MSTP, we could just listen to the 
> messages for the 
> > CIST (common and internal spanning
> > tree) which is the spanning tree that goes across all spanning tree 
> > regions and forwards traffic to VLANs that is not mapped to 
> any of the 
> > other instances.
> >   
> What you're saying then is that the DRB must be the root of 
> CIST, not of VLAN 1. Am I right ?

Hi Dinesh,

That's not what I'm trying to say at all.  All I'm
saying is that all RBridges (designated or not)
report who the root is for the CIST.  This is basically
to figure out whether they are connected to the same
LAN.

Anoop