Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-multi-layer-oam-05.txt

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Jun 2020 16:28:21 -0700

Dear Carlos,
please find my answers and notes in-line under the GIM>> tag.
Please let me know if you have any further questions.

Regards,
Greg

On Wed, May 27, 2020 at 8:15 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> We much appreciate your comments and questions.
>
>
> Thank you for asking and inviting commentary. Here’s some thoughts:
>
> Hello, WG, Chairs,
>
> I believe fundamental concerns with this work remain unanswered — examples:
> https://mailarchive.ietf.org/arch/msg/sfc/NdxlfxBuvaFp3eU8yFuLqKvNteQ/
> https://mailarchive.ietf.org/arch/msg/sfc/TT3L-R05fbIGkfjr-x_oifBrhsc/
> https://mailarchive.ietf.org/arch/msg/sfc/sSO2BcgXereje4PxnGY9Wv_pDOs/
> And since some of those questions were asked during adoption, I’d
> recommend at least un-adopting this document.
>
> Email threading in one-year-old and two-year-old emails is super hard to
> parse and follow, so some key concerns are:
> 1. This document describes an OAM solution, but ignores the WG’s SFC OAM
> framework which sits with the IESG.
>
GIM>> Will add the SFC OAM framework document as Informational Reference
and clarify which functionality the proposed mechanism addresses.

2. Existing protocols can already provide solutions without the need of
> inventing a new protocol on paper. See #1 above.
>
GIM>> Could you kindly reference a document that describes how existing
protocols can be used to troubleshoot SFC NSH? If I look at the SFC OAM
framework draft I can only find the sub-section about the potential use of
ICMP that closes with the following:
   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.
If ICMP cannot be used, then what other, unnamed in the SFC OAM Framework
document, existing protocol can be used as SFC NSH Echo Request/Reply
mechanism?

> 3. There are already documented SFC traceroute implementations but this
> document has no implementation experience. See #2 above.
>
GIM>> As mentioned in the SFC OAM Framework draft, ICMP may not fully
address all the needs of tracing SFP. Is there any other document mentioned
in the framework that can?

>
> Dear Greg,
>
> Could you please start responding to previous questions? Apologies in
> advance if I missed any of your responses.
>
> Per our analysis, existing OAM mechanisms cannot support both SFP ping and
> SFP traceroute.
>
>
> Which analysis? Perhaps you could share that analysis?
>
GIM>> Gladly. I was referring to ICMP over SFC NSH. As noted in the
framework draft, ICMP can be used to ping an SFC entity along the SFP if
the sender knows the IP address of that entity and the number of IP hops to
that distance (rather impractical but theoretically achievable). But can
ICMP be used to trace the given SFP without the upfront knowledge of IP
addresses of SFC entities along the SFP? Based on our analysis, not. Assume
that the destination IP address is set to the IP address of the last SFF
(similar to how ICMP traceroute works in IP network) and TTL in NSH is set
to 1. The first downstream from the sender SFF will remove the NSH and
forward the ICMP packet to its destination over the IP network. Similarly,
when NSH' TTL incremented, the second SFF will remove NSH and forward ICMP
packet to its destination, i.e. the last SFF. As a result, all ICMP echo
replies the sender will receive will be from the same SFF, from the last
SFF in the given SFP. Clearly, that is not what a traceroute tool should
produce.

>
> Consider ICMP. When encapsulated in NSH, it supports the ping function
> but, per our analysis, cannot be used as an SFP tracing tool.
>
>
> What exactly did you need to add to have that functionality as opposed to
> your consideration of ICMP?
>
GIM>> A dedicated to SFC NSH OAM protocol type.

