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

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

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:
> 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>>
>  >  > <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>>
>  >  >
>  > 
> <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>>
>  >  > <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/>>
>  >  > <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/>>
>  >  > <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>>
>  >  > <https://www.ietf.org/mailman/listinfo/sfc
>  > <https://www.ietf.org/mailman/listinfo/sfc 
> <https://www.ietf.org/mailman/listinfo/sfc>>>
>  >  >
>  >
>