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

[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]> 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.
>
>
> ~~~
> 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?

>
> Comments inline.
>
> 2020/06/02 午後7:28、Greg Mirsky <[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]> 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.
>
>
> 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:
>    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. 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.

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

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

>
> The point here is implementation experience — could you answer the still
> unanswered question #1 here?
> https://mailarchive.ietf.org/arch/msg/sfc/NdxlfxBuvaFp3eU8yFuLqKvNteQ/
>
GIM2>> I will look into it and respond in a separate mail.

>
>
>
>> 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]>のメール:
>>
>> 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]>
>> 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]>, Cui(Linda) Wang <
>> [e-mail]>, Greg Mirsky <[e-mail]>, Wei Meng <
>> [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
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>
>