Subject: Re: [Last-Call] [sfc] Last Call: <draft-ietf-sfc-oam-framework-11.txt> ICMP in SFC OAM (Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework) to Informational RFC

From: Greg Mirsky <[email-masked]>
Date: Sun, 12 Apr 2020 19:40:56 -0700

Dear Carlos,
here's another thread to continue the discussion of the applicability of
ICMP in SFC OAM.
The draft suggests that by managing TTL in NSH one can trace SFFs of the
given SPI. My first concern with the proposed method of using ICMP in SFC
is that RFC 8300 requires SFF to decrement TTL before doing NSH lookup. And
then it clarifies:
   NSH packets, as described above, are discarded when an SFF decrements
the TTL to 0.
True, there's no normative language but the interpretation might be
ambiguous and some implementations might not allow controlling the case of
TTL=0.
Furthermore, if we assume that NSH packet TTL=0 is punted to the control
plane, wouldn't it be forwarded over IP, as the destination IP address is
of the last SFF?
Perhaps I've missed something in the draft. I appreciate it if you can
clarify the mechanism that allows the use of ICMP in SFC as tracing the OAM
tool.

Regards,
Greg

On Fri, Apr 10, 2020 at 10:31 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> Let me first share a top-post comment, followed by inlined responses.
>
> Scanning through your extensive set of review comments below, it seems to
> me that several of these are issues that you brought up in the past already
> at SFC, including during WGLC, and the SFC chairs declared consensus on
> their disposition. Many of the comments below are repetition to the
> previous extensive reviews you shared, and not additional or incremental
> comments. Repeating them again will not change the responses.
>
> In this context, please see:
> https://mailarchive.ietf.org/arch/msg/sfc/mDkO4jSkyxJ6ofup-YbBpIF5BEs/
> Which was not responded to by you.
>
> Please see inline with:
> *CMP: bold hopeful underlined green*.
>
>
> 2020/04/09 午後6:04、Greg Mirsky <[email-masked]>のメール:
>
> Dear All,
> I have reviewed the draft and wanted to share my comments on the
> draft-ietf-sfc-oam-framework. Please find them organized into two sections
> - general and according to the text of the draft.
> General:
>
>    - SFC OAM Architecture
>
> *CMP: No. This document does not use the phrase "SFC OAM **Architecture”,
> nor it defines it.*
>
> The document includes three components in the SFC OAM architecture:
>
>
> *CMP: No. The document explains**:*
>
>    For the purpose of defining
>    the OAM framework, the service layer is broken up into three distinct
>    components:
>
>
> Service Function (SF), Service Function Chain (SFC), which is equivalent
> to the collection of all SFPs, and Classifier. Firstly, making SFC OAM a
> component of SFC OAM appears as an unfortunate selection of terminology
> that might be a source of confusion and misinterpretation (how one
> identifies the context of using "SFC OAM"?).
>
>
> *CMP: First, frankly I am unclear of what exactly you mean. It seems to me
> you are creating the confusion. "SFC OAM" is not a component. SFC is the
> component (S3.1) containing OAM Functions.*
>
> *CMP: Second, Greg, you say "**might be a source of confusion and
> misinterpretation**”. However, to our knowledge, there has not been any
> confusion or misinterpretation.*
>
> *CMP: Third, Please see*
> https://mailarchive.ietf.org/arch/msg/sfc/fTsNNMAoHe6D6Vnrox6oQJJ5JO8/
>
> The inclusion of an SF in the SFC OAM reference model is to provide the
> ability to verify "whether the SF is providing its intended service". Such
> a goal appears as a layer violation, in part of OAM, since the verification
> of the correctness of a service provided by the SFC is in the scope of
> Service OAM to which SFC OAM plays the role of transport OAM.
>
>
> *CMP: Apologies, I read this a few times and I am not sure what is meant.
> If you mean "why does the WG document include SF?", then this was discussed
> in your previous review.*
>
> In addition, the document notes that the fact of existing and deployed SFs
> is likely to leave SF OAM being implementation-specific. Combining these
> two aspects, the inclusion of the SF OAM component in the SFC OAM reference
> model is questionable as it doesn't seem to provide a good opportunity for
> the standardization given, on one hand, the lack drafts and, on the other
> hand, the growing number of deployed implementations. Figure 2 that
> illustrates SFC OAM components does not provide clarity to the
> relationships between SFC OAM and SF OAM components of the reference model
> as SF OAM is depicted both as the separate entity as well as part of SFC
> OAM component.
>
>
>
>    - The interpretation of 'availability' in SFC OAM
>
> The document extensively discusses an SFC OAM characteristic, availability
> sections on SF and SFC availability, as well as references to the
> particular OAM tool as being capable to check the availability).
> Availability is well-defined for some technologies, e.g. constant bit-rate
> paths, while not being used at all in many other networking technologies,
> e.g., packet switching networks. The definition of the availability for the
> constant bit-rate paths can be found in G.826. The specification firstly
> defines the opposite, the state of unavailability. Also, note that both
> states of unavailability and availability are defined as being continuous
> in time, at least 10 seconds interval long. I couldn't find any definition
> of the availability in IETF documents I'm familiar with. The most
> comprehensive IETF document on OAM, RFC 7276, doesn't use the availability
> as one of the OAM states or performance metrics detected or measured by OAM
> methods analyzed in it. The draft-ietf-sfc-oam-framework uses the term
> 'availability' in many places referring to the availability of SFC elements
> like SFF and SF without providing the definition. As a result, it is not
> clear what the availability of SFC OAM is and how it can be detected or
> measured. It appears that the term in this document is being used
> colloquially rather than as the technical terminology. Such a manner of
> using terminology does affect the technical accuracy of the document and
> very likely leave a reader familiar with the existing definitions of the
> term in a state of confusion.
>
>
> *CMP: Greg, please see: *
> https://mailarchive.ietf.org/arch/msg/sfc/1r8s3iB139-ETZtGskpocWxC3Ao/*.
> That email **from the chairs** went unanswered.*
>
>
> Going through the text:
>
>    - section 3.1.1 in the last paragraph states:
>
>    This framework document provides a RECOMMENDED framework where a
>    generalized approach is taken to verify that a SF is sufficiently
>    available (i.e., an adequate granularity to provide a basic SF
>    service).
>
> That "RECOMMENDED framework" seems like a deviation from the scope of the
> document defined in the Abstract and Document Scope:
>    The focus of this document is to provide an architectural framework
>    for SFC OAM, particularly focused on the aspect of the Operations
>    component within OAM.
>
>
>
> *CMP: Good point, Martin noted the same issue and it is addressed in a
> forthcoming revision.*
>
>
>    - the definition of connectivity in Section 4.1 appears as using
>    circular logic by defining itself through connectivity verification whereas
>    it is a composition of verifying that packets that belong to the monitored
>    flow are reaching the egress node and only packets that belong to that flow
>    are received by the egress (the case when a packet that belongs to a
>    different flow is detected constitutes miscommunication defect and may lead
>    to miscommunication state).
>
>
> *CMP: Apologies it is hard for me to follow. However, combining *
> https://mailarchive.ietf.org/arch/msg/sfc/mDkO4jSkyxJ6ofup-YbBpIF5BEs/
> * with *
> https://mailarchive.ietf.org/arch/msg/sfc/fTsNNMAoHe6D6Vnrox6oQJJ5JO8/*,
> please provide suggested text for an improved definition.*
>
>
>    - also in Section 4.1, the path MTU discovery and monitoring, packet
>    re-ordering and/or corruption, arbitrary path monitoring are misattributed
>    to connectivity verification function
>
> *CMP: Same as above.*
>
>
>    - notification to other application (Section 4.2) is not part of OAM
>    and is implementation-specific
>
> *CMP: I assume this refers to:*
>
>    o  Notifying the detected failures to other OAM functions or
>       applications to take appropriate action.
>
>
>
> *CMP: If so, do you suggest that OAM detects failures but notifies noone?*
>
>
>    - 'PM' in PM OAM is usually expanded as 'Performance Monitoring',
>    sometimes 'Performance Measurement". Used in the document "Performance
>    Management" is extremely unusual, if not misleading.
>
>
> *CMP: We can change "Performance Management" to "Performance Measurement".*
>
>
>    - In Section 4.4 delay variance (variation)/jitter is listed as a
>    measurable performance metric even though it can be only calculated using a
>    set of delay measurements. On the other hand, most performance monitoring
>    active OAM protocols are well-equipped to detect packet re-ordering,
>    unwarranted packet duplication.
>
> *CMP: I am sorry I do not follow what you are asking here. What would you
> like to see?*
>
>
>    - Further in Section 4, jitter, i.e. delay variation is being
>    mentioned as a measurable performance metric. That is not the case.
>    Latency, i.e. delay, is a measurable metric but jitter (delay variation)
>    can only be calculated.
>
> *CMP: The text says "**could also be calculated**"*
>
>
>    - Table 3 in Section 5.1 raises several questions:
>       - Is listing E-OAM is to suggest that an overlay network supporting
>       SFC NSH can be instantiated directly over the Ethernet network? Can you
>       illustrate that with an example?
>
> *CMP: See...* https://tools.ietf.org/html/rfc8300#section-10.1
>
>
>    - It appears that some of the information presented in Table 3
>       contradicts other material in the draft, for example, Section 6.4.1. The
>       section indicates that ICMP may be used as a connectivity verification tool
>       for both SF and SFC OAM.
>
> *CMP: I do not see a contradiction. Do you have specifics?*
>
>
>    - In Section 6.4.1 ICMP is positioned as a suitable mechanism to "test
>    the network reachability" (that seems like a new OAM function being
>    introduced in the section). Because SFC can be realized over a number of
>    combinations of underlay and overlay technologies, I believe, an example
>    (or a couple of examples would be much better) demonstrating the
>    encapsulation of an ICMP message and, particularly, triggering ICMP Echo
>    Reply on the proper element of the SFP. I have to admit, I couldn't imagine
>    the encapsulation that would make ICMP-over-SFC work as IP Ping/traceroute.
>
> *CMP: What exactly are you requesting or is the concern? The section
> describes already what you ask.*
>
>
>    - Section 6.4.2 makes the positioning statement for BFD and S-BFD as
>    follows:
>
> BFD or S-BFD could be leveraged to perform continuity function for SF or
> SFC.
> The statement, in regard to BFD, contradicts with RFC 5880 which explains
> the goal of BFD as follows:
>    ... a protocol intended to detect faults in the
>    bidirectional path between two forwarding engines, including
>    interfaces, data link(s), and to the extent possible the forwarding
>    engines themselves ...
> And the text in the second paragraph on Section 6.4.2 appears to describe
> a way of using S-BFD, not of BFD.
>
>
>
> *CMP: It describes BFD, which can be used to verify continuity in
> connectivity.*
>
>
>    - Section 6.4.3 suggests that iOAM could be used "perform SF
>    availability and SFC availability or performance measurement". I agree with
>    that statement in part of performance measurement but the references to the
>    "SF availability and SFC availability", without the definition of
>    availability in the context of SFC OAM, appear as not sufficiently
>    justified.
>
> *CMP: Greg, please see: *
> https://mailarchive.ietf.org/arch/msg/sfc/1r8s3iB139-ETZtGskpocWxC3Ao/*.
> That email **from the chairs** went unanswered.*
>
>
>    - Section 6.4.4 makes a reference to an individual draft that was last
>    updated some four and a half years ago. It appears that such a long time is
>    an indication of a lack of interest to work on the proposed solution by
>    the authors or anyone else..
>
> *CMP: Greg... this was also covered multiple times already, and
> re-re-repeating will not change the response.*
>
> *CMP: First, Internet-Drafts are "work in progress.**”*
>
> *CMP: Second, please see *
> https://tools.ietf.org/html/draft-penno-sfc-trace-03#section-6
> *CMP: Running code seems more relevant than a non-implemented
> refreshed-but-not-updated I-D...*
>
>
>    - Section 7 and, in particular, Table 4 seems as not closely relevant
>    to the subject or OAM. Especially since the title of Table 4 is not
>    reflecting the content of the table itself. RFC 6291 recommends using Mgmt
>    acronym for Management and O&M - for OAM and Management. Acronym OAM is
>    recommended to be expanded and used in the IETF document solely for
>    Operations, Administration, and Maintenance.
>
>
>
> *CMP: This was again already covered, and in fact updated and moved based
> on your previous comments.*
>
> Summarizing my comments, I find so many problematic parts in the text that
> I've to question the usefulness of the requirement in the Introduction
>    SFC OAM solution documents should refer to this document to indicate
>    the SFC OAM component and the functionality they target.
> and the value of publishing this document in its current form.
>
>
> *CMP: Greg, you wrote the same thing on WG Last-call, and the chairs
> responded to that perspective.*
>
> *CMP: It was a bit hard for me to parse some of you comments. As it was
> requested before by the SFC chairs, if you have comments accompany them by
> textual suggestions.*
>
> *CMP: **Best,*
>
> *CMP: **Carlos.*
>
> Regards,
> Greg
>
>
> ---------- Forwarded message ---------
> From: The IESG <[email-masked]>
> Date: Thu, Mar 26, 2020 at 8:47 AM
> Subject: [sfc] Last Call: <draft-ietf-sfc-oam-framework-11.txt> (Service
> Function Chaining (SFC) Operations, Administration and Maintenance (OAM)
> Framework) to Informational RFC
> To: IETF-Announce <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, <[email-masked]>
>
>
>
> The IESG has received a request from the Service Function Chaining WG (sfc)
> to consider the following document: - 'Service Function Chaining (SFC)
> Operations, Administration and
>    Maintenance (OAM) Framework'
>   <draft-ietf-sfc-oam-framework-11.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-04-09. Exceptionally, comments
> may
> be sent to [email-masked] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document provides a reference framework for Operations,
>    Administration and Maintenance (OAM) for Service Function Chaining
>    (SFC).
>
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ballot/
>
> The following IPR Declarations may be related to this I-D:
>
>    https://datatracker.ietf.org/ipr/3440/
>    https://datatracker.ietf.org/ipr/3121/
>
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 13 Apr 2020 03:15:38 +0000

