Subject: [rbridge] A "multiple VLAN Hello" proposal

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 25 Oct 2007 11:55:31 -0700

It's a bit difficult to argue on the list about proposals when one of 
them has not been specified, especially
since I can imagine lots of variations on multiple VLANs, and lots of 
questions about choices for
the details.

Here's an attempt to specify a "send Hellos on multiple VLANs" proposal. 
I've chosen details
where in many cases there are other options I could have chosen. But I 
think we need some
tangible proposal with details worked out before advocating for it. 
People should feel free
to suggest modifications to the details below, but I, as I said, cannot 
argue between proposals
if the proposals aren't concrete. I've tried to make it as simple as 
possible, as low overhead
as possible, while adding the ability to configure sending Hellos on 
lots of VLANs.

a) RBridges send and receive IS-IS Hellos on VLAN 1

b) In addition, RBridges MAY be configured to send and receive Hellos on 
some set of
VLANs in addition to 1

c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the VLANs that 
R1 is
configured to send (and receive) on. To clarify, as long as R1 thinks 
itself is DRB, it will
send Hellos on the complete set of VLANs that R1 is configured to send 
on. In addition (see
point "e"), R1 may wind up having to send Hellos on some set of VLANs in 
addition
to those it was configured to send on.

d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has 
heard Hellos from. In addition,
R1 reports in R1's Hello, for each neighbor R2, *one* VLAN that R1 hears 
hellos from R2 on.
The one VLAN that R1 reports is the lowest numbered VLAN that R1 hears a 
Hello from R2 on.

e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs,
but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the 
set of VLANs that
R1 transmits on, as long as it continues to hear Hellos on VLAN x (and no
other VLANs) from R2. Note that if R2's Hello gives R2 better priority for
being DRB, then R1 will not be DRB any more, but MUST continue sending 
Hellos on
VLAN x (even though x is not in the set of VLANs
that R1 was configured to send on) to ensure that R2 continues to send 
its Hellos on VLAN x.

e) if you are *not* the DRB, you send Hellos on VLAN 1 plus the VLAN 
that the DRB reports
that it has heard from you on. This cuts down on Hellos since it means 
that non-DRB RBridges
will send on at most two VLANs.
{Note: An alternate option would have had every RBridge send Hellos 
always on all VLANs they
have been configured to send on}.

f) all RBridge-RBridge traffic (other than Hellos) is always sent on 
VLAN 1. So if R2 cannot
reach the DRB via VLAN 1, then R2 cannot forward data to/from that 
cloud, or receive
LSPs on that cloud. In other words, that link will be broken for R2. The 
purpose
of the Hellos is only to notice (through a means *in addition* to the 
safeguards in the other
proposals)  that R2 is not DRB for the link.

g) We do the same safeguards as in the other proposals (report the
bridge root ID in the pseudonode LSP, don't decapsulate from ingress Ra 
unless
you have all the relevant pseudonode LSPs attached to Ra to ensure that 
none of them have
the same root RBridge, and that you delay before encapsulating data off 
the link until you've
been DRB for enough time to synchronize LSP databases with your neighbors)

**************
My thoughts on this:

a) I assume the only reason to send Hellos on multiple VLANs is to 
minimize the probability
of accidentally having two DRBs, and therefore loops. I'm not convinced 
this adds safety
over the safeguards in the single VLAN proposals.

b) this winds up with sending lots more Hellos, but does not create 
additional pseudonodes,
or complicate data forwarding, because the Hellos is only to find 
neighbors, not to repair
use of the link for forwarding data (or propagating LSPs) if VLAN 1 is 
partitioned on the link

c) This is a lot more complicated. It might seem simpler to not try to 
optimize the number of
Hellos (like I did in point e), but there seem to be scary corner cases 
where all the VLANs
common to R1 and R2 are partitioned. Saying there must be an 
unpartitioned VLAN 1 seems
the safest.

So, I still like the "just use VLAN 1" proposal.

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 25 Oct 2007 14:38:57 -0700

Radia,

Step "e" would be considered incorrect behavior
w.r.t. VLANs.  If an end station is not configured
with a certain VLAN, it should not be receiving and
trying to process packets from that VLAN.  In this
case, the end station is the management port running
IS-IS.

