From nobody Tue May 18 08:13:22 2021 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 9FE683A16B5; Tue, 18 May 2021 08:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMjJC4NRctaB; Tue, 18 May 2021 08:13:04 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2136.outbound.protection.outlook.com [40.107.92.136]) (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 F03CC3A169E; Tue, 18 May 2021 08:13:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fSeaufoqdWfksCpSs6F6sAqaXR6P9qsMoz6B1/EdiCGK0fbFnQTqFK0hKaCUt8XZLU/qE58oQwXAz5t5QDxUkXo1eseWOhz9HNu3zsBDWrQVqCi73K5IaW1Qre/6e6v4SY0hvNQbuHddCvBXji5gsKUYbTiK3ED+YdbsSMPSyJECqqAwK+bWa+0kRnOE390KKrk8tc0zsRsIXmVBno+nAlAKaT74ETT8AfDJU+a5HPWrF5L5T/ZOM6BPLWXgBf4V4Gh6uIab3+KVV4fyThSnzXbHFaVdfqHVfQ0o0mr29JFb3fEcTpRwyf0n9jT7Rr6YMoYy9BjX88DRyOAiS8zp3w== 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-SenderADCheck; bh=qoFE1jBCOGUyRSWX5fbw/rUZ+8iIDb+btxCbyRIraks=; b=M/lD2DGJoUb9PsmuhPUh46QnhdID5nSvV++k2gzH7F5YCFRsVz/kVcpxr7uG4G6jCLnDpA6DgznpnpJj37FT7ElKbvqsQc4bN3FPvixJR5gOsfpXMrwaYt6ow/6Zo//i8WNKJMIpu3Jt2BTSBD99ufzDsQ+EZdQ2xB0yB5mWJMKqFYc3WuN75iS+PhmTGBXIQBr/muToF+l7qbNcRENOJ+dmxjGx11G4J3cpQ5YY7rFxwat8BNipoQMxSlupMc0DScv2JO+ncy7SiCLQfFHyrmh7/lD7u9Q+rHsfq4e+2NYbo3wxQ/E5JqdGFQg35RLk2HjLAWOcS2G/YoIPlNsPXA== 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=qoFE1jBCOGUyRSWX5fbw/rUZ+8iIDb+btxCbyRIraks=; b=hAEd+I/NsargsBUQer8YiNAd1EmXLryghUQji5aF1Ygdl+4TsxmhTdUXKa1oBYa47xjm7HGVL/PUGpOTrxqyU2D9x2Hre0F8x6IG4RizEcbok8xGrCMoqxdJsi30SD/cQFDQej5tLcs2j2j34C7EdibxCvFYKsV7tNBRix3r0RU= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by BLAPR13MB4707.namprd13.prod.outlook.com (2603:10b6:208:30f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Tue, 18 May 2021 15:12:58 +0000 Received: from MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::6831:603c:8f59:8fdc]) by MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::6831:603c:8f59:8fdc%7]) with mapi id 15.20.4129.032; Tue, 18 May 2021 15:12:58 +0000 From: James Guichard To: "bruno.decraene@orange.com" , "spring@ietf.org" CC: "draft-ietf-spring-nsh-sr@ietf.org" Thread-Topic: WG Last Call draft-ietf-spring-nsh-sr Thread-Index: Adb/EbzdQyDXcLfTRQ6v+vtwpmiyOgAABBewEhO1tZA= Date: Tue, 18 May 2021 15:12:58 +0000 Message-ID: References: <25012_1612895472_6022D4F0_25012_72_1_53C29892C857584299CBF5D05346208A490C4A3A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <3058_1612896034_6022D722_3058_18_1_53C29892C857584299CBF5D05346208A490C4AE4@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <3058_1612896034_6022D722_3058_18_1_53C29892C857584299CBF5D05346208A490C4AE4@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2600:6c64:497f:d3ca:64e7:260c:c9c5:800] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1887ea44-e711-4037-8c51-08d91a0f6bf6 x-ms-traffictypediagnostic: BLAPR13MB4707: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Dg93dGLecVwFVwgShBIj7UNpkQfK3STCJuBwhAbBC839bf+6Cjh719D/CD/4NHIPnPGMHjI5CyhuIQfx/plcVpjYU+dU+dlEjxvzx4cKcvcr2xffWSJyl8e9xhVaZrVquYZS7rMQsiLpluaPGMWGW3qf310bZrbvmbfz1J4RFMpsmbuf8HQ2lD9koRCSpeQoyC/EW0AkdSKZ189KAp9tB4TUFS2uFNKOTyzzGWfA6hfzSMj8QNoIooH7HiqeMP+Y8xm2sFU6hJ2AvuikqAG02GJZQxLKx72RtAGoFjovTCLNV5oDcEsOv6dLQmZDEob4AC3XCftfy5Qc9jl8QyanDNtuJyWkY2etXQbNTP/YzE2S70qzNSqP9Euf216GIfT8Oh56ZkHnG0cDAGJSYFelhBWHgqcyrllid8vIoPf2QKKOBXpKFuUkkKgJ1CcufvtB62sjs593S43TjcdMXhf+K2l5dlMsupcCD7hNilbiY/ZoZMEZFQiO2s5/ai79P6yD6V3BlPfkaY4a13bqTb2+acdIMBcQMUN54PrmwZdEVgY5cqzWQPFHnaugl2x0eXAIpX2obJIIumRvpJS9N/84jKg+U75CLjtlNflxr5rrMK6nhAMrDmL2fb/MMLbPcy5YvyD0v3BmYLsq2OmKo/AsPgLpYiYUQsLJmZpkR7Ou1IZmFrhnUiMnJhAQfeMjPrume7dLHwn+fV0mhOGRy/qtUmYfObDCdbyKyzgjB4/XkR4= 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:(4636009)(39830400003)(376002)(366004)(396003)(136003)(346002)(110136005)(7696005)(8936002)(66476007)(66446008)(66556008)(76116006)(8676002)(166002)(64756008)(66946007)(9326002)(316002)(33656002)(478600001)(966005)(86362001)(71200400001)(4326008)(9686003)(53546011)(6506007)(55016002)(186003)(38100700002)(52536014)(2906002)(5660300002)(122000001)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?VPaDdf2YyeLU9joCsAj2YjWYZWMvrWwNJvKpg35Xa3qYAZFBa5lF/1rPbc?= =?iso-8859-1?Q?FulGcm9hCBwckRNJeDBz1hdIFf7EYgAAG+2shEWW5mH2grZgbhPe0VfEXa?= =?iso-8859-1?Q?hBz07Xd88u9ienILIGkDAU5QImgnqP1xUUw6MGKS5BStqeyYRCKKTaXTYX?= =?iso-8859-1?Q?NOjieyUaZgMOYW3in4Pq4gYSb5TXaX6kf6OW68MDFznyz9aIiIZIrihxoY?= =?iso-8859-1?Q?BxiHpqcf6PnExhakFNyGHSEz7Mmm+1cQhj7TLDWPThuAjy8MA2R9gg2IOD?= =?iso-8859-1?Q?e1p1ICK4B+yoku+c8u6J0NOeIsoEH0ovYKFFP+/BQn8XhPMZnenTyOwpq4?= =?iso-8859-1?Q?snsqoqSGCYNHqvieqWFLoVQYhXzDJxmPFdZXMShZ6zhQC5HTlUsAbU52QT?= =?iso-8859-1?Q?uEOZVQKl7tdN+8hr2EMwCWIB7wAgMWUy4t68WAt5VgiqBP670SF4L1SHpd?= =?iso-8859-1?Q?5WdMdk+1XJ4/AWdJCdYrDfe9AajQru+sS+nETV2QUmuv6C+RhGEkMP2fj1?= =?iso-8859-1?Q?elWKlVjKGdpY1gAIwY+SfNvnrZ36Lc16AbHMCjuqKgLRHDYPKAbhwYEcNn?= =?iso-8859-1?Q?KQmmvMQ11PnzOvUL+S8UADtnpvHRWA1VLsysqkCyCuuKmlpYFGcvYsAv4g?= =?iso-8859-1?Q?8kv0eZfCe9lWQG83iUbjEedIlKJE0kB4BMyex03giIBwbPLb9MjwbasJh0?= =?iso-8859-1?Q?2piOhWbJjwY6hr8rtOi51RXT6BelcotVIOwt91/Vjg9UoWsI+DoIPQmZJG?= =?iso-8859-1?Q?JKEiVSDCHbUwfRv01LEOmibfuQ2KZmkRQ50fkMOjgv9hhN4uX2RqZr7vSO?= =?iso-8859-1?Q?mUGJ0VYSEfQ3gWETcDe5xXV/Sq6nFSA1RG/s5Z8D1Ll/oMrokGToVVaCRB?= =?iso-8859-1?Q?p7tVMLrmlPsN92UcAzMympsBvbN+1+u0hNBZChYSgVR4vX1yNZvINWf1iT?= =?iso-8859-1?Q?waOx7yi8/Bc/j15ZQWHWE/cZ2hFZe7/NSM6cwU+zIFD+dlS+oddhdWbD9r?= =?iso-8859-1?Q?Dx3g1Fged25Vui0VuUUcDq43iCRgm1OAyfbkJQydcTRq5YdUEQuqHLxgtq?= =?iso-8859-1?Q?65T4lNLJjGA1+c21WzJZUQbEeHCpwnHUCNqabFtloSxPQwc/UKRIUvzaWR?= =?iso-8859-1?Q?lzEskGG8geylaHphNygw6DrJpF45CxE9tCVlXFgoeoG71ISKydbnLAZM6a?= =?iso-8859-1?Q?leen+ouy3fsWJlNvwOgMnPF1RZM+adQC5Jy3f1YOcunwH90kwkAWncqibb?= =?iso-8859-1?Q?SI2KpvGatvTbL2Y29R6uB8XvTiJfTKrOSmbswR5zQGxqJ2v5CRn1EA11EM?= =?iso-8859-1?Q?C/PUmn/RxwguxWOB28XSSjaoyBdL0s6wOm7Qvjjur8+eGSQ94EnfLaNkaw?= =?iso-8859-1?Q?atcW8DPyA4bBUINx/bleygICo+6pgYBO9uOU1ozvuPOmh2Q0pMfrR+5j88?= =?iso-8859-1?Q?X1RtARbW7YDaUt2b?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB420694920BB2C388FF833387D22C9MN2PR13MB4206namp_" 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: 1887ea44-e711-4037-8c51-08d91a0f6bf6 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2021 15:12:58.6877 (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: LLEd7L3z2Pn1xYjBKhlPFLXCtQJ3Ucv6LlG8+LRruMOqzVOyO09gikvh1/S8h2r6tS4Bu1XtNdjh65AcMv4RTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR13MB4707 Archived-At: Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 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, 18 May 2021 15:13:20 -0000 --_000_MN2PR13MB420694920BB2C388FF833387D22C9MN2PR13MB4206namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, Following up on this. Please see inline. From: bruno.decraene@orange.com Sent: Tuesday, February 9, 2021 1:41 PM To: spring@ietf.org Cc: draft-ietf-spring-nsh-sr@ietf.org Subject: RE: WG Last Call draft-ietf-spring-nsh-sr Hi authors, WG, Speaking as the shepherd. Thanks for the -04 which answer my previous set of comments. I've reviewed the document again, focusing on the new text. Please find bel= ow some additional comments. =3D=3D=3D SR-MPLS =A76.1 " At the end of the SR-MPLS path it is necessary to provide an indication to the tail-end that NSH follows the SR-MPLS label stack as described by [RFC8596]." My understanding is that RFC8596 performs the above goal by adding an SFF l= abel at the bottom of the stack. In which case it would not be mandatory to= disable Penultimate Hop Popping on the prefix SID as draft-ietf-spring-nsh= -sr-04 is mandating. I"m seeing two options that you could either choose from or describe both: - a prefix SID dedicated to NSH. In which case PHP needs to be disabled and= there is no need for the SFF label specified in RFC8596 (alternatively, th= is prefix SID is _the_ SFF label defined in RFC8596, although 8596 refers t= o a local label(segment) while usually a prefix SID is a global segment) - use a multi-purpose prefix SID. In which case, indeed " At the end of the= SR-MPLS path it is necessary to provide an indication to the tail-end tha= t NSH follows the SR-MPLS label stack as described by [RFC8596]. Jim> I believe this is clarified in -v05. The new text says: As described in [RFC8402], the IGP signaling extension for IGP-Prefix segment includes a flag to indicate whether directly connected neighbors of the node on which the prefix is attached should perform the NEXT operation or the CONTINUE operation when processing the SID. When NSH is carried beneath SR-MPLS it is necessary to terminate the NSH-based SFC at the tail-end node of the SR-MPLS label stack. This is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore the prefix-SID associated with the tail-end of the SFC MUST be advertised with the CONTINUE operation so that the penultimate hop node does not pop the top label of the SR-MPLS label stack and thereby expose NSH to the wrong SFF. This is realized by setting No- PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665]. It is RECOMMENDED that a specific prefix-SID be allocated at each node for use by the SFC application for this purpose. Alternatively, if NEXT operation is performed, then at the end of the SR-MPLS path it is necessary to provide an indication to the tail-end that NSH follows the SR-MPLS label stack as described by [RFC8596]. So there are two options as you indicate above. 1) use the prefix segment a= s the indicator as described by the 1st paragraph in the new text, or 2) us= e an SFF label as described by the second paragraph. Also " At the end of the SR-MPLS path it is necessary to provide an indication to the tail-end that NSH follows the SR-MPLS label stack as described by [RFC8596]." In the scheme "SR-based SFC", "the end of the SR-MPLS" is only the last SF = (not all other SF on the SF chain). So how does others SFC have an indication that the NSH follows the SR-MPLS = label stack? Alternatively something along :s/ end of the SR-MPLS path/for all the SF al= ong the SR-MPLS path Jim> as far as I can tell "other SFC" do not need an indication as the pref= ix SID has End.NSH action so they will remove and cache the SR stack and fo= rward the NSH packet to the SF associated with the prefix SID. =3D=3D=3D This document defines two schemes: NSH-based SFC and SR-based SFC. =A75 is called "Packet Processing Details" but seems to only cover SRv6 and= the "SR-based SFC" scheme. Jim> I will change the title to reflect these details are only applicable t= o SR-based SFC (see below). If so, - it would be good if the title/section hierarchy could reflect this. Jim> done (see below). - what about the behavior for SR-MPLS with the "SR-based SFC" scheme (a pri= ori with SR-MPLS you equally need a cache in order to re-push the SR-MPLS h= eader) Jim> for SR-MPLS the label semantics indicates the same processing logic. I= added some text and broke up the SR-based SFC packet processing section to= make this clearer. =3D=3D=3D=3D =A74 For "SR-based SFC", my understanding is that the Service Chain (ordered lis= t of SF) is specified in the list of segments. Please forgive my lack of NSH knowledge, but it seems to me that the NSH SP= I look up may return multiple next-hop within a service path for a given SF= (e.g. for load balancing). (cf table 4 of RFC 8600). Jim> yes that is true. Here, if the NSH SPI change the SFC next-hop, the SR header on the packet w= ill be completely wrong (well most probably the list of segment will overri= de the choice from the NSH SPI look up). Is this a correct understanding? Jim> no. The SR header is removed before the packet is forwarded to the SF = so the SF next-hop is not relevant at the SFF when packets return as a look= up on the SPI will be performed (note: SPI does not change regardless of SF= next-hop). If so is this a bug or a feature? Either way, may be some text would need t= o be added. e.g. to warn that such SFC feature is not available anymore. =3D=3D=3D=3D=3D Nits: - I'm not a fan of the use of the term "details" which to me are "specifica= tions". (e.g. "5. Packet Processing Details", "6. Encapsulation Details", "= encapsulation details") Jim> I can change "Encapsulation Details" to simply "Encapsulation", and "P= acket Processing Details" to "Packet Processing for SR-based SFC". Would th= at satisfy your comment? - ID Nits still reports one error (**) on the new text (in the abstract). https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-sp= ring-nsh-sr-04.txt Thanks, Regards, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Tuesday, February 9, 2021 7:31 PM To: spring@ietf.org Cc: draft-ietf-spring-nsh-sr@ietf.org Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr Dear WG, This message starts a 2 weeks WG last call for draft-ietf-spring-nsh-sr [1]= . After review of the document please indicate whether you believe this docum= ent should be progressed to the IESG. In addition to yes/no, please consider providing a technical review of this= document; in particular if you care for this document. Indeed, since WG adoption, this document had benefited from little reviews = from the WG, so we need more review from the SPRING WG. If you are aware of an implementation of this document, please report the i= mplementation either on the list or to the chairs so that the shepherd can = report implementations in the writeup. Note that I'll forward that call to the SFC WG. Thanks! [1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr --Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_MN2PR13MB420694920BB2C388FF833387D22C9MN2PR13MB4206namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

Following up on this. Please see inline.<= /p>

 

From: bruno.decraene@orange.com <bruno.dec= raene@orange.com>
Sent: Tuesday, February 9, 2021 1:41 PM
To: spring@ietf.org
Cc: draft-ietf-spring-nsh-sr@ietf.org
Subject: RE: WG Last Call draft-ietf-spring-nsh-sr

 

Hi auth= ors, WG,

&n= bsp;

Speakin= g as the shepherd.

&n= bsp;

Thanks = for the -04 which answer my previous set of comments.

&n= bsp;

I’= ;ve reviewed the document again, focusing on the new text. Please find belo= w some additional comments.

&n= bsp;

=3D=3D= =3D

SR-MPLS=   =A76.1

&n= bsp;

" = At the end of the SR-MPLS path it is necessary to provide an

 &= nbsp; indication to the tail-end that NSH follows the SR-MPLS label stack

 &= nbsp; as described by [RFC8596]."

  =

My unde= rstanding is that RFC8596 performs the above goal by adding an SFF label at= the bottom of the stack. In which case it would not be mandatory to disabl= e Penultimate Hop Popping on the prefix SID as draft-ietf-spring-nsh-sr-04 is mandating.

&n= bsp;

I"= m seeing two options that you could either choose from or describe both:

- a pre= fix SID dedicated to NSH. In which case PHP needs to be disabled and there = is no need for the SFF label specified in RFC8596 (alternatively, this pref= ix SID is _the_ SFF label defined in RFC8596, although 8596 refers to a local label(segment) while usually a prefix SID = is a global segment)

- use a= multi-purpose prefix SID. In which case, indeed " At the end of the S= R-MPLS path it is necessary to provide an  indication to the tail-end = that NSH follows the SR-MPLS label stack  as described by [RFC8596].

 

Jim> I b= elieve this is clarified in -v05. The new text says:

 =

  = ; As described in [RFC8402], the IGP signaling extension for IGP-Prefix

  = ; segment includes a flag to indicate whether directly connected=

  = ; neighbors of the node on which the prefix is attached should perform=

  = ; the NEXT operation or the CONTINUE operation when processing the SID.

  = ; When NSH is carried beneath SR-MPLS it is necessary to terminate the=

  = ; NSH-based SFC at the tail-end node of the SR-MPLS label stack.  This=

  = ; is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore

  = ; the prefix-SID associated with the tail-end of the SFC MUST be=

  = ; advertised with the CONTINUE operation so that the penultimate hop

  = ; node does not pop the top label of the SR-MPLS label stack and=

  = ; thereby expose NSH to the wrong SFF.  This is realized by setting No= -

  = ; PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665].  It is

  = ; RECOMMENDED that a specific prefix-SID be allocated at each node for=

  = ; use by the SFC application for this purpose.

 =

  = ; Alternatively, if NEXT operation is performed, then at the end of the

  = ; SR-MPLS path it is necessary to provide an indication to the tail-end

  = ; that NSH follows the SR-MPLS label stack as described by [RFC8596].<= /o:p>

  = ;

