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

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

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 <[e-mail]>
> *Date: *Saturday, 19 March 2022 at 21:11
> *To: *Francesca Palombini <[e-mail]>om>, 
> [e-mail] <[e-mail]>
> *Cc: *[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)
> 
> 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>
>  > <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>
>  > 
> <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>
>  > <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/>
>  > <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/ 
> <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>
>  > <https://www.ietf.org/mailman/listinfo/sfc 
> <https://www.ietf.org/mailman/listinfo/sfc>>
>  >
>