Subject: [rbridge] Trill Extensions and options

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Feb 2012 09:22:13 -0500

There are a number of WG LC's going on at the moment, including
rbridge-extension. I've also been reviewing and thinking about the
entire set and looking at OAM approaches as well.

At this point, I guess I have to say am am unsold on the need for the
extensions document and options at all. I'm raising this issue from
the perspective of wanting to be convinced that there is something
important I haven't considered.

At a high level, why does TRILL we need extensions and options (at the
trill header level) in the first place?

Looking at draft-ietf-trill-rbridge-options-06.txt, for example, I
don't see anything defined that seems particularly useful or
necessary. That is, the proposed options either seem to be like not
really necessary, or there are alternate ways of achieving equivalent
functionality that don't require the use of extensions (which would
require changes in the implementation of the forwarding processing).
Indeed, it almost seems like the extensibility mechanism is a solution
in search of a problem.

Second, I feel like draft-ietf-trill-rbridge-extension-02.txt has a
lot of things in it that have been proposed "just in case they might
be useful". But for which (again) I'm not aware of any compelling
possible use. And having watched the various attempts to define new
IPv4 options (or make use of even the existing ones) with similiar
issues coming up w.r.t. IPv6 option processing, I've become
increasingly skeptical with the approaches that have been proposed for
allowing for possible future extensions can be made to work in
practice. It just turns out (for many reasons) to be very hard to
deploy new functionality.

Without a compelling "must have" feature, I don't see vendors ever
implementing TRILL options/extensions. And even if they did, they
would certainly do so in the "slow path" initially (just like in
IPv4/IPv6), which severely limits the utility (and deployability) of
such extensions. I fear that these extensions will never be
implemented in practice, because they'll never be able to get past the
chicken-and-egg problem.

Do we *really* need to define options and extensions in Trill? Does
anyone think they will ever be implemented?

The main argument I can see in favor of defining extensions now is so
that folk can implement:

1) the checking of the critical bits
2) being able to  skip over unknown extensions in the future, should
   any ever be defined.

But is that enough, and will today's implementations bother to do so?
(The one implementation I am familiar with cannot).

But even with the above motivation I'm skeptical we will see even the
simple steps outlined above happening in actual implementations. The
issue goes beyond just skipping extension header on egress, transit
RBs doing ECMP will also need to skip the extension headers too, in
order to peek into the IP header fields. As will those doing pruning
of multicast trees. But will implementations bother to do so?  I have
real doubts.

In terms of OAM (and the Channel draft), the channel draft currently
has a normative dependency on the extensions draft. This is for
examination of the critical "rbridge channel alert" flag is set.  But
I think that normative dependency can be removed. My current thinking
is that the "Rbridge Channel Alert" flag does not need to exist at
all, as this is again a solution in search of a problem.

Thoughts?

Thomas

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 23 Feb 2012 15:02:18 -0500

Hi Thomas,

> entire set and looking at OAM approaches as well.

You seem to be looking considerably beyond the Extension draft
currently in WGLC. Primarily, the Extension draft provides more flag
bits and some ground rules.

> At this point, I guess I have to say am unsold on the need for the

The Options draft is not being proposed for advancement.

The Extension draft, which is in WGLC, mostly provides more detail on
facilities that are there in RFC 6325, which already provides that the
first word of the extension area is special. I wouldn't mind removing
from the Extension draft the two very minor passing references to the
possibility of the future specification of TLV options.

> necessary. ...

It seems pretty remarkable to me that you can determine that there is
nothing useful in ietf-trill-rbridge-options or in
eastlake-trill-rbridge-more-options or in anything else that someone
might think of in the future. Even if that were true, it isn't want's
being last called. What's being last called is more header flags.

> be useful". ...

I don't think there is a "lot" of anything in the Extension draft. The
concrete content of the Extension draft is just to take the rest of
the bits in the first 32-bit word of the extension area (a word
provided for and whose top two bits are specified in RFC 6325),
specify the type of the remaining bits in that word as extended header
flags, and specify the actually use of two of those bits.

