Active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC)
draft-ietf-sfc-multi-layer-oam-28

NIT:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Source ID  |   Reserved1   |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Port Number          |           Reserved2           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         IP Address                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The last box for IP Address should use ~ instead of | as it can be either 4 octets of 16 octets.

Thank you to Russ Mundy for the SECDIR review.

Thanks to the authors for the work and for the prompt reaction and discussions to my previous DISCUSS ballot at:
https://mailarchive.ietf.org/arch/msg/sfc/av2LpDU2jw3o9ErIeM5c20K11ts/

I sincerely think that -27 is an improved version of -26.

Regards

-éric

Thanks to Olivier for the TSVART review.

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