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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Greg,

Please find some follow-ups inline.

Dear Chairs,

Three quick points:

  1.  Some of the questions that are still not answered are lingering and being dodged since before the WG Adoption call of this document. Would un-adopting this document until those are answered be an appropriate counsel? What do you propose?
  2.  For the record, I cannot see the WG inventing a full solution in this document without implementation and without reference to existing protocols that can solve the problem or the WG framework.
  3.  Based on the statement below "The goal of writing, developing standards is to ensure interoperability among implementations.”, can we have clarity on implementations?

On May 18, 2019, at 4:01 PM, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:

Hi Carlos,
please find responses to your questions in-line and tagged GIM>>.

Regards,
Greg

On Fri, May 10, 2019 at 7:53 PM Carlos Pignataro (cpignata) <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Greg, SFC,

In order to understand the positioning of draft-ietf-sfc-multi-layer-oam, please find 3 high-level yet very important questions and associated comments for consideration.

To avoid potential misinterpretation and to be explicit on this note's intention: this email does not imply interest in this draft, does not mean support, I have not read the document fully.

But a quick note for completeness:

1. “Implementation Status” Section.

The authors seem to selectively respond to comments.

I asked for an “Implementation Status” Section [RFC7942] at least two or three times:
* March 29, 2018, on draft-wang-sfc-multi-layer-oam https://mailarchive.ietf.org/arch/msg/nvo3/eNRV-7GLWO_lLeeXwI97HhTrtBo
* October 27, 2018, on adoption https://mailarchive.ietf.org/arch/msg/sfc/wuK4MiyeOMNbXrRIYjiW7zCtZ70

Instead, this drafts seems to be inventing a full blown protocol without implementation practice.

SFC Chairs, could we please follow-up on repeated comments made on the list and track a disposition? These are over a year old, and part of an adoption call.

Request: Can we please add an “Implementation Status” section?
GIM>> As usual, the implementation status will be reflected in the Shepherd write-up.

I do not understand the “As usual” portion of your response.

Please see below.



2. New protocol invention outside of / rogue to an SFC OAM Framework.

draft-ietf-sfc-multi-layer-oam does not reference any other SFC I-Ds. It does not build upon existing work in progress, and instead invents a new protocol with RFC8300 as the only Normative reference from SFC.
GIM>> Isn't it a contradiction between your statements "draft-ietf-sfc-multi-layer-oam does not reference any other SFC I-Ds" and "RFC8300 as the only Normative reference from SFC"?
On the state of the SFC OAM Framework document. I don't recall a discussion of the draft at any recent SFC WG meeting. Indeed, there were many updates, plenty of information added that should be reviewed by the WG. At the same time, contributions to draft-ietf-sfc-multi-layer-oam are always welcome. Will be glad to discuss them.

Greg, I am not sure what you are answering, but this is a non-sequitur to my comment. The response about SFC OAM Framework is also a red-herring

No contradiction. My point is that this shows as a solution in isolation to the WG’s work.

Chairs, Diverting answers about another document (SFC OAM Framework) is not a response to questions and fundamental concerns  on this document (Active OAM for SFC).


The draft-ietf-sfc-oam-framework at https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06 takes a holistic approach of including an analysis (selecting only some section titles):
4.  SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . .   8
5.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  11
5.1.  Existing OAM Functions  . . . . . . . . . . . . . . . . .  11
5.2.  Missing OAM Functions . . . . . . . . . . . . . . . . . .  12
6.4.  OAM Toolset applicability . . . . . . . . . . . . . . . .  13
       6.4.1.  ICMP Applicability  . . . . . . . . . . . . . . . . .  13

This analysis ought to guide protocol definition.
GIM>> draft-ietf-sfc-oam-framework has not been discussed by the SFC WG since even though much of material has been added to it.

Comments on draft-ietf-sfc-oam-framework asymptoted due to its maturity. But more importantly, see the next response.


Question: Can this draft consider existing protocols and gap performed before re-inventing? Specifically Normatively cite the SFC OAM Framework and see where reuse is best?
GIM>> SFC OAM Framework has Informational document track and I don't see a good reason of making it Normative reference for draft-ietf-sfc-multi-layer-oam.

