Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review
"Voyer, Daniel" <daniel.voyer@bell.ca> Tue, 13 February 2024 18:21 UTC
Return-Path: <prvs=766021cb1=daniel.voyer@bell.ca>
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 251C1C151545; Tue, 13 Feb 2024 10:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bell.ca
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 W2SipupSkwhs; Tue, 13 Feb 2024 10:21:52 -0800 (PST)
Received: from ESA4-Dor.bell.ca (esa4-dor.bell.ca [204.101.223.61]) (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 E1CF8C14F5EE; Tue, 13 Feb 2024 10:21:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1707848512; x=1739384512; h=from:to:cc:date:message-id:content-id: content-transfer-encoding:mime-version:subject; bh=IpB6wXmBkZNKFXZvxDmNfAjHtrfRo9SlYG3T6H71984=; b=eRNsXW3WOAAnkN3WmwT4oV4PtpZqCe9tbRN3r3M11O75S44BKqbGbtk7 ODnv5CKLrdLwKGtycHPNPYylCKMIKW9aB7NTwkzAR5dPNxRBgoSUHMmWK cztWHjW/lBTmFt6lNsGrm8FYOj5Q5EjnEq3DlgdoR95aMsjczccrtk1yu sq/bBluRvWBSitb3QL+whWY/JB5CtK81JDpO3LzlLxhph3Bk9Wi1Dp+Wv V6DajWcM95qLXZr2LsC+SBCPax0WdIYorJnrWiRcyvog67v5y7RJ8fVGz KJDnL/LbKxKjkNdfs8WtZv6vjujGV85w2BLKR77rkhDQbacNOxCdK05gN A==;
Received: from dc5cmz-d01.bellca.int.bell.ca (HELO DG4MBX04-WYN.bell.corp.bce.ca) ([198.235.121.232]) by esa04corp-dor.bell.corp.bce.ca with ESMTP; 13 Feb 2024 13:21:50 -0500
Received: from DG4MBX01-WYN.bell.corp.bce.ca (142.182.18.27) by DG4MBX04-WYN.bell.corp.bce.ca (142.182.18.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 13 Feb 2024 13:21:49 -0500
Received: from DG4MBX01-WYN.bell.corp.bce.ca ([fe80::9d79:eeda:2c4:e2e1]) by DG4MBX01-WYN.bell.corp.bce.ca ([fe80::9d79:eeda:2c4:e2e1%4]) with mapi id 15.01.2507.035; Tue, 13 Feb 2024 13:21:49 -0500
From: "Voyer, Daniel" <daniel.voyer@bell.ca>
To: "Rishabh Parekh (riparekh)" <riparekh@cisco.com>, Megan Ferguson <mferguson@amsl.com>
CC: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, "hooman.bidgoli@nokia.com" <hooman.bidgoli@nokia.com>, "zzhang@juniper.net" <zzhang@juniper.net>, "spring-ads@ietf.org" <spring-ads@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "Mankamana Mishra (mankamis)" <mankamis@cisco.com>, "james.n.guichard@futurewei.com" <james.n.guichard@futurewei.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: [EXT]RE: AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review
Thread-Index: AQHaXqmCBIZvVmlNjkmte/2zoBrhjQ==
Date: Tue, 13 Feb 2024 18:21:49 +0000
Message-ID: <72817D07-E81A-4262-ABE7-246C8A2A7432@bell.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.81.24012814
x-originating-ip: [172.24.112.65]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8F5B31229823E446A59EC0ABB1FF39C1@exchange.bell.ca>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/6dlE-91YrMvR1Ol-cYyCLI1502c>
Subject: Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Tue, 13 Feb 2024 18:21:57 -0000
Hi, I have reviewed the document and I approve its publication. Thanks Dan On 2024-02-13, 1:18 PM, "Rishabh Parekh (riparekh)" <riparekh@cisco.com <mailto:riparekh@cisco.com>> wrote: I have reviewed the document and I approve the publication of this document. Thanks, -Rishabh > -----Original Message----- > From: Megan Ferguson <mferguson@amsl.com <mailto:mferguson@amsl.com>> > Sent: Monday, February 12, 2024 11:28 AM > To: Rishabh Parekh (riparekh) <riparekh@cisco.com <mailto:riparekh@cisco.com>> > Cc: rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>; daniel.voyer@bell.ca <mailto:daniel.voyer@bell.ca>; Clarence Filsfils (cfilsfil) > <cfilsfil@cisco.com <mailto:cfilsfil@cisco.com>>; hooman.bidgoli@nokia.com <mailto:hooman.bidgoli@nokia.com>; zzhang@juniper.net <mailto:zzhang@juniper.net>; spring- > ads@ietf.org <mailto:ads@ietf.org>; spring-chairs@ietf.org <mailto:spring-chairs@ietf.org>; Mankamana Mishra (mankamis) > <mankamis@cisco.com <mailto:mankamis@cisco.com>>; james.n.guichard@futurewei.com <mailto:james.n.guichard@futurewei.com>; > auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment- > 19> for your review > > Rishabh, > > Thank you for your reply and the updated file. We have reposted our version to > match. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9524.txt <https://www.rfc-editor.org/authors/rfc9524.txt> > https://www.rfc-editor.org/authors/rfc9524.pdf <https://www.rfc-editor.org/authors/rfc9524.pdf> > https://www.rfc-editor.org/authors/rfc9524.html <https://www.rfc-editor.org/authors/rfc9524.html> > https://www.rfc-editor.org/authors/rfc9524.xml <https://www.rfc-editor.org/authors/rfc9524.xml> > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9524-diff.html <https://www.rfc-editor.org/authors/rfc9524-diff.html> (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html> (comprehensive side- > by-side) > https://www.rfc-editor.org/authors/rfc9524-auth48diff.html <https://www.rfc-editor.org/authors/rfc9524-auth48diff.html> (all AUTH48 > changes) > https://www.rfc-editor.org/authors/rfc9524-lastdiff.html <https://www.rfc-editor.org/authors/rfc9524-lastdiff.html> (last version to this) > https://www.rfc-editor.org/authors/rfc9524-lastrfcdiff.html <https://www.rfc-editor.org/authors/rfc9524-lastrfcdiff.html> (last version to > this side-by-side) > > Upon review, please let us know if any further updates are necessary. > Please review the files carefully as we do not make changes after publication. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9524 <https://www.rfc-editor.org/auth48/rfc9524> > > Thank you. > > RFC Editor/mf > > > > > On Feb 9, 2024, at 4:23 PM, Rishabh Parekh (riparekh) <riparekh@cisco.com <mailto:riparekh@cisco.com>> > wrote: > > > > Replies inline @ [RP] > > > > I have made some of suggested changes in attached XML file. > > > > -Rishabh > > > >> -----Original Message----- > >> From: Megan Ferguson <mferguson@amsl.com <mailto:mferguson@amsl.com>> > >> Sent: Monday, February 5, 2024 5:05 PM > >> To: Rishabh Parekh (riparekh) <riparekh@cisco.com <mailto:riparekh@cisco.com>> > >> Cc: rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>; daniel.voyer@bell.ca <mailto:daniel.voyer@bell.ca>; Clarence > >> Filsfils (cfilsfil) <cfilsfil@cisco.com <mailto:cfilsfil@cisco.com>>; hooman.bidgoli@nokia.com <mailto:hooman.bidgoli@nokia.com>; > >> zzhang@juniper.net <mailto:zzhang@juniper.net>; spring- ads@ietf.org <mailto:ads@ietf.org>; spring-chairs@ietf.org <mailto:spring-chairs@ietf.org>; > >> Mankamana Mishra (mankamis) <mankamis@cisco.com <mailto:mankamis@cisco.com>>; > >> james.n.guichard@futurewei.com <mailto:james.n.guichard@futurewei.com>; auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> > >> Subject: Re: AUTH48: RFC-to-be 9524 > >> <draft-ietf-spring-sr-replication-segment- > >> 19> for your review > >> > >> Hi Rishabh, > >> > >> Thank you for sending along your edited file and responses to our queries. > >> > >> We have combined the two and posted the updated files below. > >> > >> We also had a few additional questions: > >> > >> 1.) It looks like we missed sending the following question: > >> > >> <!--[rfced] We had a few questions regarding the following text: > >> > >> Original: > >> Given the definition of the Replication segment in this document, an > >> attacker subverting ingress filter above cannot take advantage of a > >> stack of replication segments to perform amplification attacks nor link > exhaustion attacks. > >> > >> a) Would it be helpful to the reader to point them to the section in > >> which they can find the definition of “Replication segment” (i.e., Section 1.1, > Section 2)? > > > > [RP] I don't think it is necessary to refer to the definition. We can assume the > reader has read the preceding sections before the Security section. > > > >> > >> b) It might help the reader to clarify what/where “above” is referring to. > >> We see this as the only instance of “ingress filters” in the document. > >> > > > > [RP] I don't think it is necessary, but if the RFC editors think it will help to > clarify "above", please do so. > > > >> c) (Maybe depending on the response to b above) Should “subverting > >> ingress filter” > >> be made either “subverting ingress filters” (plural) or “subverting > >> an ingress filter”? > >> > > > > [RP] I see that latest XML has changed this to plural "ingress filters" which is > fine. > > > >> —> > >> > >> 2.) And we would like you to further review the use of “Replication state” vs. > >> “Replication segment state”. > >> > > > > [RP] I have changed text for "Replication segment state" in the attached XML > file. > > > >> 3) In the pseudocode, may we put parentheses around the following? > >> > >> Original: > >> S01. Lookup FUNCT portion of S to get Replication state RS > >> > >> Perhaps: > >> S01. Lookup FUNCT portion of S to get Replication state (RS) > > > > [RP] I have made the change in attached XML file. > > > >> > >> The files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9524.txt <https://www.rfc-editor.org/authors/rfc9524.txt> > >> https://www.rfc-editor.org/authors/rfc9524.pdf <https://www.rfc-editor.org/authors/rfc9524.pdf> > >> https://www.rfc-editor.org/authors/rfc9524.html <https://www.rfc-editor.org/authors/rfc9524.html> > >> https://www.rfc-editor.org/authors/rfc9524.xml <https://www.rfc-editor.org/authors/rfc9524.xml> > >> > >> The relevant diff files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9524-diff.html <https://www.rfc-editor.org/authors/rfc9524-diff.html> (comprehensive) > >> https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html> > >> (comprehensive side- > >> by-side) > >> https://www.rfc-editor.org/authors/rfc9524-auth48diff.html <https://www.rfc-editor.org/authors/rfc9524-auth48diff.html> (AUTH48 > >> changes > >> only) > >> > >> Upon review, please let us know if any further updates are necessary. > >> Please review the files carefully as we do not make changes after publication. > >> > >> We will await approvals from each of the parties listed on the AUTH48 > >> status page prior to moving forward to publication. > >> > >> The AUTH48 status page for this document is available here: > >> > >> https://www.rfc-editor.org/auth48/rfc9524 <https://www.rfc-editor.org/auth48/rfc9524> > >> > >> Thank you. > >> > >> RFC Editor/mf > >> > >>> On Jan 26, 2024, at 6:40 PM, Rishabh Parekh (riparekh) > >> <riparekh=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> wrote: > >>> > >>> I have made some of the suggested modifications in the attached XML > >>> file. For other questions and concerns, please look for my inline > >>> replies @ [RP] > >>> > >>> Thanks, > >>> -Rishabh > >>> > >>>> -----Original Message----- > >>>> From: rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org> <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>> > >>>> Sent: Friday, January 19, 2024 11:15 AM > >>>> To: daniel.voyer@bell.ca <mailto:daniel.voyer@bell.ca>; Clarence Filsfils (cfilsfil) > >>>> <cfilsfil@cisco.com <mailto:cfilsfil@cisco.com>>; Rishabh Parekh (riparekh) > >>>> <riparekh@cisco.com <mailto:riparekh@cisco.com>>; hooman.bidgoli@nokia.com <mailto:hooman.bidgoli@nokia.com>; zzhang@juniper.net <mailto:zzhang@juniper.net> > >>>> Cc: rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>; spring-ads@ietf.org <mailto:spring-ads@ietf.org>; > >>>> spring-chairs@ietf.org <mailto:spring-chairs@ietf.org>; Mankamana Mishra (mankamis) > >>>> <mankamis@cisco.com <mailto:mankamis@cisco.com>>; james.n.guichard@futurewei.com <mailto:james.n.guichard@futurewei.com>; > >>>> auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> > >>>> Subject: Re: AUTH48: RFC-to-be 9524 > >>>> <draft-ietf-spring-sr-replication-segment- > >>>> 19> for your review > >>>> > >>>> Authors, > >>>> > >>>> While reviewing this document during AUTH48, please resolve (as > >>>> necessary) the following questions, which are also in the XML file. > >>>> > >>>> 1) <!-- [rfced] Please note that the title of the document has been > >>>> updated as follows: > >>>> > >>>> a. Abbreviations have been expanded per Section 3.6 of RFC 7322 > >>>> (“RFC Style Guide”). Additionally, please let us know any > >>>> suggestions for reducing the redundancy of "Segment" (see our suggestion > below). > >>>> > >>>> b. We have also removed the hyphen from "Multi-point" for > >>>> consistency with previous RFCs (in the title and throughout). > >>>> Please review and let us know any objections. > >>>> > >>>> Original: > >>>> > >>>> SR Replication segment for Multi-point Service Delivery > >>>> > >>>> Current: > >>>> > >>>> Segment Routing Replication Segment for Multipoint Service Delivery > >>>> > >>>> Perhaps: > >>>> Segment Routing Replication for Multipoint Service Delivery > >>>> --> > >>>> > >>> > >>> [RP] I have changed the tile in the edited XML file. > >>> > >>>> > >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>>> the title) for use on https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>. > >>>> --> > >>>> > >>>> > >>>> 3) <!--[rfced] We see the following three similar sentences in close > >>>> proximity: > >>>> > >>>> Original: > >>>> This Replication segment can be either provisioned locally on > >>>> ingress and egress nodes, or using dynamic auto-discovery > >>>> procedures for MVPN > >> and EVPN. > >>>> > >>>> and > >>>> > >>>> Original: > >>>> A Replication segment is a local segment instantiated at a > >>>> Replication node. It can be either provisioned locally on a node > >>>> or > >> programmed by a control plane. > >>>> > >>> > >>> [RP] In this sentence the control plane refers to something like a > >>> PCE rather > >> than MVPN or EVPN (as used for ingress replication). > >>> > >>>> and > >>>> > >>>> Original: > >>>> Replication segments can be stitched together to form a tree by > >>>> either local provisioning on nodes or using a control plane. > >>> > >>> [RP] Again, the control plane refers to PCE in this context as > >>> explained later in > >> the paragraph. > >>> > >>>> > >>>> a) Please confirm our update to the first sentence (see below) > >>>> correctly captures your intent. Our goal is to make the two > >>>> phrases joined by > >> "either" > >>>> symmetrical. > >>>> > >>>> Perhaps: > >>>> This Replication segment can be either provisioned locally on > >>>> ingress and egress nodes or using dynamic autodiscovery procedures > >>>> for MVPN and > >> EVPN. > >>> > >>> [RP] I have rearranged the first sentence to make both options > >>> (local and > >> dynamic) symmetrical. > >>> > >>>> > >>>> b) Please review the three similar sentences listed above and > >>>> ensure that they do not need to be made more uniform and/or review > >>>> if redundancy should be reduced. > >>>> > >>>> --> > >>>> > >>>> > >>>> 4) <!--[rfced] In the following, does "Anycast set" mean "a set of > >>>> Anycast SIDs"? Note: this text occurs two times in the text. > >>>> > >>>> Original: > >>>> * A Replication node MAY use an Anycast SID or a Border Gateway > >>>> Protocol (BGP) PeerSet SID in segment list to send a > >>>> replicated packet to one downstream Replication node in an Anycast > set... > >>>> > >>>> > >>>> --> > >>> > >>> [RP] Anycast-SID is one SID that is shared by multiple nodes in an Anycast > set. > >> I have re-worded the sentence to make this clear. > >>> > >>>> > >>>> > >>>> 5) <!-- [rfced] We had the following questions regarding the pseudocode in > >>>> Section 2.2.1. > >>>> > >>>> a) The following line exceeds the 72-character limit. Please let us > >>>> know how this line can be modified. > >>>> > >>>> Original: > >>>> > >>>> S03. Discard the packet > >>>> S04. # ICMPv6 Time Exceeded is not permitted (ICMPv6 section below) > >>>> S05. } > >>>> > >>>> Perhaps: > >>>> > >>>> S03. Discard the packet > >>>> S04. # ICMPv6 Time Exceeded is not permitted > >>>> (ICMPv6 section below) > >>>> S05. } > >>>> > >>> > >>> [RP] Fixed > >>> > >>>> b) Will it be clear what "ICMPv6 section below" in the > >>>> parenthetical in point a) above refers to? Should this be replaced > >>>> by a specific section number. Note this occurs more than once. > >>>> > >>> > >>> [RP] Although it should be clear that this refers to Section 2.2.3, > >>> changing this > >> to an explicit reference is fine. > >>> > >>>> c) We note that there is no space between PPC and its expansion. > >>>> May we make the following updates? > >>>> > >>>> Original: > >>>> S20. Derive packet processing context(PPC) from Segment List > >>>> > >>>> Perhaps: > >>>> S20. Derive packet processing context (PPC) from Segment List > >>>> > >>>> Original: > >>>> S28. Derive packet processing context(PPC) > >>>> > >>>> Perhaps: > >>>> S28. Derive packet processing context (PPC) > >>> > >>> [RP] Fixed. > >>> > >>>> > >>>> d) In the pseudocode, we see Upper-layer Header. In other parts of > >>>> the document, we mostly see Upper-Layer header (but upper layer > >>>> headers also appears). Please let us know if/how these terms may > >>>> be made consistent in both the pseudocode and the body of the > document. > >>>> > >>>> Original: > >>>> S12. # (SR Upper-layer Header Error) > >>>> > >>>> Perhaps: > >>>> S12. # (SR Upper-Layer header Error) > >>>> > >>> > >>> [RP] RFC 8986 uses "Upper-Layer Header" with capital H in title of > >>> Section > >> 4.1.1 and "Upper-Layer header" in rest of the text. I think we can > >> use the same approach. > >>> > >>>> e) Please review our update to the reference to RFC 8986 in the > >>>> pseudocode and let us know any concerns. > >>>> > >>>> Original: > >>>> S09. Execute H.Encaps or H.Encaps.Red with RS.Segment-List > >>>> on packet copy #RFC 8986 Section 5.1, 5.2 > >>>> > >>>> Current: > >>>> S09. Execute H.Encaps or H.Encaps.Red with RS.Segment-List > >>>> on packet copy #RFC 8986, Sections 5.1 and 5.2 > >>>> > >>>> > >>> > >>> [RP] This is fine. > >>> > >>>> --> > >>>> > >>>> > >>>> 6) <!--[rfced] In the first sentence, "transit node" is singular. In the > >>>> second, it's plural (i.e., "The transit nodes..."). Please > >>>> review and let us know if/how updates should be made for clarity. > >>>> > >>>> Original: > >>>> The source can then send the Echo Request packet to a transit > >>>> node's Replication SID. The transit nodes replicate the packet by > >>>> replacing the IPv6 destination address till the packet reaches the > >>>> Leaf/Bud node which responds with an ICMPv6 Echo Reply. > >>>> > >>>> Perhaps: > >>>> The source can then send the Echo Request packet to a transit > >>>> node's Replication SID. The transit node replicates the packet by > >>>> replacing the IPv6 destination address until the packet reaches the > >>>> Leaf/Bud node, which responds with an ICMPv6 Echo Reply. > >>> > >>> [RP] I have made the suggested change in edited XML file. > >>> > >>>> > >>>> --> > >>>> > >>>> > >>>> 7) <!--[rfced] In the following text: > >>>> > >>>> Original: > >>>> Traceroute to a Leaf/Bud node Replication SID is not possible due > >>>> to restriction prohibiting origination of ICMPv6 Time Exceeded > >>>> error message for a Replication SID as described in the section below. > >>>> > >>>> Current: > >>>> Traceroute to a Leaf/Bud node Replication SID is not possible due > >>>> to restrictions prohibiting the origination of the ICMPv6 Time > >>>> Exceeded error message for a Replication SID as described in Section 2.2.3. > >>>> > >>>> a) Please review our update to make "restrictions" plural. > >>>> > >>>> b) Please also confirm the update to point to Section 2.2.3. > >>>> > >>> > >>> [RP] The changes are fine. > >>> > >>>> --> > >>>> > >>>> > >>>> 8) <!--[rfced] In the following, the close proximity of two occurrences > >>>> of "from" makes this sentence possibly difficult to parse on a > >>>> single read-through. Might the following suggested text be > >>>> acceptable? > >>>> > >>>> Original: > >>>> This is to prevent a storm of ICMPv6 error messages resulting from > >>>> replicated > >>>> IPv6 packets from overwhelming a source node. > >>>> > >>>> Perhaps: > >>>> This is to prevent a source node from being overwhelmed by a storm > >>>> of > >>>> ICMPv6 error messages resulting from replicated IPv6 packets. > >>>> --> > >>>> > >>> > >>> [RP] I have made the suggested change in edited XML file. > >>> > >>>> > >>>> 9) <!--[rfced] Please review the list in the Security Considerations > >>>> section. While most points begin with a verb phrase, a few > >>>> points do not. Please let us know if/how we may make this list > >>>> parallel in structure. > >>>> > >>>> Original: > >>>> > >>>> * For SR-MPLS deployments: > >>>> > >>>> - By disabling MPLS on external interfaces of each edge node or > >>>> any other technique to filter labeled traffic ingress on these > >>>> interfaces. > >>>> > >>>> * For SRv6 deployments: > >>>> > >>>> - Allocate all the SIDs from an IPv6 prefix block S/s and > >>>> configure each external interface of each edge node of the > >>>> domain with an inbound infrastructure access list (IACL) that > >>>> drops any incoming packet with a destination address in S/s. > >>>> > >>>> - Additionally, an iACL may be applied to all nodes (k) > >>>> provisioning SIDs as defined in this specification: > >>>> > >>>> o Assign all interface addresses from within IPv6 prefix A/a. > >>>> At node k, all SIDs local to k are assigned from prefix Sk/ > >>>> sk. Configure each internal interface of each SR node k in > >>>> the SR domain with an inbound IACL that drops any incoming > >>>> packet with a destination address in Sk/sk if the source > >>>> address is not in A/a. > >>>> > >>>> - Denying traffic with spoofed source addresses by implementing > >>>> recommendations in BCP 84 [RFC3704]. > >>>> > >>>> - Additionally the block S/s from which SIDs are allocated may be > >>>> a non-globally-routable address such as ULA or the prefix > >>>> defined in [I-D.ietf-6man-sids]. > >>>> --> > >>> > >>> [RP] The updated text is fine. > >>> > >>>> > >>>> > >>>> 10) <!--[rfced] This sentence may be easier to get through on a single > >>>> read if broken into a list as follows. Please let us know if > >>>> this is agreeable. > >>>> > >>>> Original: > >>>> If an attacker can forge an IPv6 packet with source address of a > >>>> node, Replication SID as destination address and an IPv6 Hop Limit > >>>> such that nodes which forward replicated packets on IPv6 locator > >>>> unicast prefix, decrement the Hop Limit to zero, then these nodes > >>>> can cause a storm of > >>>> ICMPv6 Error packets to overwhelm the source node under attack. > >>>> > >>>> Perhaps: > >>>> > >>>> If an attacker can forge an IPv6 packet with: > >>>> > >>>> * the source address of a node, > >>>> * a Replication SID as the destination address, and > >>>> * an IPv6 Hop Limit such that nodes that forward replicated packets > >>>> on an IPv6 locator unicast prefix decrement the Hop Limit to zero, > >>>> > >>>> then these nodes can cause a storm of ICMPv6 error packets to > >>>> overwhelm the source node under attack. > >>>> > >>> > >>> [RP] I have split up the sentence as suggested in edited XML file. > >>> > >>>> --> > >>>> > >>>> > >>>> 11) <!-- [rfced] Please review the "type" attribute of each sourcecode > >>>> element in the XML file to ensure correctness. If the current > >>>> list of preferred values for "type" > >>>> (https://www.rfc-editor.org/materials/sourcecode-types.txt <https://www.rfc-editor.org/materials/sourcecode-types.txt>) does > >>>> not contain an applicable type, then feel free to let us > >>>> know. Also, it is acceptable to leave the "type" attribute not > >>>> set. > >>> > >>> [RP] "pseudocode" type is appropriate. > >>> > >>>> --> > >>>> > >>>> > >>>> 12) <!-- [rfced] We have a few questions regarding the terms used in this > >>>> document. > >>>> > >>>> a. End.Replicate is treated differently in the two instances below. > >>>> Please review and let us know if/how these should be made uniform. > >>>> Perhaps this term should be added to the Terminology section in > >>>> lieu of the > >> two descriptions? > >>>> > >>>> Original: > >>>> “Endpoint with replication” behavior (End.Replicate for short) > >>>> > >>>> and > >>>> > >>>> Original: > >>>> The "Endpoint with replication and/or decapsulate behavior > >>>> (End.Replicate for > >>>> short) is variant of End behavior. > >>>> > >>> > >>> [RP] I have made changes to make both of this consistent (by using " > >>> Endpoint > >> with replication and/or decapsulate") in the edited XML file. > >>> > >>>> > >>>> b. Regarding hyphenation and capitalization of the following terms: > >>>> > >>>> i. Anycast SID: This term appears without a hyphen throughout the > >>>> document, but in cited RFCs, it appears as Anycast-SID. May we > >>>> update to the hyphenated form for consistency with these previous RFCs? > >>>> > >>> [RP] Yes, please update. > >>> > >>>> ii. Adjacency SID: This term seems to be "Adj-SID" in RFC 8402. > >>>> Please review this usage and let us know if we can adjust to use "Adj-SID" > >>>> for consistency with this cited RFC. > >>>> > >>> [RP] Yes, please use "Adj-SID" > >>> > >>>> iii. Replication SID: This term appears both hyphenated and without > >>>> a hyphen (and in lowercase at times) throughout the document. May > >>>> we update all instances to "Replication-SID", for consistency with > >>>> the previous related terms and cited RFCs? > >>>> > >>> [RP] Yes, please update to "Replication-SID" > >>> > >>>> iv. FYI - Related to the above, we see the following terms in the > >>>> document: > >>>> > >>>> Node-SID > >>>> PeerSet SID > >>>> context SID > >>>> > >>> > >>> [RP] RFC 8402 uses "Node-SID" and "PeerSet SID" (without > >>> hyphenation) and > >> we have adopted it from there, but it is fine to use "PeerSet-SID". "context > SID" > >> is introduced in this document and can therefore be changed to "context- > SID". > >>> > >>>> In addition to: > >>>> R-SID > >>>> A-SID > >>>> N-SID > >>>> > >>>> Please consider these when making decisions related to i-iii above. > >>>> > >>>> c. Several terms in this document appear separated with a slash > >>>> (/), but it is unclear whether the slash stands for "and", "or", or > >>>> "and/or". Please review uses of the slash throughout this document > >>>> and let us know how to adjust for clarity. > >>>> > >>> [RP] I have replaced all occurrences of slash (/) in "Leaf/Bud" and > >> "MVPN/EVPN" with "and" or "or" as appropriate. Please let me know if > >> there are any other ambiguous usage of the slash. > >>> > >>>> > >>>> d. Should the following capitalized terms (seemingly node names) be > >>>> changed to lowercase throughout for consistency with previous RFCs? > >>>> > >>>> Downstream > >>>> Root > >>>> Leaf > >>>> Bud > >>>> > >>>> Related: We see both Replication node and Non-replication node. > >>>> Please consider if all node name should be lowercase in light of the above. > >>>> > >>> [RP] Yes, these can be changed to lowercase. > >>> > >>>> e. We have updated the following terms to use the form on the right. > >>>> Please review and let us know any objections: > >>>> > >>>> Active Segment / active segment (to match RFC 8402) replication > >>>> branch / Replication branch > >>>> > >>> [RP] Change to "active segment" is fine, but I don't think "Replication > branch" > >> change is appropriate because lowercase "replication" is used to > >> signify the act of replication instead of needing a proper noun with > uppercase "Replication". > >>> > >>>> > >>>> f. We see the following terms used inconsistently throughout the > document. > >>>> Please review and let us know if/how these may be made uniform. > >>>> > >>>> Replication segment vs. Replication Segment vs. replication segment > >>> > >>> [RP] I think using "Replication segment" will be consistent. > >>> > >>>> > >>>> f. Please review the following questions about the message names below: > >>>> > >>>> i. Should "message" be lowercased or capitalized? > >>>> > >>>> Packet Too Big message vs. Parameter Problem Message > >>>> > >>>> ii. We see Parameter Problem both with and without ICMPv6. Please > >>>> review and let us know if/how these uses should be made uniform. > >>>> > >>>> iii. May we make the error codes uniform with regard to capping and > >> ordering? > >>>> > >>>> > >>>> Originals: > >>>> ICMPv6 Parameter Problem with Code 0 > >>>> ICMPv6 Parameter Problem with Code 4 an ICMPv6 error message > >>>> (parameter problem, code 0) Parameter Problem Message, Code 2 > >>>> Parameter Problem Message, code 2 ICMPv6 Error > >> messages. > >>>> > >>>> Perhaps (making assumptions about i, ii, and iii above): > >>>> ICMPv6 Parameter Problem message with Code 0 > >>>> ICMPv6 Parameter Problem message with Code 4 > >>>> ICMPv6 Parameter Problem message with Code 0 > >>>> ICMPv6 Parameter Problem message with Code 2 > >>>> ICMPv6 Parameter Problem message with Code 2 > >>>> > >>> [RP] Above suggestion is fine. > >>> > >>>> --> > >>>> > >>>> > >>>> 13) <!--[rfced] We had the following questions/comments related to > >>>> abbreviations used throughout the document: > >>>> > >>>> a. FYI - We have expanded the following abbreviations upon first > >>>> use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > >>>> each expansion in the document carefully to ensure correctness: > >>>> > >>>> Destination Address (DA) > >>>> Unique Local Address (ULA) > >>>> Operations, Administration, and Maintenance (OAM) > >>>> > >>> [RP] This is fine. > >>> > >>>> b. FYI - We will update to use the abbreviated form of the > >>>> following terms after the abbreviation is expanded on first use. > >>>> Please let us know any > >> objections. > >>>> > >>>> Destination Address will become DA > >>>> Replication state will become RS > >>>> Segment Routing will become SR > >>>> > >>> [RP] This Is fine. > >>> > >>>> > >>>> c) Please review this use of POP: > >>>> > >>>> Original: > >>>> ...is a Replication SID, the processing results in a POP [RFC8402]... > >>>> > >>>> We do not see POP being expanded as an abbreviation in RFC 8402 or > >>>> any of the normative references. Please let us know if/how we may > >>>> expand > >> it. > >>>> > >>> [RP] POP is not used an acronym here. It signifies a "pop" operation > >>> on the > >> top label of the label stack. > >>> > >>>> d) Please review the expansion and use of IACL/iACL. > >>>> > >>>> While we see the same expansion as used in this document in RFC > >>>> 8754 (see below), we are curious about the 1:1 relationship between > >>>> the initialism and the expansion. > >>>> > >>>> We also note a single use of "iACL" in this document (see below). > >>>> > >>>> Original: > >>>> - Allocate all the SIDs from an IPv6 prefix block S/s and > >>>> configure each external interface of each edge node of the domain > >>>> with an inbound infrastructure access list (IACL) that drops any > >>>> incoming packet with a destination address in S/s. > >>>> > >>>> then later: > >>>> > >>>> Original: > >>>> - Additionally, an iACL may be applied to all nodes (k) > >>>> provisioning SIDs as defined in this specification: > >>>> > >>>> i) Should these uses be made "infrastructure Access Control List > >>>> (iACL)" on expansion and then "iACL" thereafter? Note that we see > >>>> "Infrastructure Access Control List (iACL)" used in RFCs 7404 and 9098. > >>>> > >>>> ii) Or perhaps "infrastructure Access Control List (ACL)" on > >>>> expansion as used in RFCs 6752 and 9252 (and "infrastructure ACL > >> thereafter")? > >>>> > >>>> iii) Or maybe we should switch to using "Infrastructure Access > >>>> Control List (IACL)" with a 1:1 between the expansion and the > >>>> initialism and corresponding capitalization? This form has not > >>>> appeared in any published RFCs to date, but if this is how people > >>>> know it, > >> then perhaps this is the way to go in the future? > >>>> > >>>> We appreciate any guidance you may have. > >>>> > >>> > >>> [RP] I don't think there is an established terminology for ACL and > >>> lowercase > >> "i" or uppercase "I" do not make a difference. It should be fine to > >> use using "Infrastructure Access Control List (IACL)". > >>>> --> > >>>> > >>>> > >>>> 14) <!-- [rfced] Please review the "Inclusive Language" portion of the > >>>> online Style Guide > >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> <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.--> > >>>> > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/kf/mf > >>>> > >>>> *****IMPORTANT***** > >>>> > >>>> Updated 2024/01/19 > >>>> > >>>> 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/ <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/ <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://authors.ietf.org/rfcxml-vocabulary> <https://authors.ietf.org/rfcxml-vocabulary>>. > >>>> > >>>> * 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 <mailto: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 <mailto: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- <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-> > >>>> 4Q9l2USxIAe6P8O4Zc > >>>> > >>>> * The archive itself: > >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ <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 <mailto: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 CCed on this message need to see your > approval. > >>>> > >>>> > >>>> Files > >>>> ----- > >>>> > >>>> The files are available here: > >>>> https://www.rfc-editor.org/authors/rfc9524.xml <https://www.rfc-editor.org/authors/rfc9524.xml> > >>>> https://www.rfc-editor.org/authors/rfc9524.html <https://www.rfc-editor.org/authors/rfc9524.html> > >>>> https://www.rfc-editor.org/authors/rfc9524.pdf <https://www.rfc-editor.org/authors/rfc9524.pdf> > >>>> https://www.rfc-editor.org/authors/rfc9524.txt <https://www.rfc-editor.org/authors/rfc9524.txt> > >>>> > >>>> Diff file of the text: > >>>> https://www.rfc-editor.org/authors/rfc9524-diff.html <https://www.rfc-editor.org/authors/rfc9524-diff.html> > >>>> https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html> (side by > >>>> side) > >>>> > >>>> Diff of the XML: > >>>> https://www.rfc-editor.org/authors/rfc9524-xmldiff1.html <https://www.rfc-editor.org/authors/rfc9524-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/rfc9524.original.v2v3.xml <https://www.rfc-editor.org/authors/rfc9524.original.v2v3.xml> > >>>> > >>>> XMLv3 file that is a best effort to capture v3-related format > >>>> updates > >>>> only: > >>>> https://www.rfc-editor.org/authors/rfc9524.form.xml <https://www.rfc-editor.org/authors/rfc9524.form.xml> > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> https://www.rfc-editor.org/auth48/rfc9524 <https://www.rfc-editor.org/auth48/rfc9524> > >>>> > >>>> Please let us know if you have any questions. > >>>> > >>>> Thank you for your cooperation, > >>>> > >>>> RFC Editor > >>>> > >>>> -------------------------------------- > >>>> RFC9524 (draft-ietf-spring-sr-replication-segment-19) > >>>> > >>>> Title : SR Replication segment for Multi-point Service Delivery > >>>> Author(s) : D. Voyer, Ed., C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang > >>>> WG Chair(s) : Bruno Decraene, Alvaro Retana, Joel M. Halpern > >>>> > >>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston > >>>> > >>> > >>> <rfc9524-Jan26.xml><rfc9524-Jan26.diff.html> > >> > >> > >> > >> > > > > <rfc9524-Feb09.xml><rfc9524-Feb09.diff.html> ------------------------------------------------------------------------------ External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
- [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-sprin… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Rishabh Parekh (riparekh)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Rishabh Parekh (riparekh)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Rishabh Parekh (riparekh)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Jeffrey (Zhaohui) Zhang
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Clarence Filsfils (cfilsfil)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Voyer, Daniel
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Hooman Bidgoli (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Sarah Tarrant