[Dear Tal, a note for you at the end of this response]

Dear Greg,

This was already discussed in the ~ 2.5 months of WGLC, and changes were made from rev -06 to rev -10, including to the ICMP paragraph and moving the ICMPv4 and ICMPv6 references to Informative.

Let me remind you that this document does not include solutions, and instead it says:

  Actual solutions and mechanisms are outside
   the scope of this document.

...

  The details are
   expected to be covered in the solution documents.

So consequently, you questions on how details are specified for some specific case are also out of scope.

Now, again addressing your concern, you say:

True, there's no normative language but the interpretation might be ambiguous and some implementations might not allow controlling the case of TTL=0.

Here’s my response:

  *   That is a lot of “mights” and things that might or could happen on potential implementations that might or not exist and might or not allow specific potential things.
  *   You are right, there’s no normative language. Your comment could have ended there, instead of concocting second-order hypotheticals that have no basis anyway since there’s no solution specification.

So when you say:
Perhaps I've missed something in the draft. I appreciate it if you can clarify the mechanism that allows the use of ICMP in SFC as tracing the OAM tool.

Yes, I think you missed the fact that this does not specify solutions.

When someone writes the specific mechanism, it could clarify your hypotheticals. For now, this document says:

   It could be observed that ICMP at its current stage may not be able
   to perform all required SFC OAM functions, but as explained above, it
   can be used for some of the connectivity functions.

