Re: [sfc] Robert Wilton's No Objection on draft-ietf-sfc-multi-layer-oam-27: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Robert,
thank you for the review and your detailed comments. Please find my notes
below tagged by GIM>>. Attached, is the diff that highlights updates to
address your comments.

Regards,
Greg

On Wed, Jul 5, 2023 at 11:54 PM Robert Wilton via Datatracker <
[e-mail]> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-sfc-multi-layer-oam-27: No Objection
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi,
>
> Thanks for this document.  I found various points in the document to be
> unclear.  Please consider whether addressing these comments would improve
> the
> clarity of the document.
>
> (1) p 5, sec 3.  Requirements for Active OAM in SFC
>
>    Once the SFF1 detects the defect, the objective of the SFC OAM
>    changes from the detection of a defect to defect characterization and
>    localization.
>
> It wasn't clear to me why it is SFF1 that detects the defect, rather than
> say,
> "Once an SFF detects the defect"?
>
GIM>> Thank you for the suggestion. I agree, generalization is more
suitable here.

>
> (2) p 6, sec 3.  Requirements for Active OAM in SFC
>
>    *  REQ#8: Can be addressed by an extension of the SFC Echo Request/
>       Reply described in this document adding proxy capability.
>
> Does this mean that requirement 8 isn't actually addressed by this
> specification?  If so, this seems to conflict with the sentence above: "The
> above listed requirements are satisfied in this specification as follows:"
>
GIM>> Thank you for pointing this out. Would the following editorial update
make it clear:
OLD TEXT:
   The above listed requirements are satisfied in this specification as
   follows:
NEW TEXT:
   The conformance of the SFC Echo Request/Reply mechanism to these
   requirements reflected below:

>
> (3) p 7, sec 6.  Echo Request/Echo Reply for SFC
>
>    Echo Request/Reply is a well-known active OAM mechanism extensively
>    used to verify a path's continuity, detect inconsistencies between a
>    state in control and the data planes, and localize defects in the
>    data plane.  ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6
>    networks) and [RFC8029] are examples of broadly used active OAM
>    protocols based on the Echo Request/Reply principle.  The SFC Echo
>    Request/Reply control message format is presented in Figure 3.
>
> I didn't entirely follow how these headers fit together.  Is the "SFC Echo
> Request/Reply Format" an instance of an "SFC Active OAM Control Packet"
> that is
> used in the "SFC Active OAM Header" above?  If so, then it would probably
> be
> helpful for this to be explicitly stated.
>
GIM>> You are right, SFC Echo Request/Reply is an instance of the SFC
Active OAM Control Packet field that is part of the SFC Active OAM Header.
Another editorial update:
OLD TEXT:
   The SFC Echo
   Request/Reply control message format is presented in Figure 3.
NEW TEXT:
   The SFC Echo
   Request/Reply control message (format is presented in Figure 3) is an
   instance of the SFC Active OAM Control Packet that is a part of the
   SFC Active OAM Header (Figure 2).
I hope that the updated text is clearer.

>
> (4) p 10, sec 6.1.  Return Codes
>
>                        Table 1: SFC Echo Return Codes
>
> It is unclear to me whether the SFC Echo Return Codes are those defined in
> this
> table, or the ones specified in section 10.3.4.  Perhaps it would be
> better for
> this section to just reference 10.3.4 rather than having duplicate
> normative
> content?
>
GIM>> A very good point, thank you. I updated the draft accordingly. Please
let me know if the update satisfactorily addresses your question.

>
> (5) p 13, sec 6.4.  Processing Received SFC Echo Request
>
>       1.1 Suppose the authentication validation has failed and the
>       Source TLV is considered properly formatted.  In that case, the
>       SFF MUST send to the system identified in the Source TLV (see
>       Section 6.5), according to a rate-limit control mechanism, an SFC
>       Echo Reply with the Return Code set to "Authentication failed" and
>       the Subcode set to zero.
>
> Does this effectively mean that even if authentication fails, some level
> of SFC
> Echo Request/Reply is supported (e.g., at least to the first SFF)?  I was
> wondering whether in this case, it wouldn't be safer to treat this like
> step
> 2.1.  I.e., an error is logged but no response is sent back?
>
GIM>> Yes, logging, also with rate-limiting control, is a valid option. If
I remember correctly (although I couldn't locate the discussion thread in
the mail archive), both options were discussed and the conclusion reflected
in the document.

>
> (6) p 14, sec 6.4.  Processing Received SFC Echo Request
>
>       8.  In all other cases, SFF MUST set the Return Code value to 0
>       ("No Error, End of Path Reached") and the Subcode set to zero.
>
> Some of these steps are very explicit in that they send a responce back,
> but
> others, like 6, 7, and 8 do not explicitly indicate that they send a reply.
>
> (7) p 14, sec 6.4.  Processing Received SFC Echo Request
>
>       8.  In all other cases, SFF MUST set the Return Code value to 0
>       ("No Error, End of Path Reached") and the Subcode set to zero.
>
> I didn't understand the distinction between "End of the SFP" and "No
> Error, End
> of Path Reached".  Is the difference that in one case reaching the end is
> expected, and the other is that it is not?  Perhaps worth clarifying.
>
GIM>> Our intention to define these two values for Return Code is to
differentiate between Echo Replies transmitted by a transit SFF and the SFF
that terminates that SFP. Perhaps if we change from "No Error, End of Path
Reached" to"No Error", that will remove the ambiguity. WDYT?

>
> Nit level comments:
>
> (8) p 12, sec 6.3.1.  Source TLV
>
>       Source ID - the value MUST be 1 Section 10.4.
>
> Perhaps "MUST be 1, as per Section 10.4."
>
GIM>> Would s/MUST be 1 Section 10.4/MUST be set to 1 (Section 10.4)/ be
acceptable?

>
> Regards,
> Rob
>
>
>
>