Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam
"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 21 December 2021 02:59 UTC
Return-Path: <jmh@joelhalpern.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 B53003A107E for <sfc@ietfa.amsl.com>; Mon, 20 Dec 2021 18:59:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 vdgXFkWtgdVO for <sfc@ietfa.amsl.com>; Mon, 20 Dec 2021 18:59:45 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CCE3A1075 for <sfc@ietf.org>; Mon, 20 Dec 2021 18:59:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4JJ1QS6kCfz1nskq; Mon, 20 Dec 2021 18:59:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1640055584; bh=uzNYLl1usZ5sLi5750EK8N7xYiyyFO+9Xwkb/5HQjhA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=difTHHW84iTNRegLEja1JFGiGkP4R3VA8qTurFe/zAH1bRHMoMkJkUpDlvJb9E05N ZNSWqyLGq7ukv8KaOT3bexj+5aRLDf6FJlJZCB7Pzf7aNLe8fjHA5YFsu3KAEECkYs f9TA71y3VdwiDHUM6zCjQrO6gWZHhnJMdYI6B/V4=
X-Quarantine-ID: <nXEAv3hAU7fw>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4JJ1QR2jW8z1nsMQ; Mon, 20 Dec 2021 18:59:43 -0800 (PST)
Message-ID: <d62da18b-6fd5-da1d-aae3-e07563fa803f@joelhalpern.com>
Date: Mon, 20 Dec 2021 21:59:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0
Content-Language: en-US
To: "Carlos Pignataro (cpignata)" <cpignata=40cisco.com@dmarc.ietf.org>, Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: James N Guichard <james.n.guichard@futurewei.com>, Greg Mirsky <gregimirsky@gmail.com>, "Frank Brockners (fbrockne)" <fbrockne=40cisco.com@dmarc.ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>
References: <4bb5abb4-a8dc-c8f0-9b99-549f683e7729@joelhalpern.com> <B4F81D2C-1273-493E-8E90-35D32ACDE6D1@cisco.com> <DM8PR11MB560669E2E2C77AD662F6251CDA9F9@DM8PR11MB5606.namprd11.prod.outlook.com> <CA+RyBmXUBYFFgNfopErFYUgJDfJWVY59ERM0LrkEnxw_xC2MYg@mail.gmail.com> <DM8PR11MB5606B943F4D1A3B2702D53EBDA609@DM8PR11MB5606.namprd11.prod.outlook.com> <A012EBFA-FDAB-4591-8F3A-9D5882B69A57@cisco.com> <DM8PR11MB5606D7CDC99EB7FFE63095DFDA639@DM8PR11MB5606.namprd11.prod.outlook.com> <896B8A4B-3717-4150-9944-44906A593BC9@cisco.com> <CA+RyBmUaeSsjLE191jK94bGV3Nzed95tkN+mn-kCDs6WxucFRg@mail.gmail.com> <1B31F06E-974A-4BDA-8C89-81E61B8E6868@cisco.com> <CA+RyBmUax4VmKpMvW-JErrdjZj09kV2fCofiKH91E0qYRhGatA@mail.gmail.com> <CE085BD4-1DD3-484E-B94C-6800C9F38CFA@cisco.com> <005e334c-fd02-e7b2-4bef-3d0551c1b289@joelhalpern.com> <FE19CCFA-D499-4C3E-AB52-0E1F771D5371@cisco.com> <07cd39c5-9078-ec76-b340-43665d8805eb@joelhalpern.com> <2C6BEA5E-D7A3-4ED7-B1AD-A9353777045D@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
In-Reply-To: <2C6BEA5E-D7A3-4ED7-B1AD-A9353777045D@cisco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/XCSrvC4h-86W8kG2LzVniGpTNk8>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam
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, 21 Dec 2021 02:59:56 -0000
At this point I would really like to hear from other people in the working group. Is anyone other than the authors, Carlos, adn Frank, paying attention? Please? Thank you, Joel On 12/20/2021 8:10 PM, Carlos Pignataro (cpignata) wrote: > For this usage https://datatracker.ietf.org/doc/html/rfc8924#section-7.1 > <https://datatracker.ietf.org/doc/html/rfc8924#section-7.1>, the O-bit > should be set. For any “vanilla” ICMP in traffic is not. > >> On Dec 20, 2021, at 8:07 PM, Joel Halpern Direct >> <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>> wrote: >> >> from what I read, the example you provided was of an underlying ICMP >> Echo packet. >> As I understood your email, you want SFC to mark that as OAM in the >> NSH header. >> I would not have expected that behavior from the existing texts. >> >> As such, whichever way we want it to work, we would seem to need to >> clarify our collective expectation. >> >> More generally, I assumed the O bit of the SFC NSH header was >> concerned with OAM related to SFC. I think, although I could be >> wrong, that you read it more generally. Again, if different folks >> read it differently, we benefit from clarity. >> >> Yours, >> Joel >> >> On 12/20/2021 8:01 PM, Carlos Pignataro (cpignata) wrote: >>> Hi Joel, >>> Sorry if I was not clear — I did not mean infer from a packet payload >>> the function type. I meant: look at the O-bit. If set, it is OAM. The >>> NP says how that OAM is encapsulated, which can include IP->ICMP. >>> Based on that, what part of the definition you feel is unclear? >>> From RFC 8300: >>> O bit: Setting this bit indicates an OAM packet (see [RFC6291]). >>> … >>> The O bit MUST be set for OAM packets and MUST NOT be set for >>> non-OAM packets. The O bit MUST NOT be modified along the SFP. >>> This seems to match what I understand is also your preference. >>> What exactly is needed to be updated on the definition of the O-bit? >>> Best, >>> Carlos. >>>> On Dec 18, 2021, at 7:48 PM, Joel Halpern Direct >>>> <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>> wrote: >>>> >>>> Just commenting on one aspect of your note. I think the definition >>>> of the SFC NSH header O bit is unclear. It never occurred to me >>>> that one would expect an SFC classifier to not that an inncoming >>>> packet was carrying ICMP, look at the ICMP type, decide it was an >>>> OAM packet, and set the O bit in the SFC NSH header. No, nothing in >>>> the OAM framework prohibits that. But nothing leads one to expect >>>> it either. >>>> >>>> Thus, I think it is helpful to clarify the meaning of the O-bit. >>>> Personally, I rather like saying that the NSH O bit is to indicate >>>> the presence of OAM for SFFs. But my personal view is largely >>>> irrelevant. >>>> >>>> It would be good to hear from others in the working group. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/18/2021 5:41 PM, Carlos Pignataro (cpignata) wrote: >>>>> Dear Greg, >>>>> Thank you for the reply — please find inline my follow-ups (to the >>>>> comments you responded to, even though there’s a few you missed or >>>>> otherwise skipped) >>>>> As dialogue in this thread seem to be getting intertwined and hard >>>>> to follow, with several weeks between responses, I will let the >>>>> chairs (I believe there’s no shepherd assigned) track the issues >>>>> and review comments (not sure if there’s an issue tracker)and take >>>>> it from here. >>>>> Happy Holidays! >>>>>> 12/15/21 午後8:00、Greg Mirsky <gregimirsky@gmail.com >>>>>> <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com >>>>>> <mailto:gregimirsky@gmail.com>>>のメール: >>>>>> >>>>>> Dear Carlos, >>>>>> please find my notes below in-line under the GIM2>> tag. Attached >>>>>> is the diff highlighting two editorial changes. >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> On Fri, Nov 26, 2021 at 8:18 PM Carlos Pignataro (cpignata) >>>>>> <cpignata@cisco.com <mailto:cpignata@cisco.com> >>>>>> <mailto:cpignata@cisco.com <mailto:cpignata@cisco.com>>> wrote: >>>>>> >>>>>> Dear Greg, >>>>>> >>>>>> I disagree. My perspective is that they go from not helpful to >>>>>> plain harmful. >>>>>> >>>>>> Let’s look at those three aspects one-by-one (changing the >>>>>> bulleted list into a numbered list for ease of tracking): >>>>>> >>>>>> 1. This is no different than RFC 8300. The O bit specifies the >>>>>> packet being OAM, >>>>>> >>>>>> GIM2>> I don't know of a definition of an "OAM packet". Even more, >>>>>> RFC 8300 does not refer to any such definition, nor does it >>>>>> provide it. draft-ietf-sfc-multi-layer-oam clarifies the use of O >>>>>> bit for the active SFC NSH OAM. >>>>> CMP2: I am not sure of the implication of you not knowing that >>>>> definition, nor do I see this response moving alignment forward. >>>>> CMP2:From RFC8300: >>>>> CMP2: The O bit MUST be set for OAM packets and MUST NOT be >>>>> set for >>>>> CMP2: non-OAM packets. The O bit MUST NOT be modified along >>>>> the SFP. >>>>> CMP2: And RFC8924 includes “OAM packet” 30 times. >>>>>> 1. the Next Protocol specifies the type of packet which can be >>>>>> “Active SFC OAM” >>>>>> * Stating however that the identification is based on a >>>>>> combination of fields is incorrect. >>>>>> 2. This is not a generic behavior that needs specifying or >>>>>> updating. It is part of the specific NSH Next Protocol value >>>>>> behavior for the NSH Next Protocol being defined as “Active >>>>>> SFC OAM”. >>>>>> 3. This is incorrect and a serious over-reach. Specifically: >>>>>> * If the O bit is set and the Next protocol is not “Active >>>>>> SFC OAM”, the definition is much beyond the scope of this >>>>>> document — since this document specifies behaviors for one >>>>>> specific SFC OAM protocol which is “One Active SFC OAM” >>>>>> (name to be narrowscoped as per other pending thread) >>>>>> >>>>>> GIM2>> I don't see why you re-name the Active SFC OAM protocol >>>>>> into "One Active SFC OAM". That is not what is in the draft. Are >>>>>> you preparing another draft that you believe will update >>>>>> draft-ietf-sfc-multi-layer-oam by introducing an additional active >>>>>> SFC OAM protocol? >>>>> CMP2: My point is that draft-ietf-sfc-multi-layer-oam is not the >>>>> only Active SFC OAM protocol. >>>>> CMP2: RFC8924 includes ICMP, which by simply setting O=1 and NP as >>>>> IP can be used. >>>>>> * If the O bit is set and the Next protocol is not “Active >>>>>> SFC OAM”, and this document somehow concludes that the OAM >>>>>> is in the Context Header, then it is: >>>>>> o Breaking other OAM protocols including other Active >>>>>> SFC OAM protocols encapsulated in IPv4, in IPv6, SFC >>>>>> Trace. It is valid to have O=1, NSH NP as IPv4, and an >>>>>> OAM packet encapsulated. >>>>>> GIM2>> Protocols that use IP/UDP encapsulation are not active SFM >>>>>> OAM protocols even though they might be used as such. I expect >>>>>> that if the payload of NSH is an ICMPv6 echo request, the O bit >>>>>> will be cleared and the Next Protocol set to IPv6 value. >>>>> CMP2: The first sentence is interesting: >>>>> CMP2: 1. please point to a reference that explains that using a >>>>> specific encapsulation prevents specific functionality. >>>>> CMP2: 2. What is a protocol used as active OAM but not being active >>>>> OAM? >>>>> CMP2: Regarding the second sentence, thanks for sharing what you >>>>> expect — however that is different than what specs write :-) Why >>>>> would encapsulation dictate the value of the O bit? Take for >>>>> example BFD encapsulated in IP… >>>>>> o Breaking the use of context headers, since they need >>>>>> context that ought to equally apply to OAMs and to >>>>>> data packets, as for example a Flow Label, a >>>>>> Forwarding context, etc. Re-writing Context Headers >>>>>> breaks that. >>>>>> >>>>>> GIM2>> draft-ietf-sfc-multi-layer-oam does not include any >>>>>> processing that requires re-writing an NSH Context Header. >>>>> CMP2: Your document says the following: >>>>> CMP2: - An SFC NSH Context Header(s) contain an OAM processing >>>>> CMP2: instructions or data. >>>>> CMP2: which prevents using context header for spec’ed context >>>>> header uses. >>>>>> >>>>>> I’d encourage the WG, shepherd, and WG Chairs to more closely >>>>>> inspect and review this document, specifically whether is defining >>>>>> one SFC Active OAM protocol, or breaking functionality while >>>>>> redefining base RFC 8300 behavior. >>>>>> >>>>>> >>>>>> >>>>>> Although these were brought up before, highlighting a couple of >>>>>> comments: >>>>>> >>>>>> >>>>>> 1. Introduction >>>>>> Also, this document updates Section 2.2 of [RFC8300] in part of >>>>>> the >>>>>> definition of O bit in the NSH. >>>>>> >>>>>> CMP: I do not see the need to redefine the O bit in the NSH. >>>>>> >>>>>> >>>>>> 4. Active OAM Identification in the NSH >>>>>> The O bit in the NSH is defined in [RFC8300] as follows: >>>>>> O bit: Setting this bit indicates an OAM packet. >>>>>> This document updates that definition as follows: >>>>>> O bit: Setting this bit indicates an OAM command and/or >>>>>> data in >>>>>> the NSH Context Header or packet payload. >>>>>> >>>>>> CMP: There is, as shown above, no need for this. >>>>>> >>>>>> GIM2>> As a result of RFC 8300 not providing a reference or >>>>>> definition of an "OAM packet", this draft addresses that for the >>>>>> case of Active SFC OAM. >>>>> CMP2: Thank you for explaining the rational for the O-bit text in >>>>> your document. >>>>> CMP2: Please search for “OAM packet” in existing RFCs going back to >>>>> at least 15 years ago. >>>>> CMP2: draft-ietf-sfc-multi-layer-oam does not provide the >>>>> definition (not needed frankly) of what you say needs defining. >>>>>> >>>>>> * O bit set and the "Next Protocol" value does not match >>>>>> the value >>>>>> Active SFC OAM (TBA1), defined in Section 9.1: >>>>>> - An SFC NSH Context Header(s) contain an OAM processing >>>>>> instructions or data. >>>>>> >>>>>> CMP: As shown above, this 1. breaks functionality (e.g., Flow >>>>>> Label in context) and 2. has absolutely *no* need to be included >>>>>> in this specific OAM protocol document. >>>>>> >>>>>> GIM2>> If there's no NSH Context Header with OAM processing >>>>>> instruction or data, then the O bit will not be set. If one or >>>>>> more NSH Context Header includes OAM processing instructions or >>>>>> data, then, I assume, the O bit will be set. >>>>>> draft-ietf-sfc-multi-layer-oam does not change that. (I much >>>>>> appreciate Frank's comments and the discussion that helped clarify >>>>>> that scenario.) >>>>> CMP2: Can you please share a reference to OAM in NSH context headers? >>>>>> >>>>>> >>>>>> 5. Active SFC OAM Header >>>>>> >>>>>> This document defines Active OAM Header >>>>>> (Figure 2) to demultiplex active OAM protocols on an SFC. >>>>>> >>>>>> CMP: The identification of OAM protocols is already solved >>>>>> directly in RFC 8300 by using the NSH Next Protocol. >>>>>> CMP: This meta-header is redundant at best. >>>>>> >>>>>> Msg Type - six bits long field identifies OAM protocol, >>>>>> e.g., Echo >>>>>> Request/Reply or Bidirectional Forwarding Detection. >>>>>> >>>>>> CMP: First, why would BFD be carried as “One SFC Active OAM >>>>>> protocol” -> G-ACh-like meta-header with BFD Msg Type? >>>>>> >>>>>> GIM2>> draft-ietf-sfc-multi-layer-oam does not define how BFD to >>>>>> be carried in NSH environment. Will remove the reference to BFD in >>>>>> the next update. >>>>> CMP2: Whether you remove it from your draft, it is still another >>>>> SFC Active OAM Protocol. >>>>>> CMP: Second, I believe this also explains that what this document >>>>>> is defining is the “Echo Request/Reply” Active OAM Protocol. >>>>>> >>>>>> CMP: Since the name of the active OAM protocol defined in this >>>>>> document is "Echo Request/Reply”, could I please request to: >>>>>> CMP: 1. Provide a more specific name (since Echo Request/Reply can >>>>>> easily be confused with using ICMP) >>>>>> >>>>>> GIM2>> Throughout the document, "Echo Request/Reply" and "SFC Echo >>>>>> Request/Reply" are used interchangeably. Will add an explicit note >>>>>> to that in the Terminology section. >>>>> CMP2: Whether there’s a global replace, ICMP can still be another >>>>> SFC Active OAM Protocol. >>>>>> CMP: 2. Rename the title of this document to clearly define its >>>>>> scope for one specific SFC Active OAM protocol, by name, and not >>>>>> all Active OAM Protocols? >>>>>> >>>>>> GIM2>> The document provides the framework for Active SFC OAM and >>>>>> defines SFC Echo Request/Reply protocol. I will gladly update the >>>>>> title of the document, the WG decides that is necessary. >>>>> CMP2: What you write immediately above does not match the Abstract >>>>> of draft-ietf-sfc-multi-layer-oam. >>>>> CMP2: And again, the only time the word “Framework appears in this >>>>> draft is as part of the Citation for RFC8924! :-) >>>>> CMP2: No other framework needed. >>>>> CMP2: The Abstract says “requirements”, "an encapsulation”, "a >>>>> mechanism to detect and localize defects”… you say now a >>>>> “framework” and “a protocol”. >>>>> Best, >>>>> Carlos. >>>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Carlos. >>>>>> >>>>>>> On Nov 26, 2021, at 10:30 PM, Greg Mirsky >>>>>>> <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> >>>>>>> <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>> >>>>>>> wrote: >>>>>>> >>>>>>> Dear Carlos, >>>>>>> I believe that the proposed new text clarifies several aspects of >>>>>>> O bit: >>>>>>> >>>>>>> * active SFC NSH OAM packet is identified by the combination of >>>>>>> O bit set and the value of the NSH' Next Protocol field is >>>>>>> Active SFC OAM; >>>>>>> * the combination of O bit clear and the Next Protocol set to >>>>>>> the Active SFC OAM value - erroneous and must be reported; >>>>>>> * O bit set and the Next Protocol is not Active SFC OAM - >>>>>>> Context Header(s) include OAM processing instructions or data. >>>>>>> >>>>>>> Would you agree that these are helpful clarifications? >>>>>>> >>>>>>> Regards, >>>>>>> Greg >>>>>>> >>>>>>> On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata) >>>>>>> <cpignata@cisco.com <mailto:cpignata@cisco.com> >>>>>>> <mailto:cpignata@cisco.com <mailto:cpignata@cisco.com>>> wrote: >>>>>>> >>>>>>> Thank you Frank and Greg — what is the actual behavioral >>>>>>> change in the proposed redefinition of the O-bit from the >>>>>>> processing and rules defined in RFC8300? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Carlos. >>>>>>> >>>>>>>> On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne) >>>>>>>> <fbrockne=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:fbrockne=40cisco.com@dmarc.ietf.org> >>>>>>>> <mailto:fbrockne=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:fbrockne=40cisco.com@dmarc.ietf.org>>> wrote: >>>>>>>> >>>>>>>> Hi Carlos,____ >>>>>>>> __ __ >>>>>>>> Personally I don’t see a strong need to evolve the >>>>>>>> definition of the O-bit – but if the working group decides >>>>>>>> to do so, IMHO it would be good to ensure that the O-bit >>>>>>>> indeed signals the fact that active OAM information related >>>>>>>> to NSH is carried.____ >>>>>>>> __ __ >>>>>>>> Cheers, Frank____ >>>>>>>> __ __ >>>>>>>> *From:*Carlos Pignataro (cpignata) >>>>>>>> <cpignata=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:cpignata=40cisco.com@dmarc.ietf.org> >>>>>>>> <mailto:cpignata=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:cpignata=40cisco.com@dmarc.ietf.org>>> >>>>>>>> *Sent:*Tuesday, 23 November 2021 15:44 >>>>>>>> *To:*Frank Brockners (fbrockne) <fbrockne@cisco.com >>>>>>>> <mailto:fbrockne@cisco.com> >>>>>>>> <mailto:fbrockne@cisco.com <mailto:fbrockne@cisco.com>>> >>>>>>>> *Cc:*Greg Mirsky <gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com> >>>>>>>> <mailto:gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com>>>; Gyan Mishra >>>>>>>> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com> >>>>>>>> <mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>>; >>>>>>>> James N Guichard <james.n.guichard@futurewei.com >>>>>>>> <mailto:james.n.guichard@futurewei.com> >>>>>>>> <mailto:james.n.guichard@futurewei.com >>>>>>>> <mailto:james.n.guichard@futurewei.com>>>;sfc@ietf.org >>>>>>>> <mailto:sfc@ietf.org> >>>>>>>> <mailto:sfc@ietf.org <mailto:sfc@ietf.org>>; Joel Halpern >>>>>>>> Direct >>>>>>>> <jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com> >>>>>>>> <mailto:jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com>>> >>>>>>>> *Subject:*Re: [sfc] Regarding last call for >>>>>>>> draft-ietf-sfc-multi-layer-oam____ >>>>>>>> __ __ >>>>>>>> Frank, Greg,____ >>>>>>>> __ __ >>>>>>>> Do you see a reason to redefine the O-bit?____ >>>>>>>> __ __ >>>>>>>> Thanks,____ >>>>>>>> __ __ >>>>>>>> Carlos.____ >>>>>>>> >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 11/23/21午前9:33、Frank Brockners (fbrockne) >>>>>>>> <fbrockne=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:fbrockne=40cisco.com@dmarc.ietf.org> >>>>>>>> <mailto:fbrockne=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:fbrockne=40cisco.com@dmarc.ietf.org>>>のメール:____ >>>>>>>> __ __ >>>>>>>> Hi Greg,____ >>>>>>>> ____ >>>>>>>> Thanks for the quick reply. Please see inline.____ >>>>>>>> ____ >>>>>>>> *From:*Greg Mirsky <gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com> >>>>>>>> <mailto:gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com>>> >>>>>>>> *Sent:*Monday, 22 November 2021 23:16 >>>>>>>> *To:*Frank Brockners (fbrockne) <fbrockne@cisco.com >>>>>>>> <mailto:fbrockne@cisco.com> >>>>>>>> <mailto:fbrockne@cisco.com <mailto:fbrockne@cisco.com>>> >>>>>>>> *Cc:*Carlos Pignataro (cpignata) >>>>>>>> <cpignata=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:cpignata=40cisco.com@dmarc.ietf.org> >>>>>>>> <mailto:cpignata=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:cpignata=40cisco.com@dmarc.ietf.org>>>; Gyan >>>>>>>> Mishra <hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com> >>>>>>>> <mailto:hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com>>>; James N Guichard >>>>>>>> <james.n.guichard@futurewei.com >>>>>>>> <mailto:james.n.guichard@futurewei.com> >>>>>>>> <mailto:james.n.guichard@futurewei.com >>>>>>>> <mailto:james.n.guichard@futurewei.com>>>;sfc@ietf.org >>>>>>>> <mailto:sfc@ietf.org> >>>>>>>> <mailto:sfc@ietf.org <mailto:sfc@ietf.org>>; Joel >>>>>>>> Halpern Direct >>>>>>>> <jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com> >>>>>>>> <mailto:jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com>>> >>>>>>>> *Subject:*Re: [sfc] Regarding last call for >>>>>>>> draft-ietf-sfc-multi-layer-oam____ >>>>>>>> ____ >>>>>>>> Hi Frank,____ >>>>>>>> thank you for your comment describing an interesting >>>>>>>> IOAM use case in SFC NSH. I've thought about this case >>>>>>>> and I have several questions. I greatly appreciate your >>>>>>>> help clarifying them to me:____ >>>>>>>> >>>>>>>> * Is it envisioned that the IOAM can be part of NSH >>>>>>>> payload but not to immediately follow the SFC NSH? >>>>>>>> Perhaps such a case can be referred to as "IOAM >>>>>>>> inside NSH payload" to differentiate from "IOAM on >>>>>>>> top of NSH payload"? For example, assuming that the >>>>>>>> client payload is IPv6, then NSH is followed by an >>>>>>>> IPv6 packet, which, in turn, is followed by IOAM. >>>>>>>> ____ >>>>>>>> * If IOAM inside NSH payload is a viable use case, >>>>>>>> which SFC element is the intended addressee - SFF or >>>>>>>> SF/SF Proxy? If it is the former, what are the >>>>>>>> requirements for an SFF to handle this scenario? If >>>>>>>> it is the latter, what happens with the client >>>>>>>> packet if an SF/SF Proxy does not support IOAM in >>>>>>>> NSH but only NSH per RFC 8300?____ >>>>>>>> >>>>>>>> …FB: The scenario that you outline, i.e. NSH over “IPv6 >>>>>>>> with IOAM encapsulation”, sounds valid to me; and it >>>>>>>> could even be that NSH would also leverage IOAM, in >>>>>>>> which case, it would become a case of “IOAM Layering” as >>>>>>>> described >>>>>>>> inhttps://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2 >>>>>>>> <inhttps://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2> >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2>>. >>>>>>>> As outlined in the draft-ietf-ippm-ioam-deployment, >>>>>>>> IOAM-Data-Fields are specific to the layer (and the >>>>>>>> associated protocol) that they’re encapsulated into. As >>>>>>>> such, in the case of NSH over “IPv6 with IOAM >>>>>>>> encapsulation” it would be the IPv6 forwarder that would >>>>>>>> handle the IOAM processing. SFF/SF would be >>>>>>>> orthogonal/ships-in-the night.____ >>>>>>>> I've looked through draft-ietf-sfc-ioam-nsh but I >>>>>>>> couldn't find answers to these questions (I admit, I >>>>>>>> could have missed it).____ >>>>>>>> Also, I think that your suggestion to avoid any >>>>>>>> reference to a hybrid OAM protocol concentrating on the >>>>>>>> active OAM identification in the update to O-bit >>>>>>>> definition is logical and reasonable. Below, please find >>>>>>>> the proposed update:____ >>>>>>>> OLD TEXT:____ >>>>>>>> * O bit set and the "Next Protocol" value does not >>>>>>>> match one of____ >>>>>>>> identifying active or hybrid OAM protocols (per >>>>>>>> classification____ >>>>>>>> defined in [RFC7799]), e.g., defined in Section >>>>>>>> 9.1 Active SFC OAM____ >>>>>>>> (TBA1).____ >>>>>>>> ____ >>>>>>>> - a Fixed-Length Context Header or >>>>>>>> Variable-Length Context____ >>>>>>>> Header(s) contain an OAM command or data.____ >>>>>>>> ____ >>>>>>>> - the "Next Protocol" field determines the type >>>>>>>> of payload.____ >>>>>>>> ____ >>>>>>>> * O bit set and the "Next Protocol" value matches >>>>>>>> one of identifying____ >>>>>>>> active or hybrid OAM protocols:____ >>>>>>>> ____ >>>>>>>> - the payload that immediately follows the NSH >>>>>>>> MUST contain an____ >>>>>>>> OAM command or data.____ >>>>>>>> ____ >>>>>>>> * O bit is clear:____ >>>>>>>> ____ >>>>>>>> - no OAM in a Fixed-Length Context Header or >>>>>>>> Variable-Length____ >>>>>>>> Context Header(s).____ >>>>>>>> ____ >>>>>>>> - the payload determined by the "Next Protocol" >>>>>>>> field MUST be____ >>>>>>>> present.____ >>>>>>>> ____ >>>>>>>> * O bit is clear, and the "Next Protocol" field >>>>>>>> identifies active or____ >>>>>>>> hybrid OAM protocol MUST be identified and >>>>>>>> reported as an____ >>>>>>>> erroneous combination. An implementation MAY have >>>>>>>> control to____ >>>>>>>> enable processing of the OAM payload.____ >>>>>>>> ____ >>>>>>>> NEW TEXT:____ >>>>>>>> ____ >>>>>>>> …FB: The new text looks better. Couple of additional >>>>>>>> thoughts inline below.____ >>>>>>>> ____ >>>>>>>> * O bit set and the "Next Protocol" value does not >>>>>>>> match defined in____ >>>>>>>> Section 9.1 Active SFC OAM (TBA1).____ >>>>>>>> ____ >>>>>>>> …FB: The above sentence doesn’t sound complete. Likely >>>>>>>> you wanted to say something like “O bit set and the >>>>>>>> "Next Protocol" value does not matchany of the SFC Next >>>>>>>> Protocol values definedefined in Section 9.1 Active SFC >>>>>>>> OAM (TBA1).”____ >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> - a Fixed-Length Context Header or >>>>>>>> Variable-Length Context____ >>>>>>>> Header(s) contain an OAM command or data.____ >>>>>>>> ____ >>>>>>>> …FB: Given that it applies to both, fixed and variable – >>>>>>>> how about simplifying to “Context-header(s) that contain >>>>>>>> active OAM commands and/or data.”____ >>>>>>>> ____ >>>>>>>> - the "Next Protocol" field determines the type >>>>>>>> of payload.____ >>>>>>>> ____ >>>>>>>> * O bit set and the "Next Protocol" value matches >>>>>>>> Active SFC OAM____ >>>>>>>> (TBA1) value:____ >>>>>>>> ____ >>>>>>>> - the payload that immediately follows the NSH >>>>>>>> MUST be the____ >>>>>>>> Active OAM Header (Section 5).____ >>>>>>>> ____ >>>>>>>> * O bit is clear:____ >>>>>>>> ____ >>>>>>>> - no OAM in a Fixed-Length Context Header or >>>>>>>> Variable-Length____ >>>>>>>> Context Header(s).____ >>>>>>>> …FB: Similar to the note above, “No Context-header(s) >>>>>>>> that contain active OAM commands and/or data.” might be >>>>>>>> simpler____ >>>>>>>> ____ >>>>>>>> - the payload determined by the "Next Protocol" >>>>>>>> field MUST be____ >>>>>>>> present.____ >>>>>>>> ____ >>>>>>>> …FB: Isn’t this obvious? The reader might wonder why >>>>>>>> this is even stated. IMHO we could safely remove this >>>>>>>> bullet.____ >>>>>>>> ____ >>>>>>>> * O bit is clear, and the "Next Protocol" field is >>>>>>>> set to Active SFC____ >>>>>>>> OAM (TBA1) MUST be identified and reported as an >>>>>>>> erroneous____ >>>>>>>> combination. An implementation MAY have control >>>>>>>> to enable____ >>>>>>>> processing of the OAM payload.____ >>>>>>>> ____ >>>>>>>> …FB: Just cosmetic, but it would be good to stay with >>>>>>>> the pattern of “condition: action” of this paragraph, >>>>>>>> e.g.____ >>>>>>>> ____ >>>>>>>> * O but is clear andthe "Next Protocol" field is set to >>>>>>>> Active SFC____ >>>>>>>> OAM (TBA1):____ >>>>>>>> ____ >>>>>>>> - Erroneous combination. The combination MUST be >>>>>>>> identified and reported. >>>>>>>> >>>>>>>> >>>>>>>> ____ >>>>>>>> In addition, what would be good, is to expand a bit on >>>>>>>> how that reporting is supposed to happen – as well as >>>>>>>> what is supposed to happen with the packet that contains >>>>>>>> the erroneous combination. Is it going to be forwarded >>>>>>>> or dropped? Is the node detecting the error supposed to >>>>>>>> remove the active IOAM header, etc., …?____ >>>>>>>> ____ >>>>>>>> Thanks again, Frank____ >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> I hope that the proposed update addresses your >>>>>>>> concern.____ >>>>>>>> ____ >>>>>>>> Regards,____ >>>>>>>> Greg____ >>>>>>>> ____ >>>>>>>> On Mon, Nov 22, 2021 at 11:56 AM Frank Brockners >>>>>>>> (fbrockne) <fbrockne@cisco.com >>>>>>>> <mailto:fbrockne@cisco.com> >>>>>>>> <mailto:fbrockne@cisco.com >>>>>>>> <mailto:fbrockne@cisco.com>>> wrote:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Just saw this thread – and the section on the O-bit >>>>>>>> in section 4 caught might attention.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> * O bit is clear, and the "Next Protocol" field >>>>>>>> identifies active or____ >>>>>>>> >>>>>>>> hybrid OAM protocol MUST be identified and >>>>>>>> reported as an____ >>>>>>>> >>>>>>>> erroneous combination. An implementation MAY >>>>>>>> have control to____ >>>>>>>> >>>>>>>> enable processing of the OAM payload.____ >>>>>>>> >>>>>>>> Per what is mentioned below, the statement >>>>>>>> contradicts the principles of IOAM operation. A >>>>>>>> packet with O-bit cleared can very well have a >>>>>>>> hybrid OAM protocol in the next protocol field. IOAM >>>>>>>> is classified as a “Hybrid Type I” protocol per RFC >>>>>>>> 7799. >>>>>>>> A key objective of IOAM is to trace packets through >>>>>>>> the network as if they weren’t observed, i.e., the >>>>>>>> packet forwarding operation of a packet with IOAM is >>>>>>>> expected to be that of a plain packet, i.e., a >>>>>>>> packet without IOAM. Consequently, >>>>>>>> draft-ietf-sfc-ioam-nsh states clearly that the >>>>>>>> O-bit isn’t changed when IOAM is added to an >>>>>>>> NSH-tagged >>>>>>>> packet:https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2> >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>>____ >>>>>>>> ____ >>>>>>>> I’d strongly suggest to re-word section 4 to either >>>>>>>> avoid the reference to “hybrid IOAM” entirely, or to >>>>>>>> explicitly list which hybrid OAM approaches the >>>>>>>> section applies to – and that way ensure, that IOAM >>>>>>>> is not affected. An even simpler approach would be – >>>>>>>> as discussed below – so simply avoid the >>>>>>>> redefinition of the O-Bit.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> Thanks, Frank____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> *From:*sfc <sfc-bounces@ietf.org >>>>>>>> <mailto:sfc-bounces@ietf.org> >>>>>>>> <mailto:sfc-bounces@ietf.org >>>>>>>> <mailto:sfc-bounces@ietf.org>>>*On Behalf Of*Carlos >>>>>>>> Pignataro (cpignata) >>>>>>>> *Sent:*Monday, 22 November 2021 00:52 >>>>>>>> *To:*Gyan Mishra <hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com> >>>>>>>> <mailto:hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com>>> >>>>>>>> *Cc:*James N Guichard >>>>>>>> <james.n.guichard@futurewei.com >>>>>>>> <mailto:james.n.guichard@futurewei.com> >>>>>>>> <mailto:james.n.guichard@futurewei.com >>>>>>>> <mailto:james.n.guichard@futurewei.com>>>; Greg >>>>>>>> Mirsky <gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com> >>>>>>>> <mailto:gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com>>>;sfc@ietf.org <mailto:sfc@ietf.org> >>>>>>>> <mailto:sfc@ietf.org <mailto:sfc@ietf.org>>; Joel >>>>>>>> Halpern Direct >>>>>>>> <jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com> >>>>>>>> <mailto:jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com>>> >>>>>>>> *Subject:*Re: [sfc] Regarding last call for >>>>>>>> draft-ietf-sfc-multi-layer-oam____ >>>>>>>> ____ >>>>>>>> Hi, Gyan,____ >>>>>>>> ____ >>>>>>>> Thank you for your response!____ >>>>>>>> ____ >>>>>>>> On #1, I recall LIME (I co-chaired), but there’s no >>>>>>>> “LIME” reference in draft-ietf-sfc-multi-layer-oam, >>>>>>>> not I see the relationship. The draft you quote on >>>>>>>> https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02> >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>> >>>>>>>> seems >>>>>>>> to have expired many years ago. ____ >>>>>>>> ____ >>>>>>>> Further, Greg Mirsky wrote that it was for >>>>>>>> “Historical” reasons. Which one is it?____ >>>>>>>> ____ >>>>>>>> On #2, thanks for suggesting that section to be >>>>>>>> added. I agree.____ >>>>>>>> ____ >>>>>>>> On #3, thanks for the description of the various >>>>>>>> sections of draft-ietf-sfc-multi-layer-oam.____ >>>>>>>> ____ >>>>>>>> For the record I still do not see how foundational >>>>>>>> changes like the O-bit redefinition are needed.____ >>>>>>>> While you write that "trace an SFP” is a new >>>>>>>> functionality, there’s open source running code I-D >>>>>>>> documented tools which do that.____ >>>>>>>> ____ >>>>>>>> Best,____ >>>>>>>> ____ >>>>>>>> Carlos.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 11/20/21午前10:36、Gyan Mishra >>>>>>>> <hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com> >>>>>>>> <mailto:hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com>>>のメール:____ >>>>>>>> ____ >>>>>>>> Hi Carlos____ >>>>>>>> ____ >>>>>>>> Many Thanks for your feedback____ >>>>>>>> ____ >>>>>>>> Responses in-line____ >>>>>>>> ____ >>>>>>>> On Fri, Nov 19, 2021 at 11:39 PM Carlos >>>>>>>> Pignataro (cpignata) <cpignata@cisco.com >>>>>>>> <mailto:cpignata@cisco.com> >>>>>>>> <mailto:cpignata@cisco.com >>>>>>>> <mailto:cpignata@cisco.com>>> wrote:____ >>>>>>>> >>>>>>>> Dear Gyan,____ >>>>>>>> ____ >>>>>>>> I hope all is well!____ >>>>>>>> ____ >>>>>>>> Could I please ask three short clarifying >>>>>>>> questions, follow-ons on your statement >>>>>>>> below?____ >>>>>>>> ____ >>>>>>>> 1. When you write "/with an >>>>>>>> Active Multi layer OAM model/”, can you >>>>>>>> please explain what exactly is “Multi layer” >>>>>>>> about this “OAM model”, and why is >>>>>>>> important? You highlight it in your top-post >>>>>>>> but I cannot find that text in the draft.____ >>>>>>>> ____ >>>>>>>> When I asked your co-author Greg Mirsky, he >>>>>>>> said:____ >>>>>>>> >>>>>>>> Additionally, I wonder: Why the file >>>>>>>> name “sfc-multi-layer-oam”?____ >>>>>>>> >>>>>>>> GIM>> It is historical. ____ >>>>>>>> >>>>>>>> OAM has historic connotations but for good >>>>>>>> technical reasons as called multi layer as >>>>>>>> it provides a different job of managing >>>>>>>> different layers of the network thus the >>>>>>>> nomenclature “multi layer”____ >>>>>>>> >>>>>>>> ____ >>>>>>>> We can add some verbiage to the draft as we have >>>>>>>> the draft and file name with “multi layer” in >>>>>>>> the name.____ >>>>>>>> ____ >>>>>>>> LIME is a concluded WG on OAM that has discuss >>>>>>>> the OAM management of the various layers of the >>>>>>>> network.____ >>>>>>>> ____ >>>>>>>> https://datatracker.ietf.org/wg/lime/about/ >>>>>>>> <https://datatracker.ietf.org/wg/lime/about/> >>>>>>>> <https://datatracker.ietf.org/wg/lime/about/ >>>>>>>> <https://datatracker.ietf.org/wg/lime/about/>>____ >>>>>>>> ____ >>>>>>>> OPSWG has this draft which hones in on the multi >>>>>>>> layer OAM aspects of PM and Fault management of >>>>>>>> SFC. ____ >>>>>>>> https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02> >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>>____ >>>>>>>> ____ >>>>>>>> This draft talks about a transport independent >>>>>>>> OAM where OAM mechanisms are data plane >>>>>>>> transport dependent thus the concept of multi >>>>>>>> layer OAM requirements of multiple discrete >>>>>>>> layers of OAM to map to each layer of the >>>>>>>> network. This document also talks about E2E OAM >>>>>>>> inter layer OAM considerations in SFC as the >>>>>>>> fault may occur with the service functions at >>>>>>>> different OSI layers being chained and different >>>>>>>> network layers.____ >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> 2. When you write "/fills a crucial gap for >>>>>>>> operators/”, are you aware of interoperable >>>>>>>> implementations (which I expect is what >>>>>>>> operators need for it to be useful in an >>>>>>>> actual deployment)? Perhaps an RFC 7942 >>>>>>>> "Implementation Status” section could be >>>>>>>> added?____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Gyan> I am not aware of any implementations >>>>>>>> however Ican review with the authors on adding >>>>>>>> the section. Thank you____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> 3. When you write “/for >>>>>>>> new OAM functionality/”, could you please >>>>>>>> clearly describe or explicitly enumerate the >>>>>>>> specific *new* functionality you refer to, >>>>>>>> on top of what existing OAMs provide, and >>>>>>>> how you find that crucial, specifically?____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Troubleshooting SFC is a complex tax for >>>>>>>> operators and having additional OAM capabilities >>>>>>>> that can provide value to operators in E2E SFC >>>>>>>> troubleshooting is a major gain for >>>>>>>> operators.____ >>>>>>>> ____ >>>>>>>> RFC 8924 defines the base specification for SFC >>>>>>>> OAM, requirements analysis and generically >>>>>>>> existing OAM mechanisms used at various layers >>>>>>>> and how they can apply to SFC defined in >>>>>>>> section 7. ____ >>>>>>>> ____ >>>>>>>> This draft provides a comprehensive SFC OAM >>>>>>>> solution and takes the base SFC OAM RFC 8924 and >>>>>>>> existing network layer mechanisms and applies >>>>>>>> them to SFC OAM localized SFC fault isolation >>>>>>>> with a new Active OAM header, Authenticated >>>>>>>> Echo Request/Reply message and Source TLV. ____ >>>>>>>> ____ >>>>>>>> The new functionality in this draft is defining >>>>>>>> a new procedure for Active OAM message on RSP >>>>>>>> in NSH updating NSH RFC 8300 definition of the O >>>>>>>> bit which indicates an OAM command and/or data >>>>>>>> in NSH header or packet payload discussed in >>>>>>>> section 4. ____ >>>>>>>> ____ >>>>>>>> Section 5 talks about the issue related to >>>>>>>> additional IP/UDP headers in an IPv6 network >>>>>>>> adds noticeable overhead and this draft defines >>>>>>>> a new active OAM header to demultiplex Active >>>>>>>> OAM protocols on an SFC.____ >>>>>>>> ____ >>>>>>>> Section 6 defines a new Active OAM based >>>>>>>> Authenticated Echo Request/Reply message for >>>>>>>> SFC that addresses additional requirements, fate >>>>>>>> sharing, monitoring of continuity between SFPs, >>>>>>>> RDI by ingress to egress, connectivity >>>>>>>> verification, fault localization and tracing to >>>>>>>> discover RSP and finally on-demand FM with >>>>>>>> response back to initiator. ____ >>>>>>>> ____ >>>>>>>> This draft also provides OAM integrity check >>>>>>>> with authentication of request/reply message in >>>>>>>> conjunction with use of source TLV to prevent >>>>>>>> DDOS attack vector with SFC OAM.____ >>>>>>>> ____ >>>>>>>> The critical new functionality provided for >>>>>>>> operators with Active OAM is the honed in focus >>>>>>>> on troubleshooting continuity of an SFP, trace >>>>>>>> an SFP , consistency verification of SFP and >>>>>>>> fault isolation and localizing of a failure >>>>>>>> within an SFP as well as valuable SFF record >>>>>>>> TLV, SFF information TLV/Sub-TLV for multiple >>>>>>>> SFs as hops of SFP or multiple SFs for load >>>>>>>> balancing using SFP consistency verification >>>>>>>> procedures.____ >>>>>>>> ____ >>>>>>>> Many Thanks!!____ >>>>>>>> ____ >>>>>>>> Gyan____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> Many thanks in advance, I am just trying to >>>>>>>> understand.____ >>>>>>>> ____ >>>>>>>> Best,____ >>>>>>>> ____ >>>>>>>> Carlos.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 11/19/21午後11:02、Gyan Mishra >>>>>>>> <hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com> >>>>>>>> <mailto:hayabusagsm@gmail.com >>>>>>>> <mailto:hayabusagsm@gmail.com>>>のメール:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> Dear Chairs & All ____ >>>>>>>> ____ >>>>>>>> As co-author I support publication of >>>>>>>> this draft. ____ >>>>>>>> ____ >>>>>>>> This specification fills a crucial gap >>>>>>>> for operators for new OAM functionality, >>>>>>>> with an Active Multi layer OAM model, by >>>>>>>> defining extensibility with >>>>>>>> Active OAM messages, in NSH, to >>>>>>>> troubleshoot faults in the data >>>>>>>> plane SFC forwarding plane, SFP E2E path >>>>>>>> in the service plane framework.____ >>>>>>>> ____ >>>>>>>> Kind Regards ____ >>>>>>>> ____ >>>>>>>> Gyan____ >>>>>>>> Verizon ____ >>>>>>>> ____ >>>>>>>> On Fri, Nov 19, 2021 at 8:33 PM Carlos >>>>>>>> Pignataro (cpignata) >>>>>>>> <cpignata=40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:cpignata=40cisco.com@dmarc.ietf.org> >>>>>>>> <mailto:40cisco.com@dmarc.ietf.org >>>>>>>> <mailto:40cisco.com@dmarc.ietf.org>>> >>>>>>>> wrote:____ >>>>>>>> >>>>>>>> Dear Greg,____ >>>>>>>> ____ >>>>>>>> Thank you for replying to my email. >>>>>>>> Please find a couple follow-ups >>>>>>>> inline, as I invite other WG >>>>>>>> interested parties to the >>>>>>>> discussion.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 11/19/21午後7:11、Greg Mirsky >>>>>>>> <gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com> >>>>>>>> <mailto:gregimirsky@gmail.com >>>>>>>> <mailto:gregimirsky@gmail.com>>> >>>>>>>> のメール:____ >>>>>>>> ____ >>>>>>>> Dear Carlos,____ >>>>>>>> thank you for your >>>>>>>> thorough review and detailed >>>>>>>> comments. Please find responses >>>>>>>> in-lined below under the GIM>> >>>>>>>> tag.____ >>>>>>>> ____ >>>>>>>> Regards,____ >>>>>>>> Greg (on behalf of the >>>>>>>> authors)____ >>>>>>>> ____ >>>>>>>> On Sat, Nov 13, 2021 at 11:50 PM >>>>>>>> Carlos Pignataro (cpignata) >>>>>>>> <cpignata@cisco.com >>>>>>>> <mailto:cpignata@cisco.com> >>>>>>>> <mailto:cpignata@cisco.com >>>>>>>> <mailto:cpignata@cisco.com>>> >>>>>>>> wrote:____ >>>>>>>> >>>>>>>> Hello, WG,____ >>>>>>>> ____ >>>>>>>> In >>>>>>>> reviewing >>>>>>>> draft-ietf-sfc-multi-layer-oam-16, >>>>>>>> I find that the issues >>>>>>>> listed below are such that I >>>>>>>> cannot support >>>>>>>> publication.____ >>>>>>>> ____ >>>>>>>> Observing what appears to be >>>>>>>> a single non-author response >>>>>>>> to the original WGLC email, >>>>>>>> and one more after this >>>>>>>> extension, I also perceive >>>>>>>> the energy level to work on >>>>>>>> this to be low.____ >>>>>>>> ____ >>>>>>>> Please find some review >>>>>>>> comments and observations, I >>>>>>>> hope these are useful:____ >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> Active OAM >>>>>>>> for Service Function >>>>>>>> Chaining____ >>>>>>>> >>>>>>>> draft-ietf-sfc-multi-layer-oam-16____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Abstract____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> A set of requirements for >>>>>>>> active Operation, >>>>>>>> Administration, and____ >>>>>>>> >>>>>>>> Maintenance (OAM) of >>>>>>>> Service Function Chains >>>>>>>> (SFCs) in a network is____ >>>>>>>> >>>>>>>> presented in this >>>>>>>> document. Based on these >>>>>>>> requirements, an____ >>>>>>>> >>>>>>>> encapsulation of active >>>>>>>> OAM messages in SFC and a >>>>>>>> mechanism to detect____ >>>>>>>> >>>>>>>> and localize defects are >>>>>>>> described.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> First, a generic comment on >>>>>>>> the whole document: Even >>>>>>>> though the WG produces an >>>>>>>> SFC OAM framework >>>>>>>> in rfc8924, I cannot find >>>>>>>> exactly how >>>>>>>> draft-ietf-sfc-multi-layer-oam >>>>>>>> follows or maps to such >>>>>>>> framework.____ >>>>>>>> >>>>>>>> * rfc8924 lists >>>>>>>> requirements in S4, but >>>>>>>> this document mentions >>>>>>>> them in >>>>>>>> passing. Instead, as per >>>>>>>> the Abstract above, this >>>>>>>> document creates new >>>>>>>> requirements and based >>>>>>>> on them creates a new >>>>>>>> OAM protocol.____ >>>>>>>> >>>>>>>> GIM>> We've followed the >>>>>>>> requirements listed in RFC 8924 >>>>>>>> and used them when designing SFC >>>>>>>> Echo Request/Reply. SFC Echo >>>>>>>> Request/Reply addresses the >>>>>>>> essential requirements in >>>>>>>> Section 4 of RFC 8924.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: That’s an issue, those are not >>>>>>>> requirements for a new protocol. >>>>>>>> Neither for a single protocol to >>>>>>>> perform all functions.____ >>>>>>>> ____ >>>>>>>> CMP: Specifically, RFC 8924 says:____ >>>>>>>> ____ >>>>>>>> >>>>>>>> CMP: “7. Candidate SFC OAM >>>>>>>> Tools”____ >>>>>>>> >>>>>>>> CMP: Why were candidates descarted? >>>>>>>> When it is shown how they can >>>>>>>> address some of the functions.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> * rfc8924 lists candidate >>>>>>>> SFC OAM tools, but this >>>>>>>> document does not >>>>>>>> consider them. Or >>>>>>>> compare requirements to >>>>>>>> options. Perhaps I could >>>>>>>> be pointed to the >>>>>>>> discussion on the >>>>>>>> list?____ >>>>>>>> >>>>>>>> GIM>> RFC 8924 already provides >>>>>>>> the analysis and pointed out >>>>>>>> gaps in listed protocols. RFC >>>>>>>> 8924 has concluded that none of >>>>>>>> the available tools complies >>>>>>>> with the requirements. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: I do not see that conclusion in >>>>>>>> RFC 8924, perhaps you can quote / >>>>>>>> copy/paste the relevant text. The >>>>>>>> specific text that includes a >>>>>>>> conclusion. And specific text that >>>>>>>> says that none of the tools comply >>>>>>>> with the requirements.____ >>>>>>>> ____ >>>>>>>> CMP: In any case, there is also no >>>>>>>> implication that creating a new >>>>>>>> protocol for all requirements and >>>>>>>> ignoring the analysis of existing >>>>>>>> protocols that can be used or >>>>>>>> extended is in the best interest of >>>>>>>> SFC’s OAM.____ >>>>>>>> ____ >>>>>>>> CMP: Additionally, I did not see the >>>>>>>> discussion on the list of this >>>>>>>> comparison (since it does not exist >>>>>>>> in the draft).____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Additionally, I wonder: Why >>>>>>>> the file name >>>>>>>> “sfc-multi-layer-oam”?____ >>>>>>>> >>>>>>>> GIM>> It is historical. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> Active OAM tools,____ >>>>>>>> >>>>>>>> conformant to the >>>>>>>> requirements listed in >>>>>>>> Section 3, improve, for____ >>>>>>>> >>>>>>>> example, troubleshooting >>>>>>>> efficiency and defect >>>>>>>> localization in SFP____ >>>>>>>> >>>>>>>> because they specifically >>>>>>>> address the architectural >>>>>>>> principles of____ >>>>>>>> >>>>>>>> NSH. For that purpose, >>>>>>>> SFC Echo Request and Echo >>>>>>>> Reply are specified____ >>>>>>>> >>>>>>>> in Section 6.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> I do not fully follow these >>>>>>>> cause-consequence pair of >>>>>>>> sentences. They seem to be >>>>>>>> foundational to the rational >>>>>>>> of the document, is this why >>>>>>>> a new OAM protocol is >>>>>>>> used?____ >>>>>>>> >>>>>>>> GIM>> Indeed. Based on the >>>>>>>> analysis in RFC 8924, we've >>>>>>>> learned that none of the >>>>>>>> available OAM tools can address >>>>>>>> the requirements for active SFP >>>>>>>> OAM. The SFC Echo Request/Reply >>>>>>>> is specifically designed to >>>>>>>> address these requirements.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: This is a very useful response. >>>>>>>> As I responded above, there’s no >>>>>>>> implication that if no existing >>>>>>>> tools address all requirements, the >>>>>>>> path is to create a brand new one >>>>>>>> ignoring the existing ones.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Specifically, I feel this >>>>>>>> document over-reaches in >>>>>>>> that it presumes that the >>>>>>>> only “Active OAM” protocol >>>>>>>> for NSH SFCs is this new >>>>>>>> protocol, whereas some of >>>>>>>> the existing protocols >>>>>>>> listed in rfc8924 are also >>>>>>>> “Active OAM”.____ >>>>>>>> >>>>>>>> GIM>> I think that the document >>>>>>>> is positioned not as a general >>>>>>>> active OAM protocol but as one >>>>>>>> of the active SFC NSH OAM >>>>>>>> protocols.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> This mechanism enables >>>>>>>> on-demand Continuity >>>>>>>> Check,____ >>>>>>>> >>>>>>>> Connectivity >>>>>>>> Verification, among other >>>>>>>> operations over SFC in____ >>>>>>>> >>>>>>>> networks, addresses >>>>>>>> functionalities discussed in >>>>>>>> Sections 4.1, 4.2,____ >>>>>>>> >>>>>>>> and 4.3 of [RFC8924].____ >>>>>>>> >>>>>>>> ____ >>>>>>>> This could be well the case >>>>>>>> — however many others >>>>>>>> (including existing) >>>>>>>> mechanisms also enable in >>>>>>>> these broad terms all the >>>>>>>> connectivity+continuity+trace >>>>>>>> functions.____ >>>>>>>> >>>>>>>> GIM>> We are not questioning >>>>>>>> that there are other solutions. >>>>>>>> But these mechanisms are not >>>>>>>> supported by specifications that >>>>>>>> ensure independent interoperable >>>>>>>> implementations. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Can you please point to >>>>>>>> independent interoperable >>>>>>>> implementations >>>>>>>> of >>>>>>>> draft-ietf-sfc-multi-layer-oam?____ >>>>>>>> ____ >>>>>>>> CMP: Part of my point is that any >>>>>>>> partial solution can be extended >>>>>>>> interoperably.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> At the same time, this >>>>>>>> mechanisms is very >>>>>>>> complex. ____ >>>>>>>> I would like to see a study >>>>>>>> of comparative benefits of >>>>>>>> this added complexity >>>>>>>> vis-a-vis existing >>>>>>>> approaches that can be >>>>>>>> extended.____ >>>>>>>> >>>>>>>> GIM>> In the face of absence of >>>>>>>> sufficient and up to date >>>>>>>> documentation describing >>>>>>>> proprietary solutions, I don't >>>>>>>> see that any comparison can be >>>>>>>> comprehensive.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: I am not sure if you are >>>>>>>> answering a different question, but >>>>>>>> there’s no reference to any >>>>>>>> proprietary solutions.____ >>>>>>>> ____ >>>>>>>> CMP: ICMP, BFD, iOAM, >>>>>>>> SFC-Tracceroute, all documented in >>>>>>>> I-Ds and with open source >>>>>>>> implementations.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> The ingress may be____ >>>>>>>> >>>>>>>> capable of recovering >>>>>>>> from the failure, e.g., >>>>>>>> using redundant SFC____ >>>>>>>> >>>>>>>> elements. Thus, it is >>>>>>>> beneficial for the egress to >>>>>>>> signal the new____ >>>>>>>> >>>>>>>> defect state to the >>>>>>>> ingress, which in this >>>>>>>> example is the >>>>>>>> Classifier.____ >>>>>>>> >>>>>>>> Hence the following >>>>>>>> requirement:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> REQ#3: SFC OAM MUST >>>>>>>> support Remote Defect >>>>>>>> Indication notification____ >>>>>>>> >>>>>>>> by the egress to the >>>>>>>> ingress.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> I see a gap between “it is >>>>>>>> beneficial” and “MUST”. What >>>>>>>> is "Remote Defect >>>>>>>> Indication” in the context >>>>>>>> of SFC OAM since it is not >>>>>>>> in the OAM framework? Is >>>>>>>> this "Remote Defect >>>>>>>> Indication” the only way to >>>>>>>> achieve the rerouting or >>>>>>>> redundancy triggering?____ >>>>>>>> >>>>>>>> GIM>> That is one of possible >>>>>>>> solutions. Other mechanisms may >>>>>>>> conform to the requirement using >>>>>>>> different approach. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> 4. Active OAM >>>>>>>> Identification in the NSH____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> The O bit in the NSH is >>>>>>>> defined in [RFC8300] as >>>>>>>> follows:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> O bit: Setting this >>>>>>>> bit indicates an OAM >>>>>>>> packet.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> This document updates >>>>>>>> that definition as >>>>>>>> follows:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> O bit: Setting this >>>>>>>> bit indicates an OAM command >>>>>>>> and/or data in____ >>>>>>>> >>>>>>>> the NSH Context Header >>>>>>>> or packet payload.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Active SFC OAM is defined >>>>>>>> as a combination of OAM >>>>>>>> commands and/or____ >>>>>>>> >>>>>>>> data included in a >>>>>>>> message that immediately >>>>>>>> follows the NSH. To____ >>>>>>>> >>>>>>>> identify the active OAM >>>>>>>> message, the "Next Protocol" >>>>>>>> field MUST be____ >>>>>>>> >>>>>>>> set to Active SFC OAM >>>>>>>> (TBA1) (Section 9.1). ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> This is an example of >>>>>>>> over-reach. A “Next >>>>>>>> Protocol” pointing to IPv4, >>>>>>>> in turn pointing to ICMP, in >>>>>>>> turn pointing to Echo is >>>>>>>> already one example of >>>>>>>> “Active SFC OAM”. I wonder >>>>>>>> if this new protocol might >>>>>>>> be best served by choosing a >>>>>>>> name that is not so generic? >>>>>>>> It could be called “One of >>>>>>>> many active SFC OAM >>>>>>>> protocols” :-) ____ >>>>>>>> >>>>>>>> GIM>> Will clarify that >>>>>>>> throughout the document "active >>>>>>>> OAM" and "active SFC OAM" refers >>>>>>>> to specially constructed packets >>>>>>>> that immediately follow the SFC >>>>>>>> Active OAM Header (Figure 2).____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: The “SFC Active OAM Header” is >>>>>>>> therefore not part of the “active >>>>>>>> SFC OAM” packet?____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Otherwise, the “MUST” in the >>>>>>>> last sentence seems to not >>>>>>>> follow.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> The rules for____ >>>>>>>> >>>>>>>> interpreting the values >>>>>>>> of the O bit and the "Next >>>>>>>> Protocol" field____ >>>>>>>> >>>>>>>> are as follows:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> I am extremely concerned >>>>>>>> about this attempted >>>>>>>> re-definition (of the O-bit >>>>>>>> and Protocol fields). On >>>>>>>> several fronts as explained >>>>>>>> below. During RFC8300 the WG >>>>>>>> evaluated these and provided >>>>>>>> a solution already.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> * O bit set and the >>>>>>>> "Next Protocol" value does >>>>>>>> not match one of____ >>>>>>>> >>>>>>>> identifying active or >>>>>>>> hybrid OAM protocols (per >>>>>>>> classification____ >>>>>>>> >>>>>>>> defined in [RFC7799]), >>>>>>>> e.g., defined in Section 9.1 >>>>>>>> Active SFC OAM____ >>>>>>>> >>>>>>>> (TBA1).____ >>>>>>>> >>>>>>>> This potentially breaks the >>>>>>>> concept of nodes not >>>>>>>> understanding OAM (i.e,. >>>>>>>> Partial deployment of a new >>>>>>>> protocol)____ >>>>>>>> >>>>>>>> GIM>> Can you clarify what do >>>>>>>> you mean by "nodes not >>>>>>>> understanding OAM"? Partial >>>>>>>> deployment is, in my opinion, an >>>>>>>> operational issue. An operator >>>>>>>> plans deployments of new >>>>>>>> releases according to new >>>>>>>> features and their intended >>>>>>>> use.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Apologies, I meant not >>>>>>>> s/understanding/parsing/.____ >>>>>>>> ____ >>>>>>>> CMP: I agree it is an operational >>>>>>>> issue — an issue of operations. Like >>>>>>>> the “O” in “OAM”. Should Operational >>>>>>>> Considerations be included as >>>>>>>> well?____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> - a Fixed-Length >>>>>>>> Context Header or >>>>>>>> Variable-Length Context____ >>>>>>>> >>>>>>>> Header(s) contain >>>>>>>> an OAM command or data.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> - the "Next >>>>>>>> Protocol" field determines >>>>>>>> the type of payload.____ >>>>>>>> >>>>>>>> The semantic of Context >>>>>>>> Headers is outside this >>>>>>>> definition. For example the >>>>>>>> types in MD Type 2 define >>>>>>>> the variable headers. ____ >>>>>>>> ____ >>>>>>>> This potentially breaks also >>>>>>>> OAM, since things like ECMP >>>>>>>> can be encoded in context >>>>>>>> headers that the OAM needs. >>>>>>>> (e.g., "Flow ID” >>>>>>>> from >>>>>>>> draft-ietf-sfc-nsh-tlv).____ >>>>>>>> >>>>>>>> GIM>> As I understand it, MD >>>>>>>> Type 2 Flow ID TLV is >>>>>>>> recommended to identify a flow >>>>>>>> in SFC NSH. The document makes >>>>>>>> the use of this method. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: How?____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Further, is this describing >>>>>>>> a Hybrid OAM use?____ >>>>>>>> >>>>>>>> GIM>> No, the document does not >>>>>>>> describe the use of hybrid OAM >>>>>>>> (per RFC 7799). ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> * O bit set and the >>>>>>>> "Next Protocol" value >>>>>>>> matches one of >>>>>>>> identifying____ >>>>>>>> >>>>>>>> active or hybrid OAM >>>>>>>> protocols:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> - the payload that >>>>>>>> immediately follows the NSH >>>>>>>> MUST contain an____ >>>>>>>> >>>>>>>> OAM command or >>>>>>>> data.____ >>>>>>>> >>>>>>>> This is also unclear — what >>>>>>>> is an OAM command or data? >>>>>>>> If the O-bit is set, it is >>>>>>>> an OAM packet.____ >>>>>>>> >>>>>>>> GIM>> What is an OAM packet? Is >>>>>>>> an SFC NSH packet with IOAM an >>>>>>>> OAM packet or not? If an SFC NSH >>>>>>>> packet is part of flow under the >>>>>>>> Alternate Marking, is it an OAM >>>>>>>> packet because the Alternate >>>>>>>> Marking method is an example of >>>>>>>> the hybrid OAM? ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: This reads like not answering >>>>>>>> by asking questions. ____ >>>>>>>> ____ >>>>>>>> CMP: A user packet with marking, >>>>>>>> implicitly or explicitly, is not an >>>>>>>> OAM packet.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> * O bit is clear:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> - no OAM in a >>>>>>>> Fixed-Length Context Header >>>>>>>> or Variable-Length____ >>>>>>>> >>>>>>>> Context >>>>>>>> Header(s).____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> - the payload >>>>>>>> determined by the "Next >>>>>>>> Protocol" field MUST be____ >>>>>>>> >>>>>>>> present.____ >>>>>>>> >>>>>>>> It is unclear the rational >>>>>>>> for this.____ >>>>>>>> >>>>>>>> GIM>> Can you please clarify >>>>>>>> your interpretation, so we can >>>>>>>> look for ways to improve the >>>>>>>> text?____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Same as above. It is unclear >>>>>>>> why these rules. It is not a matter >>>>>>>> of interpretation.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> * O bit is clear, and >>>>>>>> the "Next Protocol" field >>>>>>>> identifies active or____ >>>>>>>> >>>>>>>> hybrid OAM protocol >>>>>>>> MUST be identified and >>>>>>>> reported as an____ >>>>>>>> >>>>>>>> erroneous >>>>>>>> combination. An >>>>>>>> implementation MAY have >>>>>>>> control to____ >>>>>>>> >>>>>>>> enable processing of >>>>>>>> the OAM payload.____ >>>>>>>> >>>>>>>> This seems to break the >>>>>>>> existing usage >>>>>>>> in draft-ietf-sfc-ioam-nsh. >>>>>>>> Section 4.2 >>>>>>>> of draft-ietf-sfc-ioam-nsh >>>>>>>> says clearly:____ >>>>>>>> >>>>>>>> GIM>> I don't see any problem. >>>>>>>> In fact, both definitions are in >>>>>>>> sync. According to >>>>>>>> draft-ietf-sfc-ioam-nsh if the >>>>>>>> Next Protocol field identifies a >>>>>>>> use data payload, e.g., IPv6, >>>>>>>> then O bit MUST NOT be set. If >>>>>>>> the Next Protocol is set to >>>>>>>> IOAM, then the O-bit MUST be >>>>>>>> set.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Sorry, but you do not seem to >>>>>>>> be actually reading >>>>>>>> draft-ietf-sfc-ioam-nsh. Please >>>>>>>> refer to:____ >>>>>>>> ____ >>>>>>>> CMP: >>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2> >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>>____ >>>>>>>> ____ >>>>>>>> CMP: 4.2. IOAM and the use of the >>>>>>>> NSH O-bit____ >>>>>>>> [RFC8300] defines an "O bit" for >>>>>>>> OAM packets. Per [RFC8300] the O____ >>>>>>>> bit must be set for OAM packets >>>>>>>> and must not be set for non-OAM____ >>>>>>>> packets. Packets with IOAM data >>>>>>>> included MUST follow this____ >>>>>>>> definition, i.e. the O bit MUST >>>>>>>> NOT be set for regular customer____ >>>>>>>> traffic which also carries IOAM >>>>>>>> data and the O bit MUST be set >>>>>>>> for____ >>>>>>>> OAM packets which carry only IOAM >>>>>>>> data without any regular data____ >>>>>>>> payload.____ >>>>>>>> >>>>>>>> CMP: Please note the “MUST NOT” in >>>>>>>> the paragraph immediately above.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> We agree in how O-bit works in >>>>>>>> presence of IOAM that >>>>>>>> accompanies user data and >>>>>>>> without it.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: I do not see that agreement.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 4.2. IOAM and the use of >>>>>>>> the NSH O-bit____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> [RFC8300] defines an "O >>>>>>>> bit" for OAM packets. Per >>>>>>>> [RFC8300] the O____ >>>>>>>> >>>>>>>> bit must be set for OAM >>>>>>>> packets and must not be set >>>>>>>> for non-OAM____ >>>>>>>> >>>>>>>> packets. Packets with >>>>>>>> IOAM data included MUST >>>>>>>> follow this____ >>>>>>>> >>>>>>>> definition, i.e. the O >>>>>>>> bit MUST NOT be set for >>>>>>>> regular customer____ >>>>>>>> >>>>>>>> traffic which also >>>>>>>> carries IOAM data and the O >>>>>>>> bit MUST be set for____ >>>>>>>> >>>>>>>> OAM packets which carry >>>>>>>> only IOAM data without any >>>>>>>> regular data____ >>>>>>>> >>>>>>>> payload.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> 5. Active SFC OAM Header____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> As demonstrated in >>>>>>>> Section 4 [RFC8924] and >>>>>>>> Section 3 of this____ >>>>>>>> >>>>>>>> document, SFC OAM is >>>>>>>> required to perform multiple >>>>>>>> tasks. Several____ >>>>>>>> >>>>>>>> active OAM protocols >>>>>>>> could be used to address all >>>>>>>> the requirements.____ >>>>>>>> >>>>>>>> When IP/UDP encapsulation >>>>>>>> of an SFC OAM control >>>>>>>> message is used,____ >>>>>>>> >>>>>>>> protocols can be >>>>>>>> demultiplexed using the >>>>>>>> destination UDP port >>>>>>>> number.____ >>>>>>>> >>>>>>>> But extra IP/UDP headers, >>>>>>>> especially in an IPv6 >>>>>>>> network, add____ >>>>>>>> >>>>>>>> noticeable overhead. >>>>>>>> This document defines Active >>>>>>>> OAM Header____ >>>>>>>> >>>>>>>> (Figure 2) to demultiplex >>>>>>>> active OAM protocols on >>>>>>>> an SFC.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Does this paragraph imply >>>>>>>> that the main reason for >>>>>>>> this protocol is this >>>>>>>> perceived overhead? If so, >>>>>>>> experience seems to show >>>>>>>> that in practice IP-encaped >>>>>>>> OAM works fine (as e.g., for >>>>>>>> LSP Ping). ____ >>>>>>>> >>>>>>>> GIM>> Isn't IP/UDP >>>>>>>> encapsulation, and IPv6 in >>>>>>>> particular, is a larger >>>>>>>> overhead? ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: I am sorry Greg to call this >>>>>>>> out, but you are choosing again to >>>>>>>> not answer the question and instead >>>>>>>> ask another one.____ >>>>>>>> ____ >>>>>>>> CMP: I am happy to answer: it is >>>>>>>> larger. It also does not matter. And >>>>>>>> further it is proven to work in LSP >>>>>>>> Ping.____ >>>>>>>> ____ >>>>>>>> CMP: My question again: is the whole >>>>>>>> purpose of this new protocol to be >>>>>>>> overhead efficient? I am sure there >>>>>>>> are ways of encasulating that are >>>>>>>> more overhead-efficient >>>>>>>> than >>>>>>>> draft-ietf-sfc-multi-layer-oam.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Alternatively, “Next >>>>>>>> Protocols” could be defined >>>>>>>> for “raw” existing >>>>>>>> protocols.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> Msg Type - six bits >>>>>>>> long field identifies OAM >>>>>>>> protocol, e.g., Echo____ >>>>>>>> >>>>>>>> Request/Reply or >>>>>>>> Bidirectional Forwarding >>>>>>>> Detection.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Why does BFD get >>>>>>>> encapsulated in this new >>>>>>>> protocol, as opposed to >>>>>>>> using a “Next Protocol” for >>>>>>>> it? That looks like >>>>>>>> unnecessary overhead and >>>>>>>> indirection.____ >>>>>>>> >>>>>>>> GIM>> Are you proposing >>>>>>>> assigning different Next >>>>>>>> Protocol values for every >>>>>>>> possible active OAM protocol? >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: I am not proposing anything. I >>>>>>>> am simply asking a question.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Flags - eight bits >>>>>>>> long field carries bit flags >>>>>>>> that define____ >>>>>>>> >>>>>>>> optional capability >>>>>>>> and thus processing of the >>>>>>>> SFC active OAM____ >>>>>>>> >>>>>>>> control packet, e.g., >>>>>>>> optional timestamping. ____ >>>>>>>> >>>>>>>> Does this timestamp conflict >>>>>>>> with context header >>>>>>>> timestamps? E.g., rfc8592 >>>>>>>> or >>>>>>>> draft-mymb-sfc-nsh-allocation-timestamp.____ >>>>>>>> >>>>>>>> GIM>> What do you see as a >>>>>>>> potential conflict? ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Two timestamps in different >>>>>>>> parts of a packet.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 6. Echo Request/Echo Reply >>>>>>>> for SFC____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Echo Request/Reply is a >>>>>>>> well-known active OAM >>>>>>>> mechanism extensively____ >>>>>>>> >>>>>>>> used to verify a path's >>>>>>>> continuity, detect >>>>>>>> inconsistencies between a____ >>>>>>>> >>>>>>>> state in control and the >>>>>>>> data planes, and localize >>>>>>>> defects in the____ >>>>>>>> >>>>>>>> data plane. ICMP >>>>>>>> ([RFC0792] for IPv4 and >>>>>>>> [RFC4443] for IPv6____ >>>>>>>> >>>>>>>> networks, respectively) >>>>>>>> and [RFC8029] are examples >>>>>>>> of broadly used____ >>>>>>>> >>>>>>>> active OAM protocols >>>>>>>> based on the Echo >>>>>>>> Request/Reply principle. >>>>>>>> The____ >>>>>>>> >>>>>>>> SFC Echo Request/Reply >>>>>>>> defined in this document >>>>>>>> addresses several____ >>>>>>>> >>>>>>>> requirements listed in >>>>>>>> Section 3. Specifically, it >>>>>>>> can be used to____ >>>>>>>> >>>>>>>> check the continuity of >>>>>>>> an SFP, trace an SFP, or >>>>>>>> localize the failure____ >>>>>>>> >>>>>>>> within an SFP. The SFC >>>>>>>> Echo Request/Reply control >>>>>>>> message format is____ >>>>>>>> >>>>>>>> presented in Figure 3.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> This seems to be an >>>>>>>> important paragraph — would >>>>>>>> be useful to also understand >>>>>>>> how other existing and >>>>>>>> broadly used protocols >>>>>>>> cannot fulfill >>>>>>>> requirements.____ >>>>>>>> >>>>>>>> GIM>> RFC 8924 already provided >>>>>>>> a comprehensive analysis and >>>>>>>> concluded that none of the >>>>>>>> available tools can fully >>>>>>>> conform to the requirements >>>>>>>> listed in Section 4. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: As per above, I do not see that >>>>>>>> conclusion.____ >>>>>>>> ____ >>>>>>>> CMP: And frankly even if that was >>>>>>>> the case, there’s no implication >>>>>>>> that using the existing pieces is >>>>>>>> not sufficient, or that it is not >>>>>>>> easier to extend the candidate >>>>>>>> protocols.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Length - >>>>>>>> two-octet-long field equal >>>>>>>> to the Value field's >>>>>>>> length in____ >>>>>>>> >>>>>>>> octets.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> There are several nested >>>>>>>> lengths defined in this >>>>>>>> document — would be useful >>>>>>>> to analyze that they do not >>>>>>>> result in issues such as >>>>>>>> piggybacking unaccounted >>>>>>>> data.____ >>>>>>>> >>>>>>>> GIM>> Do you see any scenario >>>>>>>> when that might be the case? ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 6.3.1. Source TLV____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Responder to the SFC Echo >>>>>>>> Request encapsulates the SFC >>>>>>>> Echo Reply____ >>>>>>>> >>>>>>>> message in IP/UDP packet >>>>>>>> if the Reply mode is "Reply >>>>>>>> via an IPv4/IPv6____ >>>>>>>> >>>>>>>> UDP Packet". Because the >>>>>>>> NSH does not identify the >>>>>>>> ingress node that____ >>>>>>>> >>>>>>>> generated the Echo >>>>>>>> Request, the source ID MUST >>>>>>>> be included in the____ >>>>>>>> >>>>>>>> message and used as the >>>>>>>> IP destination address and >>>>>>>> destination UDP____ >>>>>>>> >>>>>>>> port number of the SFC >>>>>>>> Echo Reply. The sender of >>>>>>>> the SFC Echo____ >>>>>>>> >>>>>>>> Request MUST include an >>>>>>>> SFC Source TLV (Figure >>>>>>>> 5).____ >>>>>>>> >>>>>>>> ____ >>>>>>>> This seems to negate the >>>>>>>> benefit of less overhead, if >>>>>>>> the IP/UDP fields are >>>>>>>> embedded as OAM TLVs.____ >>>>>>>> >>>>>>>> GIM>> Only the Source ID is >>>>>>>> required, not the whole set of >>>>>>>> IP and UDP headers. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> This also seems to be a bit >>>>>>>> of an invitation for an >>>>>>>> attack.____ >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> 6.4.1. Errored TLVs TLV____ >>>>>>>> >>>>>>>> ____ >>>>>>>> I wonder at this point if it >>>>>>>> is easier to use LSP Ping >>>>>>>> directly instead of >>>>>>>> re-define it.____ >>>>>>>> >>>>>>>> GIM>> If someone wants to >>>>>>>> explore that option, of >>>>>>>> course. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 6.5.1. SFC Reply Path >>>>>>>> TLV____ >>>>>>>> >>>>>>>> …____ >>>>>>>> >>>>>>>> * Service Index: the >>>>>>>> value for the Service Index >>>>>>>> field in the NSH of____ >>>>>>>> >>>>>>>> the SFC Echo Reply >>>>>>>> message.____ >>>>>>>> >>>>>>>> How is the service index in >>>>>>>> a reply constructed?____ >>>>>>>> >>>>>>>> GIM>> It is provided by the >>>>>>>> sender of the SFC Echo >>>>>>>> Request. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Does this mean it skips hops? >>>>>>>> Apologies I do not understand.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> ____ >>>>>>>> >>>>>>>> 6.5.3. SFC Echo Reply >>>>>>>> Reception____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> An SFF SHOULD NOT accept >>>>>>>> SFC Echo Reply unless the >>>>>>>> received message____ >>>>>>>> >>>>>>>> passes the following >>>>>>>> checks:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> * the received SFC Echo >>>>>>>> Reply is well-formed;____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> * it has an outstanding >>>>>>>> SFC Echo Request sent from >>>>>>>> the UDP port that____ >>>>>>>> >>>>>>>> matches destination >>>>>>>> UDP port number of the >>>>>>>> received packet;____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Is the demultiplexing based >>>>>>>> on UDP, OAM handle, or >>>>>>>> combination?____ >>>>>>>> >>>>>>>> GIM>> The values of the Sender's >>>>>>>> Handle and Sequence Number >>>>>>>> fields can be used.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: I understand several values can >>>>>>>> be used.____ >>>>>>>> CMP: Which one is actually used?____ >>>>>>>> CMP: If the Handles and sequences >>>>>>>> match but not the port?____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 6.6. Verification of the >>>>>>>> SFP Consistency____ >>>>>>>> >>>>>>>> * Collect information of >>>>>>>> the traversed by the CVReq >>>>>>>> packet SFs and____ >>>>>>>> >>>>>>>> send it to the ingress >>>>>>>> SFF as CVRep packet over IP >>>>>>>> network;____ >>>>>>>> >>>>>>>> ____ >>>>>>>> What if NSH is not over >>>>>>>> IP?____ >>>>>>>> >>>>>>>> GIM>> Then the operator will >>>>>>>> specify another method using the >>>>>>>> Reply mode. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Sorry that does not answer my >>>>>>>> question. The text in question is >>>>>>>> not contextual to a specified reply >>>>>>>> mode.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> SF Type: Two octets long >>>>>>>> field. It is defined in >>>>>>>> [RFC9015] and____ >>>>>>>> >>>>>>>> indicates the type of SF, >>>>>>>> e.g., Firewall, Deep Packet >>>>>>>> Inspection, WAN____ >>>>>>>> >>>>>>>> optimization controller, >>>>>>>> etc.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Is RFC 9015 a hard >>>>>>>> dependency to implement this >>>>>>>> OAM? ____ >>>>>>>> >>>>>>>> GIM>> RFC 9015 established the >>>>>>>> IANA registry of SF Type and any >>>>>>>> new SF types must be >>>>>>>> registered.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> IANA is requested to >>>>>>>> assign a new type from the >>>>>>>> SFC Active OAM____ >>>>>>>> >>>>>>>> Message Type sub-registry >>>>>>>> as follows:____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> +=======+=============================+===============+____ >>>>>>>> >>>>>>>> | Value | >>>>>>>> Description | >>>>>>>> Reference |____ >>>>>>>> >>>>>>>> +=======+=============================+===============+____ >>>>>>>> >>>>>>>> | TBA2 | SFC Echo >>>>>>>> Request/Echo Reply | This >>>>>>>> document |____ >>>>>>>> >>>>>>>> +-------+-----------------------------+---------------+____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Is there a single value for >>>>>>>> both Request and Reply?____ >>>>>>>> >>>>>>>> GIM>> Yes, it is a single value. >>>>>>>> Echo Request and Echo Reply are >>>>>>>> identified in the Message Type >>>>>>>> field (Figure 3). ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Is this document defining a >>>>>>>> full 64k space for a single value? >>>>>>>> If so it appears to be wasteful.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 9.2.1. Version in the >>>>>>>> Active SFC OAM Header____ >>>>>>>> >>>>>>>> 9.3.1. SFC Echo >>>>>>>> Request/Reply Version____ >>>>>>>> >>>>>>>> ____ >>>>>>>> There seems to be a version >>>>>>>> for the OAM and a version >>>>>>>> for the msg type. Is this >>>>>>>> correct? Are they >>>>>>>> hierarchical versions? Or >>>>>>>> independent? ____ >>>>>>>> This seems to overly >>>>>>>> complicate parsing and >>>>>>>> compliance.____ >>>>>>>> >>>>>>>> GIM>> All versions are >>>>>>>> independent. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: This seems like an operational >>>>>>>> unnecessary complexity, in keeping a >>>>>>>> matrix of supported combination of >>>>>>>> versions. If there was an >>>>>>>> Operational Considerations section, >>>>>>>> this should be included.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 9.3.3. SFC Echo >>>>>>>> Request/Echo Reply Message >>>>>>>> Types____ >>>>>>>> >>>>>>>> Does this mean that there’s >>>>>>>> a protocol number for >>>>>>>> “Active OAM” with a protocol >>>>>>>> number for “Request/Reply” >>>>>>>> with a protocol number for >>>>>>>> either request or reply?____ >>>>>>>> >>>>>>>> GIM>> These are not all protocol >>>>>>>> numbers. Only the Active OAM is >>>>>>>> a new protocol number. Others >>>>>>>> are message types. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Apologies I was not clear.____ >>>>>>>> CMP: The “SFC Active OAM” is >>>>>>>> actually a "SFC Next Protocol”.____ >>>>>>>> CMP: My intention of using “protocol >>>>>>>> number” is in a generic way. To get >>>>>>>> to some OAM function, a node needs >>>>>>>> to recursively parse 3 TLVs. >>>>>>>> Correct? This seems overly >>>>>>>> complex.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Values defined for the >>>>>>>> Return Codes sub-registry >>>>>>>> are listed in____ >>>>>>>> >>>>>>>> Table 14.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Various values in this table >>>>>>>> are not defined in the >>>>>>>> document. The procedures >>>>>>>> seem lacking.____ >>>>>>>> >>>>>>>> GIM>> Other specifications may >>>>>>>> define additional code points in >>>>>>>> the registry. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> CMP: Thank you. The procedures still >>>>>>>> seem lacking.____ >>>>>>>> ____ >>>>>>>> CMP: Best,____ >>>>>>>> ____ >>>>>>>> CMP: — Carlos.____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 9.7. SF Identifier Types____ >>>>>>>> >>>>>>>> This document seems to be >>>>>>>> creating a space for >>>>>>>> identifying SFs — which I >>>>>>>> thought was mostly outside >>>>>>>> the scope of OAM to test >>>>>>>> SFs. ____ >>>>>>>> >>>>>>>> GIM>> The registry is of SF >>>>>>>> Identifiers, not of SF Types >>>>>>>> (that already exists). Hope that >>>>>>>> clarifies the issue. ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> Does this further imply that >>>>>>>> there’s a new requirement to >>>>>>>> have unique identifiers >>>>>>>> within the domain for all >>>>>>>> SFs?____ >>>>>>>> ____ >>>>>>>> I hope these comments and >>>>>>>> review questions and >>>>>>>> concerns are useful for the >>>>>>>> WG discussion and >>>>>>>> consideration.____ >>>>>>>> ____ >>>>>>>> Thanks,____ >>>>>>>> ____ >>>>>>>> Carlos.____ >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> Nov 1, 2021 2:50 PM、 >>>>>>>> Joel Halpern Direct >>>>>>>> <jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com> >>>>>>>> <mailto:jmh.direct@joelhalpern.com >>>>>>>> <mailto:jmh.direct@joelhalpern.com>>> >>>>>>>> のメール:____ >>>>>>>> ____ >>>>>>>> I have received a polite >>>>>>>> request with explanation >>>>>>>> for delay asking for >>>>>>>> more time to read and >>>>>>>> review the subject >>>>>>>> document. Given the >>>>>>>> state of the working >>>>>>>> group, i want to >>>>>>>> encourage any and all >>>>>>>> review. So I am >>>>>>>> extending the last call >>>>>>>> by two additional weeks. >>>>>>>> >>>>>>>> Please read and review >>>>>>>> the document. >>>>>>>> Also, if you are willing >>>>>>>> to serve as shepherd for >>>>>>>> this, please let the >>>>>>>> chairs know. (Don't >>>>>>>> worry if you have not >>>>>>>> shepherded a document >>>>>>>> before. The chairs are >>>>>>>> more than happy to help >>>>>>>> you with the process.) >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Joel >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org <mailto:sfc@ietf.org> >>>>>>>> <mailto:sfc@ietf.org >>>>>>>> <mailto:sfc@ietf.org>> >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> <https://www.ietf.org/mailman/listinfo/sfc> >>>>>>>> <https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> <https://www.ietf.org/mailman/listinfo/sfc>>____ >>>>>>>> >>>>>>>> ____ >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org <mailto:sfc@ietf.org> <mailto:sfc@ietf.org >>>>>>>> <mailto:sfc@ietf.org>> >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> <https://www.ietf.org/mailman/listinfo/sfc> >>>>>>>> <https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> <https://www.ietf.org/mailman/listinfo/sfc>>____ >>>>>>>> >>>>>>>> --____ >>>>>>>> <image001.jpg> >>>>>>>> <http://www.verizon.com/ <http://www.verizon.com/>>____ >>>>>>>> *Gyan Mishra*____ >>>>>>>> /Network Solutions Architect /____ >>>>>>>> /Emailgyan.s.mishra@verizon.com >>>>>>>> <mailto:Emailgyan.s.mishra@verizon.com> >>>>>>>> <mailto:gyan.s.mishra@verizon.com >>>>>>>> <mailto:gyan.s.mishra@verizon.com>>/____ >>>>>>>> >>>>>>>> /M 301 502-1347/____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> --____ >>>>>>>> <image001.jpg> <http://www.verizon.com/ >>>>>>>> <http://www.verizon.com/>>____ >>>>>>>> *Gyan Mishra*____ >>>>>>>> /Network Solutions Architect /____ >>>>>>>> /Emailgyan.s.mishra@verizon.com >>>>>>>> <mailto:Emailgyan.s.mishra@verizon.com> >>>>>>>> <mailto:gyan.s.mishra@verizon.com >>>>>>>> <mailto:gyan.s.mishra@verizon.com>>/____ >>>>>>>> >>>>>>>> /M 301 502-1347/ >>>>>>>> >>>>>>> >>>>>> >>>>>> <Diff_ draft-ietf-sfc-multi-layer-oam-17.txt - >>>>>> draft-ietf-sfc-multi-layer-oam-18.txt.html> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org <mailto:sfc@ietf.org> >> https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc
- [sfc] Regarding last call for draft-ietf-sfc-mult… Joel Halpern Direct
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Dirk.von-Hugo
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Donald Eastlake
- Re: [sfc] Regarding last call for draft-ietf-sfc-… wei.yuehua
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Gyan Mishra
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Gyan Mishra
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Gyan Mishra
- [sfc] SFC OAM gap analysis [Was Re: Regarding las… Greg Mirsky
- Re: [sfc] SFC OAM gap analysis [Was Re: Regarding… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Linda Dunbar
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Dirk.von-Hugo
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Huzhibo
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Joel Halpern Direct
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Joel Halpern Direct
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Joel M. Halpern
- Re: [sfc] Regarding last call for draft-ietf-sfc-… mohamed.boucadair