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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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 <[e-mail]>のメール:
> 
> 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) <[e-mail] <mailto:[e-mail]>> wrote:
> 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.
> 

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

> 
> ~~~
> 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.
> ~~~
> 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 <[e-mail] <mailto:[e-mail]>>のメール:
>> 
>> 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) <[e-mail] <mailto:[e-mail]>> 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/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.


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.

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

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

> 2. Instead of copying MPLS LSP Ping into a brand new protocol, fill in the 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.

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.

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

> 
> 
>> 
>> 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.
> 
> 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
> 
> Problems with your logic:
> 1. When you say ICMP you are thinking unmodified ICMP Echo packet. Think outside that box.
> 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.
>> 
>>> 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.
>> 
> 
> 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.
> 
> Carlos.
> 
>> Thanks!
>> 
>> Carlos.
>> 
>> 
>> 
>>> 2020/05/20 午後10:51、Greg Mirsky <[e-mail] <mailto:[e-mail]>>のメール:
>>> 
>>> 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: <[e-mail] <mailto:[e-mail]>>
>>> 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 <[e-mail] <mailto:[e-mail]>>, Cui(Linda) Wang <[e-mail] <mailto:[e-mail]>>, Greg Mirsky <[e-mail] <mailto:[e-mail]>>, Wei Meng <[e-mail] <mailto:[e-mail]>>
>>> 
>>> 
>>> 
>>> 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 <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:
>>>    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 <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> _______________________________________________
>>> sfc mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>