Subject: [rbridge] VLAN registration

From: Radia Perlman <[email-masked]>
Date: Wed, 19 Mar 2008 07:28:34 -0700

Just noticed this section got added to the spec. Some people expressed 
privately to me  (and I share
their concern) a concern that
if RBridges had to support every new feature and protocol that IEEE 
comes up with, that we'll never be finished.
And that at the very least supporting most of these should be MAYs 
rather than MUSTs or even SHOULDs.

As for the VLAN registration frame -- it seems like R2, if it is VLAN x 
forwarder, should only send a VLAN x registration
frame if R2 sees, in its LSP database, that some other RBridge in the 
campus has a VLAN x receiver. If VLAN x is
dynamic, then R2 should not announce VLAN x in its LSP unless there is a 
VLAN x receiver on the link.

If we think that RBridges should be supporting this at all...

Radia
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 19 Mar 2008 17:44:45 -0400

Hi Radia,

See below at @@@ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Wednesday, March 19, 2008 10:29 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] VLAN registration

@@@ I agree that Rbridges don't have to support new 802.1 features and
protocols and, if they do, it should generally be a separate document,
rather than part of the base protocol specification. However, I don't
think dynamic VLAN registration is a particularly recent 802.1 feature.
I haven't tried tracing back all the way back but dynamic VLAN
registration is certainly there five years ago in 802.1Q-2003 and I
suspect that it was added at the time or very shortly after VLANs were
added. It is true that 802.1 recently replaced GVRP with MVRP but, while
not backward compatible, this logically is a minor change. It primarily
replaces a frame which indicates registration for one VLAN with a frame
which allows you to provide indications for multiple VLANs.

@@@ I think that many of those to whom it had occurred at all believed
that the previous provision, that all the 802.1 bridging registration
protocol frames would just be treated as non-IP derived multicast, would
do the trick. And, in fact, I still believe that provision works fine
for the 802.1 bridge multicast address registration protocol frames and
will probably work in the unlikely event that 802.1 specifies any
additional registration protocols that use multicast addresses in the
currently reserved block.

@@@ But, the strategy of just treating as non-IP derived multicast is
completely broken for VLAN registration frames. It doesn't work for
Rbridge ports, which had been previously overlooked, and it doesn't work
for remaining bridges in the campus. So I didn't think of this as adding
support for a feature but rather fixing completely broken support that
was there. I posted a preliminary discussion of the issue here
http://www.postel.org/pipermail/rbridge/2008-February/002871.html
and talked about it at the March TRILL meeting as a technical change
(see
http://www.ietf.org/proceedings/08mar/slides/trill-1.ppt
slide 5).

@@@ I personally don't have much problem with making MVRP support a
SHOULD but it really doesn't seem like that much of a burden. It only
requires some additional local behavior at Rbridge ports. There is no
additional inter-Rbridge traffic and no change, by current thinking, in
the link state database.

@@@ Although you can generally tell if you have an IP-derived multicast
listener, can you generally tell if you have a VLAN-x receiver?

@@@ The current TRILL specification also says that, by default, you only
send VLAN registration frames out a port if you see a bridge out that
port, although the port can also be configured to always or never send
VLAN registration frames (keeping in mind that if you are not appointed
forwarder, etc., for any VLAN it is perfectly reasonable to send VLAN
registration frames that attempt to de-register all VLANS).

@@@ Thanks,
@@@ Donald

Radia

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 19 Mar 2008 17:10:09 -0700

I'm firmly opposed to having MVRP support a SHOULD or a MUST. We have 
found no customers wanting it so far. I don't see why RBridge spec needs 
to say anything more than how VLANs are advertised. How they discover 
what VLANs to advertise is a specific RBridge implementation detail. 
Some may use MVRP, some may use some proprietary protocol (this is not 
the reason for my opposition) and some may use local configuration. MVRP 
support is not a MUST or a SHOULD and I don't want RBridge support to be 
so either.

Dinesh

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

---

From: "Silvano Gai" <[email-masked]>
Date: Wed, 19 Mar 2008 17:22:38 -0700

