Subject: [trill] Alvaro Retana's Discuss on draft-ietf-trill-channel-tunnel-10: (with DISCUSS and COMMENT)

From: "Alvaro Retana" <[email-masked]>
Date: Wed, 06 Jul 2016 18:53:30 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-channel-tunnel-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-channel-tunnel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Even though the IANA Considerations section was just updated (in version
-10), I am putting in this DISCUSS because it is still
incomplete/incorrect.

1. Guidance for managing the SubERR namespace should be included.  Note
that this document only specifies values for ERR 6, but guidance should
be given to IANA for the other ERR values as well.

2. Section 6.2.1 (RBridge Channel Error Codes Subregistry) requests the
creation of a new registry ("RBridge Channel Error Codes”), but that
registry was already created by RFC7178.  This document should then split
the requests in two parts: assignment of the vales 6-8, and the change to
the registration procedure.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

>From Section 2. (RBridge Channel Header Extension Format), is the RESV4
field a space that is reserved for potential future use?  Why isn’t it
ignored on receipt (similar to the RESV field in Section 4.3)?  If there
is potential for use of this space (RESV is defined as 4 bits, which
makes me think about potential bit-level allocations), then there should
be some guidance in the IANA Considerations.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 Jul 2016 00:16:33 -0400

Hi Alvaro,

Thanks for you comments, See below.

On Wed, Jul 6, 2016 at 9:53 PM, Alvaro Retana <[email-masked]> wrote:
> ...

No IANA registry is created for any SubERR values so I'm not sure why
there needs to be IANA guidance. The draft can be made clearer that
for all values of ERR other than 6, SubErr should be sent as zero and
ignored on receipt. If you want, a registry could be added. I would
think IETF Review was the appropriate registration procedure.

> the registration procedure.

You are correct. Sorry for the oversight.

However, I actually think the registration procedure should stay as
Standards Action for new ERR codes as provided in the current IANA
registry. New major error codes can cause substantial problems with
older implementations that do not know what they mean. (I do not think
this is a problem with SubErr since implementations can take a default
action based on the major ERR code.)

Earlier versions of this document added three features to RBridge
Channel. As well as the payload feature and security feature in the
current document, which are invoked by non-zero values of the PType
and SType nibbles,
     if you look at the -01 or -00 version you will see a "Scope"
feature invoked by non-zero values of the Scope nibble. RBridge
Channel supports messages between RBridges in the same TRILL campus
and between an end station and an RBridge on the same link. The Scope
feature extended this to support, for example, messages between an end
station and an RBridge not on the same link. However, the scope
feature added significant complexity and there was no immediate
requirement for it so it was dropped and the Scope nibble was
relabeled RESV4.
    Those bits are deliberately made "critical" so the Scope feature
could be revived in the future and Scope-ignorant RBridges would know
to reject Extended RBridge Channel messages that are using the Scope
feature which changes the format a little. Any attempt to re-instate
the Scope feature or to make other use of these four bits will require
a Standards Track document in any case. I don't understand why there
needs to be any guidance in the IANA Considerations about this. What
would it say other than that any non-zero value is treated as an
error? which is a technical specification already present in the body
of the document and not an IANA Consideration.

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 7 Jul 2016 10:51:13 +0000

On 7/7/16, 1:16 AM, "Donald Eastlake" <[email-masked]> wrote:

Donald:

Hi!

>think IETF Review was the appropriate registration procedure.

Yes, I think a registry should be added.

>> creation of a new registry ("RBridge Channel Error Codes²), but that
>registry.New major error codes can cause substantial problems with

That works for me; I just mentioned the registration procedure because it
had been changed.

>> field a space that is reserved for potential future use?  Why isn¹t it

I agree with you on the IANA part (no need to add anything related to
RESV/RESV4).  

I still think (non blocking comment) that treating a received non-zero
value as an error adds unnecessary complexity if it can just be ignored.
If the Scope feature is ever revived (or any other feature that wants to
use the field) then it can change the behavior then.

Thanks!

Alvaro.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 Jul 2016 09:26:00 -0400

Hi Alvaro,

> Yes, I think a registry should be added.

OK.

> That works for me; I just mentioned the registration procedure because it

OK.

> I agree with you on the IANA part (no need to add anything related to

OK.

> use the field) then it can change the behavior then.

Well, perhaps we can agree to disagree.
     If that nibble is made critical, it provides a strong guarantee
against mishandling packets of a somewhat different format indicated
by the nibble being non-zero even in bizarre cases of delay in
propagating link state indicating non-support if the configuration of
an RBridge is rolled-back or who knows what. On the other hand, if the
nibble is made "send as zero ignore on receipt", which I agree is
normally the right thing, you always have a small chance of something
slipping through and being misinterpreted and it gets complex to
decide what to do about cases where you have multi-destination RBridge
Channel messages. Say you have a target multi-cast group with 100
members and 1 is not advertising support of the Scope feature. It
might make sense to just send with the scope feature anyway, if that
is safe; 99 will process it and 1 discard it. But if the Scope nibble
is non-critical, you have to serially unicast 99 copies of the message
to be safe; ugh...
     I think a key thing here is that use of the Scope feature
requires the addition of a couple more address/label fields to the
packet and, without criticality of the nibble, those fields will be
misinterpreted by recipients. Of course, there are potentially other
ways around this by multiplying "protocols" and using different values
in other fields on which the recipient dispatches... Ultimately it is
a judgement call which is "simpler".

Thanks,
Donald

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 7 Jul 2016 13:49:51 +0000

>Well, perhaps we can agree to disagree.

Yes, we can.  :-)