As agreed during WGLC.

Dear Tal,

I believe there’s no basis for these questions given what was concluded in WGLC, and instead potentially these threads artificially delay the document.

From my perspective this item is also closed (was already), unless or until you as shepherd tell us otherwise.

THanks!

Carlos.

2020/04/12 午後10:40、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos,
here's another thread to continue the discussion of the applicability of ICMP in SFC OAM.
The draft suggests that by managing TTL in NSH one can trace SFFs of the given SPI. My first concern with the proposed method of using ICMP in SFC is that RFC 8300 requires SFF to decrement TTL before doing NSH lookup. And then it clarifies:
   NSH packets, as described above, are discarded when an SFF decrements the TTL to 0.
True, there's no normative language but the interpretation might be ambiguous and some implementations might not allow controlling the case of TTL=0.
Furthermore, if we assume that NSH packet TTL=0 is punted to the control plane, wouldn't it be forwarded over IP, as the destination IP address is of the last SFF?
Perhaps I've missed something in the draft. I appreciate it if you can clarify the mechanism that allows the use of ICMP in SFC as tracing the OAM tool.

Regards,
Greg

On Fri, Apr 10, 2020 at 10:31 AM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

Scanning through your extensive set of review comments below, it seems to me that several of these are issues that you brought up in the past already at SFC, including during WGLC, and the SFC chairs declared consensus on their disposition. Many of the comments below are repetition to the previous extensive reviews you shared, and not additional or incremental comments. Repeating them again will not change the responses.

