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

From: Greg Mirsky <[email-masked]>
Date: Wed, 20 May 2020 19:51:17 -0700

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 May 2020 15:15:11 +0000

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.
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 <[email-masked]>のメール:
> 
> Dear All,
> 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:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 May 2020 09:13:41 -0700

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) <
[email-masked]> wrote:

> 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:
> 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.
>
> Consider ICMP. When encapsulated in NSH, it supports the ping function
> but, per our analysis, cannot be used as an SFP tracing tool.
>
>