Anoop 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Thursday, October 25, 2007 11:56 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] A "multiple VLAN Hello" proposal
> 
> It's a bit difficult to argue on the list about proposals 
> when one of them has not been specified, especially since I 
> can imagine lots of variations on multiple VLANs, and lots of 
> questions about choices for the details.
> 
> where in many cases there are other options I could have 
> chosen. But I think we need some tangible proposal with 
> details worked out before advocating for it. 
> People should feel free
> to suggest modifications to the details below, but I, as I 
> said, cannot argue between proposals if the proposals aren't 
> concrete. I've tried to make it as simple as possible, as low 
> overhead as possible, while adding the ability to configure 
> sending Hellos on lots of VLANs.
> 
> 
> b) In addition, RBridges MAY be configured to send and 
> receive Hellos on some set of VLANs in addition to 1
> 
> configured to send (and receive) on. To clarify, as long as 
> R1 thinks itself is DRB, it will send Hellos on the complete 
> set of VLANs that R1 is configured to send on. In addition 
> (see point "e"), R1 may wind up having to send Hellos on some 
> set of VLANs in addition to those it was configured to send on.
> 
> d) In IS-IS's Hello, R1 reports the set of neighbor RBridges 
> R1 has heard Hellos from. In addition,
> R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> that R1 hears hellos from R2 on.
> The one VLAN that R1 reports is the lowest numbered VLAN that 
> R1 hears a Hello from R2 on.
> 
> e) If R1 does not hear a Hello from R2 on any of R1's 
> configured VLANs, but does hear on some other VLAN, say VLAN 
> x, then R1 adds "x" to the set of VLANs that
> R1 transmits on, as long as it continues to hear Hellos on 
> VLAN x (and no other VLANs) from R2. Note that if R2's Hello 
> gives R2 better priority for being DRB, then R1 will not be 
> DRB any more, but MUST continue sending Hellos on VLAN x 
> (even though x is not in the set of VLANs that R1 was 
> configured to send on) to ensure that R2 continues to send 
> its Hellos on VLAN x.
> 
> e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> the VLAN that the DRB reports that it has heard from you on. 
> This cuts down on Hellos since it means that non-DRB RBridges 
> {Note: An alternate option would have had every RBridge send 
> Hellos always on all VLANs they have been configured to send on}.
> 
> f) all RBridge-RBridge traffic (other than Hellos) is always 
> sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, 
> then R2 cannot forward data to/from that cloud, or receive 
> LSPs on that cloud. In other words, that link will be broken 
> for R2. The purpose of the Hellos is only to notice (through 
> a means *in addition* to the safeguards in the other
> g) We do the same safeguards as in the other proposals 
> (report the bridge root ID in the pseudonode LSP, don't 
> decapsulate from ingress Ra unless you have all the relevant 
> pseudonode LSPs attached to Ra to ensure that none of them 
> have the same root RBridge, and that you delay before 
> encapsulating data off the link until you've been DRB for 
> enough time to synchronize LSP databases with your neighbors)
> 
> **************
> My thoughts on this:
> 
> a) I assume the only reason to send Hellos on multiple VLANs 
> is to minimize the probability of accidentally having two 
> DRBs, and therefore loops. I'm not convinced this adds safety 
> b) this winds up with sending lots more Hellos, but does not 
> create additional pseudonodes, or complicate data forwarding, 
> because the Hellos is only to find neighbors, not to repair 
> use of the link for forwarding data (or propagating LSPs) if 
> VLAN 1 is partitioned on the link
> 
> c) This is a lot more complicated. It might seem simpler to 
> not try to optimize the number of Hellos (like I did in point 
> e), but there seem to be scary corner cases where all the 
> VLANs common to R1 and R2 are partitioned. Saying there must 
> be an unpartitioned VLAN 1 seems the safest.
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 25 Oct 2007 19:47:03 -0700

Hmm. I was wondering if an RBridge might be able to receive on a VLAN 
that it
isn't configured to officially support. But actually, what I meant was 
that I was
assuming there might be a large subset of VLANs that the RBridge can 
send and
receive on. and some smaller subset of those that it is configured to 
send IS-IS Hellos on.
So if an RBridge does support all 4000 VLANs, by default it would only 
send IS-IS Hellos
on VLAN 1, but would receive on any of them. And it might be configured 
to send on
a subset of the supported VLANs, but hopefully not all 4000. So that's 
what I was trying to get at.