Please see inline with:
CMP: bold hopeful underlined green.

2020/04/09 午後6:04、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear All,
I have reviewed the draft and wanted to share my comments on the draft-ietf-sfc-oam-framework. Please find them organized into two sections - general and according to the text of the draft.
General:

  *   SFC OAM Architecture

CMP: No. This document does not use the phrase "SFC OAM Architecture”, nor it defines it.

CMP: No. The document explains:

Service Function (SF), Service Function Chain (SFC), which is equivalent to the collection of all SFPs, and Classifier. Firstly, making SFC OAM a component of SFC OAM appears as an unfortunate selection of terminology that might be a source of confusion and misinterpretation (how one identifies the context of using "SFC OAM"?).

CMP: First, frankly I am unclear of what exactly you mean. It seems to me you are creating the confusion. "SFC OAM" is not a component. SFC is the component (S3.1) containing OAM Functions.

CMP: Second, Greg, you say "might be a source of confusion and misinterpretation”. However, to our knowledge, there has not been any confusion or misinterpretation.

CMP: Third, Please see https://mailarchive.ietf.org/arch/msg/sfc/fTsNNMAoHe6D6Vnrox6oQJJ5JO8/

The inclusion of an SF in the SFC OAM reference model is to provide the ability to verify "whether the SF is providing its intended service". Such a goal appears as a layer violation, in part of OAM, since the verification of the correctness of a service provided by the SFC is in the scope of Service OAM to which SFC OAM plays the role of transport OAM.

