Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06
Greg Mirsky <gregimirsky@gmail.com> Tue, 23 July 2019 20:38 UTC
Return-Path: <gregimirsky@gmail.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 D4B4D12096F; Tue, 23 Jul 2019 13:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vn9Je3SSVuoY; Tue, 23 Jul 2019 13:38:55 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760B2120950; Tue, 23 Jul 2019 13:38:54 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id b17so30316161lff.7; Tue, 23 Jul 2019 13:38:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tHHCuCXmcuH8zUz2JCuSqfZIUmma0HomQ18IRWJJjA8=; b=k6BD4CsoDwwZAH9qS3eUIBqHF3tBs3pP+wk/F5E9cuFvaPSEo3pi2NmQij+ERMTM87 ozfuW0LnbluSGiy4Yv2uGO+aXlUGCxzADQehN6Nz4YwxI9NB51pKRHz0VHVISAgI32G2 6dYrTlJogQOWXyYhF9zKW48m+old1fGt9PNNACryXns3VaRlzXjhXzy4uAC/eiTo83Eb oLB3je3Ye8GXVt4jAMxPPNwJLkSo7d0UQaUCWxo4R6OI3YyWncaZoYbhRpUlEPfMquUR J7Fu0MoT9+ZDiWkF4gfT0MGl9IgbFZ10UXb/85hyHwXdA5FQtfvcs7YzSpeCOqBqDAoN VGYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tHHCuCXmcuH8zUz2JCuSqfZIUmma0HomQ18IRWJJjA8=; b=FhFTLTzbxqV5P6SGrW9SOLnI6zo+q/llbMwSGPqTgXZ7ODd1DIa5pA4ksd1ozaZlYs wviRg9ah9o3Py5T9dVLMnMXiYaWBxiK1k1Pfa4nMn4IMOBTExxeqrjN5+TvtWDXun0R3 QmU8spMCmSNy5GgTatQJTrG/P8qt10ThmnvDtrdGrXp4dY+T2gNAho/8It0hDitntkjP FHe0MLL0qzkY4X6AMV68kqR09RzgYzNbWODeDmOXOrd0cjnHpBmZLw2du/H3nD8Dp4G6 A2u/Z173q6jT5phGWoVhHOrzjdoFKzy/x4oGMLhhVJYJOEbFmHDxJMtMv0CiDE3gQQFY 48Eg==
X-Gm-Message-State: APjAAAXF8sSuzQY2S4aU/JtHeJCempCfDLz5EFDBOWWT8PtuCNTFxflj qN9kfR2XYTA22Mv3Om8LmpE0uaXFPdf2KhsYAd8=
X-Google-Smtp-Source: APXvYqy1TRhtYEFBYzxl63yDWIWsieZYA02gdtyyMxa/ei46iDov4mLxeE8VEaLTIOuqIGsx9JYpyQGXBFCxzU3zbUA=
X-Received: by 2002:a19:9111:: with SMTP id t17mr1550353lfd.113.1563914332489; Tue, 23 Jul 2019 13:38:52 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR13MB25978FD458B59EB22067685FD21E0@BYAPR13MB2597.namprd13.prod.outlook.com> <CA+RyBmWUeNd5u1NPb9cy5-DxsPdCYcB5q5nQ904P8-n-CX3KOQ@mail.gmail.com> <1A1EA07A-94DB-4100-8149-119B7915E64B@cisco.com>
In-Reply-To: <1A1EA07A-94DB-4100-8149-119B7915E64B@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 23 Jul 2019 16:38:41 -0400
Message-ID: <CA+RyBmULKUHiBzeLww7_4kBsYceo_4UR=PcrbBQ=uPboE8BpQQ@mail.gmail.com>
To: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
Cc: James Guichard <james.n.guichard@futurewei.com>, "draft-ietf-sfc-oam-framework@ietf.org" <draft-ietf-sfc-oam-framework@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003f4cf8058e5f2ef0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/lYiXB-0CpSF5cHQ17ZwjgggEb0E>
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06
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: Tue, 23 Jul 2019 20:38:59 -0000
Hi Nagendra, thank you for your expedient response to my comments and questions. I am at IETF this week and will respond with my notes after IETF. Apologies for the delay, hope you'll understand. Regards, Greg On Tue, Jul 23, 2019 at 1:58 PM Nagendra Kumar Nainar (naikumar) < naikumar@cisco.com> wrote: > Hi Greg, > > > > Thank you for the comments. Please see our responses below. > > > > in regard to the applicability of ICMP the statement in Section 4.1.1 is > "ICMP could be leveraged for connectivity function (defined in Section 4.1) > to verify the availability of SF or SFC." When I looked through Section 4.1 > I find some discussion of a Fault Management function but no clear > definition of what is connectivity verification in SFC. > > > > <Authors> Section 4.1 already list some of the OAM functions that can be > performed as part of connectivity function. > > > > More so, it appears that connectivity verification is being mixed with > re-ordering detection, Path MTU Discovery, data integrity monitoring, > > > > <Authors> Please refer Section 2.2.7 of RFC7276 that explains MTU > verification as part of Connectivity verification. Section 3.1.1 already > explains the rationale behind including policy verification. > > > > and some sort of policy verification. Real kitchen sink. > > > > <Authors> The intention is to capture/highlight various OAM functions > based on the unique characteristics of SFC. Please read section 3.1.1 about > SF availability. It is already explained about what is (or why) policy > verification for SF availability. Accordingly, we humbly deny on this > comment. > > > > At the same time, in other documents on network OAM, connectivity > verification has been firmly defined as a function that verifies that data > have been received only form the expected source over the expected path. In > conjunction with this, a misconnection error is defined to indicate that > packets from another connection have been received. In other words, the > connectivity verification function verifies not only that packets from A > reach node B but that they arrive only on the red wire, not on blue or > yellow. Said all that, the interpretation of connectivity function in SFC > may be different but, in my opinion, Section 4.1 does not provide anything. > > > > <Authors> We dont understand your concern here. SFC OAM components > explains what is availability and PM for SF/SFC (Refer section 3.1.x and > 3.2.x) and tied it up with the function in section 4. The relevant sections > also highlight the difference in SFC (For example, what is availability in > terms of SF). > > > > Also, it is not clear how the last bullet "Proactively test alternate or > protected paths to ensure reliability of network configurations" is > specific to and requires the use of a connectivity function and why it > cannot be addressed by, for example, continuity check function. > > > > <Authors> Thanks for highlighting this. We will add the same point under > Section 4.2. Hope that satisfies your concern. > > > > Also, the very last sentence of Section 4.1 concludes that ICMP in SFC > "can be used for basic OAM functions". But I cannot find anywhere in the > document where the term, notion of "basic OAM functions" has been discussed > or defined. Which functions considered as basic? ICMP can be used as the > fault management tool, to some extent because it is relatively processing > extensive, but its value in performance monitoring is very low. Is PM OAM > not part of the basic OAM functions? > > > > <Authors> Thanks. To avoid any confusion, we modified it as below. Does > the below modification help? > > > > "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." > > > > > > Section 6.4.2, in my opinion, may provide some context to how to interpret > the use of "availability". From "BFD or S-BFD could be leveraged to perform > SF or SFC availability" it appears that the availability is viewed as part > of Fault Management OAM. (I'm still awaiting a response to my earlier > questions specifically on the interpretation of "availability" in the OAM > Framework for SFC. > > > > <Authors> Thanks, this looks like a valid point. We can change the same as > below: > > > > "BFD or S-BFD could be leveraged to perform continuity function for SF or > SFC." > > > > Further, in Section 6.4.2 the possible use is described as "Upon receiving > the control packet, the last SFF in the SFC will reply back with relevant > DIAG code." But this is not how BFD in the Asynchronous mode operates, that > is how only S-BFD works. The first sentence of the second paragraph refers > to both BFD and S-BFD. But the rest of the paragraph describes the > operation of S-BFD only, not of BFD in Asynchronous mode. I believe that > either the positioning statement must be modified or explanation of the > operation of BFD in Asynchronous mode over SFP provided. > > > > <Authors> The intention is not to explain how it works for each BFD mode. > But to explain the common behavior. AFAIK/R, setting relevant DIAG code in > the response packet is common for both BFD and S-BFD. So we dont see any > confusion here. > > > > > > Section 6.4.3 includes the statement about the applicability of iOAM to > availability: "In-Situ OAM could be used with O bit set to perform SF > availability and SFC availability or performance measurement." I interpret > this conclusion as the indication that availability is considered as part > of the Fault Management OAM toolset. If that is the case, I question the > value of using one-way OAM for fault management because only the egress > node may have the state and even that is not demonstrated in existing iOAM > documents. In order to detect path failure, a node must have information > that can be used to detect the packet loss. That can be either > monotonically increasing sequence numbers or the notion that packets must > be arriving at pre-determined intervals. Which mechanism can be used by > iOAM? Also, since iOAM, in regard to availability, appears as single-way FM > OAM mechanism, that uses the actual data flow, what is its advantage > comparing to, for example, collecting and comparing counters from ingress > and egress? In other words, even if the egress can detect the loss of its > availability for the particular SFP, how such a notion can be used? > > > > <Authors> Section 6.4 is all about the applicability of different tools. > It neither concludes nor prefers one over the other. How the data is > collected, interpreted, used for failure detection or signaled back to the > Initiator are expected to be explained in the solution document that > proposes iOAM as the tool for SFC OAM. As mentioned in the document scope, > any solution specific info is outside the scope of this document and > accordingly we dont see a reason to include those details in this document. > > > > I, again, have to point out that Section 6.4.4 references the individual > draft that had expired 3+ years ago. Usually, that is the indication that > neither authors nor the community are interested in the idea. > > > > <Authors> This was already clarified by Carlos in different thread. The > concept in the draft is already implemented and available in ODL. > > > > Hope the above clarifies your queries. We are addressing the agreed > comments and editorial comments that you raised in the other thread. We > will submit a new version with the fixes. > > > > Thanks, > > Nagendra > > > > > > *From: *sfc <sfc-bounces@ietf.org> on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Monday, July 22, 2019 at 10:44 AM > *To: *James Guichard <james.n.guichard@futurewei.com> > *Cc: *"sfc@ietf.org" <sfc@ietf.org> > *Subject: *Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06 > > > > Dear Jim, Joe, et al., > > I'd like to share my comments on Section of 6.4 of the draft. Much > appreciate your consideration and response to my questions. > > - in regard to the applicability of ICMP the statement in Section > 4.1.1 is "ICMP could be leveraged for connectivity function (defined in > Section 4.1) to verify the availability of SF or SFC." When I looked > through Section 4.1 I find some discussion of a Fault Management function > but no clear definition of what is connectivity verification in SFC. More > so, it appears that connectivity verification is being mixed with > re-ordering detection, Path MTU Discovery, data integrity monitoring, and > some sort of policy verification. Real kitchen sink. At the same time, in > other documents on network OAM, connectivity verification has been firmly > defined as a function that verifies that data have been received only form > the expected source over the expected path. In conjunction with this, a > misconnection error is defined to indicate that packets from another > connection have been received. In other words, the connectivity > verification function verifies not only that packets from A reach node B > but that they arrive only on the red wire, not on blue or yellow. Said all > that, the interpretation of connectivity function in SFC may be different > but, in my opinion, Section 4.1 does not provide anything. Also, it is not > clear how the last bullet "Proactively test alternate or protected paths to > ensure reliability of network configurations" is specific to and requires > the use of a connectivity function and why it cannot be addressed by, for > example, continuity check function. > - Also, the very last sentence of Section 4.1 concludes that ICMP in > SFC "can be used for basic OAM functions". But I cannot find anywhere in > the document where the term, notion of "basic OAM functions" has been > discussed or defined. Which functions considered as basic? ICMP can be used > as the fault management tool, to some extent because it is relatively > processing extensive, but its value in performance monitoring is very low. > Is PM OAM not part of the basic OAM functions? > - Section 6.4.2, in my opinion, may provide some context to how to > interpret the use of "availability". From "BFD or S-BFD could be leveraged > to perform SF or SFC availability" it appears that the availability is > viewed as part of Fault Management OAM. (I'm still awaiting a response to > my earlier questions specifically on the interpretation of "availability" > in the OAM Framework for SFC. > - Further, in Section 6.4.2 the possible use is described as "Upon > receiving the control packet, the last SFF in the SFC will reply back with > relevant DIAG code." But this is not how BFD in the Asynchronous mode > operates, that is how only S-BFD works. The first sentence of the second > paragraph refers to both BFD and S-BFD. But the rest of the paragraph > describes the operation of S-BFD only, not of BFD in Asynchronous mode. I > believe that either the positioning statement must be modified or > explanation of the operation of BFD in Asynchronous mode over SFP provided. > - Section 6.4.3 includes the statement about the applicability of iOAM > to availability: "In-Situ OAM could be used with O bit set to perform SF > availability and SFC availability or performance measurement." I interpret > this conclusion as the indication that availability is considered as part > of the Fault Management OAM toolset. If that is the case, I question the > value of using one-way OAM for fault management because only the egress > node may have the state and even that is not demonstrated in existing iOAM > documents. In order to detect path failure, a node must have information > that can be used to detect the packet loss. That can be either > monotonically increasing sequence numbers or the notion that packets must > be arriving at pre-determined intervals. Which mechanism can be used by > iOAM? Also, since iOAM, in regard to availability, appears as single-way FM > OAM mechanism, that uses the actual data flow, what is its advantage > comparing to, for example, collecting and comparing counters from ingress > and egress? In other words, even if the egress can detect the loss of its > availability for the particular SFP, how such a notion can be used? > - I, again, have to point out that Section 6.4.4 references the > individual draft that had expired 3+ years ago. Usually, that is the > indication that neither authors nor the community are interested in the > idea. > > Regards, > > Greg > > > > On Tue, May 28, 2019 at 10:37 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This message starts a new two week WG Last Call on advancing > https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ > <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-oam-framework%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Ce47e5eb13f224f18c46408d6e378b2f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636946504868870205&sdata=lkKvAgmKik7lkqGANQpnIvBRdbjKAqYtzTUdTfB9f3Y%3D&reserved=0> > for publication as an Informational RFC. > > > > Substantive comments and statements of support for publishing this > document should be directed to the mailing list. Editorial suggestions can > be sent to the authors. This last call will end on 11th June 2019. > > > > Thanks! > > > > Jim & Joel > > > > > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > >
- [sfc] WG Last Call draft-ietf-sfc-oam-framework-06 James Guichard
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Nagendra Kumar Nainar (naikumar)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… mohamed.boucadair
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Andrew G. Malis
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Adrian Farrel
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Nagendra Kumar Nainar (naikumar)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Sam Aldrin
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Nagendra Kumar Nainar (naikumar)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… mohamed.boucadair
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Carlos Pignataro (cpignata)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Carlos Pignataro (cpignata)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… James Guichard
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… mohamed.boucadair
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Sami Boutros
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Anoop Ghanwani
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Nagendra Kumar Nainar (naikumar)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Carlos Pignataro (cpignata)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Sam Aldrin
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Vengada Prasad Govindan (venggovi)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Ashish Panda (aspanda)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Diego R. Lopez
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Jeff Tantsura
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Carlos Pignataro (cpignata)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… James Guichard
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Nagendra Kumar Nainar (naikumar)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Carlos Pignataro (cpignata)
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… James Guichard
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… James Guichard
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Greg Mirsky
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… James Guichard
- Re: [sfc] WG Last Call draft-ietf-sfc-oam-framewo… Carlos Pignataro (cpignata)