Radia

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 26 Oct 2007 00:43:01 -0400

Hi Radia,

The proposal below appears to be written from the "one DRB per link"
point of view while the current draft claims to support "one DRB per
VLAN per link". Even if you have complete VLAN 1 connectivity and use
single Hellos, I'm not quite sure how the one DRB per VLAN per link
would work. In principle, the per VLAN priority for a Rbridge port for
all its configured VLANs might not fit into a Hello...

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, October 25, 2007 2:56 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] A "multiple VLAN Hello" proposal

I've chosen details

some set of
VLANs in addition to 1

addition

hellos from R2 on.

Hello from R2 on.

e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs,
but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the 
set of VLANs that
R1 transmits on, as long as it continues to hear Hellos on VLAN x (and
no
other VLANs) from R2. Note that if R2's Hello gives R2 better priority
for
being DRB, then R1 will not be DRB any more, but MUST continue sending 
Hellos on
VLAN x (even though x is not in the set of VLANs
that R1 was configured to send on) to ensure that R2 continues to send 
its Hellos on VLAN x.

purpose

been DRB for enough time to synchronize LSP databases with your
neighbors)

**************
My thoughts on this:

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 26 Oct 2007 00:44:48 -0400

Hi Anoop,

I don't look at it that way at all. We get to say what "correct" and
"incorrect" behavior are for Rbridges.

TRILL Ethertype frames are special. The Outer VLAN tag on a TRILL
Ethertype frame is just a transport artifact added to enable the frame
to get through a Bridged LAN that is in the way. It is unnecessary on
point-to-point links. If an Outer VLAN tag is present on a TRILL frame,
it shouldn't affect whether the frame is processed.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Thursday, October 25, 2007 5:39 PM
To: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] A "multiple VLAN Hello" proposal

Radia,

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 25 Oct 2007 22:03:51 -0700

Donald,

Once you've established connectivity over VLAN 1,
you can then exchange the list of VLANs that are
configured on that RBridge port and arbitrate 
which RBridge becomes designated for each VLAN.
For example, if RB1 has VLANs {2,4,6,8} and
RB2 has VLANs {3,5,7,9} configured, then they
will both become DRBs for those set of VLANs 
because there is no overlap.  For the ones that
there is overlap, there will need to be a tie
breaking mechanism.

Anoop 

> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Thursday, October 25, 2007 9:43 PM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.
> point of view while the current draft claims to support "one 
> DRB per VLAN per link". Even if you have complete VLAN 1 
> connectivity and use single Hellos, I'm not quite sure how 
> the one DRB per VLAN per link would work. In principle, the 
> per VLAN priority for a Rbridge port for all its configured 
> VLANs might not fit into a Hello...
> 
> Thanks,
> Donald
> 
> receive Hellos on
> set of VLANs in
> that R1 hears
> R1 hears a
> for R2. The
> of the Hellos is only to notice (through a means *in 
> addition* to the safeguards in the other

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 25 Oct 2007 22:26:28 -0700

Right...I was not intending to preclude having R1 be DRB for (inner) 
VLANs (v1, v2, v3) and
R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you point out, if 
each RBridge can
be configured with a different priority for each of the 4000 VLANs, the 
IS-IS Hello would
get too large. The only reason for different priorities is to do some 
load splitting. I'd argue
that with just a tiny bit of flexibility customers can get enough 
functionality. So I'd suggest
limiting multiple priorities to some reasonable number, like 3, and sets 
of VLANs to ranges.
That would mean that R1 can claim to have priority P1 for the VLANs in 
range (n1-n2), and
priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs 
betwen (n5-n6).
This would require (for 3 different priorities) 18 bytes in the Hello. 
For instance, "I have
priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and 
priority 2 for
VLANs (101-115). Perhaps another 500 bytes to do a bit mask of all the 
VLANs that
you support at all (or alternatively you can't claim to have a priority 
for a range of VLANs unless
you support all the VLANs in that range).

Likewise, in the pseudonode, we'd have to say the range of VLANs that 
that pseudonode
refers to.

And it's NOT a DRB collision if there is a pseudonode, say R1,17,
for which R1 is DRB, reporting root bridge X
and R2 is DRB on a link with root bridge X as long as the set of VLANs 
reported
in R1.17's LSP does not overlap with the set of VLANs that R2 is DRB for 
on that link.

And actually, R2 really only needs to decline to forward data (act as 
DRB) for the set of
VLANs in R1.17's pseudonode that overlaps with R2's. It could be that R2 
has some
other VLANs that are not in R1.17's pseudonode.

So that's an additional refinement on the rules that should be added.

Perhaps we should start a different thread on whether people can live 
with having a single
DRB be configured with at most 3 priorities on a port, and require the 
set of VLANs for
each priority to be expressible in a range (rather than having to 
enumerate each of the
VLAN tags individually).

Radia

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Sun, 28 Oct 2007 12:28:46 -0500

Radia,

	Using sets of VLANs as a range of values is likely to force
sub-optimality on load-sharing - possibly to the extent that load
sharing becomes useless.

	It is not a trivial exercise to make VLAN topologies line up
conveniently with VLAN ID assignments.  In fact, assuming that it
is possible to modify VLAN topologies, it's most likely infeasible
to do so in some scenarios.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, October 26, 2007 1:26 AM
> To: Eastlake III Donald-LDE008
> when one of 
> chosen. But I 
> said, cannot 
> R1 thinks 
> configured VLANs,
> VLAN x (and
> the VLAN 
> not try to

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Sun, 28 Oct 2007 12:43:40 -0500

Donald,

	We do not have carte-blanch in saying what is correct
and incorrect behavior for RBridges, unless we want to give
up on a large number of common concerns - compatibility with
existing/deployed technologies, software/hardware re-use and
just plain taking advantage of results of past experience,
to name a few.

	In saying that it is alright - at the protocol level 
(what people actually do is their business) - for a device
to treat VLAN traffic promiscuously is assuming both a level
of complexity and a degree of risk in achieving long term 
interoperability between RBridges and other potential VLAN
forwarding devices.

	Also, in establishing a precedent for ignoring what is
"common accepted practice" in existing VLAN devices, we may
expose ourselves to reciprocal future activities.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, October 26, 2007 12:45 AM
> To: Anoop Ghanwani
> [mailto:rbridge-bounces at postel.org] On
> Behalf Of Anoop Ghanwani

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sun, 28 Oct 2007 16:02:06 -0400

Eric,

There is currently no provision for fragmenting Hellos. If different
Rbridges are gong to have different priorities for becoming DRB for
different VLANs the current IS-IS election style would say that that
information has to go into the Hello PDUs. If bits maps are better than
ranges, we could use those.

Donald

-----Original Message-----
From: Eric Gray [mailto:eric.gray at ericsson.com] 
Sent: Sunday, October 28, 2007 1:29 PM
To: Radia Perlman; Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] A "multiple VLAN Hello" proposal

Radia,

--
Eric Gray
Principal Engineer
Ericsson

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 28 Oct 2007 13:41:45 -0700

I agree with Eric,
VLAN range is not widely deployed today.

-- Silvano

> Behalf Of Eric Gray
> Sent: Sunday, October 28, 2007 10:29 AM
Hellos
> > > b) this winds up with sending lots more Hellos, but does not
create

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 28 Oct 2007 13:45:24 -0700

Donald,

We need to face the reality that the only solution that works is to send
a Hello per VLAN.

We are in the version one of the protocol, we should use well know
solutions and look at optimizations in future versions, when we have
implementation experience.

-- Silvano

> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, October 28, 2007 1:02 PM
> To: Eric Gray
Hellos
create

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Sun, 28 Oct 2007 15:55:21 -0500

Donald,

	The issue with excessively large hello messages because 
of multiple per-VLAN priorities doesn't come up if you don't 
have hello messages with information about more than one VLAN.

	So, IMO, it looks like you are wrong in saying there's
"currently no provision for fragmenting Hellos."  It seems as
if it is simply more like some people are talking about it one
way and others are talking about it another.

	It looks as if - by trying to address a possible scale
issue that might very well be unrealistic - we have invented
a problem and are now dreaming up all kinds of neat and cool
ways to solve it.  Let's just un-invent it...

--
Eric Gray
Principal Engineer
Ericsson  

> From: Eastlake III Donald-LDE008 
> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Sunday, October 28, 2007 4:02 PM
> To: Eric Gray
> Importance: High