CMP: Apologies, I read this a few times and I am not sure what is meant. If you mean "why does the WG document include SF?", then this was discussed in your previous review.

In addition, the document notes that the fact of existing and deployed SFs is likely to leave SF OAM being implementation-specific. Combining these two aspects, the inclusion of the SF OAM component in the SFC OAM reference model is questionable as it doesn't seem to provide a good opportunity for the standardization given, on one hand, the lack drafts and, on the other hand, the growing number of deployed implementations. Figure 2 that illustrates SFC OAM components does not provide clarity to the relationships between SFC OAM and SF OAM components of the reference model as SF OAM is depicted both as the separate entity as well as part of SFC OAM component.

  *   The interpretation of 'availability' in SFC OAM

The document extensively discusses an SFC OAM characteristic, availability sections on SF and SFC availability, as well as references to the particular OAM tool as being capable to check the availability). Availability is well-defined for some technologies, e.g. constant bit-rate paths, while not being used at all in many other networking technologies, e.g., packet switching networks. The definition of the availability for the constant bit-rate paths can be found in G.826. The specification firstly defines the opposite, the state of unavailability. Also, note that both states of unavailability and availability are defined as being continuous in time, at least 10 seconds interval long. I couldn't find any definition of the availability in IETF documents I'm familiar with. The most comprehensive IETF document on OAM, RFC 7276, doesn't use the availability as one of the OAM states or performance metrics detected or measured by OAM methods analyzed in it. The draft-ietf-sfc-oam-framework uses the term 'availability' in many places referring to the availability of SFC elements like SFF and SF without providing the definition. As a result, it is not clear what the availability of SFC OAM is and how it can be detected or measured. It appears that the term in this document is being used colloquially rather than as the technical terminology. Such a manner of using terminology does affect the technical accuracy of the document and very likely leave a reader familiar with the existing definitions of the term in a state of confusion.

