Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-extension-02

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Feb 2012 11:31:14 -0800

Last year we had a last call on draft-ietf-trill-rbridge-options, and 
that resulted in separating out the minimum set of flags and associated 
behavior into a this extensions document.

The WG last call ends on Feb 15th.
Please send comments (including ones that say you've read the document 
and it is fine) to the rbridge list.

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Feb 2012 18:16:06 -0500

Here are my comments on this document. Note that I've also read a
number of related documents, in order to understand how they all fit
together.

Summary

1) I do not think we need this document at this time. It defines a
bunch of (IMO) speculative uses for which it is not clear we have a
compelling use case (yet). My overall IETF experience has led me to be
very wary of trying to design for future functionality without a clear
use case. I think we should wait on specifying the details of the
extension word until we have such a use case (e.g., drafts that are
ready to publish that depend on the functionality in
trill-rbridge-extension). That is, just leave the bits "reserved" for
now and do not specify them further.

Does anyone think this document will be implemented anytime soon? I
would argue there is little reason to do so (given no compelling use
case), so implementations most likely won't.

2) It seems to me that the critical definitions are already in the
base Trill specification, namely that the first 2 bits of the
extensions header are for critical HbH or critical Ingress to Egress
options. Until there are some specific critical options defined, there
is no need to define the remaining bits in the extension word. By
defining them now, we run the risk of getting them wrong, and we may
later conclude that we made poor use of them.

3) The one new bit in the extensions draft that is potentially
important is the Channel Alert bit. IMO, this bit is unnecessary and
should be dropped. We already have a critical HbH bit, which does
mostly (if not entirely) the same thing. Moreover, I think that having
hop-by-hop channel protocols is a dubious idea. Without a concrete
proposal for one, where the WG has agreement that there is no better
way to solve the problem than to have a channel-specific HbH bit, we
should not define one.

4) I've also been looking at the OAM in
draft-ietf-trill-rbridge-oam-01.txt, and I do not see any need for OAM
to have a special hop-by-hop processing (in any case trill-rbridge-oam
does not call for use of hop-by-hop processing). There are other ways
of achieving the necessary functionality. Arguably, the alternatives
are to be preferred if for no other reason than they keep the core
data plan processsing simple.

My recommendation:

1) table this document for now, it is not needed.

2) in the channel draft, remove the normative depedency to this
document. (The channel document should go forward.)

That said, if the WG believes this document should go forward anyway,
I'd like to suggest that it be published as experimental rather than
on standards track. When and if there is a concrete usage for the
extended functionality, we could move it to standards track (possibly
with modifications) as appropriate.

I have some other comments on the document itself, if it goes
forward. My main comment concerns Section 2.4. I think it should be
deleted entirely. We should just not allow the definition of
conflicting options. Or if we do, we should say mutually incompatable
options MUST NOT be used together at the same time. If someone ends up
generating Trill packets with conflicting options, let the behavior be
undefined. Looking at Section 2.4, it seems that implementations may
end up having to do a lot of work to adhere to the rules -- and for
what ends?  We should just strongly discourage the use of conflicting
extensions, and when they happen, buyer beware. We should not
complicate implementations to handle cases that really shouldn't be
allowed to happen. That is IMO a bad tradeoff.

Alternatively, if we ever decide we need to define a conflicting
extension, that is the time to define how to handle the two when they
occur together. We may find that the proposed rules in Section 2.4 end
up being wrong for those specific options anyway, in which case we
find ourselves in a bind.

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Feb 2012 12:32:41 -0500

Hi,

On Thu, Feb 23, 2012 at 6:16 PM, Thomas Narten <[email-masked]> wrote:
> ...

While I think it would be unreasonable to forbid ever defining options
that could conflict, prohibiting the simultaneous use of such options
and stating that the results would be unspecified is reasonable. This
would be consistent with other parts of the TRILL specification that
make checking various frame constraints optional for transit RBridges
to reduce the burden on such RBridges.

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