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

Dear Carlos,
thank you for your questions and comments. I apologize for the belated
response but that has been a pretty dense week (in a good way). I'll
respond to your questions early next week. I hope that is acceptable to you.

Regards,
Greg

On Wed, May 27, 2020 at 8:15 AM Carlos Pignataro (cpignata) <
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/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.
> 2. Existing protocols can already provide solutions without the need of
> inventing a new protocol on paper. See #1 above.
> 3. There are already documented SFC traceroute implementations but this
> document has no implementation experience. See #2 above.
>
> 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?
>
> 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?
>
> Thanks!
>
> Carlos.
>
>
>
> 2020/05/20 午後10:51、Greg Mirsky <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>
> 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>, Cui(Linda) Wang <
> lindawangjoy@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Wei Meng <
> 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
> 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
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
>
>