CMP: Greg, please see: https://mailarchive.ietf.org/arch/msg/sfc/1r8s3iB139-ETZtGskpocWxC3Ao/. That email from the chairs went unanswered.

Going through the text:

  *   section 3.1.1 in the last paragraph states:

That "RECOMMENDED framework" seems like a deviation from the scope of the document defined in the Abstract and Document Scope:

CMP: Good point, Martin noted the same issue and it is addressed in a forthcoming revision.

  *   the definition of connectivity in Section 4.1 appears as using circular logic by defining itself through connectivity verification whereas it is a composition of verifying that packets that belong to the monitored flow are reaching the egress node and only packets that belong to that flow are received by the egress (the case when a packet that belongs to a different flow is detected constitutes miscommunication defect and may lead to miscommunication state).

CMP: Apologies it is hard for me to follow. However, combining https://mailarchive.ietf.org/arch/msg/sfc/mDkO4jSkyxJ6ofup-YbBpIF5BEs/ with https://mailarchive.ietf.org/arch/msg/sfc/fTsNNMAoHe6D6Vnrox6oQJJ5JO8/, please provide suggested text for an improved definition.

  *   also in Section 4.1, the path MTU discovery and monitoring, packet re-ordering and/or corruption, arbitrary path monitoring are misattributed to connectivity verification function

CMP: Same as above.

  *   notification to other application (Section 4.2) is not part of OAM and is implementation-specific

CMP: I assume this refers to:

CMP: If so, do you suggest that OAM detects failures but notifies noone?

  *   'PM' in PM OAM is usually expanded as 'Performance Monitoring', sometimes 'Performance Measurement". Used in the document "Performance Management" is extremely unusual, if not misleading.

CMP: We can change "Performance Management" to "Performance Measurement".

  *   In Section 4.4 delay variance (variation)/jitter is listed as a measurable performance metric even though it can be only calculated using a set of delay measurements. On the other hand, most performance monitoring active OAM protocols are well-equipped to detect packet re-ordering, unwarranted packet duplication.

CMP: I am sorry I do not follow what you are asking here. What would you like to see?

  *   Further in Section 4, jitter, i.e. delay variation is being mentioned as a measurable performance metric. That is not the case. Latency, i.e. delay, is a measurable metric but jitter (delay variation) can only be calculated.

CMP: The text says "could also be calculated"

  *   Table 3 in Section 5.1 raises several questions:
     *   Is listing E-OAM is to suggest that an overlay network supporting SFC NSH can be instantiated directly over the Ethernet network? Can you illustrate that with an example?

CMP: See... https://tools.ietf.org/html/rfc8300#section-10.1

     *   It appears that some of the information presented in Table 3 contradicts other material in the draft, for example, Section 6.4.1. The section indicates that ICMP may be used as a connectivity verification tool for both SF and SFC OAM.

CMP: I do not see a contradiction. Do you have specifics?

  *   In Section 6.4.1 ICMP is positioned as a suitable mechanism to "test the network reachability" (that seems like a new OAM function being introduced in the section). Because SFC can be realized over a number of combinations of underlay and overlay technologies, I believe, an example (or a couple of examples would be much better) demonstrating the encapsulation of an ICMP message and, particularly, triggering ICMP Echo Reply on the proper element of the SFP. I have to admit, I couldn't imagine the encapsulation that would make ICMP-over-SFC work as IP Ping/traceroute.

CMP: What exactly are you requesting or is the concern? The section describes already what you ask.

  *   Section 6.4.2 makes the positioning statement for BFD and S-BFD as follows:

BFD or S-BFD could be leveraged to perform continuity function for SF or SFC.
The statement, in regard to BFD, contradicts with RFC 5880 which explains the goal of BFD as follows:
   ... a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves ...
And the text in the second paragraph on Section 6.4.2 appears to describe a way of using S-BFD, not of BFD.

CMP: It describes BFD, which can be used to verify continuity in connectivity.

  *   Section 6.4.3 suggests that iOAM could be used "perform SF availability and SFC availability or performance measurement". I agree with that statement in part of performance measurement but the references to the "SF availability and SFC availability", without the definition of availability in the context of SFC OAM, appear as not sufficiently justified.