>
> Thanks!
>
> Carlos.
>
>
>
> 2020/05/20 午後10:51、Greg Mirsky <[email-masked]>のメール:
>
> Dear All,
> this version includes a minor update to the Security Considerations
> section.
> We, the authors, believe that the draft is ready for the WG LC. It defines
> an essential function of SFC OAM - SFP Echo request/reply. Per our
> analysis, existing OAM mechanisms cannot support both SFP ping and SFP
> traceroute. Consider ICMP. When encapsulated in NSH, it supports the ping
> function but, per our analysis, cannot be used as an SFP tracing tool.
> We much appreciate your comments and questions.
>
> Dear Jim and Joel,
> please kindly consider the WG LC for this draft.
>
> Regards,
> Greg
>
> ---------- Forwarded message ---------
> From: <[email-masked]>
> Date: Wed, May 20, 2020 at 6:32 PM
> Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-05.txt
> To: Bhumip Khasnabish <[email-masked]>, Cui(Linda) Wang <
> [email-masked]>, Greg Mirsky <[email-masked]>, Wei Meng <
> [email-masked]>
>
>
>
> A new version of I-D, draft-ietf-sfc-multi-layer-oam-05.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:           draft-ietf-sfc-multi-layer-oam
> Revision:       05
> Title:          Active OAM for Service Function Chains in Networks
> Document date:  2020-05-20
> Group:          sfc
> Pages:          18
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-05
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-05
>
> Abstract:
>    A set of requirements for active Operation, Administration and
>    Maintenance (OAM) of Service Function Chains (SFCs) in networks is
>    presented.  Based on these requirements an encapsulation of active
>    OAM message in SFC and a mechanism to detect and localize defects
>    described.  Also, this document updates RFC 8300 in the definition of
>    O (OAM) bit in the Network Service Header (NSH) and defines how the
>    active OAM message identified in SFC NSH.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 3 Jun 2020 01:58:12 +0000

Dear Greg,

A top-level response first:

> GIM>> Will add the SFC OAM framework document as Informational Reference and clarify which functionality the proposed mechanism addresses.

This superficial patch does not address my deep and foundational concern, expressed initially 2 years ago before draft-ietf-sfc-multi-layer-oam adoption.

The idea is to start from the framework’s evaluation to understand what is needed based on that gap study, and produce a solutions that build on existent — not work in a vacuum, and then add an Informational Reference orthogonally.

~~~
As a complete aside, I got curious about the filename of this I-D, which has nothing to do with the content.

This document went from:
            Multi-Layering OAM for Service function Chaining
Abstract
   This document tries to discuss some problems in SFC OAM framework
   document and proposes the SFC OAM multi-layering requirements in SFC
   domain to improve the troubleshooting efficiency.

To something completely different.

It is as if the filename was reused to write 2 or 3 different drafts. Looking at diffs, there is not a single sentence that remained from earlier versions.
~~~

Comments inline.

> 2020/06/02 午後7:28、Greg Mirsky <[email-masked]>のメール:
> 
> Dear Carlos,
> On Wed, May 27, 2020 at 8:15 AM Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
> Dear Greg,
> 
> https://mailarchive.ietf.org/arch/msg/sfc/NdxlfxBuvaFp3eU8yFuLqKvNteQ/ <https://mailarchive.ietf.org/arch/msg/sfc/NdxlfxBuvaFp3eU8yFuLqKvNteQ/>
> https://mailarchive.ietf.org/arch/msg/sfc/TT3L-R05fbIGkfjr-x_oifBrhsc/ <https://mailarchive.ietf.org/arch/msg/sfc/TT3L-R05fbIGkfjr-x_oifBrhsc/>
> https://mailarchive.ietf.org/arch/msg/sfc/sSO2BcgXereje4PxnGY9Wv_pDOs/ <https://mailarchive.ietf.org/arch/msg/sfc/sSO2BcgXereje4PxnGY9Wv_pDOs/>
> And since some of those questions were asked during adoption, I’d recommend at least un-adopting this document.
> 
> Email threading in one-year-old and two-year-old emails is super hard to parse and follow, so some key concerns are:
> 1. This document describes an OAM solution, but ignores the WG’s SFC OAM framework which sits with the IESG.
> GIM>> Will add the SFC OAM framework document as Informational Reference and clarify which functionality the proposed mechanism addresses.

See above.

> 
> 2. Existing protocols can already provide solutions without the need of inventing a new protocol on paper. See #1 above.
> GIM>> Could you kindly reference a document that describes how existing protocols can be used to troubleshoot SFC NSH? If I look at the SFC OAM framework draft I can only find the sub-section about the potential use of ICMP that closes with the following:
> If ICMP cannot be used, then what other, unnamed in the SFC OAM Framework document, existing protocol can be used as SFC NSH Echo Request/Reply mechanism?
> 

What I read in that paragraph is:
1. ICMP can as-is solve many (but not ALL) required OAM functions.
2. Adding to ICMP is the path of least resistance, it is largely there, but needs additions to support ALL OAM functions.

> 3. There are already documented SFC traceroute implementations but this document has no implementation experience. See #2 above.
> GIM>> As mentioned in the SFC OAM Framework draft, ICMP may not fully address all the needs of tracing SFP. Is there any other document mentioned in the framework that can?

Greg,
1. Yes, I-D.penno-sfc-trace has the indisputable running code proof.
2. Instead of copying MPLS LSP Ping into a brand new protocol, fill in the gaps based on existing modules.

The point here is implementation experience — could you answer the still unanswered question #1 here?
https://mailarchive.ietf.org/arch/msg/sfc/NdxlfxBuvaFp3eU8yFuLqKvNteQ/ <https://mailarchive.ietf.org/arch/msg/sfc/NdxlfxBuvaFp3eU8yFuLqKvNteQ/>

> 
> Dear Greg,
> 
> Could you please start responding to previous questions? Apologies in advance if I missed any of your responses.
> 
>> Per our analysis, existing OAM mechanisms cannot support both SFP ping and SFP traceroute.
> 
> GIM>> Gladly. I was referring to ICMP over SFC NSH. As noted in the framework draft, ICMP can be used to ping an SFC entity along the SFP if the sender knows the IP address of that entity and the number of IP hops to that distance (rather impractical but theoretically achievable). But can ICMP be used to trace the given SFP without the upfront knowledge of IP addresses of SFC entities along the SFP? Based on our analysis, not. Assume that the destination IP address is set to the IP address of the last SFF (similar to how ICMP traceroute works in IP network) and TTL in NSH is set to 1. The first downstream from the sender SFF will remove the NSH and forward the ICMP packet to its destination over the IP network.

NOT.

As I had pointed out earlier, there are MANY ways of intercepting a packet. Use an IP option or a flag in the NSH.

Problems with your logic:
1. When you say ICMP you are thinking unmodified ICMP Echo packet. Think outside that box.
2. Whatever you use you need to intercept.

> Similarly, when NSH' TTL incremented, the second SFF will remove NSH and forward ICMP packet to its destination, i.e. the last SFF. As a result, all ICMP echo replies the sender will receive will be from the same SFF, from the last SFF in the given SFP. Clearly, that is not what a traceroute tool should produce.
> 
>> Consider ICMP. When encapsulated in NSH, it supports the ping function but, per our analysis, cannot be used as an SFP tracing tool.
> 
> What exactly did you need to add to have that functionality as opposed to your consideration of ICMP?

Incorrect again. There is no technical need to add an SFC NSH OAM protocol type. There are many ways of marking a pak as OAM and demultiplexing the protocol.

I do understand you have a solution in mind.

Carlos.

