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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Greg,

Please see inline …

From: iesg <[e-mail]> On Behalf Of Greg Mirsky
Sent: 07 July 2023 00:33
To: Rob Wilton (rwilton) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Robert Wilton's No Objection on draft-ietf-sfc-multi-layer-oam-27: (with COMMENT)

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]<mailto:[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.
[Rob Wilton (rwilton)]
Okay.

(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:
[Rob Wilton (rwilton)]
Yes, okay.


(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.
[Rob Wilton (rwilton)]
Yes, looks good, thanks.


(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.
[Rob Wilton (rwilton)]
Yes, it does.  Thank you.


(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.
[Rob Wilton (rwilton)]
Okay.


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

[Rob Wilton (rwilton)]
I just wanted to check that you had seen the above comment.  FWIW, I think that this is probably worth being explicit/consistent on.


(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?
[Rob Wilton (rwilton)]
I’ve fine with the distinction that you have, but probably having some text somewhere to explain the difference might be helpful (particularly, when someone queries in 5 years and you can’t remember why it was done the way it was ;-)


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?
[Rob Wilton (rwilton)]
Yes, looks good.

Regards,
Rob



Regards,
Rob