[rbridge] Ambition with different VLAN configurations

Tue Sep 18 07:18:48 PDT 2007

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

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Monday, September 17, 2007 8:24 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> 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
> >>
> >>
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge