Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> Wed, 04 May 2022 03:23 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 AFF92C15E41E for <ippm@ietfa.amsl.com>; Tue, 3 May 2022 20:23:13 -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=ewb83J9w; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=hFRbU1OI
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 123XqjzC-TCw for <ippm@ietfa.amsl.com>; Tue, 3 May 2022 20:23:09 -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 A9E94C159A21 for <ippm@ietf.org>; Tue, 3 May 2022 20:23:08 -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 2440CB0F018294 for <ippm@ietf.org>; Tue, 3 May 2022 20:23:07 -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=2qkfegt+/LZ3OywRfLYOIB8YC946HIp8re4cw5U2sxk=; b=ewb83J9wTQ3nCzuB+8R9XvwR+QcpInMmNQhptBLuslYKksS+qyRy/rUgrGKUnsSgEq6G zL60uW2lRoHc3FzAoYE/RyCxM24JXZhzctD1e5Uyc0RNiJsJyh/ug4PmvnFcEOwxQlIT 7vJwDYNKNmUKQGxfmp5G+cLMvmlT98mzj3WaQK+Pz9FGWzvWA6gJSPe9Zh1pum3MXLhM vMwliWCsIhBdvyC4P2SDCRgdyJwIzl7fTxXTNvIVTM/jFWeCgOsv9xuChYuXgt+ukkb4 jtwCSSLjLHe7lOEyWbaDHBDEQyatqEr7OobcVedctmeqQop6GydxFZ6GjuTjGUv/hlLA gg==
Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3fs4kk8k5y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <ippm@ietf.org>; Tue, 03 May 2022 20:23:06 -0700
Received: by mail-qk1-f200.google.com with SMTP id x191-20020a3763c8000000b0069fb66f3901so159733qkb.12 for <ippm@ietf.org>; Tue, 03 May 2022 20:23:06 -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=2qkfegt+/LZ3OywRfLYOIB8YC946HIp8re4cw5U2sxk=; b=hFRbU1OIZUlVhizrb51gdbGf5U0TaaM4R7du6aZx6FcGKtnfm41/uRkA5Uy7X4pji/ 5QY+mkZCv4edDUx+fH4oJr1mvKJPa4UKPIoy4KOEiBBmwoZSxP4yTyheqc5tpR3soFIt 3f7RXZegS2yFNxd64ClUGQXEWymG0EC4g1cfrw6pM0ejLLO0GsXvWGXpNTPA0m+BSkw+ CTnlHH397rLj5rThG/ZZ7l+HK6ZifWivJMVBmVqUYfjjjAMVva55eNgQxCf3n5mudCuN t/B6XPZrvnx0eQ0PhfSSROliJwbaXFJmYnaxZJKUUqA0zMrOW4VeqclvTHOh+57TO3a6 OUuw==
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=2qkfegt+/LZ3OywRfLYOIB8YC946HIp8re4cw5U2sxk=; b=vo9K5ZPjRbwWM9ItoKyJyJbluIjP+ADXm0Uguc6y68b+m7MsvvfMMt90p0/pvWIZRf j1Pk2qDlm/dCVy9qj69+VQ75m6UkZlaEcXnAmNEg+a6ysHXhI910tCnVJDtyXZqrHdqm J1ixNt1wd8wiPc6Pa3mEMJ2sdGSxzB26uso4ZRBOPy7Y2C2NUqJtpebkUQppaLV0J4Cs JvZNV4DMiNoOGsrfij9CdU4hOnHBez/E/WLd7LOz7B9Jz03VLTXYl6dOVNBhJzbnFj3T HdEc96Gr/R108yNTf7TMUiVt6nHFzdps32Wy9MEUNHN2aU9HSIFpsqegYfeOGBwCquFj y99w==
X-Gm-Message-State: AOAM530LjfQSp4wHiqH0Cym6hzTrDQZKr4cglFSJBzEbERVCh06UDPpu djUPOokCUxG0ouNBk7MDuplew3Nowl5DHD8SX05dX/SxO5sQTgb3//4L/uyfLfDfJfohAcGEZcq mQt636j20vHr4NfT+Xp1i
X-Received: by 2002:ac8:7f12:0:b0:2f3:9f5c:360c with SMTP id f18-20020ac87f12000000b002f39f5c360cmr15068153qtk.509.1651634586021; Tue, 03 May 2022 20:23:06 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJyzWabvUZGDK6DSsSlve3U20YhrZc84U09mJ59hmbVnyY4uj0yLhEeRajQCHZMPrFsc2NmVXeTnJsCBjS18u2U=
X-Received: by 2002:ac8:7f12:0:b0:2f3:9f5c:360c with SMTP id f18-20020ac87f12000000b002f39f5c360cmr15068138qtk.509.1651634585722; Tue, 03 May 2022 20:23:05 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB4206C91446BA5FBBDA69E233D2FF9@MN2PR13MB4206.namprd13.prod.outlook.com> <11111_1649774342_62558F05_11111_493_4_a734de5265ca498bbabf9805a6eaf91d@orange.com> <CAMFZu3N03E-nWYJNik91e+X=gr3s2TVF03ZCM8i02ru4_Q82og@mail.gmail.com> <CA+RyBmWUZcUN2jnpUuyhTmkNpwvh=2prBZDGinWe2v-b3n8+MQ@mail.gmail.com> <CAMFZu3N5+GdFk13oWbi8F1qhgRNsKpSFwza61SG2oeMW9TvaLQ@mail.gmail.com> <525_1649935673_62580539_525_487_2_d0a4949b3d9c4424a0261012c7ce6188@orange.com> <CA+RyBmX3MdqVX5=hEsO+9SMbpXw+enwnm_qb4+-6smqbsTPPwg@mail.gmail.com> <CAMFZu3NZBgKXHrktn04LbwW33S+j+kGG5hx2A+1+jJ8aasCRag@mail.gmail.com> <14665_1651047374_6268FBCD_14665_484_6_addb2a5f712d4307a463d0582cc0a8a0@orange.com> <CAMFZu3O-vEAnrBE6rhuFh_POPD5E2i_bHvdBx=GUjRKxk3AOYw@mail.gmail.com> <3dba81e6-3a42-3643-dc98-a750891d47f5@joelhalpern.com> <CA+RyBmU+o5spc8M_54Voe+4E_A2M+Q2oE6LyJgSN4+=MCtVrcg@mail.gmail.com> <CAMFZu3MxRx5T3XgTJfBoCpgz1pH_4tNKSdk=NJ0DXELgnCRFxw@mail.gmail.com> <1e2f0696-658d-29d4-71f2-b96a3e088f4c@joelhalpern.com>
In-Reply-To: <1e2f0696-658d-29d4-71f2-b96a3e088f4c@joelhalpern.com>
From: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Date: Wed, 04 May 2022 08:52:53 +0530
Message-ID: <CAMFZu3McUxjVTrAoT6hOWOQtiWkKg1=vMpznHzTMs-Yha=oHRA@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Med Boucadair <mohamed.boucadair@orange.com>, James Guichard <james.n.guichard@futurewei.com>, sfc@ietf.org, ippm@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c7f80805de27247f"
X-Proofpoint-ORIG-GUID: -89qbkJs2feU2I3lq9WGZ3CWF69-bIp3
X-Proofpoint-GUID: -89qbkJs2feU2I3lq9WGZ3CWF69-bIp3
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-05-04_01,2022-05-02_03,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 priorityscore=1501 spamscore=0 mlxscore=0 mlxlogscore=999 bulkscore=5 adultscore=0 impostorscore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205040018
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ZuLtRc6tR9giftg0-382cfVYwMg>
X-Mailman-Approved-At: Wed, 04 May 2022 04:09:39 -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 <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: Wed, 04 May 2022 03:23:13 -0000
Why do we need to call that out explicitly in this draft? Isn't that part of header processing anyway? Thanks Shwetha On Wed, May 4, 2022, 6:24 AM Joel Halpern <jmh@joelhalpern.com> wrote: > Can we have just a sentence or two saying that if there are multiple iOAM > options, the SFF must check all of them for relevance and act on all > relevant ones? > > > Yours, > > Joel > On 5/3/2022 8:26 PM, Shwetha Bhandari wrote: > > Hi Greg, Joel, > > The purpose of these options are different. Reiterating the use cases > described in the draft-ietf-ippm-ioam-deployment draft : hop by hop tracing > related options are -pre-allocated, incremental,direct export. The > edge-to-edge option is not collecting trace but metrics at the edge and > helps in correlation e.g sequence number is inserted and used to identify > packet loss rate. The proof-of-transit option is used to prove that the > packet has traversed the check points in the networks. > There is also IOAM namespace that is used to collect specific data types > in trace options and a node can be configured to process trace options with > a specific namespace, this is useful when we have nodes with varying > implementation of trace option data types defined. > Restricting IOAM option in NSH to a specific number will make it difficult > to deploy. Hence I don't see a need to update the current draft to add any > of this restrictions. Let's use draft-ietf-ippm-ioam-deployment to > understand the use cases and deployment modes. > > Thanks > Shwetha > > > On Wed, May 4, 2022, 3:01 AM Greg Mirsky <gregimirsky@gmail.com> wrote: > >> Hi Joel, >> thank you for highlighting this question, I've missed it. >> >> As we've discussed earlier, several IOAM trace options have been defined: >> >> - pre-allocated >> - incremental >> - edge-to-edge >> - proof-of-transit >> - direct export >> - hybrid two-step >> >> I cannot find a scenario when using more than one IOAM trace option that >> could be beneficial, and useful for an operator. I think that if there is >> no use case, then the restricting number of IOAM trace options used is >> reasonable and helps implementors in developing interoperable >> implementations. >> >> Regards, >> Greg >> >> On Mon, May 2, 2022 at 2:42 PM Joel Halpern <jmh@joelhalpern.com> wrote: >> >>> (Sorry, catching up on some emails I missed.) >>> >>> If we want to allow multiple iOAM headers (up to the WG) then I think >>> the document needs to be clear on the meaning. If there are multiple are >>> all supposed to be processed, just the top one until something removes it, >>> a random one of the receivers choice? (Yes, that last is unlikely.) >>> >>> Yours, >>> >>> Joel >>> On 4/27/2022 4:44 AM, Shwetha Bhandari wrote: >>> >>> Hi Med, >>> >>> Thanks for the confirmation and quick review. >>> >>> On, >>> >>>> This means the new requested TBD_IOAM value will also be a valid next >>>> protocol. However, I wonder whether IOAM in IOAM in NSH is really something >>>> you want to have. If not, I suggest the text is updated to exclude it from >>>> the allowed value in the above excerpt. >>> >>> Per earlier discussion in this thread, quoting Frank's mail here for reference: >>> >>> 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. >>> >>> I think the text on Next Protocol should be as is. We should not add >>> restrictions on number of IOAM headers that could be added to the packet. >>> >>> Thanks, >>> Shwetha >>> >>> >>> >>> >>> On Wed, Apr 27, 2022 at 1:46 PM <mohamed.boucadair@orange.com> wrote: >>> >>>> Hi Shwetha, all, >>>> >>>> >>>> >>>> The changes look great. Thanks. >>>> >>>> >>>> >>>> There is one specific point not addressed in previous replies. This is >>>> related to this text: >>>> >>>> >>>> >>>> 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]. >>>> >>>> >>>> >>>> This means the new requested TBD_IOAM value will also be a valid next protocol. However, I wonder whether IOAM in IOAM in NSH is really something you want to have. If not, I suggest the text is updated to exclude it from the allowed value in the above excerpt. >>>> >>>> >>>> >>>> Other than that, I think that the draft is ready to move forward. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> >>>> >>>> *De :* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> >>>> *Envoyé :* mercredi 27 avril 2022 10:06 >>>> *À :* James Guichard <james.n.guichard@futurewei.com>; >>>> sfc-chairs@ietf.org >>>> *Cc :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; >>>> Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>; >>>> sfc@ietf.org; ippm@ietf.org; Tal Mizrahi <tal.mizrahi.phd@gmail.com>; >>>> draft-ietf-sfc-ioam-nsh@ietf.org; Greg Mirsky <gregimirsky@gmail.com> >>>> *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!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhHpnETuWA$> >>>> >>>> >>>> >>>> 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=draft-ietf-sfc-ioam-nsh-09 >>>> <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09__;!!MZ3Fw45to5uY!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhFd29kDew$> >>>> >>>> >>>> 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, 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 <mohamed.boucadair@orange.com> wrote: >>>> >>>> Hi Shwetha, >>>> >>>> >>>> >>>> I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet >>>> rather than “any update to RFC8300”. This is consistent with the usage in >>>> the other OAM draft. >>>> >>>> >>>> >>>> Thank you. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> >>>> >>>> *De :* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> >>>> *Envoyé :* jeudi 14 avril 2022 12:06 >>>> *À :* Greg Mirsky <gregimirsky@gmail.com> >>>> *Cc :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; >>>> Frank Brockners (fbrockne) <fbrockne=40cisco.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 :* 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!LWQuxxxKpUum5gUoK44-znjehj2YRtlGMOATxfRVSc-7JOrPsk4BA4iP0oLQE4d0rObPhOCG_1iiipywftwMIMOEWh8lJI4$> >>>> >>>> >>>> >>>> Hi Med, Greg, >>>> >>>> >>>> >>>> How about this text : >>>> >>>> >>>> >>>> “The O-bit MUST be handled following the rules in and any updates >>>> 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 <gregimirsky@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-packet] throughout >>>> 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 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>. IOAM and the use of the NSH O-bit* >>>> >>>> >>>> >>>> [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>] 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/ >>>> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$> >>>> >>>> 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 >>>> >>>> >>>> >>>> _________________________________________________________________________________________________________________________ >>>> >>>> >>>> >>>> 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. >>>> >>>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!MZ3Fw45to5uY!KzP7tEXj2r_E1qNyQ90q9rykJ0iG0HA0CecIGBFXEIXiWITYay7wwoC0HbiFfO2GyUarxht3JEY45vcV4uCtZ8Xkud0uv58$> >>> >>
- 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