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

[Robert Wilton via Datatracker <[e-mail]>]

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"?

(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:"

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

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

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

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

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

Regards,
Rob