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

From: Francesca Palombini <[email-masked]>
Date: Sat, 19 Mar 2022 20:02:14 +0000

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: [email-masked] <[email-masked]>
Date: Wednesday, 23 February 2022 at 08:25
To: Francesca Palombini <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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: +86 13851460269 E: [email-masked]
------------------原始邮件------------------
发件人：FrancescaPalombini
收件人：魏月华00019655;[email-masked];
抄送人：[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];
日 期 ：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
[email-masked]
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: [email-masked] <[email-masked]>
Date: Wednesday, 26 January 2022 at 03:15
To: [email-masked] <[email-masked]>, Francesca Palombini <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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: [email-masked]
------------------原始邮件------------------
发件人：MartinVigoureux
收件人：Francesca Palombini;The IESG;
抄送人：[email-masked];[email-masked];[email-masked];[email-masked];
日  期 ：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
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 19 Mar 2022 16:11:00 -0400

the first part of your proposal looks quite reasonable to me.

I am however confused by the second part.  You seem to be asking about 
interoperability across "different deployments".  SFC NSH (which is what 
is used for this) is restricted to use within a single operational 
domain.  Yes, if the operator configures different devices in their 
domain with different interpretations of any fields, it will make a 
mess.  That is their foot to shoot.

Yours,
Joel