So there ar= e two options as you indicate above. 1) use the prefix segment as the indic= ator as described by the 1st paragraph in the new text, or 2) us= e an SFF label as described by the second paragraph.

 &= nbsp;

Also&nb= sp;  

"&= nbsp;  At the end of the SR-MPLS path it is necessary to provide an

 &= nbsp; indication to the tail-end that NSH follows the SR-MPLS label stack

 &= nbsp; as described by [RFC8596]."

&n= bsp;

In the = scheme "SR-based SFC", "the end of the SR-MPLS" is only= the last SF (not all other SF on the SF chain).

So how = does others SFC have an indication that the NSH follows the SR-MPLS label s= tack?

Alterna= tively something along :s/ end of the SR-MPLS path/for all the SF along the= SR-MPLS path

 

Jim> as = far as I can tell “other SFC” do not need an indication as the = prefix SID has End.NSH action so they will remove and cache the SR stack an= d forward the NSH packet to the SF associated with the prefix SID.

 &= nbsp; 

=3D=3D= =3D

This do= cument defines two schemes: NSH-based SFC and SR-based SFC.

&n= bsp;

=A75 is= called "Packet Processing Details" but seems to only cover SRv6 = and  the "SR-based SFC" scheme.

&n= bsp;

Jim> I w= ill change the title to reflect these details are only applicable to SR-bas= ed SFC (see below).

