From nobody Thu Apr 28 02:34:54 2022 Return-Path: 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 68FEBC14F727 for ; Wed, 27 Apr 2022 19:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=thoughtspot.com header.b=aLy3fBvI; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=ma0Rzv8u Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJa6gCGDb5Rx for ; Wed, 27 Apr 2022 19:55:56 -0700 (PDT) Received: from mx0a-0055fe01.pphosted.com (mx0a-0055fe01.pphosted.com [205.220.164.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 4F06EC157B39 for ; Wed, 27 Apr 2022 19:55:54 -0700 (PDT) Received: from pps.filterd (m0211451.ppops.net [127.0.0.1]) by mx0b-0055fe01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 23RNKDgp002315 for ; Wed, 27 Apr 2022 19:40:48 -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=lRxgTnhvHexn3He9Dvvz2RJvXK/10G72A3NMfx8bEI4=; b=aLy3fBvIkep7SCQzWrQqikihyn1zTFjF596nGfHz1duq3GShi7tDNZAKot/hflaW2EPa wKuNx0wcPwaI1QTkESs3y1eHb98ao0rwfM8hVGNshpQsvDOB3yH7MpWG0gNOaAcY6ZQK 8dMRmEk+4cWfndibzILwDZm0Rpa7PsEWT+vzhJR+Opy/ofnwQWsasN6tKUCBK22ov9K/ KGBZe/X/3pBA4XfeWXGveM7bskuXZHivoKzB1TV+VtaS3e4wfWOaNXqA/K9DcqATE0zZ PBG9wuJVTC2Pi1MGdRikaqo2vrBu6g87ZOUbGoIZo/3rd4yu9O/TR8VaYMDolLD1A10q bw== Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3fprrtkd34-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 27 Apr 2022 19:40:47 -0700 Received: by mail-qk1-f198.google.com with SMTP id u7-20020ae9d807000000b00680a8111ef6so2368113qkf.17 for ; Wed, 27 Apr 2022 19:40:47 -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=lRxgTnhvHexn3He9Dvvz2RJvXK/10G72A3NMfx8bEI4=; b=ma0Rzv8uAdbGwhjThdDO8t7aqgGMrpHn0dPfeojwkRad3KTutbehq4q89t9cNxCG9I aBqKvMVrhoUKRf/iAv1HSUAGQlLv6T4ZpeSNRFSurc/vUHyi2mK0dSWx0dec72IV4ABM teuix9XwMxI+kdnj3xDwn5lN63QS8VdnR6Zm4+FJufE9XO6qHWq+S0mSigAcLb4KecRf DS3YWV8FEyc691i0NscgznoQ4D3kooHnEGZF/xtzfbHJXuZDbf81tE5e/FUKd69/6BTQ vN3cHh8t71f+4nNousFLv4KEMbfR1M2utOyDOv/kFkGuB+VcSt8PrSwAVAAyEhaziBjc kJjw== 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=lRxgTnhvHexn3He9Dvvz2RJvXK/10G72A3NMfx8bEI4=; b=WFWn9Qp9xkWlctXm6RyYk3GbBM/4VusJP1FYwXVX/g/tNBcMzw3/GSbFleGXnd2Wge Vt3GvEggQjkaf/Byq/9KsRpXPYLHAeDt01t7O0BYKMw+MlUnrrIQFcb+PoAal8yU1do/ hH45K9uxHoybdbABMbPr6uKXU5kAG81qe9PCq06aV/WCvaWigQ1voN0Lmsw6+k3T3i95 gpf9gmXyur4a3rdjAlLKMUgu5ShfqdjorhPNe4+5ZWJb07K/KfCkQzjopDQP29L9NAxk NDbh24wjdaGM7sjmyjNkJBZIj6jR4EZUlB/kGgkd8z1a3gX0e3a+JxAxGRp2lwWmxKNe VICw== X-Gm-Message-State: AOAM530/tpnFiaqB7lht+yKJxQ5K67cC+k/eMM0/+SSSIKCNjvnrxymH H4eQ49xiHJ4TgWrDNepnJd8+2pDCV4ClbKmCbyImfWx66NC2bu3oTZV/FPYgrk4kG+784eq49Tv 0yyPvpwHSlmuwJ3YCSmE2 X-Received: by 2002:a05:620a:2a0f:b0:69f:1837:1fd with SMTP id o15-20020a05620a2a0f00b0069f183701fdmr17814383qkp.486.1651113646481; Wed, 27 Apr 2022 19:40:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycZq59QKtboKSnhw55DyXbJog4dDaWkEcazgkuJLCyZx8I9kdGHj/CGfFIpmEw6AcnlKn33yN0Ju+UwUelMGI= X-Received: by 2002:a05:620a:2a0f:b0:69f:1837:1fd with SMTP id o15-20020a05620a2a0f00b0069f183701fdmr17814369qkp.486.1651113646157; Wed, 27 Apr 2022 19:40:46 -0700 (PDT) MIME-Version: 1.0 References: <26916_1649050778_624A849A_26916_245_1_aa5a0049026247d9980f4ebbc8c5ac0b@orange.com> <11111_1649774342_62558F05_11111_493_4_a734de5265ca498bbabf9805a6eaf91d@orange.com> <525_1649935673_62580539_525_487_2_d0a4949b3d9c4424a0261012c7ce6188@orange.com> In-Reply-To: From: Shwetha Bhandari Date: Thu, 28 Apr 2022 08:10:33 +0530 Message-ID: To: Greg Mirsky Cc: James Guichard , sfc-chairs@ietf.org, Med Boucadair , "Frank Brockners (fbrockne)" , sfc@ietf.org, ippm@ietf.org, Tal Mizrahi , draft-ietf-sfc-ioam-nsh@ietf.org Content-Type: multipart/alternative; boundary="0000000000005d037c05ddaddac2" X-Proofpoint-GUID: _8zZeOshEsX2SWnTCZ2ltE0SSo_HrUeo X-Proofpoint-ORIG-GUID: _8zZeOshEsX2SWnTCZ2ltE0SSo_HrUeo 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-27_04,2022-04-27_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=5 mlxscore=0 suspectscore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 mlxlogscore=999 clxscore=1015 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204280013 Archived-At: X-Mailman-Approved-At: Thu, 28 Apr 2022 02:34:54 -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.34 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2022 02:56:00 -0000 --0000000000005d037c05ddaddac2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the confirmation on changes. There are 4 IOAM Option types defined in the draft-ietf-ippm-ioam-data that includes tracing, proof of transit and edge to edge option types. Then there is DEX Option type defined in draft-ietf-ippm-ioam-direct-export. Given this I think the current diagram covers all of this and any future Option types in a generic way to be carried in NSH. Hence I propose to keep the structure as is. Thanks Shwetha On Wed, Apr 27, 2022, 7:12 PM Greg Mirsky wrote: > Hi Shwetha, > thank you and the authors for the update. I agree with the updates. > In the course of reviewing the latest version I came up with a question > and appreciate your thoughts on it. The figure that displayed the format = of > an NSH with IOAM IOAM Option and Optional IOAM Data presented as a single > field. At the same time, there's no IOAM Option construct defined in > draft-ietf-ippm-ioam-data. As I understand it, IOAM Option relates to IOA= M > Option Trace headers defined: > > - Pre-allocated and Incremental > - Edge-to-Edge > - Proof-ot-Transit > - Direct Export > - Hybrid Two-Step > > Considering all that, I think it would be helpful to separate the IOAM > Option field, renaming it as IOAM Option Trace Header. And the Optional > IOAM Data field to follow. > What do you think? > > Regards, > Greg > > > On Wed, Apr 27, 2022 at 1:06 AM Shwetha Bhandari < > shwetha.bhandari@thoughtspot.com> wrote: > >> Dear SFC chairs, >> >> A new version of the draft I-D.ietf-sfc-ioam-nsh has been submitted per >> the discussion in this thread. >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-ioam-nsh-09 >> >> >> Can we please progress this draft to IESG if there are no further >> comments? >> >> Thanks, >> Shwetha >> >> On Thu, Apr 14, 2022 at 6:41 PM Greg Mirsky >> wrote: >> >>> Hi Shwetha, >>> thank you for the proposed resolution. I agree with Med, direct >>> normative reference to I-D.ietf-sfc-oam-packet seems like the logical >>> conclusion of our discussion of the use of the NSH O bit. Please note t= hat >>> we're referring to I-D.ietf-sfc-oam-packet in the Active SFC OAM draft, >>> e.g.,: >>> >>> The O bit in NSH MUST be set, according to [I-D.ietf-sfc-oam-packet]. >>> >>> >>> Regards, >>> Greg >>> >>> On Thu, Apr 14, 2022 at 4:27 AM wrote: >>> >>>> Hi Shwetha, >>>> >>>> >>>> >>>> I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet >>>> rather than =E2=80=9Cany update to RFC8300=E2=80=9D. This is consisten= t with the usage in >>>> the other OAM draft. >>>> >>>> >>>> >>>> Thank you. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> >>>> >>>> *De :* Shwetha Bhandari >>>> *Envoy=C3=A9 :* jeudi 14 avril 2022 12:06 >>>> *=C3=80 :* Greg Mirsky >>>> *Cc :* BOUCADAIR Mohamed INNOV/NET ; >>>> Frank Brockners (fbrockne) ; >>>> sfc-chairs@ietf.org; sfc@ietf.org; ippm@ietf.org; James Guichard < >>>> james.n.guichard@futurewei.com>; Tal Mizrahi ; >>>> draft-ietf-sfc-ioam-nsh@ietf.org >>>> *Objet :* Re: [sfc] WGLC for >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>>> >>>> >>>> >>>> >>>> Hi Med, Greg, >>>> >>>> >>>> >>>> How about this text : >>>> >>>> >>>> >>>> =E2=80=9CThe O-bit MUST be handled following the rules in and any upda= tes >>>> to [RFC8300] ." >>>> >>>> >>>> >>>> Given that I-D.ietf-sfc-oam-packet will update RF8300 and there could >>>> be others in future? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Shwetha >>>> >>>> >>>> >>>> On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky >>>> wrote: >>>> >>>> Hi Shwetha, >>>> >>>> I believe that the text you've quoted is helpful. I would suggest >>>> changing references from [RFC8300] to [I-D.ietf-sfc-oam-packet] throug= hout >>>> that paragraph. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> >>>> >>>> On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari < >>>> shwetha.bhandari@thoughtspot.com> wrote: >>>> >>>> Med, >>>> >>>> >>>> >>>> Thanks for the details: this is exactly what we had before the latest >>>> revision: >>>> >>>> *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. >>>> >>>> >>>> >>>> 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 nex= t >>>> protocol header chain is introduced in draft-ietf-sfc-oam-packet to up= date >>>> the RFC8300. >>>> >>>> Jim, What are you thoughts on this? Should we reintroduce the above >>>> text ? >>>> >>>> Thanks, >>>> Shwetha >>>> >>>> >>>> >>>> ______________________________________________________________________= ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privilege= d 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. >>>> >>>> --0000000000005d037c05ddaddac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

Tha= nks for the confirmation on changes.
There are 4 IOA= M Option types defined in the draft-ietf-ippm-ioam-data that includes traci= ng, proof of transit and edge to edge option types. Then there is DEX Optio= n type defined in dr= aft-ietf-ippm-ioam-direct-export. Given this I think the current diagram co= vers all of this and any future Option types in a generic way to be carried= in NSH. Hence I propose to keep the structure as is.

=
Thanks
Shwetha

=
On Wed, Apr 27, 2022, 7:12 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Shwetha,
thank you and the aut= hors for the update. I agree with the updates.
In the course of r= eviewing=C2=A0the latest version I came up with a question and appreciate y= our thoughts on it. The figure that displayed=C2=A0the format of an NSH wit= h IOAM IOAM Option and Optional IOAM Data presented as a single field. At t= he same time, there's no IOAM Option construct defined in draft-ietf-ip= pm-ioam-data. As I understand it, IOAM Option relates to IOAM Option Trace = headers defined:
  • Pre-allocated and Incremental
  • Ed= ge-to-Edge
  • Proof-ot-Transit
  • Direct Export
  • Hybrid Tw= o-Step
Considering all that, I think it would be helpful to s= eparate the IOAM Option field, renaming it as IOAM Option Trace Header. And= the Optional IOAM Data field to follow.
What do you think?=

Regards,
Greg


On We= d, Apr 27, 2022 at 1:06 AM Shwetha Bhandari <shwetha.bhand= ari@thoughtspot.com> wrote:
Dear SFC chairs,

A n= ew version of the draft I-D.ietf-sfc-ioam-nsh has been submitted per the di= scussion in this thread.
Can= we please progress this draft to IESG if there are no further comments?

Thanks,
Shwetha

On Thu, Apr 14, 2022= at 6:41 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Shwetha,
thank you for the proposed resolution. I agree w= ith Med, direct normative reference to I-D.ietf-sfc-oam-packet seems like t= he logical conclusion of our discussion of the use of the NSH O bit. Please= note that we're referring to I-D.ietf-sfc-oam-packet in the Active SFC= OAM draft, e.g.,:
The O bit in NSH MUST b= e set, according to [I-D.ietf-sfc-oam-packet].

Regards,
Greg
<= /div>
O= n Thu, Apr 14, 2022 at 4:27 AM <mohamed.boucadair@orange.com> wrote:

= Hi Shwetha,

= =C2=A0

I prefer we go for an explicit reference to I-D.ietf-sfc-oam= -packet rather than =E2=80=9Cany update to RFC8300=E2=80=9D. This is consis= tent with the usage in the other OAM draft.

=C2=A0

Thank you. =C2=A0

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Shwetha Bhandari <= shwetha.bhandari@thoughtspot.com>
Envoy=C3=A9=C2=A0: jeudi 14 avril 2022 12:06
=C3=80=C2=A0: Greg Mirsky <gregimirsky@gmail.com>
Cc=C2=A0: BOUCADAIR Mohamed INNOV/NET <mohamed.boucadai= r@orange.com>; Frank Brockners (fbrockne) <fbrockne=3D40c= isco.com@dmarc.ietf.org>; 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=C2=A0: Re: [sfc] WGLC for https://data= tracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

=C2=A0

Hi Med, Greg,=C2=A0

=C2=A0

How about this text :

=C2=A0

= =E2=80=9CThe O-bit MUST be handled following the rules in=C2=A0and any upda= tes to=C2=A0[RFC8300]=C2=A0."

=C2=A0

= Given that=C2=A0I-D.ietf-sfc-oam-packet=C2=A0 will update RF8300 and= there could be others in future?

=C2=A0

Thanks,

Shwetha

=C2=A0

On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky <g= regimirsky@gmail.com> wrote:

Hi Shwetha,

I believe that the text you've quoted is helpful= . I would suggest changing references from [RFC8300] to [I-D.ietf-sfc-oam-p= acket] throughout that paragraph.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari <= ;shwetha.bhandari@thoughtspot.com> wrote:

Med,

=C2=A0

Thanks for the details: this is exactly what we had = before the latest revision:

4.2.=C2=
=A0 IOAM and the use of the NSH O-bit
=C2=A0
=C2=A0=C2=A0 [RFC8300] defines an "O =
bit" for OAM packets.=C2=A0 Per [RFC8300] the O
=C2=A0=C2=A0 bit must be set for OAM packe=
ts and must not be set for non-OAM
=C2=A0=C2=A0 packets.=C2=A0 Packets with I=
OAM data included MUST follow this
=C2=A0=C2=A0 definition, i.e. the O bit MU=
ST NOT be set for regular customer
=C2=A0=C2=A0 traffic which also carries IO=
AM data and the O bit MUST be set for
=C2=A0=C2=A0 OAM packets which carry only =
IOAM data without any regular data
=C2=A0=C2=A0 payload.=

=C2=A0

This was removed as per the discussion in this threa= d. Please check https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/<= br>
It looks like we are going in a loop here. This definition of SFC OAM packe= t 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 RFC8= 300.

Jim, What are you thoughts on this? Should we reintr= oduce the above text ?

Thanks,
Shwetha

=C2=A0

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 message=
s 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 inf=
ormation 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 dele=
te 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.
--0000000000005d037c05ddaddac2--