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

[Francesca Palombini <[e-mail]>]

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 <[e-mail]>
Date: Saturday, 19 March 2022 at 21:24
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)
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>>
>  >
>