[rbridge] Ambition with different VLAN configurations
Radia Perlman
Radia.Perlman at sun.com
Mon Sep 17 20:23:53 PDT 2007
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
Dinesh G Dutt wrote:
> I agree to Radia's points with the addition of Silvano's points,
>
> Dinesh
> Silvano Gai wrote:
>> 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
>>
>>
>>
>>> -----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
>>>
>>> . 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:
>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>
More information about the rbridge
mailing list