I am ABSOLUTELY opposed to have MVRP as a SHOULD.
Today MVRP has ZERO deployment

-- Silvano

> Behalf Of Dinesh G Dutt
> Sent: Wednesday, March 19, 2008 5:10 PM
> To: Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] VLAN registration
>

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 19 Mar 2008 18:08:35 -0700

Typing with one hand is a pain.

I meant to say MVRP support is not required in .1d bridges and so 
neither should it be in Rbridges,

Dinesh

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 19 Mar 2008 21:50:10 -0500

Donald/Radia,

	I agree with Donald on all of his points in this mail.

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Wednesday, March 19, 2008 5:45 PM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 20 Mar 2008 08:36:33 -0400

I think we need to de-couple TRILL compliance from any specific
level of 802.1 compliance on any specific 802.1 cloud/protocol suite.

802.1 is in the process of defining various "clouds", such as
Data Center (for Congestion Notification and other purposes)
and AVB (audio-vide-bridging). The issue of where an RBridge
should or even can extend those clouds is complex, and a rat
hold best avoided by allowing implementers to do as litte or
as much as they want and only dealing with issues that affect
RBridge functionality.

Participation in any of these clouds should clearly be optional
(as in MAY). The draft should be clear that 802.1 documents will
describe RBridge interactions with conventional bridges. Those
documents already protect the right of end stations and bridges
to upgrade or  not upgrade at their own pace.

That suggests the only extent to which TRILL needs to be involved
is to allow a mechanism by which two RBridges can communicate their
intent to extend a specific 802.1 cloud through the RBridge tunnel.
Even that can be worked around. To the extent that standard signaling
is required I think it can be added in later documents as additional
TLVs in the discovery process.

I certainly hope that RBridge functionality is considered as a 
superset of Bridge functionality, and not as an excuse for freezing
Bridge features at a certain revision. But it's up to the market to
determine which 802.1 protocols are relevant, not IETF.

---

From: James Carlson <[email-masked]>
Date: Thu, 20 Mar 2008 09:32:43 -0400

Eastlake III Donald-LDE008 writes:
> campus has a VLAN x receiver.

That implies that RBridges need to manipulate MVRP messages in order
to play at this game.  The MVRP request that an RBridge sends out
needs to be the bitwise sum of all of the requests received on all
other LANs by the RBridge cloud plus the list of enabled VLANs known
in the LSP database.

> listener, can you generally tell if you have a VLAN-x receiver?

No, because of manual configuration.  VLANs can lurk.

I suspect that SHOULD for MVRP carries a bit too much force here.
It's an optional part of the IEEE world, and, as best I can tell, it's
not really used anywhere (yet?).  SHOULD means that vendors need to
have a very good reason to avoid implementing, and not just that their
target markets use .1d bridging only.

I think optional parts ought to be listed as MAY in the base
specification or -- much better yet -- listed in a separate document
(or documents) where you can be free with the MUSTs as needed.

Things we list in the base document need to be the things that are
required to build an implementation.  Is MVRP really one of those
things?

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 30 Mar 2008 13:52:25 -0400

Hi Dinesh,

There have been posts to this list stating that there are customers that
want and use standards based dynamic VLAN registration.

It seems to me that the completely broken state of dynamic VLAN
registration that was in the TRILL base protocol draft version -06
needed to be fixed. If you have two 802.1Q bridges, say X and Z, and put
an Rbridge conformant to the -06 spec between them or if you have three
such bridges connected in sequence, say X - Y - Z, and replace Y with
such an Rbridge, the Rbridge will generally break any dynamic VLAN
registration going on between these bridges, whether you are using GVRP
or the new MVRP. How can such network damage be consistent with our
goals of incremental deployment and VLAN support?

It seemed to me that Rbridges should be forward looking, so I thought
they should support the newer MVRP, and Rbridges should be simple, so I
didn't even bother to think much about how you could support both GVRP
and MVRP (although you could do that as the frames seem to be easily
distinguishable). That's why I just said MVRP in my earlier posting to
the Rbridge list and in my presentation to the TRILL working group in
Philadelphia. MVRP also appears to me to be technically superior to GVRP
because you can sometimes replace thousands of GVRP frames with one MVRP
frame.

