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

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 <gregimirsky@gmail.com>のメール:
> 
> 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) <cpignata@cisco.com <mailto:cpignata@cisco.com>> 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.

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

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

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

I do understand you have a solution in mind.

Carlos.

> Thanks!
> 
> Carlos.
> 
> 
> 
>> 2020/05/20 午後10:51、Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>のメール:
>> 
>> 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: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>> 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 <vumip1@gmail.com <mailto:vumip1@gmail.com>>, Cui(Linda) Wang <lindawangjoy@gmail.com <mailto:lindawangjoy@gmail.com>>, Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>, Wei Meng <meng.wei2@zte.com.cn <mailto:meng.wei2@zte.com.cn>>
>> 
>> 
>> 
>> 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
>> sfc@ietf.org <mailto:sfc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>

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

Attachment: signature.asc