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

[Francesca Palombini via Datatracker <[e-mail]>]

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.
Second - I'd like some clarification about interoperability. More details below.

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.