I assume by "advertise" VLANs below you mean propagate through the link
state database. I've got no problem with there being additional methods
to configure VLANs but I think we will need to say how to configure them
with SNMP (even if that is mostly just a pointer to an existing bridge
MIB) and say how they work with 802.1 dynamic VLAN registration.

In a later message you clarified your statement that MVRP was not
mandatory to implement by narrowing that claim to 802.1D bridges. Since
802.1D bridges are VLAN ignorant and do not support VLANs, it is hardly
surprising that they do not mandate implementing dynamic VLAN
registration. But the TRILL WG has decided that Rbridges will support
VLANs and, in most cases, be incrementally deployable into 802.1Q
bridged LANs. As I document in a separate message, as far as I can see,
802.1Q requires the implementation of dynamic VLAN registration.

Donald

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2008 8:10 PM
To: Eastlake III Donald-LDE008
Cc: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] VLAN registration

so either.

Dinesh

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 30 Mar 2008 14:52:35 -0400

Hi Anoop,

So what should an Rbridge which does not support MVRP do when it
receives an MVRP frame? (I assume you are not just supporting the older
GVRP over MVRP so what you are really saying is that an Rbridge does not
need to provide any real support for dynamic VLAN registration.)

Under such circumstances, there are various possibilities:

Just discarding the frame doesn't seem very friendly and certainly won't
work if you have bridges in the path that have dynamic VLAN
configuration.

Distributing as a non-IP-derived multicast, which is what the -06 draft
provided, seems pretty flakey. It might work sometimes, depending on
exactly port configurations, but would commonly fail because the VLAN
registration frame wouldn't get to where it was needed or, if it did, it
would be VLAN tagged in violation of 802.1Q.

You could also special case it as a non-VLAN constrained frame which is
never VLAN-tagged when decapsulated...

Thanks,
Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Thursday, March 20, 2008 10:54 AM
To: Silvano Gai; Dinesh G Dutt; Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.; Radia Perlman
Subject: RE: [rbridge] VLAN registration

While I'm not sure I agree with the "ZERO deployment"
statement, I think it's OK to mention MVRP support as MAY.

Anoop

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 30 Mar 2008 23:19:21 -0400

See below at ### 

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Thursday, March 20, 2008 9:33 AM
To: Eastlake III Donald-LDE008
Cc: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] VLAN registration

### (Actually, the "> " prefixed lines immediately below were, I
believe, from Radia Perlman.

### I don't think so. MVRPs can be handled locally at each port based on
the configuration and state of that port and the link state database. I
don't think there is a dependence on requests received except to the
extent they change the state of a port and that in turn affects the link
state database. Perhaps I should write up a more detailed description of
how this would work.

### Right. So really my point was that, since you can't tell if there is
a VLAN-x listener, if you are sending MVRPs, you have to formulate them
based not on some other Rbridge in the campus having a VLAN-x receiver
but just on some other Rbridge in the campus being a VLAN-x appointed
forwarder, which is what is reported in the link state database.

### I wish, when people slam MVRP, they would make it clear if they are
slamming dynamic VLAN registration or just MVRP.

### As per my other messages, I think we have been targeting 802.1Q
bridges. Lots of things could be vastly simplified in Rbridges if they,
like 802.1D bridges, didn't need to support VLANs at all. And, as far as
I can tell, MVRP is a mandatory to implement part of 802.1Q. And I don't
think we should look only at today's deployment. Presumably Rbridges
should be aimed at a future state of deployment.

### It seems like you should still say something about what you do when
you receive a VLAN registration frame.

### Well, the group gets to decide that. But I suspect that dynamic VLAN
registration, either GVRP or MVRP, takes at least an order of magnitude
fewer lines of code that implementing SNMP and static VLAN
configuration. And in 802.1Q, MVRP is mandatory while configuration by a
management protocol is optional.

### Thanks,
### Donald

---

From: Dinesh G Dutt <[email-masked]>
Date: Sun, 30 Mar 2008 21:30:56 -0700