CMP: Greg, please see: https://mailarchive.ietf.org/arch/msg/sfc/1r8s3iB139-ETZtGskpocWxC3Ao/. That email from the chairs went unanswered.

  *   Section 6.4.4 makes a reference to an individual draft that was last updated some four and a half years ago. It appears that such a long time is an indication of a lack of interest to work on the proposed solution by the authors or anyone else..

CMP: Greg... this was also covered multiple times already, and re-re-repeating will not change the response.

CMP: First, Internet-Drafts are "work in progress.”

CMP: Second, please see https://tools.ietf.org/html/draft-penno-sfc-trace-03#section-6
CMP: Running code seems more relevant than a non-implemented refreshed-but-not-updated I-D...

  *   Section 7 and, in particular, Table 4 seems as not closely relevant to the subject or OAM. Especially since the title of Table 4 is not reflecting the content of the table itself. RFC 6291 recommends using Mgmt acronym for Management and O&M - for OAM and Management. Acronym OAM is recommended to be expanded and used in the IETF document solely for Operations, Administration, and Maintenance.

CMP: This was again already covered, and in fact updated and moved based on your previous comments.

Summarizing my comments, I find so many problematic parts in the text that I've to question the usefulness of the requirement in the Introduction
   SFC OAM solution documents should refer to this document to indicate
   the SFC OAM component and the functionality they target.
and the value of publishing this document in its current form.

CMP: Greg, you wrote the same thing on WG Last-call, and the chairs responded to that perspective.

CMP: It was a bit hard for me to parse some of you comments. As it was requested before by the SFC chairs, if you have comments accompany them by textual suggestions.

CMP: Best,

CMP: Carlos.

Regards,
Greg

---------- Forwarded message ---------
From: The IESG <[email-masked]<mailto:[email-masked]>>
Date: Thu, Mar 26, 2020 at 8:47 AM
Subject: [sfc] Last Call: <draft-ietf-sfc-oam-framework-11.txt> (Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework) to Informational RFC
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2020-04-09. Exceptionally, comments may
be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc
--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 13 Apr 2020 08:54:59 -0700

Dear Carlos, et al.,
I should have been more assertive in the analysis of the applicability of
ICMP to SFC OAM.

   - the statement "a classifier initiating OAM can generate ICMP echo
   request message, can set the TTL field in NSH header to 255 to get the
   response from last SFF and thereby test the SFC availability" is
   technically wrong because it is programmatically impossible to set NSH TTL
   value to 255. The length of the NSH TTL field is only six bits and thus the
   largest value is 63. Secondly, ping does not test the availability of
   a path but its continuity (or connectivity between the sender and
   receiver if terms "continuity" and "connectivity" being used
   interchangeably).
   - the statement "the initiator could send OAM packets with sequentially
   incrementing the TTL in the NSH to trace the SFP" is technically incomplete
   as I've pointed in the earlier note. Decapsulated "normal" ICMP Echo
   request will not be processed by the SFF where NSF TTL expired but will be
   forward to the destination address listed in the IP header of the ICMP
   message.
   - because of these problems with section 6.4.1, I suggest removing it
   altogether from the document.

Regards,
Greg