Greg, just to be explicit: are you stating that draft-ietf-sfc-multi-layer-oam is simply not even considering the content and existence of draft-ietf-sfc-oam-framework? Even though that document’s Abstract states:
   This document provides a reference framework for Operations,
   Administration and Maintenance (OAM) for Service Function Chaining
   (SFC).




3. Existing implementation of OAM functions.

Hows does this draft work with existing OAM functions with existing implementation, such as https://tools.ietf.org/html/draft-penno-sfc-trace-03 ? The fact that the draft is expired does not mean the implementation is uncoded.
GIM>> How it can interwork with something that is not fully documented, which state is unknown, uncertain? The goal of writing, developing standards is to ensure interoperability among implementations.

Greg, following your statement about, can you please explain which implementations of draft-ietf-sfc-multi-layer-oam are you ensuring interoperability among?

Otherwise, following your statement, would you say that this document should not be developed without implementations to ensure interop among?

If someone is not committed to the development of their solution for the interoperable multi-vendor environment, then what we can do in such case?

Greg, is this a hypothetical statement, or are you stating this about someone specific, and quantifying that person’s commitment to standards development? Please clarify.

You are the co-author of the draft and I encourage you to re-start the work, bring to WG for the discussion.

Thanks, will consider. That work already interops in the wire.

Best,

Carlos.



Many thanks,

— Carlos Pignataro

On May 9, 2019, at 1:31 AM, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:

Dear All,
the update to the draft addresses the comment received from Joel at the meeting in Prague:
- Joel: if we get an echo request we can't parse, how do we know that it is an echo request, and do we have the information to return it to the correct source?
- Greg: we will clarify this in the draft. It has to practical so the sender can understand the situation.. We introduced two classes of TLVs: mandatory and optional. Will add clearer text.

A new TLV, Errored TLVs, introduced to be optionally used to pass in an echo reply mandatory TLVs that were not understood because either the implementation on the receiver does not support them or couldn't parse them correctly.

Also, please review the update to the interpretation of O-bit and the value of the Next Protocol field to address Adrian's comments at the meeting in Bangkok:
The rules of
   interpreting the values of O bit and the Next Protocol field are as
   follows:

   o  O bit set, and the Next Protocol value is not one of identifying
      active or hybrid OAM protocol (per [RFC7799] definitions), e.g.,
      defined in this specification Active SFC OAM - a Fixed-Length
      Context Header or Variable-Length Context Header(s) contain OAM
      command or data.  and the type of payload determined by the Next
      Protocol field;

   o  O bit set, and the Next Protocol value is one of identifying
      active or hybrid OAM protocol - the payload that immediately
      follows SFC NSH contains OAM command or data;

   o  O bit is clear - no OAM in a Fixed-Length Context Header or
      Variable-Length Context Header(s) and the payload determined by
      the value of the Next Protocol field;

   o  O bit is clear and the Next Protocol value is one of identifying
      active or hybrid OAM protocol MUST be identified and reported as
      the erroneous combination.  An implementation MAY have control to
      enable processing of the OAM payload.

   From the above-listed rules follows the recommendation to avoid
   combination of OAM in a Fixed-Length Context Header or Variable-
   Length Context Header(s) and in the payload immediately following the
   SFC NSH because there is no unambiguous way to identify such
   combination using the O bit and the Next Protocol field.

Regards,
Greg

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Wed, May 8, 2019 at 10:21 PM
Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
To: <[e-mail]<mailto:[e-mail]>>, Gregory Mirsky <[e-mail]<mailto:[e-mail]>>, Bhumip Khasnabish <[e-mail]<mailto:[e-mail]>>, Wei Meng <[e-mail]<mailto:meng.wei2@zte..com.cn>>, Cui(Linda) Wang <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-ietf-sfc-multi-layer-oam-03.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-ietf-sfc-multi-layer-oam
Revision:       03
Title:          Active OAM for Service Function Chains in Networks
Document date:  2019-05-08
Group:          sfc
Pages:          18
URL:            https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-03.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-03
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-03

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc