Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam
Greg Mirsky <gregimirsky@gmail.com> Sat, 27 November 2021 03:30 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 5E2323A0CA7 for <sfc@ietfa.amsl.com>; Fri, 26 Nov 2021 19:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ECtoUWh1pBV3 for <sfc@ietfa.amsl.com>; Fri, 26 Nov 2021 19:30:41 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 9DB6E3A0CA9 for <sfc@ietf.org>; Fri, 26 Nov 2021 19:30:37 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id e3so46335695edu.4 for <sfc@ietf.org>; Fri, 26 Nov 2021 19:30:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iYjO7rQ1wXdjV8nFmdHUYwpWfuWyBdjisg1/xK70Fks=; b=gP6gLPTdFy6TdfuhMkCfuSJxFptEa1tqk8VS4LahVVuq7e97tcMyut1JsuQnMhx6MS AplnAjAK4KG3jj3h7SWnvEdMPw6O2cLuVzcOCEns9rCQm8Kp6PQNaXULP7FxqrzawxkH dK88aiE9s/7CgUOz9V5DTmj+KUEkXCM2ZTdLokQ0ShLC97olW12pSs/Ma7pflU+p3hVx ilBG02OJCs2XVRf7muZb1VE+cGYmi3KZAJjTm1aQxwSK/d7GSsBAZtf4n59Xs2u2chti PTks51ZG+TE5nU8iTYYD9+GU5z9Q4Zvke3jtMxzgsI3LFQI78varqva6JTGJHwo/1PrG qhwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iYjO7rQ1wXdjV8nFmdHUYwpWfuWyBdjisg1/xK70Fks=; b=PO2hqfDdv6O7re86qhEjsl2HZzXr2LMBhaWZnc8ugLa59SWvC3gZsPvOH5vMsqXMyq pM1gajiM5OTqr6tM8nq5hjc7lSpLfSRK9A0pmMOia/Vy29xJENPigKO6XnVPgmnWp4NG fFHS9qRFfNOgG/0JN8v35xo1AugTeRoF87khO2DT1iqNA9Di1eFTtxnqBeMronJB1Foi 1r1zl/hEtZy8BS15J+KFCZfrUKhGuJwULxlR616PyUjXfZbLzAYhc8wIhOoTQUmgmtOi Vqwzo1mUgsNIl8oghq9HxW1ZsOcZM9yvWrvkjLUdvPnZsqEgdsoPA/kjlWO/eTB36RGd EKxg==
X-Gm-Message-State: AOAM530AXyoylWt3jexwiMGLqFZtLFE7NtSuxVp93qJ+mrZQSu8DNDxv a2AcQisgsf6Sxda4tddXWQEV3dyxBNqKoqaxGJA=
X-Google-Smtp-Source: ABdhPJzthgX8Bhgj8AL2sUChL8OKNoTn9Od/CWICUp+9ijmCwPzr8vCWK4iVs7+6JuMax4lTbXo0QtQRIa/qodsj8eg=
X-Received: by 2002:a17:906:c302:: with SMTP id s2mr42989807ejz.499.1637983830853; Fri, 26 Nov 2021 19:30:30 -0800 (PST)
MIME-Version: 1.0
References: <4bb5abb4-a8dc-c8f0-9b99-549f683e7729@joelhalpern.com> <05FDF1D8-6CBD-403B-8F51-88E51346A36F@cisco.com> <CA+RyBmXHhjyqTtc0pVtwmTRku-SV+0cFf7tFL_xOHnQ56xBvfQ@mail.gmail.com> <BD6EBECC-E7C7-4A80-8972-9DD008FF81B1@cisco.com> <CABNhwV3_uqRTZNy4xAjvetHJqoFbJa4obw-UsEhgukQ3aQBJRw@mail.gmail.com> <9DDFE3B0-54A2-47D9-B05E-A081EAEED410@cisco.com> <CABNhwV1YKvfSdbJo9LzAvGuWLvjWofHz5TuCE6Fp8SDUyxmTHw@mail.gmail.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>
In-Reply-To: <896B8A4B-3717-4150-9944-44906A593BC9@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 26 Nov 2021 19:30:17 -0800
Message-ID: <CA+RyBmUaeSsjLE191jK94bGV3Nzed95tkN+mn-kCDs6WxucFRg@mail.gmail.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "Frank Brockners (fbrockne)" <fbrockne=40cisco.com@dmarc.ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, James N Guichard <james.n.guichard@futurewei.com>, "sfc@ietf.org" <sfc@ietf.org>, Joel Halpern Direct <jmh.direct@joelhalpern.com>
Content-Type: multipart/alternative; boundary="00000000000062ca4805d1bcd4f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/AkxWy5J2KdKTVPbFfdsFkrCnTPo>
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: Sat, 27 Nov 2021 03:30:49 -0000
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> 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> 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> > *Sent:* Tuesday, 23 November 2021 15:44 > *To:* Frank Brockners (fbrockne) <fbrockne@cisco.com> > *Cc:* Greg Mirsky <gregimirsky@gmail.com>; Gyan Mishra < > hayabusagsm@gmail.com>; James N Guichard <james.n.guichard@futurewei.com>; > sfc@ietf.org; Joel Halpern Direct <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>のメール: > > Hi Greg, > > Thanks for the quick reply. Please see inline. > > *From:* Greg Mirsky <gregimirsky@gmail.com> > *Sent:* Monday, 22 November 2021 23:16 > *To:* Frank Brockners (fbrockne) <fbrockne@cisco.com> > *Cc:* Carlos Pignataro (cpignata) <cpignata=40cisco.com@dmarc.ietf.org>; > Gyan Mishra <hayabusagsm@gmail.com>; James N Guichard < > james.n.guichard@futurewei.com>; sfc@ietf.org; Joel Halpern Direct < > 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 in > 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 match any > of the SFC Next Protocol values define 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. > > …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 and the "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> 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 > > 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> *On Behalf Of *Carlos Pignataro > (cpignata) > *Sent:* Monday, 22 November 2021 00:52 > *To:* Gyan Mishra <hayabusagsm@gmail.com> > *Cc:* James N Guichard <james.n.guichard@futurewei.com>; Greg Mirsky < > gregimirsky@gmail.com>; sfc@ietf.org; Joel Halpern Direct < > 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 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>のメール: > > 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> 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/ > > 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 > > 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>のメール: > > > > 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> 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>のメール: > > 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> 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 > > 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>のメール: > > 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 > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- > <image001.jpg> <http://www.verizon.com/> > *Gyan Mishra* > *Network Solutions Architect * > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > > > -- > <image001.jpg> <http://www.verizon.com/> > *Gyan Mishra* > *Network Solutions Architect * > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > >
- [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