Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear Authors and All,
I've read the current version of the draft and have some comments I'd like
to share with you. I much appreciate your thoughts on where this work
should go considering developments in other IETF WGs. Please find my notes
and questions below:

   - It is stated in the Abstract that:

   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in the packet while the packet
   traverses a path between two points in the network.

But that is the case only for the pre-allocated and incremental trace
option types. The Direct Export option
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/> does
not write telemetry data into the data packet itself but export telemetry
information in a specially constructed packet.
And as we are talking about different IOAM trace options, the question of
the scope of this document seems appropriate. There is a WGLC on two IOAM
documents
<https://mailarchive.ietf.org/arch/msg/ippm/A0OcGQ5LlNjnjfRVp_iUTMYMrcs/>
active through September 15th at the IPPM WG. I believe that it would be
beneficial if we had a single document that describes the applicability of
IOAM in all its functionality defined by documents in IPPM WG. Of course,
that cannot be a moving target as that would not be helpful. But since the
IPPM WG discusses the progress of two IOAM documents, it could be a great
time to address the applicability of the Direct Export trace type
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/> and
Loopback and Active flags defined in draft-ietf-ippm-ioam-flags
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/>. It would be
concerning to have more than one SFC document describing the applicability
of the generic IOAM mechanisms.

   - The location of the IOAM header in the SFC NSH-encapsulated packet is
   defined in Section 3:

   IOAM-Data-Fields are carried in NSH
   using a next protocol header which follows the NSH MD context
   headers.

I've checked RFC 8300 but couldn't find it defines the Next Protocol
header. Also, it appears that NSH Context headers are optional. Hence my
question. Is the presence of an NSH Context header required when using
IOAM? Could you clarify which mechanism is used to identify the payload of
an SFC NSH-encapsulated packet as IOAM?

   - If I understand the format of the IOAM header defined in Section 3
   correctly, the header's length is limited by 1020 octets, while the
   effective length containing IOAM options and data - 1016 octets. Is that
   correct? What is the recommended technique of collecting IOAM data that
   exceeds that limit?
   - In Section 4.1, I've found the text reflecting the history of the
   discussion about how to carry the IOAM header using NSH encapsulation. As
   the text has no normative value, I suggest moving it into an Appendix.
   - I find the rules of handling the O-bit in NSH listed in Section 4.2
   inconsistent and confusing. The IOAM header is not part of NSH
   encapsulation but is a part of the payload. But in one case, when user data
   follows it, the O-bit must not be set as. If there's no user data after the
   IOAM header, then the O-bit must be set. But from the perspective of NSH
   encapsulation, it includes specially constructed data added for the sole
   purpose of collecting OAM/telemetry information. Then, why, in one case,
   the O-bit is cleared and in the other set if, in both cases, the
   NSH-encapsulated packet is used to perform the OAM function?

I much appreciate your consideration of my comments and questions and
looking forward to your feedback.

Regards,
Greg

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <
james.n.guichard@futurewei.com> wrote:

> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-sfc-ioam-nsh [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SFC WG list no later than September 1st 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributor please response to indicate
> whether you know of any undisclosed IPR related to this document.
>
>
>
> Thanks!
>
>
>
> Jim & Joel
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>