> Thanks!
> 
> Carlos.
> 
> 
> 
>> 2020/05/20 午後10:51、Greg Mirsky <[email-masked] <mailto:[email-masked]>>のメール:
>> 
>> Dear All,
>> this version includes a minor update to the Security Considerations section.
>> We, the authors, believe that the draft is ready for the WG LC. It defines an essential function of SFC OAM - SFP Echo request/reply. Per our analysis, existing OAM mechanisms cannot support both SFP ping and SFP traceroute. Consider ICMP. When encapsulated in NSH, it supports the ping function but, per our analysis, cannot be used as an SFP tracing tool.
>> From: <[email-masked] <mailto:[email-masked]>>
>> To: Bhumip Khasnabish <[email-masked] <mailto:[email-masked]>>, Cui(Linda) Wang <[email-masked] <mailto:[email-masked]>>, Greg Mirsky <[email-masked] <mailto:[email-masked]>>, Wei Meng <[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-05.txt <https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-05.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/ <https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/>
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-05 <https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-05>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-05 <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-05>
>> 
>> Abstract:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 3 Jun 2020 15:33:53 -0700

Dear Carlos,
please find my answers and notes below in-line under GIM2>> tag.

Regards,
Greg

On Tue, Jun 2, 2020 at 6:58 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> This superficial patch does not address my deep and foundational concern,
> expressed initially 2 years ago before
> draft-ietf-sfc-multi-layer-oam adoption.
>
> The idea is to start from the framework’s evaluation to understand what is
> needed based on that gap study, and produce a solutions that build on
> existent — not work in a vacuum, and then add an Informational Reference
> orthogonally.
>
>
> ~~~
> It is as if the filename was reused to write 2 or 3 different drafts.
> Looking at diffs, there is not a single sentence that remained from earlier
> versions.
> ~~~
>
GIM2>> In the opinion of authors, that is the reflection of the evolution
of the document. do you see that to be a violation of any IETF process?

> 2. Adding to ICMP is the path of least resistance, it is largely there,
> but needs additions to support ALL OAM functions.
>
GIM2>> We appreciate you sharing your ideas but authors decided to develop
an alternative approach. Also, we note that as you've mentioned above, you
have made this suggestion two years ago. IETF, as we understand, is a
contribution-driven organization and the fact that in, at least, two years
no one, including you, produced a document, using the suggested by you
approach, probably can be interpreted as lack of interest to that idea.

> 1. Yes, I-D.penno-sfc-trace has the indisputable running code proof.
GIM2>> It is interesting that you present a draft that was abandoned by its
authors for more than five years as a possible foundation of a
specification to facilitate interoperable implementations. Personally, I am
not questioning that there are tools to address the problem that we are
addressing with the SFC NSH Echo Request/Reply proposal. But these are
proprietary tools and, at least so far, none of its authors stepped in with
a document sufficient to have interoperable implementations.

> gaps based on existing modules.
GIM2>> Again, thank you for sharing your suggestions. True, SFC NSH shares
ideas with the design proven by MPLS LSP. Our approach is no different from
the approach taken by authors, including you and me, of draft-ietf-bier-ping
<https://datatracker.ietf.org/doc/draft-ietf-bier-ping/>. As noted earlier,
the fact that there's no contribution that uses the path you've been
advocating for 2+ years may be interpreted as the indication that it is not
a practical direction.

> https://mailarchive.ietf.org/arch/msg/sfc/NdxlfxBuvaFp3eU8yFuLqKvNteQ/
GIM2>> I will look into it and respond in a separate mail.

> forward the ICMP packet to its destination over the IP network.
>
>
> NOT.
>
> As I had pointed out earlier, there are MANY ways of intercepting a
> packet. Use an IP option or a flag in the NSH.
>
GIM2>> I don't argue that the solution described in the draft is the only
possible. But can you point to a document that describes, sufficiently
accurately

> 1. When you say ICMP you are thinking unmodified ICMP Echo packet. Think
GIM2>> Again, thank you for sharing your ideas. Probably some of your
colleagues will get interested and develop a solution based on them.

> 2. Whatever you use you need to intercept.
GIM2>> Agree. I believe that the solution described in the draft addresses
that problem.

>
> Similarly, when NSH' TTL incremented, the second SFF will remove NSH and
> forward ICMP packet to its destination, i.e. the last SFF. As a result, all
> ICMP echo replies the sender will receive will be from the same SFF, from
> the last SFF in the given SFP. Clearly, that is not what a traceroute tool
> should produce.
>
>>
> Incorrect again. There is no technical need to add an SFC NSH OAM protocol
> type. There are many ways of marking a pak as OAM and demultiplexing the
> protocol.
>
GIM2>> We, the authors, are not claiming that the proposed solution is the
only one possible. We've analyzed options and decided to develop this
approach. Others can decide differently and present their work as a draft.

> I do understand you have a solution in mind.
GIM2>> Indeed, it is documented in the draft being discussed. Also, there
are several individual SFC OAM drafts that use SFC NSH Echo Request/Reply
mechanism.

>> We, the authors, believe that the draft is ready for the WG LC. It
>> defines an essential function of SFC OAM - SFP Echo request/reply. Per our

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 3 Jun 2020 23:30:37 +0000

Hi, Greg,

Thanks for the quick response.

I feel that your responses are diverging from addressing the issues I brought up.
I also want to ensure there is unpolluted space for others to share their thoughts. This draft has shown in the past that silence can be very loud, as the interest level seems challenged.

As such, this is my last email on this thread.

Please find some closing comments inline, prefaced with “CMP: "

> 2020/06/03 午後6:33、Greg Mirsky <[email-masked]>のメール:
> 
> Dear Carlos,
> On Tue, Jun 2, 2020 at 6:58 PM Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
> Dear Greg,
> 

CMP: Greg, you selectively skipped responding to this issue which is a critical one, in my humble opinion.

> GIM2>> In the opinion of authors, that is the reflection of the evolution of the document. do you see that to be a violation of any IETF process?

CMP: I made no inference or judgement — it was a factual comment.
CMP: That said, the “violation of any IETF process” response from you is a straw man argument.
CMP: Since you implicitly ask, seems like a Trojan horse disguising lack of value, rather than process violation.

> 
> Comments inline.
> 
>> 2020/06/02 午後7:28、Greg Mirsky <[email-masked] <mailto:[email-masked]>>のメール:
>> 
>> Dear Carlos,

CMP: You also did not respond to this. Another example of selectively not responding.

CMP: I was happy to engage into a technical and architectural discussion to improve the outcomes produced by a WG. That is not possible if you selectively skip comments.

> GIM2>> We appreciate you sharing your ideas but authors decided to develop an alternative approach.

CMP: Yes, I know that the authors of this document chose to develop a brand new protocol on paper. That is one of my concerns.

> Also, we note that as you've mentioned above, you have made this suggestion two years ago. IETF, as we understand, is a contribution-driven organization and the fact that in, at least, two years no one, including you, produced a document, using the suggested by you approach, probably can be interpreted as lack of interest to that idea.

CMP: I’m trying to decide which type of fallacy this argument falls under — I think more than one.

CMP: Unfortunately, this direction of discussion does not help advance or solve anything.

CMP: Since you attempt to turn this into my intentions, I chose to focus on the bigger picture (framework) first, and on the milestones agreed by the WG first.

CMP: Let me be clear: no other active OAM contributions do not imply this document is useful or sensible.

CMP: As I already mentioned, the framework document shows how ICMP is enough for most needs, it can be enhanced, it also shows other existing approaches.

> GIM2>> It is interesting that you present a draft that was abandoned by its authors for more than five years as a possible foundation of a specification to facilitate interoperable implementations.

CMP: Greg, I-D.penno-sfc-trace *has* interoperable implementations already.

CMP: Since you bring this up, can you please explain to the WG which implementations exist of draft-ietf-sfc-multi-layer-oam? Please :-)

