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

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Rob,

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: Robert Wilton via Datatracker <[e-mail]>
> Sent: Tuesday, 2 May 2023 14:53
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Robert Wilton's Discuss on draft-ietf-sfc-ioam-nsh-11: (with
> DISCUSS and COMMENT)
> 
> Robert Wilton 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/about/groups/iesg/statements/handling-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-ioam-nsh/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> Thanks for this document.
> 
> A couple of discuss points that I raised only because I find the spec to be
> unclear which should be be easy to clarify:
> 
> (1) p 2, sec 3.  IOAM encapsulation with NSH
> 
>                                                        The operator MUST
>    ensure that all nodes along the service path support IOAM.
> 
> Is it actually 'all nodes along the service path' or "SFC aware nodes along
> the
> service path" that MUST support IOAM?

...FB: Thanks. The sentence has been updated to read:

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).

> 
> (2) p 3, sec 3.  IOAM encapsulation with NSH
> 
>       IOAM HDR Len:  8 bit Length field contains the length of the IOAM
>          header in 4-octet units.
> 
> Does this mean quantized to 4 byte units, or that the actual length in bytes
> is
> 4 * "Hdr Len" field?

...FB: John had a related comment on the length field. The updated version now reads:

      IOAM HDR Len:  8-bit field that contains the length of the IOAM
         header in multiples of 4-octets, including the "IOAM-Type" and
         "IOAM HDR Len" fields.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (3) p 2, sec 3.  IOAM encapsulation with NSH
> 
>      Otherwise
>    packets with IOAM are likely to be dropped per [RFC8300].  There can
>    be multiple IOAM headers added by encapsulating nodes as configured.
> 
> Possibly "MAY" may be better than "can", since RFC 2119 language is being
> used
> elsewhere in this paragraph.

...FB: Changed to MAY in version -12.

Thanks again for the review.

Cheers, Frank

> 
> Also thanks to Susan Hares for the OPSDIR review.
> 
> Regards,
> Rob
> 
>