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

[Greg Mirsky <[e-mail]>]

Hi Rob,
thank you for your prompt response and further clarifications. I've
updated Section 6.4 explicitly calling out transmission of the SFC Echo
Reply message and clarifying the interpretation of the "No Error" Return
Code:
   An SFF that received the SFC Echo Request MUST validate the packet as
   follows:

      1.  If the SFC Echo Request is integrity-protected, the receiving
      SFF first MUST verify the authentication.

      1.1 Suppose the authentication validation has failed and the
      Source ID TLV is considered properly formatted.  In that case, the
      SFF MUST send to the system identified in the Source ID 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.

      1.2 If the authentication is validated successfully, the SFF that
      has received an SFC Echo Request verifies the rest of the packet's
      general sanity.

      2.  Validate the Source ID TLV, as defined in Section 6.3.1.

      2.1 If the Source ID TLV is determined malformed, the received SFC
      Echo Request processing is stopped, the message is dropped, and
      the event SHOULD be logged, according to a rate-limiting control
      for logging.

      3.  Sender's Handle and Sequence Number fields are not examined
      but are copied in the SFC Echo Reply message.

      4.  If the packet is not well-formed, i.e., not formed according
      to this specification, the receiver SFF SHOULD send an SFC Echo
      Reply with the Return Code set to "Malformed Echo Request
      received" and the Subcode set to zero under the control of the
      rate-limiting mechanism to the system identified in the Source ID
      TLV (see Section 6.5).

      5.  If there are any TLVs that the SFF does not understand, the
      SFF MUST send an SFC Echo Reply with the Return Code set to 2
      ("One or more TLVs was not understood") and set the Subcode to
      zero.  Also, the SFF MAY include an Errored TLVs TLV
      (Section 6.4.1) that, as sub-TLVs, contains only the misunderstood
      TLVs.

      6.  If the sanity check of the received Echo Request succeeded,
      i.e., the Echo Request is deemed properly formed, then the SFF at
      the end of the SFP MUST send an SFC Echo Reply with the Return
      Code value to 5 ("End of the SFP") and the Subcode set to zero.

      7.  If the SFF is not at the end of the SFP and the NSH TTL value
      is 1, the SFF MUST send an SFC Echo Reply with the Return Code set
      to 4 ("SFC TTL Exceeded") and the Subcode set to zero.

      8.  In all other cases, for the validated Echo Request message, a
      transit, i.e., not at the end of the SFP, SFF MUST send an SFC
      Echo Reply with the Return Code value to 0 ("No Error") and the
      Subcode set to zero.

I hope you will find the updated text clearer. Thank you for your help in
improving the document. I will upload it before the deadline.

Regards,
Greg

On Fri, Jul 7, 2023 at 8:37 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> 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]> 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
>
>
>