> Personally, I am not questioning that there are tools to address the problem that we are addressing with the SFC NSH Echo Request/Reply proposal. But these are proprietary tools and, at least so far, none of its authors stepped in with a document sufficient to have interoperable implementations.

CMP: Do you realize that none of these are valid explanations of why it makes sense to start a brand new protocol from scratch without answering the comparative to existing?

> GIM2>> Again, thank you for sharing your suggestions. True, SFC NSH shares ideas with the design proven by MPLS LSP.

CMP: "Shares ideas" is an understatement, for the record.

> Our approach is no different from the approach taken by authors, including you and me, of draft-ietf-bier-ping <https://datatracker.ietf.org/doc/draft-ietf-bier-ping/>.

CMP: Another diversion. Let’s talk about your document in SFC :)
CMP: That said, the approach is hugely different, for multicast vs. unicast service path chaining. Is that an oversimplification fallacy?

> As noted earlier, the fact that there's no contribution that uses the path you've been advocating for 2+ years may be interpreted as the indication that it is not a practical direction.

CMP: Greg, another fallacy. There are many potential reasons.

CMP: If you ask me, frankly, I think the WG does not care enough about this topic to begin with — that is no reason to let any idea in paper go through.

> GIM2>> I will look into it and respond in a separate mail.

CMP: Thanks. That said, I’m signing off from this thread as the ROI of responding does not add up.

Best,

Carlos.

