Re: [sfc] Jim Guichard's Discuss on draft-ietf-sfc-ioam-nsh-11: (with DISCUSS and COMMENT)

[James Guichard <[e-mail]>]

Hi Frank,

Thanks for the quick turnaround and the new version. Looks good so I will clear my DISCUSS.

Jim

-----Original Message-----
From: Frank Brockners (fbrockne) <[e-mail]>
Sent: Thursday, May 4, 2023 4:18 PM
To: James Guichard <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Jim Guichard's Discuss on draft-ietf-sfc-ioam-nsh-11: (with DISCUSS and COMMENT)

Hi Jim,

Thanks a lot for your review. We've just posted an updated revision (12):
https://www.ietf.org/archive/id/draft-ietf-sfc-ioam-nsh-12.txt

Please see inline below:

> -----Original Message-----
> From: Jim Guichard via Datatracker <[e-mail]>
> Sent: Friday, 28 April 2023 21:32
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Jim Guichard's Discuss on draft-ietf-sfc-ioam-nsh-11: (with
> DISCUSS and COMMENT)
>
> Jim Guichard has entered the following ballot position for
> draft-ietf-sfc-ioam-nsh-11: 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%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-&data=
> 05%7C01%7Cjames.n.guichard%40futurewei.com%7C070486ccce544e2611bd08db4
> cdca1a1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63818828275209622
> 1%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GjI8lb39eBSgq%2BrWV1x974n
> BhY8ga1xuEtHuGDGbR3Y%3D&reserved=0
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://data/
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-ioam-nsh%2F&data=05%7C01%7Cjam
> es.n.guichard%40futurewei.com%7C070486ccce544e2611bd08db4cdca1a1%7C0fe
> e8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638188282752096221%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=BZQN1UeCktu9Nncxb17v4YYyPt7d6cvTajS2Eq
> 7%2F6dw%3D&reserved=0
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> - Section 3:
>    The IOAM-Data-Fields MUST follow the definitions corresponding to
>    IOAM-Option-Types (e.g., see Section 5 of [RFC9197] and Section 3.2
>    of [I-D.ietf-ippm-ioam-direct-export])
>
> The above reference to RFC9197 is incorrect although a simple fix. The
> IOAM-Option-Types are defined in Section 4 of that document not
> Section 5.
> Adding a DISCUSS as this reference is important enough to not just be
> a comment. Note that the same incorrect reference is used later on in
> Section
> 3
> and must be corrected also.

...FB: Corrected in  draft-ietf-sfc-ioam-nsh-12

>
> - Section 3:
>    The operator MUST ensure that all nodes along the service path
> support IOAM.
>     Otherwise packets with IOAM are likely to be dropped per [RFC8300].
>
> This text needs clarification as RFC8300 says nothing about IOAM
> specifically and dropping of OAM packets is discussed in that RFC here
> ->
> https://www/.
> rfc-%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C070486ccce54
> 4e2611bd08db4cdca1a1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6381
> 88282752096221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3jfHoWAJCVZT
> LlQfBcQlRAfnSnKezk5qOjuGMAtfz%2FQ%3D&reserved=0
> editor.org/rfc/rfc8300#:~:text=O%20bit%3A%20%20Setting,disabled%20by
> %20default.
> The authors should clarify exactly what they mean by the above text
> and clarify what specifically in RFC8300 would cause packets to be
> dropped if a node does not support IOAM.

...FB: This sentence has been updated to refer to section 3 of the document as well as RFC 8300, section 2.2:

The operator MUST ensure that SFC-aware
   nodes along the Service Function Path support IOAM, otherwise packets
   might be dropped (see Section 3 further below, as well as [RFC8300]
   Section 2.2).

>
> - IANA Considerations:
> The text says "IANA is requested to allocate protocol numbers for the
> following "NSH Next Protocol" related to IOAM" but there is no
> reference to the correct registry. NSH Next Protocol allocations can
> be found here:
> https://www/.
> iana.org%2Fassignments%2Fnsh%2Fnsh.xhtml%23next-protocol&data=05%7C01%
> 7Cjames.n.guichard%40futurewei.com%7C070486ccce544e2611bd08db4cdca1a1%
> 7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638188282752096221%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Sm0bq30jtb9%2FrIrYUZ%2BG0e5f5P4ZOBGT8FvhLi7Tej0%3D&reserved=0 and they are part of the Network Service Header (NSH) Parameters registry. Please provide an accurate reference to the Network Service Header (NSH) Parameters registry for IANA.

...FB: Thanks! The IANA request now reads:

   IANA is requested to allocate a code point for IOAM in the "NSH Next
   Protocol" registry (https://www.iana.org/assignments/nsh/
   nsh.xhtml#next-protocol):

>
> - Section 5: Another incorrect reference needs to be corrected. "For
> additional IOAM related security considerations, see Section 10 in
> [RFC9197].". It is actually section 9 of that RFC so please correct
> the reference.

...FB: Corrected in version 12.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> General comment. There are several typos or grammatical errors in the
> document.
> Suggest running an error checker against the document.
>
> Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to
> be expanded as the authors already did so in the abstract.

...FB: Fixed.

>
> Section 1: "Service Function Chaining (SFC) [RFC7665]" should read
> "Service Function Chaining (SFC) Architecture [RFC7665]".

...FB: Fixed.

>
> Section 3: 6th sentence use of "service path" should probably be
> changed to the correct terminology used by the SFC architecture which
> is Service Function Path (SFP). Further, the next sentence should be
> folded into the 6th sentence as a single sentence to make it more
> readable.

...FB: Fixed.

>
> Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of
> deployment related aspects of IOAM-Data-fields.". This reference
> should be changed to [RFC9378].
>
> Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be
> changed to [RFC9322].
>
> Several outdated references need to be updated:
>
>   == Outdated reference: A later version (-03) exists of
>      draft-ietf-sfc-oam-packet-01
>
>   == Outdated reference: draft-ietf-ippm-ioam-deployment has been
> published
>      as RFC 9378
>
>   == Outdated reference: draft-ietf-ippm-ioam-direct-export has been
>      published as RFC 9326
>
>   == Outdated reference: draft-ietf-ippm-ioam-flags has been published
> as RFC
>      9322
>
>

...FB: All the references were updated.

Thanks again for the review.

Cheers, Frank