From nobody Tue Feb 28 13:55:28 2023 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3851CC15AE03; Tue, 28 Feb 2023 13:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 ldNT2Rn7tOnQ; Tue, 28 Feb 2023 13:55:21 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20710.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eaa::710]) (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 11DE3C14F74F; Tue, 28 Feb 2023 13:55:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aYk8SFMaCjrmeDyVizYXXTfdjrd3wIt6Tt/FnZEs7FIhVO4Mlr1P6/wqWWD6nPfQQ4BwK2fcaqQg7GE2fBR8RVlGw76en/wqsWzu1paFd+6w8yerjQ3GaCGd/oqbmCUXKX7hGnBD61UUvoKd3ivjGH9AfZ+5W8eXUwf0yBGEPvZyBBZsgiYl8yk4tGx1Xa5dBG/0UEsbhYnNCGFc2azkNydKatzclSIoSaFFVeeXfvoaeQ+b6metIDOtGxjgBuOvF9xSP/KYUGVADkznBwDBkKVALw6HQSA4uveKPMKy1eYQNj5wxgAp9aIzhtXaxs97f2HUGsm/yfWhYCgH2rTmig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Tj+kNJusQ4NkQXD/GgP7kzsC2xdeo5MLG2UYXnvy35U=; b=dO+INfWmVmqXK41sokR68ivcMXCw9bGE0qJXso/2EtDsNLrnh+ZyQjWdtEM5mD8EalzHO46zmloHORcNn7e3zQXmIKKTEbaaM1U4NIKAp2GfJwyl1POyLc3/rFVtHhzTJCUEWYbGf2AgK0RNe3SI/OodgOndryVOtt3Si/TCZCiQM43x3jXJk6XbFJvukLS8IQJwQkCBIXMMDAioshzyCiO08nKQieAhE5xsrt+j7Z0A5zR823Nyj5JWWWR1zn7pwD0nxWnvQALrkdNa6qx6hv4HTF32h7kf1kb047FEG0bCSqW3nMeJCsnGcgovk6Q44IH2cByzSMRm8WbaT8tYog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tj+kNJusQ4NkQXD/GgP7kzsC2xdeo5MLG2UYXnvy35U=; b=leo4LH2zu1/OQSZNXWni94+GNxasNDdxqvUruRWfmia55o1TGxKqDwRdbRmHUImR3rI0mOafH7bNshxN9WcBFezkp+zal5bs/8MfsvLVaswJUrVv/yL8OBBK62Jdb6fZCaUYtfuqdxn+X3Wh2o0Wwp1tgdF2h3o8ZbicPTb6f2A= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by PH7PR13MB6296.namprd13.prod.outlook.com (2603:10b6:510:237::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.30; Tue, 28 Feb 2023 21:55:15 +0000 Received: from MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::f499:7585:d554:2b55]) by MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::f499:7585:d554:2b55%3]) with mapi id 15.20.6134.030; Tue, 28 Feb 2023 21:55:15 +0000 From: James Guichard To: Rishabh Parekh CC: SPRING WG List , "spring-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-spring-sr-replication-segment Thread-Index: AdkDOXX5fD56cgadQLyJ82sZgqL1jQh0aAsgBgmhqRAACx270AD74g8AAB7F94AA3oNAwADajgCAAI4oEAAAJW31wAAQwFcAAABn/jD///2+gIAAAuYg Date: Tue, 28 Feb 2023 21:55:15 +0000 Message-ID: References: <52270_1676021265_63E60E10_52270_250_1_AS2PR02MB88396E9E3C714762089A301BF0DE9@AS2PR02MB8839.eurprd02.prod.outlook.com> <91949156a8c540fe8b4f357087713add@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN2PR13MB4206:EE_|PH7PR13MB6296:EE_ x-ms-office365-filtering-correlation-id: 4163aa13-c7b8-4e20-a001-08db19d6794d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yZtNxnPwg/Fr++oAgcsniUqClwPbY8rLHy9Mlx38W/h4CJ6z99bDpUvKE9FBwR6ZmHyI1SmwELs9CbmI2tDADHTb4cDbxXAeG8TMHp4cK4YTEfD6vmCdh64Bh6+0VWNcqmADFoAEBRBrVGTDWbaOPo4BUfAVHNQrbLbTz0zvmRiFrh+JoWo4ySaWJ8QtUD1a/nN8rNGTI+n76vj5mphugraW1C/3ltdqTyNjEkFsNRGfYvvsYyt12czczgbfgWO8WcjNHKH74UpLBDzy3PcrxFs8zBSFF26okZ4VmJQoTZVqXUNyU0cbW6ZXxt32RayoLAicfNUNNohFTNWVbFReuryS88roZFfoRKuKYlOMjQ/5r050FuIbIdRpIjLqInP+uiMI5xJkn3l/PWaARW9wFTOyeV6nTVLhEKtqyztmvPw502w8vg0Wraiit+1oF1kzqHpO4SyevFs/vCQoRl4abmjwnk8CgQnHt26waRl1TEFpI09kla2Hcgj9C4p7vEgSttb09ahs8iP05CKBDIXsOcSWcmeJg7uZccqjgvuWG1g8eQUD4kJMZ4DyG9oTb4dilE4ZUyl2HmmVppqxeXUnT2dgatOzQSkFNC4b0sTh4MvEXppaXk5NRTGZOU9H81D7wf6DcP8FbussuBjUuUyZKR3gUDvrK3tJd6OhCaBe6paWuHFhGjXeI6sPn2Dmrco3MDHDPL1o5aKbXeL8wvwNT+t1FONdM54vyqiutSxSD7M= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB4206.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(346002)(136003)(376002)(39850400004)(366004)(396003)(451199018)(66899018)(33656002)(55016003)(66556008)(66476007)(41300700001)(66446008)(66946007)(5660300002)(64756008)(8676002)(8936002)(6916009)(2906002)(86362001)(122000001)(166002)(4326008)(38100700002)(38070700005)(9326002)(7696005)(71200400001)(966005)(52536014)(54906003)(316002)(478600001)(76116006)(83380400001)(186003)(53546011)(9686003)(6506007)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?d6h4QZaHECSrFuk4Yvl0/Zng3xd7EkAH+Kw/JSL4B8AOxph+MiFEJzUZxNxz?= =?us-ascii?Q?uCcVkdc6VFHSFrbXaXWT/w70xNIwdh7oaMztoQOc+bS6JCuv10aCRF0Zhah8?= =?us-ascii?Q?N/Tlb3N4mvsVH3UxN1QJSbdyitJHEEXA5OyepEjIGR+YvTL9vQzqprNNh4b5?= =?us-ascii?Q?7dnjv8rJrioWLBwlBBDXbtM6Zrby7zg4XdUlGqFKohbelc8PnVQq9lUo9n2K?= =?us-ascii?Q?8ux2gqT9u3q+oUcaLgw2JlE3nortNKSjDTINtd3GwLbxHTrqjWLjwik3Mi/X?= =?us-ascii?Q?FyeuUGkrOQf8pMcahwI9NcnHuDKfJYGHodKv4wL8CHmG2ooQCSeUIiZV4hCq?= =?us-ascii?Q?WD9IGlJ5ordiRmwNyDNY2cE+uMZcvi9E0epROzTUn9Y1Cz9TpQ7lkLTPDwgw?= =?us-ascii?Q?oZERCEMI4wwzOQJ6Fr9L2aX1qLiXsLNGw5jp4ZSqm7E+LwXf2QCKOdQnk1j3?= =?us-ascii?Q?n8XaP3xps9uz0qzv6PzNHFXLtTECzfw7Z8ivnU6i/KXnBT21oira/bfj70o1?= =?us-ascii?Q?q11IOiG3YnSNHq/0/bX0LOXRbQxvNa9IU5ZMITHhNOBgvVSUYrlLxzFUB4iq?= =?us-ascii?Q?LWW1y+uRzcy8mrjjQwOVbewDC3ir4lLI+Yq4b/xfBLg9inwrtSk5IdvZ5U/q?= =?us-ascii?Q?2UdTrALv8RSnthO3QwCSPArBN3yLdoMSY+7Hp0QOywS3TbeEmlS3KsLDCxZa?= =?us-ascii?Q?v8B1jRuO8EyOwZGq3CQ2ym4FfdybjStF3vSBlD07eMe1hDsnPNVObcZD/B7F?= =?us-ascii?Q?Xe8YBZ6sH5ip1HlEXt9MFXxexGanelRJYyo4UCGyYd7reKCO2JOl6GqMkjON?= =?us-ascii?Q?p4T+bWa0R0CU3qSzmDUs7BG+0WZBmdV+//1Fm9PQf9oQtSSzk4jNA4JNABDS?= =?us-ascii?Q?nXhHT0qFWimGBNXPgC11viXSnW3bUTjzC96bVFYdqzerWkRN9v4gCZyp7189?= =?us-ascii?Q?dIHta4evIFmQRGZUXR4eV5y1kwKXpB8u3Iv6KGG+8Si4jKkp32G3g9LW+E7q?= =?us-ascii?Q?UQlVi+fOqqcZ7ztoa+1FdmWZW5+Vhrsn9D01EgnhPQgzBqbyOP9mC488G8VQ?= =?us-ascii?Q?ACwDG8ZRk2NvDIX5G4Q0IowoR/BNMWSce1gZIEIbvOIswrQ6ouFrYp1SopCp?= =?us-ascii?Q?Xv6NqsW9bHYgD37W0snIXzgAwpdUrSNlBRuDYOQ2HEdNVSc6tI3I3qcmDdGI?= =?us-ascii?Q?rk6sNrgw6BVDC/kiJ0CjzH4NTLukvKvnI6JY/OzCoI8v/2KNCsyWn1XKyAMf?= =?us-ascii?Q?X7dIEXCHQpLku3TgQ4sZ37zxB17eK1TP9HoJ73lVC4+xP+O1ZPmqEviAufNV?= =?us-ascii?Q?QJx8wZPH8VKoOgENlAqiq03nuyeovCYvlZE2RNznAmFenpbaeK5jHF6I8lre?= =?us-ascii?Q?LPNT5LUMY3yjot8cl5cAZlMGMT3NNXngP2z62Z1G3/eCbsSxLHtPYn1m19zS?= =?us-ascii?Q?P8vI8fjPlGNhHZQ6YjFHLnxGr56KfMkJUDF/mOfnbKwQzILXR9uZzgQc2tqU?= =?us-ascii?Q?sQJKloo/a4znqqKRPodnR5XrRSQ/e7eSS0I1HdrFHVhp0Gk3sFTeSpLmYTxc?= =?us-ascii?Q?u2/9YLDZhnGtmgEy2z9ezmAnza6oCGjxGA+BLcjdlsONH5ulLW3Xa8rSEt8j?= =?us-ascii?Q?HmpPaiAuZ3G8Z0Zr18IdEKXSyiM1tSgfFUAsBeVhPuS2?= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB4206792848905A14833B32C5D2AC9MN2PR13MB4206namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB4206.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4163aa13-c7b8-4e20-a001-08db19d6794d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2023 21:55:15.1258 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +DysKJh2krYgnssWtmD3PoalMrrRYOpYE8l0hCcai3t/j9ntTjzhRGnYiv2JppnMiwmi2Xo27Rfmh/HQItUTkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR13MB6296 Archived-At: Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2023 21:55:27 -0000 --_000_MN2PR13MB4206792848905A14833B32C5D2AC9MN2PR13MB4206namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rishabh, Just to be clear, I do not expect you to document how TLVs are to be proces= sed just simply wording like 8754 and where in the logic that should happen= : S06. If local configuration requires TLV processing { S07. Perform TLV processing (see TLV Processing) Jim From: Rishabh Parekh Sent: Tuesday, February 28, 2023 4:52 PM To: James Guichard Cc: SPRING WG List ; spring-chairs@ietf.org Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment Jim, Fine. Will add SRH TLV processing to pseudo-code in next revision. -Rishabh On Tue, Feb 28, 2023 at 1:49 PM James Guichard > wrote: Hi Rishabh, Thanks. Adding where in the processing logic TLVs are processed (if locally= configured) I think is a worthwhile update. Jim From: Rishabh Parekh > Sent: Tuesday, February 28, 2023 4:48 PM To: James Guichard > Cc: SPRING WG List >; spring-chairs= @ietf.org Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment Jim, Thanks for diligently catching the typos in the document :) Will fix them i= n the next revision. As for SRH TLVs, they can be processed at Replication Node, if allowed by l= ocal configuration, before an incoming packet is replicated. I see RFC 8754= Section 4.3.1.1 SRH processing pseudo-code does not explicitly mention SRH= TLV processing, but we can add to SRv6 End.Replication pseudo-code if you = think it is necessary. Thanks, -Rishabh On Tue, Feb 28, 2023 at 6:11 AM James Guichard > wrote: Hi Rishabh, Thank you for the new version. A few nits/comments: * Text in the abstract currently says "A SR Replication segment allows = a packet to be replicated from a Replication Node to Downstream nodes". * Perhaps change to -> ""A SR Replication segment allows a packet to= be replicated from a Replication Node to one or more Downstream nodes". * Couple of typos in the Introduction: * Replication segment is a new type of segment for Segment Routing [= RFC8402], which allows a node (henceforth called as Replication * [Jim] r/as/a * A Replication segment can replicate packet to directly connected node= s or to downstream nodes * [Jim] r/packet/packets * Section 2.2.1 * [Jim] I do not see any mention of TLV processing. If local configu= ration requires TLV processing where in the pseudo code does this fit? Are = there circumstances where TLV processing is prohibited if using a Replicati= on SID? Please add this. * Section 2.2.1 * * The behavior above MAY result in a packet with partially proces= sed segment list in SRH under some circumstances * [Jim] It would be helpful to provide an example of such a circu= mstance here. * Section 2.2.2 * the Leaf/Bud bud node which responds with an ICMPv6 Echo * [Jim] remove "bud" typo Thanks! Jim From: Rishabh Parekh > Sent: Monday, February 27, 2023 2:57 PM To: SPRING WG List > Cc: spring-chairs@ietf.org Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment We have published revision 12 of the draft. Main changes include: - Pseudo-code for SRv6 End.Replicate - Description and example of ping to a Replication SID - Changes to text to address comments from Bruno, Jim and Joel Please review. Thanks, -Rishabh On Fri, Feb 24, 2023 at 4:06 PM Rishabh Parekh > wrote: Jim, The text you refer to in Section 2.1 and .2.2 has changed after addressing = comments since the last revision, but we will try to incorporate the sugges= ted change. Thanks, -Rishabh On Mon, Feb 20, 2023 at 8:06 AM James Guichard > wrote: Hi Rishabh & authors, To close out this discussion, in sections 2.1 and 2.2 we have: There MAY be SIDs after the Replication SID in the segment list of a packet= . These SIDs are used to provide additional context for processing a packet= locally at the node where the Replication SID is the Active Segment. The p= rocessing of SIDs following the Replication SID MUST NOT forward the SR-MPL= S packet to another node. The chairs believe it would be helpful to add a sentence to clarity the sco= pe and offer the following text "Coordination regarding the absence or pres= ence and value of context information for replication leaves is outside the= scope of this document.". Thanks! Jim, Joel & Bruno From: Rishabh Parekh > Sent: Thursday, February 16, 2023 12:37 AM To: James Guichard > Cc: Xiejingrong (Jingrong) >; bruno.decraene@orange.com; SPRING WG > Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment James, On Wed, Feb 15, 2023 at 8:05 AM James Guichard > wrote: Hi Jingrong & document authors, I would like for now to leave aside the issue of whether or not application= /VPN specifics should be outside the scope of this SPRING document (I will = however be revisiting this point in subsequent emails) and focus on bringin= g closure to the technical comments detailed in https://mailarchive.ietf.or= g/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/. As I read through your comments Jingrong I think I can summarize your objec= tion to be that you believe the proposal breaks the SRv6 architecture as th= e forwarding relies upon local state rather than state carried within the S= RH. Do I have that right? If this is the case then you need to be specific = in terms of which text/sentences in the document are in conflict with which= text/sentences of existing RFCs. As written I think Rishabh's forwarding e= xample is accurate as he describes a lookup on the Replication SID and the = action is to either update the outer IPv6 address with the downstream nodes= address, or re-encapsulate the packet with a new IPv6 header and SRH. I mi= ght draw your attention to https://www.rfc-editor.org/rfc/rfc8754.html#nam= e-fib-entry-is-a-locally-inst which talks about the defin= ition of future SIDs and their behaviors. Further your comments appear to me to suggest that the VPN identification e= ncapsulated at PE1 acts like a normal VPN SID in the sense that forwarding = is based upon that IPv6 address. I don't think that is the intent here; I t= hink the SID is used as an identifier for the VPN itself so that the downst= ream nodes are given the correct VPN forwarding context i.e. they are not s= upposed to use that SID to forward the packets back to PE1. Perhaps the aut= hors could clarify this point further? Hi Rishabh, it would be helpful if you could review the comments in https:/= /mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/ again and perhaps provide more clarity on the expected behav= ior as there seems to be a difference in understanding of the actual operat= ion. [RP] Exactly, the only purpose of VPN SID is to provide a VPN context at Le= af/Bud nodes to forward the inner packet (encapsulated at ingress PE). I h= ave removed most of the text related to VPN (in yet unpublished next revisi= on) based on Bruno's earlier, but this has been explained earlier in the th= read. -Rishabh --_000_MN2PR13MB4206792848905A14833B32C5D2AC9MN2PR13MB4206namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rishabh,

 

Just to be clear, I do not expect you to document ho= w TLVs are to be processed just simply wording like 8754 and where in the l= ogic that should happen:

 

S06.     If local configuration requires TLV p= rocessing {

S07.       Perform TLV processing (s= ee TLV Processing)

 

Jim

 

From: Rishabh Parekh <rishabhp@gmail.com&g= t;
Sent: Tuesday, February 28, 2023 4:52 PM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: SPRING WG List <spring@ietf.org>; spring-chairs@ietf.org Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment<= /o:p>

 

Jim,

Fine. Will add SRH TLV processing to pseudo-code in = next revision.

 

-Rishabh

 

On Tue, Feb 28, 2023 at 1:49 PM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com">james.n.guichard@futurewei= .com> wrote:

Hi Rishabh,

 

Thanks. Adding where in the processing logic TLVs are processed (i= f locally configured) I think is a worthwhile update.

 

Jim

 

From: Rishabh Parekh <rishabhp@gmail.com>
Sent: Tuesday, February 28, 2023 4:48 PM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: SPRING WG List <spring@ietf.org>; spring-chairs@i= etf.org
Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment<= /o:p>

 

Jim,

Thanks for diligently catching the typos in the document :) Will f= ix them in the next revision.

 

As for SRH TLVs, they can be processed at Replication Node, if all= owed by local configuration, before an incoming packet is replicated. I see= RFC 8754 Section 4.3.1.1 SRH processing pseudo-code does not explicitly mention SRH TLV processing, but we can add= to SRv6 End.Replication pseudo-code if you think it is necessary.

 

Thanks,

-Rishabh

 

On Tue, Feb 28, 2023 at 6:11 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

Hi Rishabh,

 

Thank you for the new version. A few nits/comments:

 

  • Text in the abstract currently says “A SR Replication segment allows = a packet to be replicated from a Replication Node to Downstream nodes”= ;.
    • Perhaps change to -> ““A SR Replication segment allows a pac= ket to be replicated from a Replication Node to one or more Downstream nodes”.
  • Couple of typos in the Introduction:
  •    Replication segment is a new type of segment for Segment Routi= ng [RFC8402], which allows a node (henceforth called as Replication
    • [Jim] r/as/a
  • A Replication segment can replicate packet to directly connected nodes or t= o downstream nodes
    • [Jim] r/packet/packets
  • Section 2.2.1
    • [Jim] I do not see any mention of TLV processing. If local configuration= requires TLV processing where in the pseudo code does this fit? Are there = circumstances where TLV processing is prohibited if using a Replication SID= ? Please add this.
  • Section 2.2.1
    • *  The behavior above MAY result in a packet with partially processed = segment list in SRH under some circumstances
      • [Jim] It would be helpful to provide an example of such a circumstance h= ere.
  • Section 2.2.2
    • the Leaf/Bud bud node which responds with an ICMPv6 Echo
        • [Jim] remove “bud” typo

     

    Thanks!

     

    Jim

     

     

    From: Rishabh Parekh <rishabhp@gmail.com>
    Sent: Monday, February 27, 2023 2:57 PM
    To: SPRING WG List <spring@ietf.org>
    Cc: spri= ng-chairs@ietf.org
    Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment<= /o:p>

     

    We have published revision 12 of the draft. Main changes include:<= o:p>

    - Pseudo-code for SRv6 End.Replicate

    - Description and example of ping to a Replication SID<= /p>

    - Changes to text to address comments from Bruno, Jim and Joel

     

    Please review.

     

    Thanks,

    -Rishabh

     

    On Fri, Feb 24, 2023 at 4:06 PM Rishabh Parekh <rishabhp@gmail.com> wrote:<= o:p>

    Jim,

    The text you refer to in Section 2.1 and .2.2 has changed after ad= dressing comments since the last revision, but we will try to incorporate t= he suggested change.

     

    Thanks,

    -Rishabh

     

    On Mon, Feb 20, 2023 at 8:06 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

    Hi Rishabh & authors,

    To close out this discussion, in sections 2.1 and 2.2 we have:

    There MAY be SIDs after the Replication SID in the segment list of a packet= . These SIDs are used to provide additional context for processing a packet= locally at the node where the Replication SID is the Active Segment. The p= rocessing of SIDs following the Replication SID MUST NOT forward the SR-MPLS packet to another node.<= /o:p>

     

    The chairs believe it would be helpful to add a sentence to clarit= y the scope and offer the following text "Coordination regarding the a= bsence or presence and value of context information for replication leaves is outside the scope of this document.". =

     

    Thanks!

     

    Jim, Joel & Bruno

     

     

    From: Rishabh Parekh <rishabhp@gmail.com>
    Sent: Thursday, February 16, 2023 12:37 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: Xiejingrong (Jingrong) <xiejingrong=3D40huawei.com@dmarc.ietf.org&g= t;; bruno.decrae= ne@orange.com; SPRING WG <spring@ietf.org>
    Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment<= /o:p>

     

    James,

     

    On Wed, Feb 15, 2023 at 8:05 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

    Hi Jingrong & document authors,

     

    I would like for now to leave aside the issue of whether or not ap= plication/VPN specifics should be outside the scope of this SPRING document= (I will however be revisiting this point in subsequent emails) and focus on bringing closure to the technical= comments detailed in https://mailarchive.ietf.org/arch/msg/spri= ng/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/.

     <= /o:p>

    As I read through your comments Jingrong I think I can summarize y= our objection to be that you believe the proposal breaks the SRv6 architect= ure as the forwarding relies upon local state rather than state carried within the SRH. Do I have that right? If t= his is the case then you need to be specific in terms of which text/sentenc= es in the document are in conflict with which text/sentences of existing RF= Cs. As written I think Rishabh’s forwarding example is accurate as he describes a lookup on the Replication= SID and the action is to either update the outer IPv6 address with the dow= nstream nodes address, or re-encapsulate the packet with a new IPv6 header = and SRH. I might draw your attention to  https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-ins= t which talks about the definition of future SIDs and their behaviors.<= o:p>

     

    Further your comments appear to me to suggest that the VPN identif= ication encapsulated at PE1 acts like a normal VPN SID in the sense that fo= rwarding is based upon that IPv6 address. I don’t think that is the intent here; I think the SID is used as an= identifier for the VPN itself so that the downstream nodes are given the c= orrect VPN forwarding context i.e. they are not supposed to use that SID to= forward the packets back to PE1. Perhaps the authors could clarify this point further? 

     

    Hi Rishabh, it would be helpful if you could review the comments i= n https://mailarchive.ietf.org/arch/msg/spri= ng/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/ again and perhaps provide more clar= ity on the expected behavior as there seems to be a difference in understan= ding of the actual operation.

     

    [RP] Exactly, the only purpose of VPN SID is to provide a VPN cont= ext at Leaf/Bud nodes to forward the inner packet (encapsulated at ingress = PE).  I have removed most of the text related to VPN (in yet unpublished next revision) based on Bruno's earlier= , but this has been explained earlier in the thread.

     

    -Rishabh

     

     

--_000_MN2PR13MB4206792848905A14833B32C5D2AC9MN2PR13MB4206namp_--