On 3/19/2022 4:02 PM, Francesca Palombini wrote:
> 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, 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: [email-masked] <[email-masked]>
> *Date: *Wednesday, 23 February 2022 at 08:25
> *To: *Francesca Palombini <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, 
> [email-masked] <[email-masked]>, 
> [email-masked] <[email-masked]>, [email-masked] 
> <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] 
> <[email-masked]>
> *Subject: *Re:[sfc] Francesca Palombini's Discuss on 
> draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
> 
> Dear Francesca,
> “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
> 抄送人：[email-masked];sfc- 
> [email-masked];[email-masked];[email-masked];[email-masked];
> 日 期 ：2022年02月11日 21:33
> 主 题 ：Re: [sfc] Francesca Palombini's Discuss on 
> draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
> <https://www.ietf.org/mailman/listinfo/sfc>
> 
> Hi Yuehua,
> This was discussed during the telechat (minutes here: 
> https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt 
> <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.
> To: [email-masked] <[email-masked]>, Francesca 
> Palombini <[email-masked]>
> Cc: [email-masked] <[email-masked]>, [email-masked] 
> <[email-masked]>, [email-masked] 
> <[email-masked]>, [email-masked] <[email-masked]>, 
> [email-masked] <[email-masked]>
> Subject: Re:[sfc] Francesca Palombini's Discuss on 
> draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt>
> Best Regards,
> Yuehua Wei
> 抄送人：[email-masked];sfc- 
> [email-masked];[email-masked];[email-masked];
> 日 期 ：2021年12月02日 20:31
> 主 题 ：Re: [sfc] Francesca Palombini's Discuss on 
> draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
> Hello Francesca,
>  > Please refer to 
> https://www.ietf.org/blog/handling-iesg-ballot-positions/ 
> <https://www.ietf.org/blog/handling-iesg-ballot-positions/>
> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/>
>  >
>  >
>  >
> <https://www.ietf.org/mailman/listinfo/sfc>
>

---

From: Francesca Palombini <[email-masked]>
Date: Sat, 19 Mar 2022 20:22:02 +0000

Hi Joel,

Thanks for your response. I guess my confusion then comes from the use of the term “deployment” in the sentence “The structure and semantics of this field are deployment specific.” I interpreted “different deployments” as “different implementations”, which I assume could exist even within a single operational domain. What I meant to ask is for more warning text about that – but if you are telling me my understanding of the term deployment is incorrect in this context, and that this situation cannot really happen (or rather could happen but does not have consequences outside of the single operational domain), I am fine with that.

Thanks,
Francesca

From: Joel M. Halpern <[email-masked]>
Date: Saturday, 19 March 2022 at 21:11
To: Francesca Palombini <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
the first part of your proposal looks quite reasonable to me.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 19 Mar 2022 16:23:42 -0400

As far as I know, "deployment" is intended to refer to the set of things 
deployed by an operator, under their orchestration.

If you can suggest wording to clarify that, I expect the authors would 
be happy to add it.  (If it is confusing you, it presumably is likely to 
confuse others as well.)

Yours,
Joel

On 3/19/2022 4:22 PM, Francesca Palombini wrote:
> Hi Joel,
> 
> Thanks for your response. I guess my confusion then comes from the use 
> of the term “deployment” in the sentence “The structure and semantics of 
> this field are deployment specific.” I interpreted “different 
> deployments” as “different implementations”, which I assume could exist 
> even within a single operational domain. What I meant to ask is for more 
> warning text about that – but if you are telling me my understanding of 
> the term deployment is incorrect in this context, and that this 
> situation cannot really happen (or rather could happen but does not have 
> consequences outside of the single operational domain), I am fine with that.
> 
> Thanks,
> Francesca
> 
> *From: *Joel M. Halpern <[email-masked]>
> *Date: *Saturday, 19 March 2022 at 21:11
> *To: *Francesca Palombini <[email-masked]>, 
> [email-masked] <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, 
> [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
> *Subject: *Re: [sfc] Francesca Palombini's Discuss on 
>  > <https://www.ietf.org/mailman/listinfo/sfc 
> <https://www.ietf.org/mailman/listinfo/sfc>>
>  >
>  > Hi Yuehua,
> <https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt <https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt>> 
> 
>  > <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt 
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt>>
>  > Best Regards,
>  > Yuehua Wei
>  >  > 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/ 
> <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/ 
>  > <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ 
> <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.
>  >  >
>  >  >
>  >  >
>  >  >
>  > <https://www.ietf.org/mailman/listinfo/sfc 
> <https://www.ietf.org/mailman/listinfo/sfc>>
>  >
>

---

From: Francesca Palombini <[email-masked]>
Date: Sat, 19 Mar 2022 20:39:25 +0000

What about this:

OLD:
The structure and semantics of this field are deployment specific.
NEW:
The structure and semantics of this field are specific to the operator's deployment across its operational domain, and are specified and assigned by an orchestration system. The specifics of that orchestration system assignment are outside the scope of this document.

Does that make sense? In my (biased) view it does help clarify what was said.
Francesca

Date: Saturday, 19 March 2022 at 21:24

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 19 Mar 2022 16:41:12 -0400

Looks good to me.  I will et the authors and shepherd comment from here.
Thank you,
Joel

On 3/19/2022 4:39 PM, Francesca Palombini wrote:
> The structure and semantics of this field are specific to the operator's 
> deployment across its operational domain, and are specified and assigned 
> by an orchestration system. The specifics of that orchestration system 
> assignment are outside the scope of this document.
> 
> *Date: *Saturday, 19 March 2022 at 21:24
>  >  > 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: [email-masked] <[email-masked]>
>  >  > *Date: *Wednesday, 23 February 2022 at 08:25
>  >  > *To: *Francesca Palombini <[email-masked]>
>  >  > *Cc: [email-masked] <[email-masked]>,
>  >  > [email-masked] <[email-masked]>,
>  >  > [email-masked] <[email-masked]>, [email-masked]
>  >  > <[email-masked]>, [email-masked] <[email-masked]>, [email-masked]
>  >  > <[email-masked]>
>  >  > *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: +86 13851460269 E: [email-masked]
>  >  > ------------------原始邮件------------------
>  >  > 发件人：FrancescaPalombini
>  >  > 收件人：魏月华00019655;[email-masked];
>  >  > 抄送人：[email-masked];sfc-
>  >  > [email-masked];[email-masked];[email-masked];[email-masked];
>  >  > 日 期 ：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
>  >  > [email-masked]
>  >  > https://www.ietf.org/mailman/listinfo/sfc 
>  >  > <https://www.ietf.org/mailman/listinfo/sfc
> <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:
>  >  > system-generated tenant identifier.  The structure and semantics
>  >  > 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 <https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt 
> <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: [email-masked] <[email-masked]>
>  >  > Date: Wednesday, 26 January 2022 at 03:15
>  >  > To: [email-masked] <[email-masked]>, Francesca
>  >  > Palombini <[email-masked]>
>  >  > Cc: [email-masked] <[email-masked]>, [email-masked]
>  >  > <[email-masked]>, [email-masked]
>  >  > <[email-masked]>, [email-masked] <[email-masked]>,
>  >  > [email-masked] <[email-masked]>
>  >  > 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 
>  >  > <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt>>>
>  >  > Best Regards,
>  >  > Yuehua Wei
>  >  > M: +86 13851460269 E: [email-masked]
>  >  > ------------------原始邮件------------------
>  >  > 发件人：MartinVigoureux
>  >  > 收件人：Francesca Palombini;The IESG;
>  >  > 抄送人：[email-masked];sfc-
>  >  > [email-masked];[email-masked];[email-masked];
>  >  > 日 期 ：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/ 
>  >  > <https://www.ietf.org/blog/handling-iesg-ballot-positions/
> <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/ 
>  >  > <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
> <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
>  >  > [email-masked]
>  >  > https://www.ietf.org/mailman/listinfo/sfc 
>  >  > <https://www.ietf.org/mailman/listinfo/sfc
> <https://www.ietf.org/mailman/listinfo/sfc>>>
>  >  >
>  >
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 20 Mar 2022 01:42:21 +0000

Many thanks Joel and Francesca!

As I had suggested the word ‘deployment’, for completeness, it had the exact intended meaning as Joel articulate. I am OK with the text, though have a very small suggestion: ’orchestration function’ seems to be more general than ‘orchestration system’.

How about:

OLD:
The structure and semantics of this field are deployment specific.
NEW:
The structure and semantics of this field are specific to the operator's deployment across its operational domain, and are specified and assigned by an orchestration function. The specifics of that orchestration-based assignment are outside the scope of this document.

Thanks!

Carlos.

On Mar 19, 2022, at 4:41 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

On 3/19/2022 4:39 PM, Francesca Palombini wrote:
What about this:
OLD:
The structure and semantics of this field are deployment specific.
NEW:
The structure and semantics of this field are specific to the operator's deployment across its operational domain, and are specified and assigned by an orchestration system. The specifics of that orchestration system assignment are outside the scope of this document.
Does that make sense? In my (biased) view it does help clarify what was said.
Francesca
*From: *Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
*Date: *Saturday, 19 March 2022 at 21:24
*To: *Francesca Palombini <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
*Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
*Subject: *Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
As far as I know, "deployment" is intended to refer to the set of things
deployed by an operator, under their orchestration.
If you can suggest wording to clarify that, I expect the authors would
be happy to add it.  (If it is confusing you, it presumably is likely to
confuse others as well.)
Yours,
Joel
On 3/19/2022 4:22 PM, Francesca Palombini wrote:
> *From: *Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> *To: *Francesca Palombini <[email-masked]<mailto:[email-masked]>>,
> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> *Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>,
> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>  > *From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>  > *To: *Francesca Palombini <[email-masked]<mailto:[email-masked]>>
>  > *Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>,
>  > [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>,
>  > [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
>  > <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
>  > <[email-masked]<mailto:[email-masked]>>
>  > M: +86 13851460269 E: [email-masked]<mailto:[email-masked]>
>  > 收件人：魏月华00019655;[email-masked]<mailto:[email-masked]>;
>  > 抄送人：[email-masked]<mailto:[email-masked]>;sfc-
>  > [email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;
>  > 日 期 ：2022年02月11日 21:33
>  > [email-masked]<mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> <https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>>
> <https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>>>
>  >
>  > Hi Yuehua,
> https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt <https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt>
> <https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt <https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt <https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt>>>  >
>  > From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>  > To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Francesca
>  > Palombini <[email-masked]<mailto:[email-masked]>>
>  > Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
>  > <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
>  > <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>,
>  > [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>  > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt>
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt>>
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt>>>
>  > Best Regards,
>  > Yuehua Wei
>  > M: +86 13851460269 E: [email-masked]<mailto:[email-masked]>
>  > 抄送人：[email-masked]<mailto:[email-masked]>;sfc-
>  > [email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;
>  > 日 期 ：2021年12月02日 20:31
>  > https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://www.ietf.org/blog/handling-iesg-ballot-positions/>
> <https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://www.ietf.org/blog/handling-iesg-ballot-positions/>>
> <https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://www.ietf.org/blog/handling-iesg-ballot-positions/>>>
>  >  > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/>
> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/>>
> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/>>>
>  >  >
>  >  >
>  >  >
>  > [email-masked]<mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> <https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>>
> <https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>>>
>  >
>

---

From: Francesca Palombini <[email-masked]>
Date: Wed, 23 Mar 2022 07:34:22 +0000

Hi Carlos,

That looks good, I’ll clear my discuss as soon as this update is posted.

Thanks for working with me,
Francesca

From: Carlos Pignataro (cpignata) <[email-masked]>
Date: Sunday, 20 March 2022 at 02:42
To: Joel M. Halpern <[email-masked]>
Cc: Francesca Palombini <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, The IESG <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Many thanks Joel and Francesca!

How about:

OLD:

Carlos.

What about this:
OLD:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 23 Mar 2022 16:09:53 +0000

Thank you Francesca as the document is improved with that change.

Carlos.

From: Francesca Palombini <[email-masked]>
Date: Wednesday, March 23, 2022 at 3:34 AM
To: "Carlos Pignataro (cpignata)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, March 23, 2022 at 3:34 AM

Hi Carlos,

How about:

OLD:

Carlos.

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 10:22:06 +0800 (CST)

Thank you Francesca and Carlos, will update to the next version.

Best Regards,
Yuehua Wei
------------------原始邮件------------------
发件人：CarlosPignataro(cpignata)
收件人：Francesca Palombini;Joel M. Halpern;
抄送人：魏月华00019655;[email-masked];The IESG;[email-masked];
日 期 ：2022年03月24日 00:10
" _ue_custom_node_="true">
On Mar 19, 2022, at 4:41 PM, Joel M. Halpern <[email-masked]> wrote:
*To: *Francesca Palombini <[email-masked]>, [email-masked] <[email-masked]>
*Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 09:52:41 +0800 (CST)

Dear Francesca and Carlos,
New version has been posted reflecting resolved comments in 4.2 , please take a look.
https://www.ietf.org/archive/id/draft-ietf-sfc-nsh-tlv-14.txt

Best Regards,

Yuehua Wei
------------------原始邮件------------------
发件人：魏月华00019655
收件人：[email-masked];[email-masked];
抄送人：[email-masked];[email-masked];[email-masked];
日 期 ：2022年03月24日 10:22
主 题 ：Re: [sfc]  Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Thank you Francesca and Carlos, will update to the next version.

Best Regards,
Yuehua Wei