Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> Tue, 12 April 2022 14:56 UTC
Return-Path: <shwetha.bhandari@thoughtspot.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D47D3A1711 for <ippm@ietfa.amsl.com>; Tue, 12 Apr 2022 07:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Level:
X-Spam-Status: No, score=-1.505 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.com header.b=rsALMj1Q; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=4OpwHlsd
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 u1fWaeNULR8Q for <ippm@ietfa.amsl.com>; Tue, 12 Apr 2022 07:56:13 -0700 (PDT)
Received: from mx0b-0055fe01.pphosted.com (mx0b-0055fe01.pphosted.com [205.220.176.104]) (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 B46993A165F for <ippm@ietf.org>; Tue, 12 Apr 2022 07:56:13 -0700 (PDT)
Received: from pps.filterd (m0211452.ppops.net [127.0.0.1]) by mx0b-0055fe01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 23C6HxkL004298 for <ippm@ietf.org>; Tue, 12 Apr 2022 07:56:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=proofpoint; bh=rkvsQ+mA3qtGnDBOpPdg1KFeO8W0USbeTwG2Bm/btBQ=; b=rsALMj1QkPFwxr9/RuXkwauFooCj/mSRmasrtIMw6ITuCYmXAk322Q59n9lWa0QwXFpn ZZPuNDc+RH9tnswo71kKz4dkOKGQi2+EUXwdUL16riQ+P0sZD5NZJEZzspkKvIfSGBes HtM6vfCrGefLJqoPmgTmeTugJ0fC/DMDH76qVGNF0HQdhtP/NSlPIALvRVjj8PVWDlPn GZBvnrsjxyTrewt5k5jDyfSQXVIfHfjRc8vZcjyJtndcRpTVyAmENiRIqLlxCD517hTX UQP2UTYs3ROhYaLHsz23BBlfVcV7l1bPWs2FcHsmR+h5BTyD1ab9iAHu2M4UtNv18uBv 9A==
Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3fb9mkrrfm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <ippm@ietf.org>; Tue, 12 Apr 2022 07:56:10 -0700
Received: by mail-qv1-f71.google.com with SMTP id 33-20020a0c8024000000b0043d17ffb0bdso18560930qva.18 for <ippm@ietf.org>; Tue, 12 Apr 2022 07:56:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rkvsQ+mA3qtGnDBOpPdg1KFeO8W0USbeTwG2Bm/btBQ=; b=4OpwHlsdQCP/OhlOSvUQmXQpH40sSclemEzw6cBAXEFJ85H+h2BEAm5nD7ofyuHiYA BMdzTWoUecmnSaG98cjwFsIbREJAL4GZc1TxRynkLWBL45FSiB19oM1p8dmMBIUtQGJC Q3o5m2YlDltbc2twkk6KWedMBjlmwN0HxK86RyJ5Zxx1BkA2Y/tDQXx7PWu4Lkjo2nKj avzSOvXOuXbO3yzi/jUHzpxTQTZdLptwQbTMq7Yl55nR//L7PrYprmfoySJfuh0oKYtX ipJDt3mxycin5g/7fBCC1I7PCvHL0H9RAx1fe9k8ElZVIxpeZjaMxGM6o00y8IHmrLU8 cHQA==
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=rkvsQ+mA3qtGnDBOpPdg1KFeO8W0USbeTwG2Bm/btBQ=; b=b6+++wtVayb9AvyJXa0h+Ou2b/CUvcRo20hF1K6Bk48JVY/p0B8TshfjaTOVc/qdQg TYrnSPYfVV5ogPfU47UO64Tf2LKBjAApSqtCVojqVj9KS869TXmUlfBOYT7rwS6yqQv4 zdUw+0apEHcdh7l0bYpcCCSO15XSlxXcz1uuWJ6MBY5shghwBf+B8mAS5qP5DV+yTVub GWq/7k/5wptXKdrFKauEZgdNJaDdUACdkZH5Czf6aCfb1hzvK7He2jHCzAn5y6BM4S66 0r47JsRLyBlrFaoksGLZgLmytVL5spEn7RuRdyUbzvMdPWfMNQkvxxBIpPTtKxgyX++o NI6w==
X-Gm-Message-State: AOAM531KwGy8Ujas4hvOcMxjaUsnB1wkHn9PEzQ2Ey2sJdWkMhsDp7uP w0cVrgafR+t838eP+pb82ozfRdN6ceZiPpQuLy5WP2vbPCQg+G1HTj+GysDblSs66Rv4xJD+aL6 awupZuoTtqVSmVmAX7XIc
X-Received: by 2002:a05:622a:1926:b0:2ef:fe22:8aec with SMTP id w38-20020a05622a192600b002effe228aecmr3696864qtc.446.1649775370014; Tue, 12 Apr 2022 07:56:10 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJw89utHKFYHaibIB5pVqViOilfoZW85hTE6aTQnuRU/St9eVKn2lhKY320nrlONvmEWkC6qAMsiksl5z669lcQ=
X-Received: by 2002:a05:622a:1926:b0:2ef:fe22:8aec with SMTP id w38-20020a05622a192600b002effe228aecmr3696830qtc.446.1649775369396; Tue, 12 Apr 2022 07:56:09 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB4206C91446BA5FBBDA69E233D2FF9@MN2PR13MB4206.namprd13.prod.outlook.com> <CA+RyBmVSrdCaO77P4=1vZ2LmxtR65OmspN_wozyGPNwtM5Uv3A@mail.gmail.com> <CAMFZu3PaLQrHcBULzsxbdnTJyr-bVDVs1WpnFwLuSkR7DbntuQ@mail.gmail.com> <CA+RyBmWeUiTsA7-CvpXSBViB00Y-tmAuSr-P=Vf3vB61zfn6bg@mail.gmail.com> <CAMFZu3P45x9Mt5-MUpGO1Puqz57DPcGE4aBsPNxczW-pw9n=AA@mail.gmail.com> <MN2PR13MB42066C22CA66B0E1F0FC3FFFD2269@MN2PR13MB4206.namprd13.prod.outlook.com> <CAMFZu3NO6J-MM_a7TZm+wTzxbKzY5t0OkW8QNLk0673Fkr16RQ@mail.gmail.com> <CA+RyBmVVWdvLZdANV_whtcwwMKVfVpM8VL7BYMM7NTnmooUpcQ@mail.gmail.com> <CAMFZu3PEmrarcsp4tXQsx4eKvai8+UvzKSFxfcakX4LUAcayJA@mail.gmail.com> <MN2PR13MB420615DA403388EA0144A9C1D22F9@MN2PR13MB4206.namprd13.prod.outlook.com> <CAMFZu3MUmuBEDEzdafw2UHEvsTE+7sQ=E1kik5TuQ=_NznFF9w@mail.gmail.com> <CA+RyBmW=ZT0EUmSYYfZJjcapBZ5-pg93um5t287LreONLOVnJQ@mail.gmail.com> <CAMFZu3NCCmj4u75taEzBiMmkMQ0YrmK5KsUToSOKfwX1yBxePA@mail.gmail.com> <26916_1649050778_624A849A_26916_245_1_aa5a0049026247d9980f4ebbc8c5ac0b@orange.com> <CY4PR11MB1672FCF27DA2A4822C6E1B40DAED9@CY4PR11MB1672.namprd11.prod.outlook.com> <11111_1649774342_62558F05_11111_493_4_a734de5265ca498bbabf9805a6eaf91d@orange.com>
In-Reply-To: <11111_1649774342_62558F05_11111_493_4_a734de5265ca498bbabf9805a6eaf91d@orange.com>
From: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Date: Tue, 12 Apr 2022 20:25:58 +0530
Message-ID: <CAMFZu3N03E-nWYJNik91e+X=gr3s2TVF03ZCM8i02ru4_Q82og@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "Frank Brockners (fbrockne)" <fbrockne=40cisco.com@dmarc.ietf.org>, Greg Mirsky <gregimirsky@gmail.com>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, "draft-ietf-sfc-ioam-nsh@ietf.org" <draft-ietf-sfc-ioam-nsh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000da3a4905dc764213"
X-Proofpoint-ORIG-GUID: HmpzcwoOeHpRbAa26Gfovt0M4h2jA4Zm
X-Proofpoint-GUID: HmpzcwoOeHpRbAa26Gfovt0M4h2jA4Zm
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-12_05,2022-04-12_02,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1011 bulkscore=5 spamscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 impostorscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204120072
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ph9qZcKJFJX0INrmsp-SNd755yI>
X-Mailman-Approved-At: Tue, 12 Apr 2022 08:01:33 -0700
Subject: Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2022 14:56:20 -0000
Med, Thanks for the details: this is exactly what we had before the latest revision: 4.2 <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06#section-4.2>. IOAM and the use of the NSH O-bit [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 <https://datatracker.ietf.org/doc/html/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. This was removed as per the discussion in this thread. Please check https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/ It looks like we are going in a loop here. This definition of SFC OAM packet to include the OAM data that comes in inner packets via the next protocol header chain is introduced in draft-ietf-sfc-oam-packet to update the RFC8300. Jim, What are you thoughts on this? Should we reintroduce the above text ? Thanks, Shwetha On Tue, Apr 12, 2022 at 8:09 PM <mohamed.boucadair@orange.com> wrote: > Hi Franck, > > > > Thank you for the clarification even if I don’t think there is a > confusion. > > > > Please note that SFC OAM packet is defined as follows: > > > > == > > Such a packet > > is any NSH-encapsulated packet that exclusively includes OAM data. > > An OAM data can be included in the Fixed-Length Context Header, > > optional Context Headers, and/or the inner packet. > > == > > > > Things are pretty clear (as per draft-ietf-sfc-oam-packet) that the O bit > must be unset when IOAM data is included + user data. > > > > The concern I had is that you are pointing to RFC8300 for the IOAM next > protocol, which makes both “none” (i.e., no payload) and IOAM (as you > request a new code) legitimate values. > > > > Cheers, > > Med > > > > *De :* sfc <sfc-bounces@ietf.org> *De la part de* Frank Brockners > (fbrockne) > *Envoyé :* mardi 12 avril 2022 13:55 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Shwetha > Bhandari <shwetha.bhandari@thoughtspot.com>; Greg Mirsky < > gregimirsky@gmail.com> > *Cc :* sfc-chairs@ietf.org; sfc@ietf.org; ippm@ietf.org; James Guichard < > james.n.guichard@futurewei.com>; Tal Mizrahi <tal.mizrahi.phd@gmail.com>; > draft-ietf-sfc-ioam-nsh@ietf.org > *Objet :* Re: [sfc] WGLC for > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$> > > > > Hi Med, > > > > Sorry for arriving late to the party. Reading through your message below, > there seems to be a confusion about the scope and concept of different OAM > mechanisms. > > > > IOAM is scoped and designed to be protocol agnostic. IOAM data can be > encapsulated into various protocols – and NSH is one example – but there is > no semantic link between IOAM and the protocol used to encapsulate IOAM > data. > > > > Protocols can have their protocol specific OAM methods and solutions, like > SFC OAM. Those protocol specific solutions (like SFC OAM as an example) are > orthogonal to IOAM from a concept and scope perspective. > > > > From an SFC OAM perspective, your draft-ietf-sfc-oam-packet-00 clearly and > rightly states that “O bit: Setting this bit indicates an SFC OAM packet.” > The O bit is about SFC OAM, and as such is orthogonal to “anything IOAM”. > In earlier versions of draft-ietf-sfc-ioam-nsh we had text which stated > that the O bit remains unchanged whether IOAM is present or not. To avoid > any confusion, in -08 we removed this statement – just to make it crystal > clear that there is no link between “IOAM” and “SFC OAM”. > > > > In addition, I don’t think that draft-ietf-sfc-ioam-nsh would be the > appropriate place to discuss and restrict deployment options. E.g., I’m not > sure why we’d want to restrict a deployment to using a single IOAM header > only. E.g., one could think of using different headers for different > namespaces or groups of namespaces for operational reasons. IMHO, such a > discussion – if we really need it - would belong into > draft-ietf-ippm-ioam-deployment, rather than into a draft that defines the > encap of IOAM into NSH. > > > > Hope this clarifies things – and we can finish up draft-ietf-sfc-ioam-nsh > :-). > > > > Cc’ing the ippm working group as an FYI. > > > > Thanks & Cheers, Frank > > > > > > > > *From:* mohamed.boucadair@orange.com <mohamed.boucadair@orange.com> > *Sent:* Monday, 4 April 2022 07:40 > *To:* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>; Greg Mirsky < > gregimirsky@gmail.com> > *Cc:* sfc-chairs@ietf.org; Frank Brockners (fbrockne) <fbrockne@cisco.com>; > sfc@ietf.org; James Guichard <james.n.guichard@futurewei.com>; Tal > Mizrahi <tal.mizrahi.phd@gmail.com>; draft-ietf-sfc-ioam-nsh@ietf.org > *Subject:* RE: [sfc] WGLC for > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$> > > > > Hi Shwetha, all, > > > > I agree with Greg that a statement is needed to be added to > draft-ietf-sfc-oam-packet. > > > > For example, the current text says the following: > > > > Next Protocol: 8-bit unsigned integer that determines the type of > > header following IOAM. The semantics of this field are > > identical to the Next Protocol field in [RFC8300 > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnDoYxXlRw$> > ]. > > > > which means that “None” is authorized. The O-bit must be set for such > packets, while it should be unset for other values indicating user payload > as per draft-ietf-sfc-oam-packet. Absent a pointer to the OAM packet, an > implementer will have to guess the behavior to follow. > > > > BTW, the text quoted above when combined with: > > > > IANA is requested to allocate protocol numbers for the following "NSH > > Next Protocol" related to IOAM: > > > > …means that IOAM data can be encapsulated in IOAM data. I don’t think you > want such a behavior. No? > > > > One last comment: please update the security considerations with > NSH-specific considerations. An approach is to simply refer to Section 5 of > draft-ietf-sfc-oam-packet. > > > > Cheers, > > Med > > > > *De :* sfc <sfc-bounces@ietf.org> *De la part de* Shwetha Bhandari > *Envoyé :* lundi 4 avril 2022 02:41 > *À :* Greg Mirsky <gregimirsky@gmail.com> > *Cc :* sfc-chairs@ietf.org; Frank Brockners (fbrockne) <fbrockne@cisco.com>; > sfc@ietf.org; James Guichard <james.n.guichard@futurewei.com>; Tal > Mizrahi <tal.mizrahi.phd@gmail.com>; draft-ietf-sfc-ioam-nsh@ietf.org > *Objet :* Re: [sfc] WGLC for > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$> > > > > Hi Greg, > > > > Thanks for the feedback. From the discussion and Jim's feedback > > "My only point was that in the case of IOAM the O-bit seems to be > obsolete as you use the next protocol field rather than the context > headers. It seems to me that the definition of the O-bit should be that if > set then the context headers are used to obtain the OAM instructions." > > Which makes sense. The O-bit does not influence IOAM handling as it is > carried as a next protocol. > > Hence the consideration section on O-bit is removed in the new revision. > What do you think? > > > > Thanks > > Shwetha > > > > On Mon, Apr 4, 2022, 1:41 AM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Hi Shwetha, > > thank you for your kind consideration of my comments and for > thoroughly addressing those in the new version. I've noticed that you've > decided to remove the discussion of the O bit in the NSH from the draft > altogether. I think that it might be helpful to a reader if the document > includes a short clarification and the reference to > draft-ietf-sfc-oam-packet > <https://urldefense.com/v3/__https:/www.ietf.org/id/draft-ietf-sfc-oam-packet-00.html__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVditWyZ_8$> like > the following: > > For the IOAM functionality is SFC NSH described in this document the O bit > > in NSH MUST be set clear according to [I-D.ietf-sfc-oam-packet]. > > > > Regards, > > Greg > > > > On Sun, Apr 3, 2022 at 1:06 AM Shwetha Bhandari < > shwetha.bhandari@thoughtspot.com> wrote: > > Hi Jim, Greg, > > > > We have addressed the additional comments received in this discussion. Can > you please take a look : > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-08.txt > <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-08.txt__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVd4KRpUCA$> > > > > Thanks, > > Shwetha > > > > On Thu, Feb 10, 2022 at 11:27 PM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Hi Shwetha, > > > > My only point was that in the case of IOAM the O-bit seems to be obsolete > as you use the next protocol field rather than the context headers. It > seems to me that the definition of the O-bit should be that if set then the > context headers are used to obtain the OAM instructions. Currently that is > not what 8300 says. As I said in my previous emails I would really like to > hear the WGs opinion on what to do with the O-bit and we certainly need to > reconcile the various documents to be following the same standard. > > > > Jim > > > > *From:* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> > *Sent:* Wednesday, February 9, 2022 9:57 AM > *To:* Greg Mirsky <gregimirsky@gmail.com> > *Cc:* James Guichard <james.n.guichard@futurewei.com>; > draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org > *Subject:* Re: [sfc] WGLC for > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_8pjQ1iQ$> > > > > Hi Jim, > > > > On the O bit handling, are you suggesting that the O-bit for IOAM, that is > carried as a next protocol following NSH header, is not applicable? Would > removing the section on O-bit considerations resolve your concern? > > > > Hi Greg, > > > > >I have one more question. As the draft now mentions the option of using > IOAM Direct Export to collect the IOAM data, it might be helpful reflecting > that in the figure on p.2. I think that the caption "IOAM Option and Data > Space" might be reworded to "IOAM Option and Optional Data Space". > > What are your thoughts? > > Yes, that will make it accurate. I will update the diagram and publish a > new version. > > > > >I cannot find the text in the draft suggesting that an SFF that does not > support IOAM may forward the packet with the NSH Next Protocol field equal > to IOAM protocol identifier. Could you help me find it? > > Can you suggest text to help with this ? This would be a generic problem > for NSH implementation when a next protocol is set to a value it does not > understand. What should is recommended action in this situation? > > > > > > > For example, if the Loopback IOAM flag is set, the node is required to > send a copy of the packet back to the IOAM encapsulating node. It is not > clear to me how an SFF learns the identity of the IOAM encapsulating node > and how it encapsulates the loopbacked packet. Can you help me find how it > is supposed to work in the NSH? > > > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags#section-4.2 > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-ippm-ioam-flags*23section-4.2&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631120774*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zcOpC0Gzzi8xzhttBqWaeaU3pMd0KDo*2FZYdGsEPG0uE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_cH_6kAg$> > : > > A Loopback flag that is set indicates to the transit nodes processing > > this option that they are to create a copy of the received packet and > > send the copy back to the source of the packet. > > Given this is explained in the flag handling, do you see a need to define > it again in NSH? IMHO the explanation of flag handling is quite generic for > any packet based transport. > > Please share your thoughts and text suggestions to improve the draft for > flag handling if it requires clarification. > > > > > > Thanks, > > Shwetha > > > > On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Hi Shwetha, > > I have one more question. As the draft now mentions the option of using > IOAM Direct Export to collect the IOAM data, it might be helpful reflecting > that in the figure on p.2. I think that the caption "IOAM Option and Data > Space" might be reworded to "IOAM Option and Optional Data Space". > > What are your thoughts? > > > > Regards, > > Greg > > > > On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari < > shwetha.bhandari@thoughtspot.com> wrote: > > Hi Jim, Greg, > > > > Thanks for the follow up. > > 1) On O-bit: I am a bit confused about the O-bit feedback. Are you > suggesting that it should not be a consideration for IOAM as it is handled > as a next protocol and not as NSH context headers? > > What should a SFC element handle a packet containing IOAM as next header > and does not implement IOAM and hence does not understand IOAM? I think > O-bit helps in such situations to help such elements decide to drop or > forward without processing the IOAM header. > > Let me know if that is not the case and if simply not considering O-bit in > the context of IOAM is what you would recommend. > > 2) Active or Loopback flags > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-ioam-flags*2F__*3B!!MZ3Fw45to5uY!eu05ObEvXtnVX2OXFzl0g16vk36xSqTyjMReG_i6BavtG_ru2AnjQSjXHiZ_Ve3sBjJRuHMBUg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=DvpZHlkn0PNCP5*2BzFQzGayutZGPUMxJXtPll6nR8Ay8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_4eduZWg$> - > there is nothing specific for NSH on how the flags are to be handled. The > IOAM specific fields are to be handled as recommended by the respective > IOAM drafts. Do you see any specific NSH considerations to be documented > for IOAM fields? > > > > Thanks, > > Shwetha > > > > > > > > > > > > > > > > On Tue, Feb 1, 2022 at 4:29 PM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Hi Shwetha & Greg, > > > > Thank you for the update. > > > > I still believe however that more work is necessary to reconcile how SFC > OAM is supposed to work. RFC 8300 says: > > > > O bit: Setting this bit indicates an OAM packet (see [RFC6291 > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6291__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJs06rKUNw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=4wRcNgj93har9TlylAfX*2BtbW24VCqfneSZd0rD9CRzs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8b5uw-Yg$> > ]). > > The actual format and processing of SFC OAM packets is outside the > > scope of this specification (for example, see [SFC-OAM-FRAMEWORK > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300*ref-SFC-OAM-FRAMEWORK__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJsisioAug*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=A6fkAO8CwRJeW5tLLEpU0GhZrqsBOm7nUiE1QiMxwVQ*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_b7k_TUA$> > ] > > for one approach). > > > > The O bit MUST be set for OAM packets and MUST NOT be set for > > non-OAM packets. > > > > If we look at RFC6291 it simply describes what OAM is supposed to mean and > this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) in > section 6.3 says: > > > > The Next Protocol field in the NSH header may be used to indicate what > OAM function is intended > > or what toolset is used. Any other overlay encapsulations used at the > service layer must have a > > similar way to indicate the intended OAM function. > > > > So my reading of this is that if you take 8300 together with the framework > then 1. The O-bit MUST be set for OAM packets, and 2. The Next Protocol > field may or may not be used to indicate which OAM function is to be > applied. From this I can determine that iOAM has taken the approach of > using the next protocol field to indicate how to process the OAM packet and > does NOT use the NSH context headers in any way shape or form. This seems > consistent with the current definitions of the O-bit from RFC 8300 and > processing guidelines from RFC 8924. > > > > However, your document says: > > > > *4.1 > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*section-4.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJtXMLMQUw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=w3hANsqqvVWz5oeH*2BLfPwS*2Fxwh2hNERJwCw5zwdrAMA*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9Fp7_C8w$>. > IOAM and the use of the NSH O-bit* > > > > [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJuMIrqXAQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=a*2BVevL6noSzqRzdWg6dscjiqevlLbxcgEdTEmfJAY7U*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW92fQLzlQ$>] > 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. > > > > This text basically says that if the packet is customer traffic and > happens to carry iOAM data then it is NOT an OAM packet. What am I > missing, customer traffic or not, both carry iOAM data so how are they > different within an SFC domain? > > > > In addition to the above I will note that there is still a conflict with > Greg’s draft namely this text from section 4: > > * O bit set and the "Next Protocol" value does not match the value > > Active SFC OAM (TBA1), defined in Section 10.1 > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-multi-layer-oam*section-10.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv1ohYIeg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=HTLx6e4sQCvsjXZKxG1GA8XPvdswsQKEMIEABitkprw*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-EwTZ2zw$> > : > > > > - An SFC NSH Context Header(s) contain an OAM processing > > instructions or data. > > > > - The "Next Protocol" field determines the type of the payload. > > > > The above text suggests to me that if the O-bit is set and the next > protocol is not active SFC OAM then it is **required** that OAM data will > be in the NSH context headers (which is not the case for iOAM) and the next > protocol will indicate what follows the NSH header. While iOAM does follow > the NSH header as indicated by the next protocol there is still an > expectation that OAM is also carried in the NSH context headers. This seems > to be in conflict with RFC 8300 AND RFC 8924. > > > > This of course is just my reading of the text and I would like to hear > yours and other folks thoughts. > > > > Jim > > > > *From:* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> > *Sent:* Monday, January 31, 2022 11:25 PM > *To:* Greg Mirsky <gregimirsky@gmail.com> > *Cc:* James Guichard <james.n.guichard@futurewei.com>; > draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org > *Subject:* Re: [sfc] WGLC for > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-sfc-ioam-nsh*2F__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu3416GCQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=NKz8*2Fm*2Fh7WXjK0OP8NF4j5cQ*2FYgSrSMULRmDt*2FkX*2B10*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8EWrHtpA$> > > > > Hi Greg, > > > > Sorry for the late action on this. > https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Dpl23JSzuzl5p2F8vooPyxVcUnWRdcWx*2F26MRFfJAIh4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJvEbkwM5w*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=dpoyXLu*2F9fGVSgLtewdI7wNfSPdrkhs7FtBdD3Aq7*2B0*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9PuM1neA$> > has been now posted with the edits per this discussion. > > > > Hi Jim, > > > > After Greg's review please let us know if the changes are good to progress > the draft to the next step. > > > > Thanks, > > Shwetha > > > > On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Hi Shwetha, > > thank you for the detailed response to my comments. Please feel free to > share any updates you're considering for the next version. I'll be glad to > work together on these. > > I have several follow-up notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < > shwetha.bhandari@thoughtspot.com> wrote: > > Hi Greg, > > > > Sorry for the very late reply. Please find responses to your comments > inline @Shwetha: > > > > > > > > On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Dear Authors and All, > > I've read the current version of the draft and have some comments I'd like > to share with you. I much appreciate your thoughts on where this work > should go considering developments in other IETF WGs. Please find my notes > and questions below: > > - It is stated in the Abstract that: > > In-situ Operations, Administration, and Maintenance (IOAM) records > operational and telemetry information in the packet while the packet > traverses a path between two points in the network. > > But that is the case only for the pre-allocated and incremental trace > option types. The Direct Export option > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-ioam-direct-export*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKE0jphubQ*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$> > does not write telemetry data into the data packet itself but export > telemetry information in a specially constructed packet. > > And as we are talking about different IOAM trace options, the question of > the scope of this document seems appropriate. There is a WGLC on two IOAM > documents > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fippm*2FA0OcGQ5LlNjnjfRVp_iUTMYMrcs*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHOndSFRg*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DcHtvsgDl*2FuzSv70oS9LN5l2o5nEIwiKHDZ1sfiFJCrE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu2SsX7cg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=Y*2BwywuTSj4SpugrjmDTquAY0MZWKoT43CMjsyha*2FnOc*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FRADPxg$> > active through September 15th at the IPPM WG. I believe that it would be > beneficial if we had a single document that describes the applicability of > IOAM in all its functionality defined by documents in IPPM WG. Of course, > that cannot be a moving target as that would not be helpful. But since the > IPPM WG discusses the progress of two IOAM documents, it could be a great > time to address the applicability of the Direct Export trace type > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-ioam-direct-export*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKE0jphubQ*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$> > and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-ioam-flags*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHO7lReVw*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D1kqtcu3xjl1C7ytQ*2BoaKdiQN96rQt94e1S2ElC0nD3M*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt8NqRRKg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zzcnXlewWKrtEDv4BmsNNk4pvDlMKNKvPzBZ2dZJm5k*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-gOuTqwg$>. > It would be concerning to have more than one SFC document describing the > applicability of the generic IOAM mechanisms > > > > Shwetha> This is a fair point. We will revise the draft with text in the > abstract and Section 3 IOAM-Type to be updated to include the usage of > trace and DEX options. The encapsulation of IOAM options within NSH itself > in its current form already supports all the IOAM Option Type defined both > from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export > along with the flags supported within the options. Hence the > IOAM-data-field definitions in the draft will remain unchanged. > > GIM>> I agree that the definitions of the IOAM data-fields are invariant > in various data plane encapsulations. You likely follow the discussion of > the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that for > SFC NSH, IOAM Direct Export could be as simple as "use the local policy". > The applicability of the Loopback and Active flags seems to require > detailed explanation by SFP actors. > > > > > > > - The location of the IOAM header in the SFC NSH-encapsulated packet > is defined in Section 3: > > IOAM-Data-Fields are carried in NSH > > using a next protocol header which follows the NSH MD context > > headers. > > I've checked RFC 8300 but couldn't find it defines the Next Protocol > header. Also, it appears that NSH Context headers are optional. Hence my > question. Is the presence of an NSH Context header required when using > IOAM? Could you clarify which mechanism is used to identify the payload of > an SFC NSH-encapsulated packet as IOAM? > > Shwetha> We will reword it, it is not Next Protocol header but using IOAM > as a Next Protocol as described in Section 4.1 and requested in IANA > section. Following is the proposed text to align with the RFC 8300 > reference to context headers following base header and service path header: > > "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in > NSH using a next protocol to identify IOAM data fields that follows NSH > context headers." > > GIM>> I think that RFC 8300 views data following Context Headers as NSH > payload, not being "in NSH". > > > - If I understand the format of the IOAM header defined in Section 3 > correctly, the header's length is limited by 1020 octets, while the > effective length containing IOAM options and data - 1016 octets. Is that > correct? What is the recommended technique of collecting IOAM data that > exceeds that limit? > > Shwetha > IOAM options inherently support specifying the size limits at > the node that added the IOAM options. While operationalizing the solution > the data types included and number of nodes expected to be adding the data > should be selected. This is covered in deployment > considerations draft-brockners-opsawg-ioam-deployment. > > > - In Section 4.1, I've found the text reflecting the history of the > discussion about how to carry the IOAM header using NSH encapsulation. As > the text has no normative value, I suggest moving it into an Appendix. > > Shwetha > Agreed, revised draft will have this section moved to Appendix. > > GIM>> Thank you. > > > - I find the rules of handling the O-bit in NSH listed in Section 4.2 > inconsistent and confusing. The IOAM header is not part of NSH > encapsulation but is a part of the payload. But in one case, when user data > follows it, the O-bit must not be set as. If there's no user data after the > IOAM header, then the O-bit must be set. But from the perspective of NSH > encapsulation, it includes specially constructed data added for the sole > purpose of collecting OAM/telemetry information. Then, why, in one case, > the O-bit is cleared and in the other set if, in both cases, the > NSH-encapsulated packet is used to perform the OAM function? > > Shwetha > The reason for not setting the O-bit for packets that contains > actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier > implementations that do not support > > SFC OAM procedures SHOULD discard packets with O bit set". It will be undesirable to discard packets with O-bit set that carry user data as IOAM can be inserted insitu. > > For synthetic traffic created for OAM along with IOAM-data-fields in NSH following the NSH OAM function with 0-bit set is desirable. > > GIM>> This is an interesting situation. I agree that there could be an > SFC element not supporting "SFC OAM procedures" (not clear what these are). > By the same token, would such SFC element support IOAM, be capable of > processing IOAM without adverse impact to user data? I am not certain and > it seems that it might be better to recommend that NSH packets with IOAM be > dropped by an SFP element if it does not support "SFC OAM". What are your > thoughts? > > > > > > Thanks, > > Shwetha > > I much appreciate your consideration of my comments and questions and > looking forward to your feedback. > > > > Regards, > > Greg > > > > On Wed, Aug 18, 2021 at 5:32 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This email starts a 2 week Working Group Last Call for > draft-ietf-sfc-ioam-nsh [1]. > > > > Please read this document if you haven’t read the most recent version and > send your comments to the SFC WG list no later than September 1st 2021. > > > > If you are raising a point which you expect will be specifically debated > on the mailing list, consider using a specific email/thread for this point. > > > > Lastly, if you are an author or contributor please response to indicate > whether you know of any undisclosed IPR related to this document. > > > > Thanks! > > > > Jim & Joel > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-sfc-ioam-nsh*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHdTiRE6A*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D9uDdhw0ViwBtWvn52V8UZ2G77lRnSye2Ols5z3U8QwQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv33kGkLw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=S6sx7MrrVkzKepVgj45q*2F2KPZzBMyOFnol*2BMfgRQ730*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FOmuSHA$> > > > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > > _________________________________________________________________________________________________________________________ > > 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. > >
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Frank Brockners (fbrockne)
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… xiao.min2
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… mohamed.boucadair
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Greg Mirsky
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Joel Halpern
- Re: [ippm] [sfc] WGLC for https://datatracker.iet… Shwetha Bhandari