> implementing TRILL options/extensions. ...

The functionality of the two particular extended header flags
specified in the Extension draft are, as far as I know, supported by
all existing TRILL silicon. To repeat, the Options draft is not
currently being proposed for advancement.

> 2) being able to  skip over unknown extensions in the future, should

I agree that 1 is an significant argument but on your 2, I would say
it is more to be able to do things like tunnel some known information
from ingress to egress, or the like, not necessarily that that
information be "unknown".

> (The one implementation I am familiar with cannot).

I can't guarantee anything but I would say that if the Extension draft
is not adopted, its content is unlikely to be implemented :-)

> simple steps outlined above happening in actual implementations.
> ... skipping extension header ...
> But will implementations bother to do so?  I have real doubts.
>

One person's "solution in search of a problem" is another person's
simple foundation facilities that should be specified early so they at
least have a chance of being available later if needed. Although
specific concrete example uses are given for the channel Alert flags,
I can't guarantee they will actually be used in the future. But since
their functionality is supported by all existing silicon I know about
and the cost of supporting the Alert flags, for an RBridge that
supports the channel feature at all, would be very low, I believe they
should be specified and the Extension draft should advance.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Feb 2012 09:16:20 -0500

Hi Donald.

> bits and some ground rules.

I'm looking beyond the extensions draft because presumably the
extensions draft is being defined to support some future facility. But
absent such a future facility (and a compelling argument for its
utility), I think we are better off not defining the bits in the
extensions draft at this time. Rather, we should just leave them
reserved.

This is driven by my overall sense that it is very hard to design
(correctly) facilities for some future unspecified use. The IETF has
done so with many protocols, only to find out later that our attempts
were not helpful. IMO, as a general principle, we are better off
leaving fields undefined and reserved until there is a specific,
concrete proposed use case. Only with a concrete proposed use case can
we properly design the mechanism for providing that facility.

Moreover, if we define facilities for which there is no compelling
current use, it is unlikely that implementors will bother to implement
them anyway. In which case, we haven't really acheived anything.

> The Options draft is not being proposed for advancement.

Understood.

> possibility of the future specification of TLV options.

The current reference to possible future TLV options doesn't concern
me. I'm OK leaving it as it is.

> being last called. What's being last called is more header flags.

What I mean is that nothing that is in rbridge options to me provides
important or critical functionality that couldn't be provided in some
other way without using extensions. Sure, there are some possible
features that *might* be useful, but to me, that is not sufficient
justification. The Trill data plane should be optimized for the common
case, and not be burdened with facilities that are not critical.

> flags, and specify the actually use of two of those bits.

I think the entire concept of reserving ranges of bits for individual
classes of flags is speculative.

> currently being proposed for advancement.

I think we have different views on what "supported" means. Sure,
existing silicon most likely can check for the critical bits and when
present, punt the packet to the service processor. But IMO, that is
not "support". The cost of shunting packets to the service processor
is *very* high. Such extensions cannot be commonly used (else the
service processor will be overloaded), meaning that in practice one
cannot use such extensions on any *data* packet. Thus, such extensions
are IMO very likely unusable/undeployable in practice.

Thus, I think it is very misleading to say that existing silicon
"supports" such extensions.

> information be "unknown".

I think you miss my point on 2). Trill (for ECMP and for multicast
tree prunning) requires that the forwarding plane be able to find the
inner header and extract relevant fields. In order to do this (in the
fast path), ASICs must be able to use the Op Length field in order to
skip over any extensions to find the inner header fields

Are you saying existing silicon can do that? I do not believe this is
the case. And if not, it means that any packet with an extension will
get shunted to the service processor, which means use of such options
in a typical Trill data packet will be a non-starter.

Do you disagree?

> specific concrete example uses are given for the channel Alert

Note that per my other message, I don't believe the case for a Channel
Alert flag has been made. I'd prefer to wait before defining it.

> should be specified and the Extension draft should advance.

Again, we disagree on what "supported by all existing silicon" means.

Thomas