&n= bsp;

If so, =

- it wo= uld be good if the title/section hierarchy could reflect this.

&n= bsp;

Jim> don= e (see below).

&n= bsp;

- what = about the behavior for SR-MPLS with the "SR-based SFC" scheme (a = priori with SR-MPLS you equally need a cache in order to re-push the SR-MPL= S header)

&n= bsp;

Jim> for= SR-MPLS the label semantics indicates the same processing logic. I added s= ome text and broke up the SR-based SFC packet processing section to make th= is clearer.

=3D=3D= =3D=3D

=A74

For &qu= ot;SR-based SFC", my understanding is that the Service Chain (ordered = list of SF) is specified in the list of segments.

Please = forgive my lack of NSH knowledge, but it seems to me that the NSH SPI look = up may return multiple next-hop within a service path for a given SF (e.g. = for load balancing). (cf table 4 of RFC 8600).

&n= bsp;

Jim> yes= that is true.

 =

Here, i= f the NSH SPI change the SFC next-hop, the SR header on the packet will be = completely wrong (well most probably the list of segment will override the = choice from the NSH SPI look up). Is this a correct understanding?

&n= bsp;

Jim> no.= The SR header is removed before the packet is forwarded to the SF so the S= F next-hop is not relevant at the SFF when packets return as a lookup on th= e SPI will be performed (note: SPI does not change regardless of SF next-hop).

