Re: [sfc] New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Sat, 11 May 2019 03:34 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511BF12028A for <sfc@ietfa.amsl.com>; Fri, 10 May 2019 20:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB-SLKcRtzMv for <sfc@ietfa.amsl.com>; Fri, 10 May 2019 20:34:51 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2016B120273 for <sfc@ietf.org>; Fri, 10 May 2019 20:34:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42894; q=dns/txt; s=iport; t=1557545691; x=1558755291; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aNIvUo/ac0jwQswUXr3EV5LdfTVqOoxH2AxXCi0un5k=; b=a2XwP2sG/RXE6UfMknFV0Yixx1T9bTfAYiKs8LL8kw92Djf+WTC4Rz/H aE4LigM37xniUsq1+vnTYE+3ngkNFA7glb0zdwPQGun6R1c6SrOvZZh0n dZma0cmBxQZ6VvkDxO8gd5f1RaQ5ExbTRwLMEV7pqIRb1aw3wEU5KHfJM c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAA8QtZc/49dJa1ZChkBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYEOUwUqaVQwKAqEB4gcjQOJP48UFIFjBAkBAQEMAQEYAQwKAQGEQAIXgXQjNAkOAQMBAQQBAQIBBG0cDIVKAQEBBAEBIUsJAhACAQgRAwECIQEGAwICAh8GCxQJCAIEDgWDIgGBHU0DHQ8DrTaBL4QyAQMCDkFAgjcNgiOBMwGLTheBQD+BEAEnH4FOfj6CGkcBAQIBARaBDwUBBwsBHiEGGIJMMoImBIp7GAyCO4RQIIF1kls5CQKCCYYfhDmBfIIxg1UbghNlhWYFg2+JGY1UhTKBTolpgngCERWBMA0SOGZxcBUaISoBgkEJNYJ1AQIGh1aFP0ExAY4rgSKBIQEB
X-IronPort-AV: E=Sophos;i="5.60,455,1549929600"; d="scan'208,217";a="553727835"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 May 2019 03:34:47 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x4B3YkG9016277 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 May 2019 03:34:47 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 May 2019 23:34:45 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1473.003; Fri, 10 May 2019 23:34:45 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Service Function Chaining IETF list <sfc@ietf.org>
Thread-Topic: [sfc] New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
Thread-Index: AQHVB6S3vuqtmZ+lwU+/KBkoNG/gmqZlgwqAgAAFroA=
Date: Sat, 11 May 2019 03:34:45 +0000
Message-ID: <11BA26AF-FB36-497C-9F9E-76E9658BFF47@cisco.com>
References: <155737926141.22620.15797109690906794999.idtracker@ietfa.amsl.com> <CA+RyBmXKNGqd8NCirzOrY4cREGB3dQHCMV7EhpKEWi8ft8vUUg@mail.gmail.com> <E0EA0543-0A53-42F2-9070-81569EFA0C86@cisco.com> <CA+RyBmVb6FGcAR+rPGrQOoYg=A1xYWX+c7hrQ4zq7hHMV2eHgg@mail.gmail.com>
In-Reply-To: <CA+RyBmVb6FGcAR+rPGrQOoYg=A1xYWX+c7hrQ4zq7hHMV2eHgg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.8)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.132]
Content-Type: multipart/alternative; boundary="_000_11BA26AFFB36497C9F9E76E9658BFF47ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.156, xch-rtp-016.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/8TDuPDAqlobEF4rPhjInNpzC63E>
Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 May 2019 03:35:02 -0000
Dear SFC Chairs, I believe Greg’s response is mis-representing my position, and mis-quoting what I wrote, as follows: Greg wrote: Thus I'm puzzled why are you demanding that this optional section be added to the draft now? 1. I am not demanding. Instead I wrote: Request: Can we please add an “Implementation Status” section? Greg wrote: Thus I'm puzzled why are you demanding that this optional section be added to the draft now? However, I suggested this over a year ago, and then 6 months ago, as per the list posting included below. Not “now”. * 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 My main request is that on-list comments and suggestions are responded to and discussed on technical merits. The previous two/three times, my comment was ignored and not responded to. I also do not understand why questions are selectively ignored. I asked three questions on this email, but received a response to only one. Dear Greg, Sorry to have puzzled you. That was not the intention. The intention was to engage in a technical discussion about an Internet Best Current Practice. Apologies if I sounded (or was) repetitive, just seeking an answer. I understand the “Implementation Status” section is optional, but since Internet documents are (among other things) for interoperability, I kindly request you consider adding that optional section. Besides the one-liner you quoted, RFC 7942 goes into great lengths at explaining the importance of doing so. You also mention: Yes, the work on the implementation is ongoing Does this mean “the implementation” as in only one? Best, — Carlos Pignataro On May 10, 2019, at 11:14 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote: Hi Carlos, I'm sure you've read the section "Implementation Status" in RFC 7942 that opens with the following sentence: Each Internet-Draft may contain a section entitled "Implementation Status". Thus I'm puzzled why are you demanding that this optional section be added to the draft now? Yes, the work on the implementation is ongoing and when there will be updates, we'll certainly share them with the WG. Regards, Greg On Fri, May 10, 2019 at 7:53 PM Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> 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? 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. 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. 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? 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. Many thanks, — Carlos Pignataro On May 9, 2019, at 1:31 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> 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: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> Date: Wed, May 8, 2019 at 10:21 PM Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt To: <sfc-chairs@ietf.org<mailto:sfc-chairs@ietf.org>>, Gregory Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>, Bhumip Khasnabish <vumip1@gmail.com<mailto:vumip1@gmail.com>>, Wei Meng <meng.wei2@zte.com.cn<mailto:meng.wei2@zte..com.cn>>, Cui(Linda) Wang <lindawangjoy@gmail.com<mailto:lindawangjoy@gmail.com>> 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 sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc
- [sfc] Fwd: New Version Notification for draft-iet… Greg Mirsky
- Re: [sfc] New Version Notification for draft-ietf… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-ietf… Greg Mirsky
- Re: [sfc] New Version Notification for draft-ietf… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-ietf… Joel M. Halpern
- Re: [sfc] New Version Notification for draft-ietf… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-ietf… Joel M. Halpern
- Re: [sfc] New Version Notification for draft-ietf… Greg Mirsky
- Re: [sfc] New Version Notification for draft-ietf… Carlos Pignataro (cpignata)