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

Hi Yuehua,

Thanks for your update! It addresses almost all my comments.

I still have the same problem with the following unchanged text:

      Tenant ID: Represents an opaque value pointing to Orchestration

      system-generated tenant identifier.  The structure and semantics

      of this field are deployment specific.

The question being how can this field be interoperable if the structure and semantics is deployment specific.

This was discussed during the telechat (minutes here: https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt ), and Ben was great at putting into words my concern:

Ben: If it's going to be the byte string that is just configured everywhere and you just check if it matches or doesn't match, that's pretty straightforward and that is probably going to be interoperable. I think you can get some interoperability issues if it's a value that may or may not be configured as opaque to the NSH implementation but then it has to be processed in some way by the recipients, as the software implementation on the recipient is only going to implement support for some fixed set of formats. If that implementation picks one set of formats and another implementation picks a different set of formats, there may not be any overlap so you may not be able to actually interoperate in terms of the contents of that field. That's a little far removed from the NSH protocol itself but there is perhaps still some interoperability concern to be worried about there, depending on how this value is expected to be processed by the recipient.

I was hoping some text could be added about configuration, and why this should not be a problem in the use cases of this document. Basically some more details about what Martin says: The point is really that both the classifier that we insert to that metadata and possibly some virtual network function that will process it, be configured the same.

This in my opinion is not clear enough in the document as is. It could be clarified ither in the “Tenant ID” definition or in a separate paragraph.

I’ll update the DISCUSS to reflect this comment.
Thank you,
Francesca

From: wei.yuehua@zte.com.cn <wei.yuehua@zte.com.cn>
Date: Wednesday, 26 January 2022 at 03:15
To: martin.vigoureux@nokia.com <martin.vigoureux@nokia.com>om>, Francesca Palombini <francesca.palombini@ericsson.com>
Cc: iesg@ietf.org <iesg@ietf.org>rg>, draft-ietf-sfc-nsh-tlv@ietf.org <draft-ietf-sfc-nsh-tlv@ietf.org>rg>, sfc-chairs@ietf.org <sfc-chairs@ietf.org>rg>, sfc@ietf.org <sfc@ietf.org>rg>, gregimirsky@gmail.com <gregimirsky@gmail.com>
Subject: Re:[sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Dear Martin and Francesca,
Combine with your comments and suggestions, I uploaded a ver12 to reflected the updates.
I appreciate your further review.
The link of differences is :
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt

Best Regards,
Yuehua Wei
M: +86 13851460269 E: wei.yuehua@zte.com.cn
------------------原始邮件------------------
发件人：MartinVigoureux
收件人：Francesca Palombini;The IESG;
抄送人：draft-ietf-sfc-nsh-tlv@ietf.org;sfc-chairs@ietf.org;sfc@ietf.org;gregimirsky@gmail.com;
日 期 ：2021年12月02日 20:31
主 题 ：Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
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.
>
>
>
>

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc