Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt
Greg Mirsky <gregimirsky@gmail.com> Mon, 18 October 2021 16:15 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 7C2143A158C; Mon, 18 Oct 2021 09:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.696
X-Spam-Level:
X-Spam-Status: No, score=-0.696 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, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 iO6w8lJQg2Vb; Mon, 18 Oct 2021 09:15:36 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 98D243A095C; Mon, 18 Oct 2021 09:15:35 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id ec8so1206085edb.6; Mon, 18 Oct 2021 09:15:35 -0700 (PDT)
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=TeRos7rwIiPCGveHvhBRoJUcFmpYT+bn4m4W4ey1cP8=; b=dl+orRgDxlTRvzdGl5UxTU5f31iKLgcBeicrRgqQNo5sr0bZ2byXtbc3oIT7uk+IEj HDmTdWoUulrwwI0RN8ask80E4l/eBqAN0LpIJdVLpQL83W0t0B1MuPX5E6pdrRFxWWxj 2UYVCuAwzUEFhTJqXN//1f7/iZRjMxpeQ2Uo79Nb0flms0POUm+5DnE9M2ES0V33/Mrh wExaMUTU263COybk+v3vidHCwmcDD4/zDGjpCVEKPrMblY3zq14HSPhSVStYUrKtT1Gq mRx3mDBw0LC3RCDC5lZYIfgijjfBB/CcmhmyaTybK1lqwZYkmWpG/KDLw4xh++WmcgAG +Ysw==
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=TeRos7rwIiPCGveHvhBRoJUcFmpYT+bn4m4W4ey1cP8=; b=AVRFD3bCm2usthwf9aiqTDfK4qCIa5svChD+L5+/mukcRntn2yvMTniZcOthvdjrXV OTI/v7hXKgrrsnBjwacKJ7LhZXG9THQksEBermRHlHlKji+symgx4cBc17J8MjwtGUTa SSm6s8ndjXtPk/K8QqT23d2IkIJguSTQkWbgw20JBPilX92mv3Gu51eGKZDBWPU5KK/P ana9PnWMNQL0za0rdgiegs+yKW0OYy9uLFMT5n9X4EjBx6NzO4UGfpdPbXSm4QpnaUK2 Q1/FeFLTmOGK2v8v77poqasUkqKQ/OuUEqHQODdcOVClXblrMJB+OxcvDPeHF4KxxGFh XkGA==
X-Gm-Message-State: AOAM5324QVNhBeQ0KaggU41APCB3120tqCFRs3EfQy6GFZZhBxfLLsB5 vx6CS4eE+ehWculre5gTVp1/6w5C4mEZ85w/N52TVZZs
X-Google-Smtp-Source: ABdhPJz+b4v4JFtOLbwPdRk5q3/7zVvvz7FM8oHLR3yQIGezyDD77uyQ/xPe28VE55Ux2oLO1Ljt9Oc/tV6eiieHC4o=
X-Received: by 2002:a05:6402:3547:: with SMTP id f7mr45247736edd.395.1634573730397; Mon, 18 Oct 2021 09:15:30 -0700 (PDT)
MIME-Version: 1.0
References: <163370962115.18283.9043697369207976285@ietfa.amsl.com> <CA+RyBmXVH-W4d_kbJDX=6Z-BY_nACw5yQsJsOy-A0SsGDLjkKw@mail.gmail.com> <10112_1634136890_6166F33A_10112_380_1_787AE7BB302AE849A7480A190F8B93303542B55C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CA+RyBmXEgt0QUWM1JofDJfDhEx7g8_Hyvq8kGKEhObf11Xt1=Q@mail.gmail.com> <11909_1634317047_6169B2F7_11909_25_1_787AE7BB302AE849A7480A190F8B93303542CC72@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CA+RyBmW7ipPGp1oRYMWROXvw=TxuD3LMocaRJ3dAmzzr-iTp4g@mail.gmail.com> <8945_1634534769_616D0571_8945_291_1_787AE7BB302AE849A7480A190F8B93303542D7FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <8945_1634534769_616D0571_8945_291_1_787AE7BB302AE849A7480A190F8B93303542D7FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 18 Oct 2021 09:15:19 -0700
Message-ID: <CA+RyBmVx+-dmhgw+qzbPg54o4wwvrSFrFT3_YdCA8D4h8fd1-g@mail.gmail.com>
To: Med Boucadair <mohamed.boucadair@orange.com>
Cc: "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, Service Function Chaining IETF list <sfc@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000008f594605cea2da7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/8wb0yIhWMnIoCetJZaGRQOEWi0E>
Subject: Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2021 16:15:42 -0000
Hi Med, thank you for pointing that out to me. Attached is the diff highlighting the proposed update. I greatly appreciate your feedback on the proposed change. Regards, Greg On Sun, Oct 17, 2021 at 10:26 PM <mohamed.boucadair@orange.com> wrote: > Hi Greg, > > > > Thank you. > > > > There is still one statement that was not removed, though: > > > > (6.6.1): > > > > The initiator of CVReq MAY require the collected information in the > > CVRep be sent in the integrity-protected mode using the MAC Context > > Header, defined in [I-D.ietf-sfc-nsh-integrity]. > > > > Cheers, > > Med > > > > *De :* sfc <sfc-bounces@ietf.org> *De la part de* Greg Mirsky > *Envoyé :* vendredi 15 octobre 2021 22:13 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> > *Cc :* sfc-chairs@ietf.org; Service Function Chaining IETF list < > sfc@ietf.org> > *Objet :* Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt > > > > Hi Med, > > thank you for your quick response. I've modified the text according to > your suggestions and uploaded the new version. > > > > Regards, > > Greg > > > > On Fri, Oct 15, 2021 at 9:57 AM <mohamed.boucadair@orange.com> wrote: > > Hi Greg, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky <gregimirsky@gmail.com> > *Envoyé :* vendredi 15 octobre 2021 18:06 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> > *Cc :* Service Function Chaining IETF list <sfc@ietf.org>; > sfc-chairs@ietf.org > *Objet :* Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt > > > > Hi Med, > > thank you for your review and comments. Please find my notes in-lined > below tagged by GIM>>. > > > > Regards, > > Greg > > > > On Wed, Oct 13, 2021 at 7:54 AM <mohamed.boucadair@orange.com> wrote: > > Hi Greg, all, > > > > Please find below some quick comments about this version: > > > > (1) > > > > “While SFC Echo Request always traverses the SFP, it is directed to, > > the corresponding Echo Reply usually is sent over an IP network.” > > > > I’m not sure to get the intent here, especially that an SFP is still “over > an IP network”. > > GIM>> We are pointing out that the Echo Request traverses SFP using NSH > while the Echo Reply is not. Do you think that explicitly referring to the > role of NSH helps to make it clearer: > > OLD TEXT: > > While SFC Echo Request always traverses the SFP, it is directed to, > > the corresponding Echo Reply usually is sent over an IP network. > > NEW TEXT: > > While SFC Echo Request always traverses the SFP, it is directed to, > > using NSH, the corresponding Echo Reply usually is sent over an IP > > network without NSH. > > > > *[Med] I would just delete “over an IP network” from the NEW text. Thanks. > * > > > > > > I have the same concern with this one: > > > > “There are scenarios when it is beneficial to direct the responder to > > use a path other than the IP network“ > > GIM>> Would the following update make it clearer: > > OLD TEXT: > > There are scenarios when it is beneficial to direct the responder to > > use a path other than the IP network. > > NEW TEXT: > > In some cases, an operator might choose to direct the responder > > to send the Echo Reply with NSH over a particular SFP. > > > > *[Med] This is better, thanks. * > > > > (2) You may want align these two statements to avoid what may be perceived > as an internal inconsistency (or redundant requirements): > > > > The Message Authentication Code (MAC) Context Header that is > defined > > in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the SFC > Echo > > Request's integrity when using the SFC Return Path TLV > > > > vs. > > > > When the integrity protection for SFC active OAM, and SFC Echo > > Request/Reply in particular, is required, it is RECOMMENDED to use > > one of the Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. > > GIM>> Thank you for catching this inconsistency. Would you agree that > s/MAY/SHOULD/ resolves it? > > *[Med] Yes… but I would just maintain the one in the Security > Considerations Section. * > > > > Cheers, > > Med > > > > *De :* sfc <sfc-bounces@ietf.org> *De la part de* Greg Mirsky > *Envoyé :* vendredi 8 octobre 2021 18:19 > *À :* Service Function Chaining IETF list <sfc@ietf.org>; > sfc-chairs@ietf.org > *Objet :* [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt > > > > Dear All, > > following the discussion on the SFC WG mailing list and the direction from > the SFC WG Chairs, we've merged substantive parts > of draft-ao-sfc-oam-path-consistency > and draft-ao-sfc-oam-return-path-specified with this draft where the base > functionality of the SFC NSH Echo Request/Reply is defined. The authors > greatly appreciate and welcome your comments, questions, and suggestions. > We're looking forward to the discussion that will help to progress this > document to the WG LC. > > > > Regards, > > Greg (on behalf of the authors). > > ---------- Forwarded message --------- > From: <internet-drafts@ietf.org> > Date: Fri, Oct 8, 2021 at 9:13 AM > Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt > To: <i-d-announce@ietf.org> > Cc: <sfc@ietf.org> > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining WG of the IETF. > > Title : Active OAM for Service Function Chaining > Authors : Greg Mirsky > Wei Meng > Ting Ao > Kent Leung > Gyan Mishra > Filename : draft-ietf-sfc-multi-layer-oam-14.txt > Pages : 37 > Date : 2021-10-08 > > 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. > > This document updates RFC 8300. Particularly, it updates the > definition of O (OAM) bit in the Network Service Header (NSH) (RFC > 8300) and defines how an active OAM message is identified in the NSH. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-sfc-multi-layer-oam-14.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-14 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > > Thank you. > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > > Thank you. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > >
- [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-… internet-drafts
- [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer… Greg Mirsky
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… mohamed.boucadair
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… Greg Mirsky
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… mohamed.boucadair
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… Greg Mirsky
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… mohamed.boucadair
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… Greg Mirsky
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… mohamed.boucadair
- Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-l… Greg Mirsky