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

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

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?

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

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

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