[auth48] [IANA #1232801] [IANA] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review
Amanda Baber via RT <iana-matrix@iana.org> Fri, 01 July 2022 23:13 UTC
Return-Path: <iana-shared@icann.org>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9270C157B40; Fri, 1 Jul 2022 16:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level:
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 lw6eqDl27aok; Fri, 1 Jul 2022 16:12:59 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [192.0.33.81]) (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 4B708C14CF0F; Fri, 1 Jul 2022 16:12:59 -0700 (PDT)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 09457E772D; Fri, 1 Jul 2022 23:12:59 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id 0433220603; Fri, 1 Jul 2022 23:12:59 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <iana-matrix@iana.org>
Reply-To: iana-matrix@iana.org
In-Reply-To: <608A22F8-3AF3-47FC-BD70-658F3A1CE3A3@amsl.com>
References: <RT-Ticket-1232801@icann.org> <130D0F95-6EC8-41B6-84BD-7BFA55355CA1@amsl.com> <D3D92D3D-F1B8-436F-8846-5CFF3043D0CF@gmail.com> <608A22F8-3AF3-47FC-BD70-658F3A1CE3A3@amsl.com>
Message-ID: <rt-4.4.3-17995-1656717178-312.1232801-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1232801
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
To: apaloma@amsl.com
CC: zhuangshunwan@huawei.com, robert@raszuk.net, rfc-editor@rfc-editor.org, matthew.bocci@nokia.com, ketant.ietf@gmail.com, jorge.rabadan@nokia.com, gdawra.ietf@gmail.com, bruno.decraene@orange.com, bess-chairs@ietf.org, bess-ads@ietf.org, auth48archive@rfc-editor.org, andrew-ietf@liquid.tech
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Fri, 01 Jul 2022 23:12:58 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/rvOubq_vCI2sOj5m8Rbgpu_iPBA>
Subject: [auth48] [IANA #1232801] [IANA] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2022 23:13:03 -0000
Hi all, Sorry about the delay. This change has been made: https://www.iana.org/assignments/bgp-parameters Best regards, Amanda Baber IANA Operations Manager On Tue Jun 28 18:08:29 2022, apaloma@amsl.com wrote: > IANA, > > Please update your registries as follows to match the edited document > at https://www.rfc-editor.org/authors/rfc9252-diff.html. > > Please update the “BGP Prefix-SID TLV Types” registry > <https://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#bgp-prefix-sid-tlv-types> > to add “TLV” to "SRv6 L3 Service” and "SRv6 L2 Service". > > Old: > Value Type Reference > 5 SRv6 L3 Service [RFC-ietf-bess-srv6-services-15] > 6 SRv6 L2 Service [RFC-ietf-bess-srv6-services-15] > > New: > Value Type Reference > 5 SRv6 L3 Service TLV [RFC-ietf-bess-srv6-services- > 15] > 6 SRv6 L2 Service TLV [RFC-ietf-bess-srv6-services- > 15] > > Best regards, > RFC Editor/ap > > > On Jun 24, 2022, at 9:51 PM, Gaurav Dawra <gdawra.ietf@gmail.com> > > wrote: > > > > Approved. > > > > Sent from my iPhone > > > >> On Jun 24, 2022, at 1:57 PM, Alanna Paloma <apaloma@amsl.com> wrote: > >> > >> Hi Ketan and Robert, > >> > >> We have updated our files accordingly. > >> > >> We will await approval from Gaurav before asking IANA to update > >> their registry accordingly. > >> When the IANA update is complete, we will move forward with the > >> publication process. > >> > >> For the AUTH48 status of this document, please see: > >> https://www.rfc-editor.org/auth48/rfc9252 > >> > >> The files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9252.xml > >> https://www.rfc-editor.org/authors/rfc9252.txt > >> https://www.rfc-editor.org/authors/rfc9252.html > >> https://www.rfc-editor.org/authors/rfc9252.pdf > >> > >> The relevant diff files have been posted here: > >> https://www.rfc-editor.org/authors/rfc9252-diff.html (comprehensive > >> diff) > >> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html (AUTH48 > >> changes) > >> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last > >> version to this one) > >> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html (last > >> version to this one side by side) > >> > >> Thank you, > >> RFC Editor/ap > >> > >>> On Jun 24, 2022, at 12:35 PM, Robert Raszuk <robert@raszuk.net> > >>> wrote: > >>> > >>> Well since you opened that bxo Kentn, > >>> > >>> VRF does not stand as an abbreviation for "VPN Routing and > >>> Forwarding table - that is incorrect. > >>> > >>> VRF table == Virtual Routing and Forwarding table. > >>> > >>> With that the brackets are not needed and the entire description > >>> already deserves an errata :) > >>> > >>> Thx, > >>> R. > >>> > >>> On Fri, Jun 24, 2022 at 6:30 PM Ketan Talaulikar > >>> <ketant.ietf@gmail.com> wrote: > >>> Hi Alanna, > >>> > >>> A Minor nit came to my attention in Sec 1 > >>> OLD: End.DT (table look up in VPN Routing and Forwarding (VRF)) > >>> NEW: End.DT (look up in VPN Routing and Forwarding (VRF) table) > >>> > >>> Thanks, > >>> Ketan > >>> > >>> > >>> On Tue, Jun 21, 2022 at 11:58 PM Alanna Paloma <apaloma@amsl.com> > >>> wrote: > >>> Bruno, Jorge, Ketan, and Shunwan, > >>> > >>> Thank you for your replies. Your approvals have been noted on the > >>> AUTH48 status page. > >>> > >>> https://www.rfc-editor.org/auth48/rfc9252 > >>> > >>> Once we have received approvals from Gaurav and Robert, we will ask > >>> IANA to update > >>> their registry accordingly. After the IANA updates are complete, we > >>> will move forward > >>> with the publication process. > >>> > >>> Thank you, > >>> RFC Editor/ap > >>> > >>>>> On Jun 21, 2022, at 5:10 AM, bruno.decraene@orange.com wrote: > >>>> > >>>> Hi Alanna, RFC Editor, > >>>> > >>>> I approve latest version. > >>>> > >>>> Thank you > >>>> --Bruno > >>>> > >>>> > >>>> Orange Restricted > >>>> > >>>> -----Original Message----- > >>>> From: Alanna Paloma <apaloma@amsl.com> > >>>> Sent: Monday, June 20, 2022 11:41 PM > >>>> To: Andrew Alston - IETF <andrew-ietf@liquid.tech> > >>>> Cc: Rabadan, Jorge (Nokia - US/Sunnyvale) > >>>> <jorge.rabadan@nokia.com>; Ketan Talaulikar > >>>> <ketant.ietf@gmail.com>; DECRAENE Bruno INNOV/NET > >>>> <bruno.decraene@orange.com>; gdawra.ietf@gmail.com; > >>>> robert@raszuk.net; zhuangshunwan@huawei.com; rfc-editor@rfc- > >>>> editor.org; bess-ads@ietf.org; bess-chairs@ietf.org; Bocci, > >>>> Matthew (Nokia - GB) <matthew.bocci@nokia.com>; auth48archive@rfc- > >>>> editor.org > >>>> Subject: Re: AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6- > >>>> services-15> for your review > >>>> > >>>> Hi Andrew, > >>>> > >>>> Thank you for your reply. Your approval has been noted on the > >>>> AUTH48 status page. > >>>> > >>>> https://www.rfc-editor.org/auth48/rfc9252 > >>>> > >>>> We will await further word from the authors regarding updates > >>>> and/or approvals > >>>> prior to moving forward in the publication process. > >>>> > >>>> Thank you, > >>>> RFC Editor/ap > >>>> > >>>>> On Jun 20, 2022, at 11:23 AM, Andrew Alston - IETF <andrew- > >>>>> ietf@liquid.tech> wrote: > >>>>> > >>>>> I’m ok with the changes to 3.1 and and the addition in section 2. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Andrew > >>>>> > >>>>> > >>>>> From: Alanna Paloma <apaloma@amsl.com> > >>>>> Sent: Monday, June 20, 2022 8:22 PM > >>>>> To: Rabadan, Jorge (Nokia - US/Sunnyvale) > >>>>> <jorge.rabadan@nokia.com>; Ketan Talaulikar > >>>>> <ketant.ietf@gmail.com>; Andrew Alston - IETF <andrew- > >>>>> ietf@liquid.tech> > >>>>> Cc: bruno.decraene@orange.com; gdawra.ietf@gmail.com; > >>>>> robert@raszuk.net; zhuangshunwan@huawei.com; rfc-editor@rfc- > >>>>> editor.org; bess-ads@ietf.org; bess-chairs@ietf.org; Bocci, > >>>>> Matthew (Nokia - GB) <matthew.bocci@nokia.com>; > >>>>> auth48archive@rfc-editor.org > >>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6- > >>>>> services-15> for your review > >>>>> > >>>>> Ketan, Jorge, and *Andrew (AD), > >>>>> > >>>>> *Andrew (AD) - Please review and approve the change from “SHOULD” > >>>>> to “MUST” in > >>>>> Section 3.1, as well as the addition of “Layer 2 services” in > >>>>> Section 2. > >>>>> > >>>>> https://www.rfc-editor.org/authors/rfc9252-ad-diff.html > >>>>> > >>>>> Ketan and Jorge - Thank you for your replies. We have updated > >>>>> accordingly. > >>>>> > >>>>> FYI, we removed the following reference from the References > >>>>> section as its only > >>>>> occurrence was replaced with [RFC9012] in Section 1 per Ketan's > >>>>> request. > >>>>> > >>>>> [BGP-SR-POLICY] > >>>>> Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, > >>>>> P., Jain, D., and S. Lin, "Advertising Segment Routing > >>>>> Policies in BGP", Work in Progress, Internet-Draft, draft- > >>>>> ietf-idr-segment-routing-te-policy-17, 14 April 2022, > >>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-idr- > >>>>> segment-routing-te-policy-17>. > >>>>> > >>>>> The files have been posted here (please refresh): > >>>>> https://www.rfc-editor.org/authors/rfc9252.xml > >>>>> https://www.rfc-editor.org/authors/rfc9252.txt > >>>>> https://www.rfc-editor.org/authors/rfc9252.html > >>>>> https://www.rfc-editor.org/authors/rfc9252.pdf > >>>>> > >>>>> The relevant diff files have been posted here: > >>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html > >>>>> (comprehensive diff) > >>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html > >>>>> (AUTH48 changes) > >>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last > >>>>> version to this one) > >>>>> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html (last > >>>>> version to this one side by side) > >>>>> > >>>>> For the AUTH48 status of this document, please see: > >>>>> https://www.rfc-editor.org/auth48/rfc9252 > >>>>> > >>>>> Thank you, > >>>>> RFC Editor/ap > >>>>> > >>>>>> On Jun 17, 2022, at 11:17 AM, Rabadan, Jorge (Nokia - > >>>>>> US/Sunnyvale) <jorge.rabadan@nokia.com> wrote: > >>>>>> > >>>>>> Hi Alanna, > >>>>>> > >>>>>> I discussed offline with Ketan and we decided to modify a little > >>>>>> bit (for clarity) the second change that he suggested in his > >>>>>> last email: > >>>>>> > >>>>>> > >>>>>> For all occurrences in sections 6.1.1, 6.1.2, 6.2 (two > >>>>>> occurrences), 6.2.1, 6.2.2 (two occurrences) and 6.5 > >>>>>> > >>>>>> OLD: it is set to the Implicit NULL value. In either case, the > >>>>>> value is set in the 24 bits (e.g., as 0x000030 in the case of > >>>>>> Implicit NULL). > >>>>>> NEW: it is set to Implicit NULL in the higher-order 20 bits > >>>>>> (i.e., as 0x000030). In either case, the value is set in the 24 > >>>>>> bits. > >>>>>> > >>>>>> > >>>>>> Please let us know if you have questions. > >>>>>> Thank you. > >>>>>> Jorge > >>>>>> > >>>>>> > >>>>>> From: Ketan Talaulikar <ketant.ietf@gmail.com> > >>>>>> Date: Friday, June 17, 2022 at 1:32 PM > >>>>>> To: Alanna Paloma <apaloma@amsl.com> > >>>>>> Cc: bruno.decraene@orange.com <bruno.decraene@orange.com>, > >>>>>> gdawra.ietf@gmail.com<gdawra.ietf@gmail.com>, robert@raszuk.net > >>>>>> <robert@raszuk.net>, > >>>>>> zhuangshunwan@huawei.com<zhuangshunwan@huawei.com>, Rabadan, > >>>>>> Jorge (Nokia - US/Sunnyvale) <jorge.rabadan@nokia.com>, rfc- > >>>>>> editor@rfc-editor.org <rfc-editor@rfc-editor.org>, andrew- > >>>>>> ietf@liquid.tech <andrew-ietf@liquid.tech>, bess-ads@ietf.org > >>>>>> <bess-ads@ietf.org>, bess-chairs@ietf.org <bess- > >>>>>> chairs@ietf.org>, Bocci, Matthew (Nokia - GB) > >>>>>> <matthew.bocci@nokia.com>,auth48archive@rfc-editor.org > >>>>>> <auth48archive@rfc-editor.org> > >>>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6- > >>>>>> services-15> for your review > >>>>>> > >>>>>> Hi Alanna, > >>>>>> > >>>>>> There are 2 further changes based on the discussion below about > >>>>>> the original "high order 20 bits" error. > >>>>>> > >>>>>> https://mailarchive.ietf.org/arch/msg/bess/VN3_pFg5CbB337SQYFKDubR_EQM/ > >>>>>> > >>>>>> In sec 3.2.1 > >>>>>> > >>>>>> OLD: SRv6 SID value and put into high order bits of the MPLS > >>>>>> Label field. > >>>>>> NEW: SRv6 SID value and encoded in the MPLS Label field. > >>>>>> > >>>>>> For all occurrences in sections 6.1.1, 6.1.2, 6.2 (two > >>>>>> occurrences), 6.2.1, 6.2.2 (two occurrences) and 6.5 > >>>>>> > >>>>>> OLD: it is set to the Implicit NULL value. In either case, the > >>>>>> value is set in the 24 bits (e.g., as 0x000030 in the case of > >>>>>> Implicit NULL). > >>>>>> NEW: it is set to the Implicit NULL value (i.e., as 0x000030). > >>>>>> In either case, the value is set in the 24 bits. > >>>>>> > >>>>>> Thanks, > >>>>>> Ketan > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 17, 2022 at 6:13 AM Alanna Paloma <apaloma@amsl.com> > >>>>>> wrote: > >>>>>> Hi Ketan, > >>>>>> > >>>>>> Thank you for your reply. We updated the files as requested and > >>>>>> have > >>>>>> a couple of follow-up questions. > >>>>>> > >>>>>> 1) This suggested text needs further updating as the either/or > >>>>>> relationship > >>>>>> is not parallel. Please review and let us know if option A or B > >>>>>> reflects the > >>>>>> intended meaning. > >>>>>> > >>>>>> Suggested text: > >>>>>> To achieve efficient packing, this document allows 1) the > >>>>>> encoding of > >>>>>> the SRv6 Service SID as a whole in either the SRv6 Services > >>>>>> TLVs, or > >>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g., > >>>>>> Locator) > >>>>>> in the SRv6 Services TLVs and the encoding of the variable > >>>>>> (e.g., Function or Argument parts) in the existing label fields > >>>>>> specific to that service encoding. > >>>>>> > >>>>>> Perhaps (Moved “either” after allows): > >>>>>> A) To achieve efficient packing, this document allows either 1) > >>>>>> the encoding of > >>>>>> the SRv6 Service SID as a whole in the SRv6 Services TLVs or > >>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g., > >>>>>> Locator) > >>>>>> in the SRv6 Services TLVs and the encoding of the variable > >>>>>> (e.g., Function or Argument parts) in the existing label fields > >>>>>> specific to that service encoding. > >>>>>> > >>>>>> Or (Removed “either”): > >>>>>> B) To achieve efficient packing, this document allows 1) the > >>>>>> encoding of > >>>>>> the SRv6 Service SID as a whole in the SRv6 Services TLVs or > >>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g., > >>>>>> Locator) > >>>>>> in the SRv6 Services TLVs and the encoding of the variable > >>>>>> (e.g., Function or Argument parts) in the existing label fields > >>>>>> specific to that service encoding. > >>>>>> > >>>>>> 2) Regarding the terminology, we have not made any changes to > >>>>>> the terms > >>>>>> where you replied “Depends on the usage”. If any further updates > >>>>>> are required > >>>>>> for these, please let us know. > >>>>>> > >>>>>> The files have been posted here (please refresh): > >>>>>> https://www.rfc-editor.org/authors/rfc9252.xml > >>>>>> https://www.rfc-editor.org/authors/rfc9252.txt > >>>>>> https://www.rfc-editor.org/authors/rfc9252.html > >>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf > >>>>>> > >>>>>> The relevant diff files have been posted here: > >>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html > >>>>>> (comprehensive diff) > >>>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html > >>>>>> (AUTH48 changes) > >>>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last > >>>>>> version to this one) > >>>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last > >>>>>> version to this one side by side) > >>>>>> > >>>>>> Please review the document carefully and contact us with any > >>>>>> further > >>>>>> updates you may have. Note that we do not make changes once a > >>>>>> document is published as an RFC. > >>>>>> > >>>>>> We will await approvals from each author and the AD prior to > >>>>>> moving > >>>>>> this document forward in the publication process. > >>>>>> > >>>>>> For the AUTH48 status of this document, please see: > >>>>>> https://www.rfc-editor.org/auth48/rfc9252 > >>>>>> > >>>>>> Thank you, > >>>>>> RFC Editor/ap > >>>>>> > >>>>>>> On Jun 16, 2022, at 7:55 AM, Ketan Talaulikar > >>>>>>> <ketant.ietf@gmail.com> wrote: > >>>>>>> > >>>>>>> Hi Alanna, > >>>>>>> > >>>>>>> Thanks for resending and please check inline below for > >>>>>>> responses. > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Jun 16, 2022 at 6:45 AM Alanna Paloma > >>>>>>> <apaloma@amsl.com> wrote: > >>>>>>> Hi Ketan, > >>>>>>> > >>>>>>> The remaining unanswered queries are listed below. > >>>>>>> > >>>>>>> Additionally, they can be seen in the XML file as comments > >>>>>>> marked as: <!-- [rfced] ... —> > >>>>>>> > >>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml > >>>>>>> > >>>>>>> > >>>>>>> 1) <!--[rfced] We notice that the Abstract and Introduction use > >>>>>>> "SRv6-based BGP services" but the title and short title across > >>>>>>> the header in the pdf use "SRv6 BGP-based Overlay > >>>>>>> Services". Should the titles be updated per Option A or B > >>>>>>> below, > >>>>>>> or should the text in the Abstract and Introduction be updated > >>>>>>> to reflect "SRv6 BGP-based Overlay Services" for consistency? > >>>>>>> > >>>>>>> Also note that the abbreviations in the title have been > >>>>>>> expanded > >>>>>>> per Section 3.6 of RFC 7332 ("RFC Style Guide"). Please review. > >>>>>>> > >>>>>>> Original: > >>>>>>> SRv6 BGP based Overlay Services > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> A) > >>>>>>> Title: BGP Overlay Services Based on Segment Routing over IPv6 > >>>>>>> (SRv6) > >>>>>>> Short title: SRv6-Based BGP Overlay Services > >>>>>>> > >>>>>>> or > >>>>>>> > >>>>>>> B) > >>>>>>> Title: Segment Routing over IPv6 (SRv6) Overlay Services Based > >>>>>>> on BGP > >>>>>>> Short Title: SRv6 BGP-Based Overlay Services > >>>>>>> --> > >>>>>>> > >>>>>>> KT> (A) is more appropriate. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2) <!--[rfced] In this sentence, does "them" refer to > >>>>>>> "mechanisms" or "a variable > >>>>>>> part"? Please review and let us know how to update. > >>>>>>> > >>>>>>> Original: > >>>>>>> Section 4 describes mechanisms for signaling of the SRv6 > >>>>>>> Service SID > >>>>>>> by transposing a variable part of the SRv6 SID value and > >>>>>>> carrying > >>>>>>> them in existing MPLS label fields to achieve more efficient > >>>>>>> packing > >>>>>>> of those service prefix NLRIs in BGP update messages. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> A) (if referring to "mechanisms"): > >>>>>>> Section 4 describes mechanisms for the signaling of the SRv6 > >>>>>>> Service > >>>>>>> SID by transposing a variable part of the SRv6 SID value and > >>>>>>> carrying > >>>>>>> the mechanism in existing MPLS label fields to achieve more > >>>>>>> efficient > >>>>>>> packing of those service prefix NLRIs in BGP update messages. > >>>>>>> Or > >>>>>>> > >>>>>>> B) (if referring to "a variable part"): > >>>>>>> Section 4 describes mechanisms for the signaling of the SRv6 > >>>>>>> Service > >>>>>>> SID by transposing a variable part of the SRv6 SID value and > >>>>>>> carrying > >>>>>>> the variable part in existing MPLS label fields to achieve more > >>>>>>> efficient > >>>>>>> packing of those service prefix NLRIs in BGP update messages. > >>>>>>> --> > >>>>>>> > >>>>>>> KT> (B) is correct. Wouldn't "and carrying this variable part" > >>>>>>> KT> be better? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 3) <!--[rfced] This sentence is a bit tough to read. Please > >>>>>>> review the > >>>>>>> suggested text and let us know if this is agreeable or if you > >>>>>>> prefer otherwise. > >>>>>>> > >>>>>>> Original: > >>>>>>> To achieve efficient packing, this document allows the encoding > >>>>>>> of > >>>>>>> the SRv6 Service SID either as a whole in the SRv6 Services > >>>>>>> TLVs or > >>>>>>> the encoding of only the common part of the SRv6 SID (e.g., > >>>>>>> Locator) > >>>>>>> in the SRv6 Services TLVs and encoding the variable (e.g., > >>>>>>> Function > >>>>>>> or Argument parts) in the existing label fields specific to > >>>>>>> that > >>>>>>> service encoding. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> To achieve efficient packing, this document allows 1) the > >>>>>>> encoding of > >>>>>>> the SRv6 Service SID as a whole in either the SRv6 Services > >>>>>>> TLVs or > >>>>>>> the encoding of only the common part of the SRv6 SID (e.g., > >>>>>>> Locator) > >>>>>>> in the SRv6 Services TLVs and 2) the encoding of the variable > >>>>>>> (e.g., Function or Argument parts) in the existing label > >>>>>>> fields > >>>>>>> specific to that service encoding. > >>>>>>> --> > >>>>>>> > >>>>>>> > >>>>>>> KT> I get your point. I think the following conveys the correct > >>>>>>> KT> meaning: > >>>>>>> > >>>>>>> To achieve efficient packing, this document allows 1) the > >>>>>>> encoding of > >>>>>>> the SRv6 Service SID as a whole in either the SRv6 Services > >>>>>>> TLVs, or > >>>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g., > >>>>>>> Locator) > >>>>>>> in the SRv6 Services TLVs and the encoding of the variable > >>>>>>> (e.g., Function or Argument parts) in the existing label fields > >>>>>>> specific to that service encoding. > >>>>>>> > >>>>>>> > >>>>>>> 5) <!--[rfced] We note that RFC 8950 includes "IPv4 VPN Unicast > >>>>>>> over IPv6 > >>>>>>> Core" and "IPv4 VPN Multicast over IPv6 Core". Is "IPv4 VPN > >>>>>>> over > >>>>>>> IPv6 Core" okay as is, or should it be updated to reflect > >>>>>>> either > >>>>>>> of these forms? > >>>>>>> > >>>>>>> Original: > >>>>>>> The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 > >>>>>>> VPN > >>>>>>> Over IPv6 Core defined in [RFC8950]. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> A) The MP_REACH_NLRI over SRv6 core is encoded according to > >>>>>>> IPv4 VPN > >>>>>>> unicast over IPv6 core defined in [RFC8950]. > >>>>>>> > >>>>>>> Or > >>>>>>> > >>>>>>> B) The MP_REACH_NLRI over SRv6 core is encoded according to > >>>>>>> IPv4 VPN > >>>>>>> multicast over IPv6 core defined in [RFC8950]. > >>>>>>> --> > >>>>>>> > >>>>>>> KT> (A) is correct. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 6) <!--[rfced] The following text mentions where Route Types > >>>>>>> 1,2,3,5,6,7, > >>>>>>> and 8 are defined, but it does not mention where Route Type 4 > >>>>>>> is > >>>>>>> defined. Is this intentional, or would you like to include a > >>>>>>> citation where Route Type 4 is defined? If so, please > >>>>>>> provide that reference. > >>>>>>> > >>>>>>> Original: > >>>>>>> [RFC7432] defines Route > >>>>>>> Types 1, 2, and 3 which carry prefixes and MPLS Label fields; > >>>>>>> the > >>>>>>> Label fields have a specific use for MPLS encapsulation of EVPN > >>>>>>> traffic. Route Type 5 carrying MPLS label information (and thus > >>>>>>> encapsulation information) for EVPN is defined in [RFC9136]. > >>>>>>> Route > >>>>>>> Types 6, 7, and 8 are defined in [I-D.ietf-bess-evpn-igmp-mld- > >>>>>>> proxy]. > >>>>>>> --> > >>>>>>> > >>>>>>> KT> The Route Type 4 is defined in RFC7432 (https://www.rfc- > >>>>>>> KT> editor.org/rfc/rfc7432.html#section-7.4). We don't need to > >>>>>>> KT> refer to it and hence citation is also not required. This > >>>>>>> KT> is because that route type advertisement is unchanged from > >>>>>>> KT> the base spec RFC7432. The original text is therefore > >>>>>>> KT> intentional. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 7) <!--[rfced] May we update this sentence from "point-to-point > >>>>>>> services ID" to "point-to-point service IDs"? > >>>>>>> > >>>>>>> Original: > >>>>>>> EVPN Route Type 1 is also used in EVPN- > >>>>>>> VPWS as well as in EVPN flexible cross-connect; mainly used to > >>>>>>> advertise point-to-point services ID. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> EVPN Route Type 1 is also used in EVPN- > >>>>>>> VPWS as well as in EVPN-flexible cross-connect, mainly to > >>>>>>> advertise point-to-point service IDs. > >>>>>>> --> > >>>>>>> > >>>>>>> KT> Ack. Your suggestion above is better than the original. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 8) <!--[rfced] We have included some specific information about > >>>>>>> the IANA > >>>>>>> text below (mainly FYIs). In addition to reviewing those > >>>>>>> changes, please > >>>>>>> review all of the IANA-related updates carefully and let us > >>>>>>> know > >>>>>>> if any further updates are needed. > >>>>>>> > >>>>>>> A) FYI: For values 5 and 6, the Type names do not include "TLV" > >>>>>>> in the > >>>>>>> "BGP Prefix-SID TLV Types" subregistry. We will ask IANA to add > >>>>>>> "TLV" > >>>>>>> to the subregistry accordingly. > >>>>>>> > >>>>>>> Current (Table 1): > >>>>>>> | 5 | SRv6 L3 Service TLV | RFC 9252 | > >>>>>>> + - - - - - - - - - - - - - - - - - - - - + > >>>>>>> | 6 | SRv6 L2 Service TLV | RFC 9252 | > >>>>>>> > >>>>>>> Current (IANA registry): > >>>>>>> | 5 | SRv6 L3 Service | RFC 9252 | > >>>>>>> + - - - - - - - - - - - - - - - - - - - - + > >>>>>>> | 6 | SRv6 L2 Service | RFC 9252 | > >>>>>>> > >>>>>>> > >>>>>>> KT> Ack > >>>>>>> > >>>>>>> > >>>>>>> B) FYI: The registration procedures in Tables 2 and 4 do not > >>>>>>> match IANA's > >>>>>>> registration procedures under the "SRv6 Service Sub-TLV Types" > >>>>>>> and > >>>>>>> "SRv6 Service Sub-Sub-TLV Types" subregistries. We updated > >>>>>>> these > >>>>>>> tables to match the registries by changing the "Value" and > >>>>>>> "Type" > >>>>>>> headings to "Range" and "Registration Procedures", > >>>>>>> respectively; > >>>>>>> moving the value "0" and its corresponding information to > >>>>>>> Tables 3 > >>>>>>> and 5; and changing "Reserved" to "IETF Review" for value 255. > >>>>>>> > >>>>>>> Original: > >>>>>>> Value Type > >>>>>>> - - - - - - - - - - - - - - - - - - > >>>>>>> 0 Reserved > >>>>>>> 0-127 IETF Review > >>>>>>> 128-254 First Come First Served > >>>>>>> 255 Reserved > >>>>>>> > >>>>>>> Current (for Tables 2 and 4): > >>>>>>> Range Registration Procedures > >>>>>>> - - - - - - - - - - - - - - - - - - > >>>>>>> 0-127 IETF Review > >>>>>>> 128-254 First Come First Served > >>>>>>> 255 IETF Review > >>>>>>> > >>>>>>> > >>>>>>> KT> Ack > >>>>>>> > >>>>>>> > >>>>>>> C) FYI: Tables 3 and 5 have been updated to match the > >>>>>>> relevant IANA registries. Please review. > >>>>>>> --> > >>>>>>> > >>>>>>> KT> Ack > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 9) <!--[rfced] May we update "SRv6 SID Endpoint" to be "SRv6 > >>>>>>> Endpoint" to > >>>>>>> reflect usage throughout the document? > >>>>>>> > >>>>>>> Original: > >>>>>>> The SRv6 SID Endpoint behaviors implementing the services > >>>>>>> signalled > >>>>>>> in this document are defined in [RFC8986] and hence the > >>>>>>> security > >>>>>>> considerations of that document apply. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> The SRv6 Endpoint behaviors implementing the services signaled > >>>>>>> in this document are defined in [RFC8986]; hence, the security > >>>>>>> considerations of that document apply. > >>>>>>> --> > >>>>>>> > >>>>>>> KT> Ack. Your suggested change is better than the original. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 10) <!-- [rfced] FYI: The following reference has been deleted > >>>>>>> from the > >>>>>>> References section as it was only mentioned within the > >>>>>>> Implementation Status section, which has been deleted per your > >>>>>>> request. > >>>>>>> > >>>>>>> Removed: > >>>>>>> [I-D.matsushima-spring-srv6-deployment-status] > >>>>>>> Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman, > >>>>>>> K., and A. Dhamija, "SRv6 Implementation and Deployment > >>>>>>> Status", draft-matsushima-spring-srv6-deployment-status-13 > >>>>>>> (work in progress), March 2022. > >>>>>>> --> > >>>>>>> > >>>>>>> KT> Ack > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 11) <!--[rfced] Please review the "Inclusive Language" portion > >>>>>>> of the > >>>>>>> online Style Guide > >>>>>>> <https://www.rfc- > >>>>>>> editor.org/styleguide/part2/#inclusive_language> > >>>>>>> and let us know if any changes are needed. Note that our script > >>>>>>> did not flag any words in particular, but this should still be > >>>>>>> reviewed as a best practice. --> > >>>>>>> > >>>>>>> KT> Looks good to me. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 12) <!--[rfced] Throughout the text, the following terminology > >>>>>>> appears to be used > >>>>>>> inconsistently. Please review these occurrences and let us know > >>>>>>> if/how they > >>>>>>> may be made consistent. > >>>>>>> > >>>>>>> KT> In general, when referring to the name of a field, TLV/sub- > >>>>>>> KT> TLV, SID, etc. we have used the capitalized versions. In > >>>>>>> KT> other places, as "normal text", there should not be > >>>>>>> KT> capitalization. > >>>>>>> > >>>>>>> > >>>>>>> - SRv6 Service vs. SRv6 service > >>>>>>> > >>>>>>> KT> Depends on the usage > >>>>>>> > >>>>>>> > >>>>>>> - MPLS Label field vs. MPLS label field > >>>>>>> > >>>>>>> KT> "MPLS Label field" since we are referring to the name of a > >>>>>>> KT> field. > >>>>>>> > >>>>>>> - Endpoint Behavior vs. Endpoint behavior vs. endpoint behavior > >>>>>>> > >>>>>>> KT> I would think in almost all cases, "Endpoint Behavior" > >>>>>>> KT> would be more appropriate - but please correct me. > >>>>>>> > >>>>>>> - BGP Service vs. BGP service > >>>>>>> > >>>>>>> KT> Depends on the usage > >>>>>>> > >>>>>>> - Transposition Offset vs. transposition offset > >>>>>>> - Transposition Length vs. transposition length > >>>>>>> > >>>>>>> KT> Depends on the usage. > >>>>>>> > >>>>>>> - Transposition Scheme vs. transposition scheme > >>>>>>> > >>>>>>> KT> The capitalized version was used because we are referring > >>>>>>> KT> to the name of the scheme. > >>>>>>> > >>>>>>> KT> There is an error in the draft that has been thankfully > >>>>>>> KT> caught by a WG participant that we would like to fix. > >>>>>>> KT> Please see the thread > >>>>>>> KT> here:https://mailarchive.ietf.org/arch/msg/bess/puPdmGwKmmGMJaA_eW_vOM6Bk- > >>>>>>> KT> k/ > >>>>>>> > >>>>>>> The following change is required in the following places: > >>>>>>> - 6.1.1 para 2 > >>>>>>> - 6.1.2 para 2 > >>>>>>> - 6.2 para 4 and 5 > >>>>>>> - 6.2.1 para 1 > >>>>>>> - 6.2.2 para 1 and 2 > >>>>>>> - 6.5 para 4 > >>>>>>> > >>>>>>> OLD: the value is set in the high order 20 bits > >>>>>>> NEW: the value is set in the 24 bits > >>>>>>> > >>>>>>> KT> Additionally, I would like to suggest the following > >>>>>>> KT> editorial changes: > >>>>>>> > >>>>>>> OLD: [SEGMENT-ROUTING-TE-POLICY] > >>>>>>> NEW: If this is going to be replaced by RFC number since it is > >>>>>>> also in the RFCed Q, then that is ok. If not, I would suggest > >>>>>>> [SEGMENT-ROUTING-POLICY]. > >>>>>>> > >>>>>>> OLD: [IDR-SEGMENT-ROUTING-TE-POLICY] > >>>>>>> NEW: [BGP-SR-POLICY] > >>>>>>> > >>>>>>> OLD: [LSR-FLEX-ALGO] > >>>>>>> NEW: [IGP-FLEX-ALGO] > >>>>>>> > >>>>>>> I am yet to do a full review pass and will do so once these > >>>>>>> updates have been incorporated on the full diff against the > >>>>>>> original text. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Ketan > >>>>>>> > >>>>>>> —> > >>>>>>> > >>>>>>> Best regards, > >>>>>>> RFC Editor/ap > >>>>>>> > >>>>>>>> On Jun 15, 2022, at 11:28 AM, Ketan Talaulikar > >>>>>>>> <ketant.ietf@gmail.com> wrote: > >>>>>>>> > >>>>>>>> Hi Alanna, > >>>>>>>> > >>>>>>>> For some reason, I am unable to locate your first email (the > >>>>>>>> one with the questions?) in my mailbox. Could you please > >>>>>>>> resend it? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Ketan > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Jun 15, 2022 at 5:28 AM Alanna Paloma > >>>>>>>> <apaloma@amsl.com> wrote: > >>>>>>>> Authors and *Andrew (AD), > >>>>>>>> > >>>>>>>> *Andrew (AD) - Please review and approve the change from > >>>>>>>> “SHOULD” to “MUST” in > >>>>>>>> Section 3.1 in the diff file below. > >>>>>>>> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252-ad-diff.html > >>>>>>>> > >>>>>>>> Authors - Thank you for your reply. We have updated as > >>>>>>>> requested. > >>>>>>>> > >>>>>>>> Note that Bruno’s response only answered query 4). Please > >>>>>>>> review our previous mail > >>>>>>>> (sent on June 10, 2022) to review and respond the the > >>>>>>>> remaining queries. > >>>>>>>> > >>>>>>>> The files have been posted here (please refresh): > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252.txt > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml > >>>>>>>> > >>>>>>>> The relevant diff files are posted here: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html > >>>>>>>> (comprehensive diff) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html > >>>>>>>> (all AUTH48 changes) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html > >>>>>>>> (htmlwdiff diff between last version and this) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html > >>>>>>>> (rfcdiff between last version and this) > >>>>>>>> > >>>>>>>> Please review the document carefully as documents do not > >>>>>>>> change once > >>>>>>>> published as RFCs. > >>>>>>>> > >>>>>>>> We will await responses to our queries and any further changes > >>>>>>>> you may have, as well as > >>>>>>>> approvals from each author and the *AD prior to moving forward > >>>>>>>> in the publication process. > >>>>>>>> > >>>>>>>> Please see the AUTH48 status page for this document here: > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9252 > >>>>>>>> > >>>>>>>> Thank you, > >>>>>>>> RFC Editor/ap > >>>>>>>> > >>>>>>>>> On Jun 13, 2022, at 8:16 AM, bruno.decraene@orange.com wrote: > >>>>>>>>> > >>>>>>>>> *Andrew, ADs, Ketan 1rst & 2nd questions are for you. And > >>>>>>>>> checking the 3rd would be safer. Thanks. > >>>>>>>>> > >>>>>>>>> Hi RFC Editor, all, > >>>>>>>>> > >>>>>>>>> Thanks for the work. > >>>>>>>>> I've reviewed the diff and the full text. > >>>>>>>>> Please find below some proposed changes. > >>>>>>>>> > >>>>>>>>> ---- > >>>>>>>>> §3.1 > >>>>>>>>> In this doc, the semantic of all reserved fields are > >>>>>>>>> specified as MUST on the sender side, and MUST on the > >>>>>>>>> receiver side. (which is my personal preference, but I ignore > >>>>>>>>> if there is an IETF guideline on this) e.g. > >>>>>>>>> " RESERVED1 (1 octet): > >>>>>>>>> This field MUST be set to 0 by the sender and ignored by the > >>>>>>>>> receiver." > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> except the following text which is specified as SHOULD, MUST: > >>>>>>>>> > >>>>>>>>> " SRv6 Service SID Flags (1 octet): > >>>>>>>>> This field encodes SRv6 Service SID Flags -- none are > >>>>>>>>> currently > >>>>>>>>> defined. It SHOULD be set to 0 by the sender and any unknown > >>>>>>>>> flags MUST be ignored by the receiver." > >>>>>>>>> > >>>>>>>>> For consistency in this doc, I would propose > >>>>>>>>> OLD: SHOULD > >>>>>>>>> NEW: MUST > >>>>>>>>> > >>>>>>>>> ---- > >>>>>>>>> §5 > >>>>>>>>> " For service over SRv6 core, the egress PE sets the next hop > >>>>>>>>> to one of its IPv6 addresses." > >>>>>>>>> > >>>>>>>>> May be a personal preference, but I would prefer to make it > >>>>>>>>> explicit that "next hop" refers to the BGP Next Hop, as > >>>>>>>>> otherwise it would potentially be understood as the > >>>>>>>>> forwarding next hop of the egress PE (toward its CE), > >>>>>>>>> especially since the long previous paragraph refers to > >>>>>>>>> routing tables rather than BGP messages. > >>>>>>>>> > >>>>>>>>> OLD: the egress PE sets the next hop > >>>>>>>>> NEW: the egress PE sets the BGP Next Hop > >>>>>>>>> > >>>>>>>>> (next hop, next-hop, Next-Hop or whatever is usually used > >>>>>>>>> equally works for me) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ------- > >>>>>>>>> > >>>>>>>>> §10.2 > >>>>>>>>> " [IGMP-MLD-EVPN] > >>>>>>>>> Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, > >>>>>>>>> A., and P. Mattes, "Segment Routing Policy Architecture", > >>>>>>>>> Work in Progress, Internet-Draft, draft-ietf-spring- > >>>>>>>>> segment-routing-policy-22, 22 March 2022, > >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-spring- > >>>>>>>>> segment-routing-policy-22>. > >>>>>>>>> " > >>>>>>>>> > >>>>>>>>> The name of the reference seems (extremely) misleading to me. > >>>>>>>>> I would assume a typo > >>>>>>>>> OLD: [IGMP-MLD-EVPN] > >>>>>>>>> NEW: [SEGMENT-ROUTING-TE-POLICY] > >>>>>>>>> > >>>>>>>>> ------- > >>>>>>>>> > >>>>>>>>> §2 > >>>>>>>>> " TLV Type (1 octet): > >>>>>>>>> This field is assigned values from IANA's "BGP Prefix-SID TLV > >>>>>>>>> Types" subregistry." > >>>>>>>>> > >>>>>>>>> The field can only contain a single value. So I'd propose > >>>>>>>>> > >>>>>>>>> OLD: values > >>>>>>>>> NEW: a value > >>>>>>>>> > >>>>>>>>> ---- > >>>>>>>>> "Any unrecognized, received Sub-TLVs and Sub-Sub-TLVs MUST be > >>>>>>>>> removed." > >>>>>>>>> > >>>>>>>>> Personally I would not put a comma. But English typo is > >>>>>>>>> definitely not my expertise. So totally up to you. > >>>>>>>>> > >>>>>>>>> ---- > >>>>>>>>> §3 > >>>>>>>>> "SRv6 Service Sub-TLV Type (1 octet): > >>>>>>>>> This field identifies the type of SRv6 service information. > >>>>>>>>> It is > >>>>>>>>> assigned values from IANA's "SRv6 Service Sub-TLV Types" > >>>>>>>>> subregistry." > >>>>>>>>> > >>>>>>>>> The field can only contain a single value. So I'd propose > >>>>>>>>> > >>>>>>>>> OLD: values > >>>>>>>>> NEW: a value > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>> §3.2 > >>>>>>>>> > >>>>>>>>> SRv6 Service Data Sub-Sub-TLV Type (1 octet): > >>>>>>>>> This field identifies the type of Sub-Sub-TLV. It is assigned > >>>>>>>>> values from IANA's "SRv6 Service Data Sub-Sub-TLV Types" > >>>>>>>>> subregistry. > >>>>>>>>> > >>>>>>>>> The field can only contain a single value. So I'd propose > >>>>>>>>> > >>>>>>>>> OLD: values > >>>>>>>>> NEW: a value > >>>>>>>>> > >>>>>>>>> ---- > >>>>>>>>> §3.2.1 > >>>>>>>>> > >>>>>>>>> " While for an SRv6 > >>>>>>>>> SID, where the FL is 24 bits and only the lower order 20 bits > >>>>>>>>> are > >>>>>>>>> transposed (e.g., due to the limit of the MPLS label field > >>>>>>>>> size), the > >>>>>>>>> transposition offset is set to 68 and the transposition > >>>>>>>>> length is set > >>>>>>>>> to 20." > >>>>>>>>> > >>>>>>>>> I would not put the first comma. And I could rather use "for > >>>>>>>>> which" rather than "where" > >>>>>>>>> OLD: While for an SRv6 SID, where the FL is 24 bits > >>>>>>>>> NEW: While for an SRv6SID for which the FL is 24 bits > >>>>>>>>> > >>>>>>>>> However English is not my first language, so totally up to > >>>>>>>>> you. > >>>>>>>>> > >>>>>>>>> ----- > >>>>>>>>> §5 > >>>>>>>>> > >>>>>>>>> OLD: When the BGP route is received at an ingress PE is > >>>>>>>>> colored with a > >>>>>>>>> Color Extended Community and a valid SRv6 Policy is > >>>>>>>>> available, the > >>>>>>>>> steering for service flows is performed, as described in > >>>>>>>>> Section 8 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> NEW: When the BGP route received at an ingress PE is colored > >>>>>>>>> with a > >>>>>>>>> Color Extended Community and a valid SRv6 Policy is > >>>>>>>>> available, the > >>>>>>>>> steering for service flows is performed as described in > >>>>>>>>> Section 8 > >>>>>>>>> > >>>>>>>>> i.e. > >>>>>>>>> :s/is received/received > >>>>>>>>> :s/is performed, as described/ is performed as described > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> §6 > >>>>>>>>> > >>>>>>>>> Idem above. (except that the 2nd correction is already in > >>>>>>>>> place) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thank you, > >>>>>>>>> Regards, > >>>>>>>>> --Bruno > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Orange Restricted > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> > >>>>>>>>> Sent: Friday, June 10, 2022 10:56 PM > >>>>>>>>> To: gdawra.ietf@gmail.com; ketant.ietf@gmail.com; > >>>>>>>>> robert@raszuk.net; DECRAENE Bruno INNOV/NET > >>>>>>>>> <bruno.decraene@orange.com>; > >>>>>>>>> zhuangshunwan@huawei.com;jorge.rabadan@nokia.com > >>>>>>>>> Cc: rfc-editor@rfc-editor.org; bess-ads@ietf.org; bess- > >>>>>>>>> chairs@ietf.org; matthew.bocci@nokia.com; andrew- > >>>>>>>>> ietf@liquid.tech; auth48archive@rfc-editor.org > >>>>>>>>> Subject: AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6- > >>>>>>>>> services-15> for your review > >>>>>>>>> > >>>>>>>>> *****IMPORTANT***** > >>>>>>>>> > >>>>>>>>> Updated 2022/06/10 > >>>>>>>>> > >>>>>>>>> RFC Author(s): > >>>>>>>>> -------------- > >>>>>>>>> > >>>>>>>>> Instructions for Completing AUTH48 > >>>>>>>>> > >>>>>>>>> Your document has now entered AUTH48. Once it has been > >>>>>>>>> reviewed and > >>>>>>>>> approved by you and all coauthors, it will be published as an > >>>>>>>>> RFC. > >>>>>>>>> If an author is no longer available, there are several > >>>>>>>>> remedies > >>>>>>>>> available as listed in the FAQ (https://www.rfc- > >>>>>>>>> editor.org/faq/). > >>>>>>>>> > >>>>>>>>> You and you coauthors are responsible for engaging other > >>>>>>>>> parties > >>>>>>>>> (e.g., Contributors or Working Group) as necessary before > >>>>>>>>> providing > >>>>>>>>> your approval. > >>>>>>>>> > >>>>>>>>> Planning your review > >>>>>>>>> --------------------- > >>>>>>>>> > >>>>>>>>> Please review the following aspects of your document: > >>>>>>>>> > >>>>>>>>> * RFC Editor questions > >>>>>>>>> > >>>>>>>>> Please review and resolve any questions raised by the RFC > >>>>>>>>> Editor > >>>>>>>>> that have been included in the XML file as comments marked as > >>>>>>>>> follows: > >>>>>>>>> > >>>>>>>>> <!-- [rfced] ... --> > >>>>>>>>> > >>>>>>>>> These questions will also be sent in a subsequent email. > >>>>>>>>> > >>>>>>>>> * Changes submitted by coauthors > >>>>>>>>> > >>>>>>>>> Please ensure that you review any changes submitted by your > >>>>>>>>> coauthors. We assume that if you do not speak up that you > >>>>>>>>> agree to changes submitted by your coauthors. > >>>>>>>>> > >>>>>>>>> * Content > >>>>>>>>> > >>>>>>>>> Please review the full content of the document, as this > >>>>>>>>> cannot > >>>>>>>>> change once the RFC is published. Please pay particular > >>>>>>>>> attention to: > >>>>>>>>> - IANA considerations updates (if applicable) > >>>>>>>>> - contact information > >>>>>>>>> - references > >>>>>>>>> > >>>>>>>>> * Copyright notices and legends > >>>>>>>>> > >>>>>>>>> Please review the copyright notice and legends as defined in > >>>>>>>>> RFC 5378 and the Trust Legal Provisions > >>>>>>>>> (TLP – https://trustee.ietf.org/license-info/). > >>>>>>>>> > >>>>>>>>> * Semantic markup > >>>>>>>>> > >>>>>>>>> Please review the markup in the XML file to ensure that > >>>>>>>>> elements of > >>>>>>>>> content are correctly tagged. For example, ensure that > >>>>>>>>> <sourcecode> > >>>>>>>>> and <artwork> are set correctly. See details at > >>>>>>>>> <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>. > >>>>>>>>> > >>>>>>>>> * Formatted output > >>>>>>>>> > >>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>>>>>> formatted output, as generated from the markup in the XML > >>>>>>>>> file, is > >>>>>>>>> reasonable. Please note that the TXT will have formatting > >>>>>>>>> limitations compared to the PDF and HTML. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Submitting changes > >>>>>>>>> ------------------ > >>>>>>>>> > >>>>>>>>> To submit changes, please reply to this email using ‘REPLY > >>>>>>>>> ALL’ as all > >>>>>>>>> the parties CCed on this message need to see your changes. > >>>>>>>>> The parties > >>>>>>>>> include: > >>>>>>>>> > >>>>>>>>> * your coauthors > >>>>>>>>> > >>>>>>>>> * rfc-editor@rfc-editor.org (the RPC team) > >>>>>>>>> > >>>>>>>>> * other document participants, depending on the stream (e.g., > >>>>>>>>> IETF Stream participants are your working group chairs, the > >>>>>>>>> responsible ADs, and the document shepherd). > >>>>>>>>> > >>>>>>>>> * auth48archive@rfc-editor.org, which is a new archival > >>>>>>>>> mailing list > >>>>>>>>> to preserve AUTH48 conversations; it is not an active > >>>>>>>>> discussion > >>>>>>>>> list: > >>>>>>>>> > >>>>>>>>> * More info: > >>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- > >>>>>>>>> 4Q9l2USxIAe6P8O4Zc > >>>>>>>>> > >>>>>>>>> * The archive itself: > >>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>>>>>>> > >>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt > >>>>>>>>> out > >>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive > >>>>>>>>> matter). > >>>>>>>>> If needed, please add a note at the top of the message that > >>>>>>>>> you > >>>>>>>>> have dropped the address. When the discussion is concluded, > >>>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list > >>>>>>>>> and > >>>>>>>>> its addition will be noted at the top of the message. > >>>>>>>>> > >>>>>>>>> You may submit your changes in one of two ways: > >>>>>>>>> > >>>>>>>>> An update to the provided XML file > >>>>>>>>> — OR — > >>>>>>>>> An explicit list of changes in this format > >>>>>>>>> > >>>>>>>>> Section # (or indicate Global) > >>>>>>>>> > >>>>>>>>> OLD: > >>>>>>>>> old text > >>>>>>>>> > >>>>>>>>> NEW: > >>>>>>>>> new text > >>>>>>>>> > >>>>>>>>> You do not need to reply with both an updated XML file and an > >>>>>>>>> explicit > >>>>>>>>> list of changes, as either form is sufficient. > >>>>>>>>> > >>>>>>>>> We will ask a stream manager to review and approve any > >>>>>>>>> changes that seem > >>>>>>>>> beyond editorial in nature, e.g., addition of new text, > >>>>>>>>> deletion of text, > >>>>>>>>> and technical changes. Information about stream managers can > >>>>>>>>> be found in > >>>>>>>>> the FAQ. Editorial changes do not require approval from a > >>>>>>>>> stream manager. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Approving for publication > >>>>>>>>> -------------------------- > >>>>>>>>> > >>>>>>>>> To approve your RFC for publication, please reply to this > >>>>>>>>> email stating > >>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY > >>>>>>>>> ALL’, > >>>>>>>>> as all the parties CC’ed on this message need to see your > >>>>>>>>> approval. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Files > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>> The files are available here: > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.html > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.txt > >>>>>>>>> > >>>>>>>>> Diff file of the text: > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-rfcdiff.html (side > >>>>>>>>> by side) > >>>>>>>>> > >>>>>>>>> Diff of the XML: > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-xmldiff1.html > >>>>>>>>> > >>>>>>>>> The following files are provided to facilitate creation of > >>>>>>>>> your own > >>>>>>>>> diff files of the XML. > >>>>>>>>> > >>>>>>>>> Initial XMLv3 created using XMLv2 as input: > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.original.v2v3.xml > >>>>>>>>> > >>>>>>>>> XMLv3 file that is a best effort to capture v3-related format > >>>>>>>>> updates > >>>>>>>>> only: > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.form.xml > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Tracking progress > >>>>>>>>> ----------------- > >>>>>>>>> > >>>>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9252 > >>>>>>>>> > >>>>>>>>> Please let us know if you have any questions. > >>>>>>>>> > >>>>>>>>> Thank you for your cooperation, > >>>>>>>>> > >>>>>>>>> RFC Editor > >>>>>>>>> > >>>>>>>>> -------------------------------------- > >>>>>>>>> RFC9252 (draft-ietf-bess-srv6-services-15) > >>>>>>>>> > >>>>>>>>> Title : SRv6 BGP based Overlay Services > >>>>>>>>> Author(s) : G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. > >>>>>>>>> Decraene, S. Zhuang, J. Rabadan > >>>>>>>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski > >>>>>>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _________________________________________________________________________________________________________________________ > >>>>>>>>> > >>>>>>>>> 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. > >>>> > >>> > >>> > >> > >> > >
- [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-bess-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… bruno.decraene
- [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-ietf-… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Ketan Talaulikar
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Ketan Talaulikar
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Ketan Talaulikar
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Ketan Talaulikar
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Rabadan, Jorge (Nokia - US/Sunnyvale)
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9252 <draft-i… Andrew Alston - IETF
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Zhuangshunwan
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Ketan Talaulikar
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Rabadan, Jorge (Nokia - US/Sunnyvale)
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… bruno.decraene
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Robert Raszuk
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Ketan Talaulikar
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Robert Raszuk
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Gaurav Dawra
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Alanna Paloma
- [auth48] [IANA] AUTH48: RFC-to-be 9252 <draft-iet… Alanna Paloma
- [auth48] [IANA #1232801] [IANA] AUTH48: RFC-to-be… Amanda Baber via RT
- Re: [auth48] [IANA #1232801] [IANA] AUTH48: RFC-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Ketan Talaulikar
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-b… Ketan Talaulikar