&n= bsp;

If so i= s this a bug or a feature? Either way, may be some text would need to be ad= ded. e.g. to warn that such SFC feature is not available anymore.

&n= bsp;

=3D=3D= =3D=3D=3D

Nits:

- I'm n= ot a fan of the use of the term "details" which to me are "s= pecifications". (e.g. "5. Packet Processing Details", "= 6. Encapsulation Details", "encapsulation details")

&n= bsp;

Jim> I c= an change “Encapsulation Details” to simply “Encapsulatio= n”, and “Packet Processing Details” to “Packet Proc= essing for SR-based SFC”. Would that satisfy your comment?=

&n= bsp;

- ID Ni= ts still reports one error (**) on the new text (in the abstract).

= https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-sp= ring-nsh-sr-04.txt<= o:p>

&n= bsp;

Thanks,=

Regards= ,

--Bruno=

&n= bsp;

From: spr= ing [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /span>
Sent: Tuesday, February 9, 2021 7:31 PM
To: spring@ietf.org
Cc: draft-ietf-spring-nsh-sr@ie= tf.org
Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr

 

Dear WG,

 

This message starts a 2 weeks W= G last call for draft-ietf-spring-nsh-sr [1].

 

After review of the document pl= ease indicate whether you believe this document should be progressed to the= IESG.

 

In addition to yes/no, please c= onsider providing a technical review of this document; in particular if you= care for this document.

Indeed, since WG adoption, this= document had benefited from little reviews from the WG, so we need more re= view from the SPRING WG.

 

If you are aware of an implemen= tation of this document, please report the implementation either on the lis= t or to the chairs so that the shepherd can report implementations in the w= riteup.

 

Note that I’ll forward th= at call to the SFC WG.

 

Thanks!

 

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr

 

--Bruno

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_MN2PR13MB420694920BB2C388FF833387D22C9MN2PR13MB4206namp_--