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

[Francesca Palombini <[e-mail]>]

Hi,

Apologies for the delay.

This text does not really addresses my concern – what is missing is something complementing the sentence “The structure and semantics of this field are deployment specific.” So maybe the following change could help:

OLD:
The structure and semantics of this field are deployment specific.
NEW:
The structure and semantics of this field are deployment specific, and are specified and assigned by an orchestration system. The specifics of that orchestration system assignment are outside the scope of this document. “

Additionally, it would be really necessary in my opinion to have some additional consideration saying that if the Tenant IDs semantics and structure are not configured the same for different deployments, interoperability will break, and what that would mean: what happens if deployment cannot interpret the Tenant IDs? How is that interpreted by the recipient?

Francesca



From: [e-mail] <[e-mail]>
Date: Wednesday, 23 February 2022 at 08:25
To: Francesca Palombini <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re:[sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Dear Francesca,
Thank you for providing detailed opinions and references.
How about adding some text like the following ：
“The Tenant ID is assumed to be generated and assigned by an orchestration system, which would allow for interoperability. The specifics of that orchestration system assignment are outside the scope of this document.”


Best Regards,
魏月华 Yuehua Wei
承载网标准预研-项目经理/Lead of Bearer Network Standards Development Project
架构团队/有线规划部/有线产品经营部/Architecture Team/Wireline Product Planning Dept/Wireline Product Operation
ZTE Corporation
南京市软件大道50号/No.50, Software Avenue, Nanjing, 210012, P. R. China
M: [phone] E: [e-mail]
------------------原始邮件------------------
发件人：FrancescaPalombini
收件人：魏月华00019655;[e-mail];
抄送人：[e-mail];[e-mail];[e-mail];[e-mail];[e-mail];
日 期 ：2022年02月11日 21:33
主 题 ：Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc

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: [e-mail] <[e-mail]>
Date: Wednesday, 26 January 2022 at 03:15
To: [e-mail] <[e-mail]>, Francesca Palombini <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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: [phone] E: [e-mail]
------------------原始邮件------------------
发件人：MartinVigoureux
收件人：Francesca Palombini;The IESG;
抄送人：[e-mail];[e-mail];[e-mail];[e-mail];
日  期 ：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
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc