Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)

[Martin Vigoureux <[e-mail]>]

Hello Francesca,

thank you for your review. Please see inline.

I invite the authors to share their views.

-m

Le 2021-11-29 à 11:59, Francesca Palombini via Datatracker a écrit :
> Francesca Palombini has entered the following ballot position for
> draft-ietf-sfc-nsh-tlv-09: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thank you for the work on this document.
> 
> I have some comments, mostly having to do with clarifications and improvement
> of text for readability. I'd like answers to two main points: first - I believe
> the lack of normative references to the documents that define the fields this
> document registers into IANA is important enough to warrant some discussion.
Not sure whether you are asking for Normative references in 4.1 or in 
4.2 to 4.6, or both.
I'm not sure Normative references would be appropriate for the metadata 
objects (from 4.2 to 4.6) this document defines. All of them are opaque, 
and under the control of the operator. Informative references (like in 
4.6) would be a plus though.
I'm sure the authors can add Normative references to 4.1 too.


> Second - I'd like some clarification about interoperability. More details below.
It would be great if you could elaborate a bit on the interoperability 
issues you foresee. Personally, I can envisage misconfiguration driven 
problems, but not interop ones.

> 
> Francesca
> 
> 1. -----
> 
>        Tenant ID: Represents an opaque value pointing to Orchestration
>        system-generated tenant identifier.  The structure and semantics
>        of this field are deployment specific.
> 
> FP: I am worried about interoperability, as the field is defined as deployment
> specific. Could you clarify why you don't think this is an issue? Also, please
> add a normative reference to the section and document defining tenant
> identification.
> 
> 2. ----
> 
> Section 4.3
> 
> FP: Same comment as above for Node ID: please add a reference and explain
> interoperability, as this is defined as deployment specific.
> 
> 3. -----
> 
> Sections 4.4, 4.5
> 
> FP: I do think these fields need references to the documents they are defined
> in. (I am aware section 2.1 and the normative references should help, but I
> think it would be much clearer to have direct links to the right place in the
> text.) For Flow ID, if I understand correctly, this document defines it high
> level and gives examples of what value it can take. I would clarify that in the
> first paragraph of the section (as you do for Section 4.6), instead of having
> the references only in the "Length" paragraph.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 4. -----
> 
> Section 4.1
> 
> FP: I think it would be better to have the sentence "Reserved bits MUST be sent
> as zero and ignored on receipt." only once, rather than repeat for each
> context. What is missing instead is the number of bits that are reserved for
> each CT. I know that it can be extracted from the figure or from the value of
> the Forwarding Context field, but I believe figures should be complemented by
> clear written text. Additionally, to improve readability, references should be
> added for the forwarding context where they are missing: VLAN identifier, MPLS
> VPN label‚ VNI.
> 
> 
> 
>