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

["Joel M. Halpern" <[e-mail]>]

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.
> 
> 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]>om>, 
> [e-mail] <[e-mail]>rg>, 
> [e-mail] <[e-mail]>rg>, [e-mail] 
> <[e-mail]>rg>, [e-mail] <[e-mail]>rg>, [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];sfc- 
> [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 
> <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 
> <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]>om>, Francesca 
> Palombini <[e-mail]>
> Cc: [e-mail] <[e-mail]>rg>, [e-mail] 
> <[e-mail]>rg>, [e-mail] 
> <[e-mail]>rg>, [e-mail] <[e-mail]>rg>, 
> [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 
> <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];sfc- 
> [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/ 
> <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/>
>  >
>  >
>  >
>  > ----------------------------------------------------------------------
>  > 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 
> <https://www.ietf.org/mailman/listinfo/sfc>
>