[sfc] Éric Vyncke's Discuss on draft-ietf-sfc-multi-layer-oam-26: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-sfc-multi-layer-oam-26: 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-multi-layer-oam/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-sfc-multi-layer-oam-26

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (very easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education).

Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-sfc-multi-layer-oam-26-intdir-telechat-bernardos-2023-06-28/
(and I have read Greg's reply, still waiting for a revised I-D though)

Special thanks to Don Eastlake for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status and the author
counts.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Section 6

As there two V header fields defined (one for Echo message and one for all OAM
messages), it is unclear whether the Echo V-field is set back to 0 when SFC OAM
header Version is incremented? Or in other words, should Echo with V=0 but with
OAM V != 0 be interpreted as specified in this document ?

Are the TLV type depending on the Version being 0 ?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# COMMENTS

## Multi-layer ?

I wonder what is "multi-layer" (per the I-D title) aspect in the specification.
Suggest to either explain the "multi-layer" aspect or drop it from the draft
title.

## Section 3

Suggest to write that SFFI stands for SFF Instance in Figure 1.

Isn't `FM SFC OAM` a pleonasm ? I.e., either "FM" or "OAM" are redundant.

`(e.g., NSH)` why `e.g.` when section 1 states the focus of this I-D to NSH ?

About REQ#1, should this be a "MUST" rather than a "SHOULD" ?

In REQ#8, `the initiator of such a request` should probably be more specific.

## Section 4

Isn't RFC 8300 a better reference for the O bit rather than an IETF draft ?

## Section 5

Please add a justification / actual data about `But extra IP/UDP headers,
especially in an IPv6 network, add noticeable overhead.`

I am really concerned by having only 2 bits to indicate the version while there
are 8 bits reserved on the side. This does not look too good for revisions.

When can an implementation deviate from the SHOULD in Sender's Handle: `The
sender of the Echo Request SHOULD use a pseudo-random number generator ` ?
While I understand that this is an opaque value, and using a random number
prevents fingerprinting, I would assume that some implementations would like to
add some private semantics to this number.

## Section 6

Suggest adding some text about the absence of TLVs based on the length of the
SFC OAM header.

## Section 6.1

To avoid confusion s/TTL Exceeded/NSH TTL Exceeded/ (even if explained later in
the text).

In `The receiver of said Echo Request can set it to one of the values` should
the "can" be replaced by a "MUST" ?

## Section 6.3

`If the NSH is used,` but section 1 specifies that this I-D is only about NSH.

`Reply via an IPv4/IPv6 UDP Packet` is unclear when reading it. Please add a
forward reference to section 6.3.1 (I would also prefer to have 6.3.1 earlier
in the flow

## Section 6.5.2

How `If the NSH of the received SFC Echo Request includes the MAC Context
Header, the packet's authentication MUST be verified before using any data. `is
different to the text of section 6.4 about the MAC ?

`Sequence Number in the Echo Request sent matches to the Sequence Number in the
Echo Reply received` should it rather be a window of sequence number ? I.e.,
pipelined requests could be sent.

## Section 6.6

`Consistency Verification Request` this message is not defined before this
section and not in RFC 8300. If specified in this section, may I suggest to
rename the section to be about CVReq ?

## Section 7

`if the underlay is an IPv6 network` what about IPv4 ? I would assume that
IPv[46] underlays can support AH/ESP.

Should this be a SHOULD in `an implementation MAY check that the source of the
Echo Request is indeed part of the SFP`?