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

[Donald Eastlake <[e-mail]>]

Hi Alvaro,

Version -11 of this draft has been posted which is intended to resolve your
DISCUSS.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Thu, Jul 7, 2016 at 6:51 AM, Alvaro Retana (aretana) <[e-mail]>
wrote:

> On 7/7/16, 1:16 AM, "Donald Eastlake" <[e-mail]> wrote:
>
> Donald:
>
> Hi!
>
> >>----------------------------------------------------------------------
> >> 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.
> >
> >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.
>
> Yes, I think a registry should be added.
>
> >
> >> 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.
> >
> >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.)
>
> That works for me; I just mentioned the registration procedure because it
> had been changed.
>
>
> >
> >> ----------------------------------------------------------------------
> >> 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.
> >
> >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.
>
> 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.
>
>