Subject: [rbridge] Extensions

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 5 Dec 2006 15:17:28 -0500

Hi,

See comments below at @@@

-----Original Message-----
From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] 
Sent: Wednesday, November 29, 2006 11:27 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: Re: [rbridge] Extensions

Clearly making the ability to add fields in the future in a compatible
way gives flexibility. Having TLV encoding in IS-IS has proven to be
really valuable.

On the other hand, questions  that should be asked are:

a) why not? As in, what is the cost of doing this future flexibility?
b) what kinds of features might we imagine
c) is there any other way of adding features in the future in a
compatible way?

I'll make a stab at some of these
a) Why not?
Perhaps complexity of forwarding decision, or perceived complexity of
the protocol that might discourage adoption.
If all the fields necessary for current functionality are in the fixed
portion of the shim, and RBridges that don't do the feature can ignore
it, then that would not be a problem. But for instance, if they have to
look at the inner header to find the VLAN tag (in order to know whether
to filter a multicast), or the inner destination address (for IP derived
multicast -- though maybe it's the layer 3 destination address that
matters...not sure), then having a variable length shim header could be
a cost

@@@ There is no getting around the fact that providing extensions makes
things more complex. And since extensions can be present or absence, it
necessarily leads to a variable length shim in cases where extensions
might be present. However, the extension proposal in my presentation,
which does incorporate some ideas I got from others, tries to minimize
the additional complexity. In particular, it tries to assure that any
Rbridge that might be an egress Rbridge will not receive any extension
that it does not understand. A goal of the extension design is that an
Rbridge the does not understand any extensions would not need any
additional code.

@@@ If there are fields after the shim in the current design that are
clearly needed for normal operation, such as inner VLAN tag for
broadcast/multicast filtering, then it seems like it might be a good
idea to mirror them in the shim.

@@@ But, beyond normal Rbridge operation, there is no obvious limit on
how deeply some QoS policy might want to look into a packet. It could
certainly want to look at TCP port, for example, which already requires
it, in the Rbridge case, to skip over a variable length assortment of
802.1 inserts between the inner MAC addresses and the inner payload. If
a feature outside of TRILL already has to do something that complex, it
doesn't seem like much of a burden for it to understand a variable
length shim due to extensions. Thus, the proposal in my presentation
provides an overall extensions size to make it relatively easy to skip
them.

b) features: LIDs ... any others?

@@@ LIDs seem like a nice extension that has the characteristic that you
only would want to include it if both  end point Rbridges understood it
(see comments under "c)" below).

@@@ Someone might want a security extension. Even if it turned out to
use 802.1AE, it seem like you would need a way to indicate that such
information was present in the Rbridge shim.

@@@ Of course, the most interesting extensions would be those that are
not currently thought of.

c) not sure

@@@ Adding feature can be done in different ways. I think they may all
be logically equivalent but they would have very different
implementation impact. For example, instead of extensions, you could
have a version number so that when you define extension N, if you use
that extension, you have to assert version N. This seems like a bad idea
because you have to upgrade all your equipment to know about version N.
Possibly that makes sense for an extension that every Rbridge actually
has to understand, but maybe such a radical extension is best considered
to be a revision of the base protocol. More reasonable extension
proposals would provide more or less end-to-end Rbridge extensions in
such a way that intervening Rbridges could ignore them.

Radia

@@@ Thanks,
@@@ Donald

----- Original Message -----
From: Eastlake III Donald-LDE008 <Donald.Eastlake at motorola.com>
Date: Wednesday, November 29, 2006 7:58 pm
Subject: [rbridge] Extensions

> Hi,
> 
> It is not so much that I think that TRILL needs any particular 
> extension added right now, it is just that if there is ever a reason
to 
> add an extension, it would be good for the extension framework to have

> been decided in advance. The presentation that I didn't have time to 
> make at the TRILL WG meeting in San Diego has now been converted from 
> MS Power Point and is on the Working Group agendas and presentations 
> web page for the 67th IETF meeting in HTML and is also available at
> http://www.pothole.com/~dee3 in PDF.
> 
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] On 
> Behalf Of Radia Perlman
> Sent: Monday, November 13, 2006 8:01 PM
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> ......
> 
> Another thing we haven't talked about on the list (and ran out of time

> at the meeting), is Don Eastlake's suggestion of allowing the shim 
> header to be variable length, so that we can optionally put in thing 
> like LIDs.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>