From nobody Wed Apr 27 03:07:02 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 D97B7C07C759 for ; Wed, 27 Apr 2022 01:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.993 X-Spam-Level: X-Spam-Status: No, score=-6.993 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.com header.b=QC+Vmsey; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=F6TuLXsx 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 X44aGHH4R5cX for ; Wed, 27 Apr 2022 01:06:10 -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 CF490C19E0EE for ; Wed, 27 Apr 2022 01:06:10 -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 23QLXtes002293 for ; Wed, 27 Apr 2022 01:06:09 -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=5IJdwLn5Ws3sgPJbadXRYcxmPfDVIe1myNXJZsVb0Lc=; b=QC+Vmsey+cdUaqpnvrS2QKbluwuQ4ncuH0a8yvwELNPKTFhuVigauCWdUIbuP8T0pfMO Qo56pFKIbQYpMQWvrPvRuLiR8S1boBgKULiHH81wP/pwuhfXoPw21TIZoibG7HVDkAZv m9fBg+C/Elo6MuL0Umq6bQ3PJ7DXxi6giDOR1YwULwtoj03B54Y8gf+8FfA7MDR/Nn5S vOw3yWEG5xv4+ibvLHWQAx6iuPRuO1m3ZoS28/RRqU1h58EhulKAwA1LdmPcPq6MtKWt zqLRyVXT85+Hg+fk9bNco8HEiGFp+pwPjaLQ7+APnYNI2FkSlbZjUBLKH6Cf+Gnwet89 fQ== Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3fprrth418-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 27 Apr 2022 01:06:09 -0700 Received: by mail-qk1-f197.google.com with SMTP id bs18-20020a05620a471200b0069f8c1c8b27so667970qkb.8 for ; Wed, 27 Apr 2022 01:06:09 -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=5IJdwLn5Ws3sgPJbadXRYcxmPfDVIe1myNXJZsVb0Lc=; b=F6TuLXsxugBYq8ZtgGV3T3/dzbUZCFo65O0Cx6x1tw5hitqEpfWW2FTJObtiMCv5eD tQBnp7xrksTBmIXSyykkswFHsZnYnAb1G7WEimLlX/hLxh8cICCHKRo9E3ij6rU+ZLQC yIUw2OWDxB2G2grWecSyNz9r0N9304qoYPY151LAXDNEOovnKk1jqQ5XrYmbGy/E5iUR OTWhTcPYVlOVhkt0bryGthUpTqQbN9pzEt+Sn/6FtZjbaw2J+9rq2dfJ+bksG93c+pqZ D+mtaRktdNlGBe51f372YiQjOZq/LNUzxFGBvq9awMSuwKRiZUBvNwRCn+Wwo1enbhKP XEiA== 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=5IJdwLn5Ws3sgPJbadXRYcxmPfDVIe1myNXJZsVb0Lc=; b=f/R5HDzrF0m63bZUW6UfIqBJz2hy1dDU9EKKF36d3Uf0l/Y1DpVw3iGFE6Kf4Yi/ot mHPeaHxXfTJ/6sCcmGpnXhWQYf9lR5RPHwdpdo5uL77qHmO8m033NfwgcEpCX0Pu2Ohe OP2d6vnbLfOXU0dfBg3CgYjbs1pcZ5np6/J3wjlDJnVXFo7S8ME/KT84inxzkesCdh1l 8dLngb3KQH0XBiadiVcWdEjUaGgYROeoqBKB0zolp2oS6p6bakl5jq5UmRY+BzQY0/iE zvOfS/36cd+ACre9fXwmS6BGo0z9/sV6l2j/o2frkwQ5oE6dg0VlisIZ/z85jWerFXqt moPQ== X-Gm-Message-State: AOAM531ljLvnuF8CP/9UGVtleB2Nfrc0Xw0PQGsb6n5VpJH+k658Cofn QPixg/rEtldiQ6Pn/J9PYhyQ+JFxsle+w6GVhw1ayO6fkf+q/oaTAYqJSVc9mmUgNOF3+pAnhI0 2kawISSXutubZJVgh+8jB X-Received: by 2002:a05:6214:27c9:b0:446:5771:397b with SMTP id ge9-20020a05621427c900b004465771397bmr18766625qvb.75.1651046768014; Wed, 27 Apr 2022 01:06:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyzFvpPz3xlLxtjzRi05CjkngwMbUEG4aBKkdZrMKOnPNYmt82dMbeKP1lpSFdWHarx7qEDv8Nh84pKzgyfqY= X-Received: by 2002:a05:6214:27c9:b0:446:5771:397b with SMTP id ge9-20020a05621427c900b004465771397bmr18766621qvb.75.1651046767751; Wed, 27 Apr 2022 01:06:07 -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: Wed, 27 Apr 2022 13:35:56 +0530 Message-ID: To: James Guichard , "sfc-chairs@ietf.org" Cc: Med Boucadair , "Frank Brockners (fbrockne)" , "sfc@ietf.org" , "ippm@ietf.org" , Tal Mizrahi , "draft-ietf-sfc-ioam-nsh@ietf.org" , Greg Mirsky Content-Type: multipart/alternative; boundary="00000000000019867305dd9e482f" X-Proofpoint-GUID: aRCAW4kzBu-44OaoNbphp1DkGaEmBLA8 X-Proofpoint-ORIG-GUID: aRCAW4kzBu-44OaoNbphp1DkGaEmBLA8 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_02,2022-04-26_02,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=950 clxscore=1015 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204270054 Archived-At: X-Mailman-Approved-At: Wed, 27 Apr 2022 03:07:01 -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: Wed, 27 Apr 2022 08:06:14 -0000 --00000000000019867305dd9e482f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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 consistent = 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 update= s >> 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] througho= ut >> 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 next >> protocol header chain is introduced in draft-ietf-sfc-oam-packet to upda= te >> 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 confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> --00000000000019867305dd9e482f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear SFC chairs,

A new version of the d= raft I-D.ietf-sfc-ioam-nsh has been submitted per the discussion in this th= read.
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 with Med, di= rect 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 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 be set, acco= rding to [I-D.ietf-sfc-oam-packet].

Regards,
Greg

<= div class=3D"gmail_quote">
On 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@th= oughtspot.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.boucadair@orange.com>= ;; Frank Brockners (fbrockne) <fbrockne=3D40cisco.com@dmarc.ietf.org>; sfc-chairs@ietf.org= ; sfc@ietf.org; ippm@ietf.org; James Guic= hard <james.n.guichard@futurewei.com>; Tal Mizrahi <tal.mizrahi.phd@gmail.com= >; draf= t-ietf-sfc-ioam-nsh@ietf.org
Objet=C2=A0: Re: [sfc] WGLC for https://datatracker.ietf.org/do= c/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 <gregimirsky@gmail.co= m> 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 <= ;shwe= tha.bhandari@thoughtspot.com> wrote:

Med,

=C2=A0

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

4.2<=
/a>.=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.
--00000000000019867305dd9e482f--