> GIM2>> I don't argue that the solution described in the draft is the only possible. But can you point to a document that describes, sufficiently accurately
> 
> GIM2>> Again, thank you for sharing your ideas. Probably some of your colleagues will get interested and develop a solution based on them.
> GIM2>> Agree. I believe that the solution described in the draft addresses that problem.
> 
> GIM2>> We, the authors, are not claiming that the proposed solution is the only one possible. We've analyzed options and decided to develop this approach. Others can decide differently and present their work as a draft.
> 
> GIM2>> Indeed, it is documented in the draft being discussed. Also, there are several individual SFC OAM drafts that use SFC NSH Echo Request/Reply mechanism.
> 
> Carlos.
> 
>> Thanks!
>> 
>> Carlos.
>> 
>> 
>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Jun 2020 17:34:43 -0700

Dear Carlos,
thank you for sharing your opinion. Please find my closing notes in-line
below now tagged GIM2>>.

Regards,
Greg

On Wed, Jun 3, 2020 at 4:30 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> I also want to ensure there is unpolluted space for others to share their
> thoughts. This draft has shown in the past that silence can be very loud,
> as the interest level seems challenged.
>
GIM2>> We have our opinions but that is up to WG  and WG Chairs to decide.

>> The idea is to start from the framework’s evaluation to understand what
>> is needed based on that gap study, and produce a solutions that build on
GIM2>> As I've demonstrated, and also acknowledged in the SEF OAM
framework, as-is ICMP cannot be used to trace SFP. The solution described
in the draft can be used as ping and tracing tool over an SFP. I'm always
open to discuss constructive technical arguments about the proposed
solution.

> CMP: I was happy to engage into a technical and architectural discussion
> to improve the outcomes produced by a WG. That is not possible if you
> selectively skip comments.
>
GIM2>> I always carefully consider and respond to constructive technical
arguments.

> an alternative approach.
> CMP: Yes, I know that the authors of this document chose to develop a
> brand new protocol on paper. That is one of my concerns.
>
> Also, we note that as you've mentioned above, you have made this
> suggestion two years ago. IETF, as we understand, is a contribution-driven
> organization and the fact that in, at least, two years no one, including
> you, produced a document, using the suggested by you approach, probably can
> be interpreted as lack of interest to that idea.
>
>
> CMP: Since you attempt to turn this into my intentions, I chose to focus
> on the bigger picture (framework) first, and on the milestones agreed by
> the WG first.
>
> CMP: As I already mentioned, the framework document shows how ICMP is
> enough for most needs, it can be enhanced, it also shows other existing
> approaches.
>
GIM2>> I've searched through the SFC OAM framework and couldn't find
another example of partially working for SFC on-demand path continuity
verification and tracing mechanism. Perhaps you mean that a tool that
checks SFC availability? But in the face of SFC availability being
undefined, it is hard to verify that some on-path mechanism in fact can be
used to on-demand verify SFP continuity and trace the SFP.

> GIM2>> It is interesting that you present a draft that was abandoned by
> its authors for more than five years as a possible foundation of a
> specification to facilitate interoperable implementations.
>
>
> CMP: Since you bring this up, can you please explain to the WG which
> implementations exist of draft-ietf-sfc-multi-layer-oam? Please :-)
>
> Personally, I am not questioning that there are tools to address the
> problem that we are addressing with the SFC NSH Echo Request/Reply
> proposal. But these are proprietary tools and, at least so far, none of its
> authors stepped in with a document sufficient to have interoperable
> implementations.
>
>
> CMP: Do you realize that none of these are valid explanations of why it
> makes sense to start a brand new protocol from scratch without answering
> the comparative to existing?
>
> ideas with the design proven by MPLS LSP.
>
>
> Our approach is no different from the approach taken by authors, including
> you and me, of draft-ietf-bier-ping
> <https://datatracker.ietf.org/doc/draft-ietf-bier-ping/>.
>
>
> CMP: That said, the approach is hugely different, for multicast vs.
> unicast service path chaining. Is that an oversimplification fallacy?
>
> As noted earlier, the fact that there's no contribution that uses the path
> you've been advocating for 2+ years may be interpreted as the indication
> that it is not a practical direction.
>
>
> CMP: If you ask me, frankly, I think the WG does not care enough about
> this topic to begin with — that is no reason to let any idea in paper
> go through.
>
GIM2>> Well, let the WG and WG Chairs to decide.

>> Incorrect again. There is no technical need to add an SFC NSH OAM
>> protocol type. There are many ways of marking a pak as OAM and
>> demultiplexing the protocol.
>>