On Sun, Apr 12, 2020 at 8:15 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> This was already discussed in the ~ 2.5 months of WGLC, and changes were
> made from rev -06 to rev -10, including to the ICMP paragraph and moving
> the ICMPv4 and ICMPv6 references to Informative.
>
>    - That is a lot of “mights” and things that might or could happen on
>    potential implementations that might or not exist and might or not allow
>    specific potential things.
>    - You are right, there’s no normative language. Your comment could
>    have ended there, instead of concocting second-order hypotheticals that
>    have no basis anyway since there’s no solution specification.
>
>
> So when you say:
>
> When someone writes the specific mechanism, it could clarify your
> hypotheticals. For now, this document says:
>
> I believe there’s no basis for these questions given what was concluded in
> WGLC, and instead potentially these threads artificially delay the
> document.
>
> 2020/04/12 午後10:40、Greg Mirsky <[email-masked]>のメール:
>
> Dear Carlos,
>> *CMP: First, frankly I am unclear of what exactly you mean. It seems to
>> me you are creating the confusion. "SFC OAM" is not a component. SFC is the
>> In addition, the document notes that the fact of existing and deployed
>> SFs is likely to leave SF OAM being implementation-specific. Combining
>> these two aspects, the inclusion of the SF OAM component in the SFC OAM
>> reference model is questionable as it doesn't seem to provide a good
>> opportunity for the standardization given, on one hand, the lack drafts
>> and, on the other hand, the growing number of deployed implementations.
>> Figure 2 that illustrates SFC OAM components does not provide clarity to
>> the relationships between SFC OAM and SF OAM components of the reference
>> model as SF OAM is depicted both as the separate entity as well as part of
>> SFC OAM component.
>>
>>
>>
>> The document extensively discusses an SFC OAM characteristic,
>> availability sections on SF and SFC availability, as well as references to
>> the particular OAM tool as being capable to check the availability).
>>       - Is listing E-OAM is to suggest that an overlay network
>>       supporting SFC NSH can be instantiated directly over the Ethernet network?
>>       Can you illustrate that with an example?
>>
>>    - In Section 6.4.1 ICMP is positioned as a suitable mechanism to
>>    "test the network reachability" (that seems like a new OAM function being
>>    - Section 6.4.4 makes a reference to an individual draft that was
>>    last updated some four and a half years ago. It appears that such a
>>    long time is an indication of a lack of interest to work on the proposed
>>    solution by the authors or anyone else..
>>
>> Summarizing my comments, I find so many problematic parts in the text
>> that I've to question the usefulness of the requirement in the Introduction

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 13 Apr 2020 20:32:18 +0000

Dear Greg,

Good editorial catch! We will fix the 255 with 63.

Thank you!
(You understood that by “255” what was meant was “max possible value of the TTL field, all ones in the field”)

The rest of the comments fall in the existing category of ’this draft does not intend to provide a complete protocol solution” as pointed out before. Clearly, a solution document using ICMP ought to concern itself with producing a complete detailed specification including encapsulation, interception, processing, and protocol field specification and interaction. All these considerations area already solved for other protocols such as using VCCV, and similar and equivalent solutions apply here, just not in this document.

Best,

Carlos.

2020/04/13 午前11:54、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos, et al.,
I should have been more assertive in the analysis of the applicability of ICMP to SFC OAM.

  *   the statement "a classifier initiating OAM can generate ICMP echo request message, can set the TTL field in NSH header to 255 to get the response from last SFF and thereby test the SFC availability" is technically wrong because it is programmatically impossible to set NSH TTL value to 255. The length of the NSH TTL field is only six bits and thus the largest value is 63. Secondly, ping does not test the availability of a path but its continuity (or connectivity between the sender and receiver if terms "continuity" and "connectivity" being used interchangeably).
  *   the statement "the initiator could send OAM packets with sequentially incrementing the TTL in the NSH to trace the SFP" is technically incomplete as I've pointed in the earlier note. Decapsulated "normal" ICMP Echo request will not be processed by the SFF where NSF TTL expired but will be forward to the destination address listed in the IP header of the ICMP message.
  *   because of these problems with section 6.4.1, I suggest removing it altogether from the document.

Regards,
Greg

On Sun, Apr 12, 2020 at 8:15 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
[Dear Tal, a note for you at the end of this response]

Dear Greg,

...

  The details are

Here’s my response:

So when you say:

As agreed during WGLC.

Dear Tal,

THanks!

Carlos.

Dear Carlos,

Regards,
Greg

Please see inline with:

Dear All,

  *   SFC OAM Architecture

Going through the text:

CMP: Same as above.

CMP: Best,

CMP: Carlos.

Regards,
Greg

---------- Forwarded message ---------
From: The IESG <[email-masked]<mailto:[email-masked]>>
Date: Thu, Mar 26, 2020 at 8:47 AM
Subject: [sfc] Last Call: <draft-ietf-sfc-oam-framework-11.txt> (Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework) to Informational RFC
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

Abstract