Donald,

First off, if I used the word .1D bridges,  I really meant .1Q bridges. 
IEEE does  NOT mandate MVRP or MMRP to be implemented in 802.1Q bridges. 
Dynamic VLAN registration is not mandated in the 802.1Q 2005 standard. 
So, TRILL spec should not either. Further, I know of no customer using 
these protocols in their networks and I work closely with a lot of 
customers in the field, from small networks to F500 customers.

Next, are we going to specify what an Rbridge does for every single IEEE 
protocol ? I don't think so. If we get into that game, we're in deep 
trouble. I'm fine if someone wants to write an informational draft that 
talks about how an RBridge should correctly implement various IEEE 
protocols. I, for one, don't think it is valuable in the base protocol 
spec, has the danger of being out of date and duplicating information. 
I'd like to draw a clean demarcation of Rbridge functionality from IEEE 
bridge functionality. We don't specify how VLANs work in this draft. 
They're specified in IEEE and folks follow those documents for 
understanding and implementing VLAN functionality.

Rbridges are forward looking. They fix what is broken and is in urgent 
demand, by keeping it simple and not complicating the base protocol with 
unnecessary functionality. They don't get to be forward looking by 
mandating what is not required in the field, that standards bodies that 
define those standards don't mandate either.

If we had broken statements about handling dynamic VLAN registration in 
the draft, let's take it out completely, not fix it. I must've missed 
seeing that section or you'd have heard me holler a lot sooner.

Dinesh

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 31 Mar 2008 12:15:14 -0400

> understanding and implementing VLAN functionality.

I agree with this approach.

I suspect this boils down to where we think an RBridge fits in 802's 
hierarchy. If you view it as an alternate to 802.1 which cobbles
together
802.3 links then you end up having to specify how it supports or does
not
support virtually every 802.1 protocol.

802.1 has trouble keeping track of 802.1 projects. We don't want to go
there.

A more stable approach is to view RBridge as a *consumer* of 802.1
services.
Each RBridge connects to one or more physical LANs using 802.1 services,
and
participates in VLANs on each physical LAN according to whatever 802.1
rules
are appropriate for that LAN. That means 802.l and the market place
determines
how much standards lag is tolerable, not an IETF group.

BRridges then share their VLAN membership with each other. This ends up
relaying
information about VLAN membership, but it is not the same thing as
relaying/proxying
BPDUs and LLDP packets around.

There may be some 802.1 protocols that are desirable to carry through
RBridges.
AVB and Congestion Notification are both possibilities. But the rules
for extending
special 802.1 clouds through RBridges should be dealt with later in
separate
documents. Having base specifications for both RBridges and the 802.1
cloud
discovery rules will certainly help.

There is a very simple and easily understood model where RBridges use
802.1 services
to relay messages between RBridges, performs encapsulation on ingress
data frames
and decapsulation on egress data frames. Trying to figure out which
802.1 control
frames should be forwarded by RBridges will greatly complicate that
entire process.
We should at least wait until 802.1 has finished working that out for
all the various
types of 802.1 bridges.

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 31 Mar 2008 09:39:58 -0700

Caitlin,

> 802.1 has trouble keeping track of 802.1 projects. We don't want to go
Exactly.
> A more stable approach is to view RBridge as a *consumer* of 802.1
This was the same thing I wanted to convey with a picture,

Dinesh

---

From: "Silvano Gai" <[email-masked]>
Date: Mon, 31 Mar 2008 12:03:07 -0700

I agree with Dinesh and Caitlin

-- Silvano

> Sent: Monday, March 31, 2008 9:40 AM
> To: Caitlin Bestler

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Apr 2008 07:50:16 -0700

Caitlin Bestler wrote:
>> protocol ? I don't think so. 
...
>> bridge functionality.
...
> hierarchy. 
...
> A more stable approach is to view RBridge as a *consumer* of 802.1

This is why I wanted (and still want) to define a campus as emulating a 
single ethernet switch - where the IEEE defines that device, not us. 
That then defines all other behaviors as a derivative of that approach.

Joe