Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

James Guichard <jguichar@futurewei.com> Fri, 18 June 2021 15:00 UTC

Return-Path: <jguichar@futurewei.com>
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 276B33A1363; Fri, 18 Jun 2021 08:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, 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 QJQDsaknOUae; Fri, 18 Jun 2021 08:00:03 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2090.outbound.protection.outlook.com [40.107.93.90]) (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 242A13A1314; Fri, 18 Jun 2021 08:00:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W0DzTV6nCKF21Kb1PG4gNY+oZeYsqx3UBzimEgsvt8JErVdoy8DvvPf+lsT52pi/STfqdtkI85AomtRWCpEyIjqzaTnKCskzOh3TXkQEciEdGAQ7aU4/yF3MumZn9uZ7Azjj9hLggxUmgPfiHJUSkQ388Mg0ST+F+/EeKF/p641sAgCFvED+ZdfA4yG5wkvdMoIwmZepEbbsP6Y2K4QJkQyMyxiMZ+KVubm1igLb9/+SPmc58fRsRgrI2/YG1TvpKLoMvV573B+vdlzq16bjoF/o//OnqHWX/1njKten56G1I3F3fTgyiBDjWN8ktMjHnucDi5uvTlJBJktwpTaRLQ==
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=efB6VYe0NEBebIBhm18zMP2eE0C2sLCvW5tRGzC70tI=; b=HdeetPv6UWPCWKK4swQqBtC2VpK/wIqeKB9hrdX934ya0se0MKAiQMCJvqCAKlzjriS8xjYDTzxW9H3gLmOv+ONxWmntO44YtpQtu4LnM59wZXT8kSXpns9HArzUs3EhMgEFujkTyLqVShK3andXrG5Q6tpehAhpQChJ6qe++5pocMvnA88Xvmml1kT2iKXmLaVcADU/PqpXW75TkJg6DpMTMas+V+nBtWeI04TaBaLzQk3sCLar0ystzq0FzKsjf75QN97Ty1n2E+JT/CjH7ymPGV6V6EHos45RDmxKtvPpsEb6J1E3zet5lO1ZTrCAyRR6c023j9Z2Ikatde4aVw==
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=efB6VYe0NEBebIBhm18zMP2eE0C2sLCvW5tRGzC70tI=; b=ptnN0kZkYSK0tGIa5z7S4G/Y9aQWnBSjqh3jxdstUR1ZSf0xeg2fg/1XwZ2rxHheYZ73i3/nhEvKQJoZsVHfWmheBhzzbYF2WULf695OtXhURNgzg9K/4yNTYwGpug1k4rBh0CkE+6/zbsrsjYGPH2tMOAVNkppp5al20OzMtmE=
Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by BLAPR13MB4738.namprd13.prod.outlook.com (2603:10b6:208:322::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.7; Fri, 18 Jun 2021 14:59:58 +0000
Received: from MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::5841:26e:9cf8:7661]) by MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::5841:26e:9cf8:7661%7]) with mapi id 15.20.4264.011; Fri, 18 Jun 2021 14:59:58 +0000
From: James Guichard <jguichar@futurewei.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>
CC: "draft-ietf-spring-nsh-sr@ietf.org" <draft-ietf-spring-nsh-sr@ietf.org>
Thread-Topic: WG Last Call draft-ietf-spring-nsh-sr
Thread-Index: Adb/EbzdQyDXcLfTRQ6v+vtwpmiyOgAABBewEhO1tZAFRL5gMAH3kCIQ
Date: Fri, 18 Jun 2021 14:59:58 +0000
Message-ID: <MN2PR13MB42063DEA31BA4160BAA3034DC20D9@MN2PR13MB4206.namprd13.prod.outlook.com>
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> <MN2PR13MB420694920BB2C388FF833387D22C9@MN2PR13MB4206.namprd13.prod.outlook.com> <28823_1623169127_60BF9867_28823_29_1_53C29892C857584299CBF5D05346208A4CDC8DB3@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <28823_1623169127_60BF9867_28823_29_1_53C29892C857584299CBF5D05346208A4CDC8DB3@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:6d8d:c8f9:d11f:2e53]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f8295036-f934-4a0a-9947-08d93269bdcf
x-ms-traffictypediagnostic: BLAPR13MB4738:
x-microsoft-antispam-prvs: <BLAPR13MB473803353EBDF6B0E7A71C58C20D9@BLAPR13MB4738.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vLmurNwR8D82WKpYD81kxVYJ8fsJQbRaMTH1PRoz9cNsVfa/eAFCZcBtysmBpfUqmfACblWvag4jN8FN+mJs1NkaGc+P4Hzo9zk+C9kbmrJSMrqpSJ6aE/vCmqeAJLwSlJKzj7zBQxUvDfIXCeQNStclgB0Qun+kVkCvUpbT2st9QetEn6zuW/Z+1hVmKr3ft3cqcWylYOgxgVMhfvxEuUPpnKYIN+r29mjnyBUbalHpV7CBuInIov/q+MM79dyB9Af8D7qEIdbGeMPajvT0BgbmK9gediidkNedEMoJNDoC2R8tcZxtc+0KJRT28W7KdFybd4O/zE+2eFdfO0zD25R1XorkOpa3wZNlThDV3TVTJ14YN2rJDUlLPFchs89Eq0s5OUJrkytonPiVVA+IjGaZ80GAuRRRCsxAbA9l9Xva+65fwN2nfAb1J5NG4BRNKoEN4T/udSeDn3jxtZcXD2zqSB32VrpR9METnPPKbVHpbXubRDBF1k9/vFRw6u9hpL/EjbbX2b4BvVG+9dJWP1PqOryCtK4mKCmei82KBBNPFWYwj42RjvfIewb9GXqsJg/dzQiEag2El5gS6dLiyy4jllwnB2tM8D/lGfJnyz2SeY7zdJG3PoLzEe6EHH4iJ+1rngZvKX5KYjkx82B3c0408zi3j7pQ810oT9dTTdqM2Hx/IiKItg2mGFFJ/Fa6z93wh0AhZeHlbzusCA4C7OlC8GRrcpxV43Tmvvc+YFxr7xCx9DLWB4/cNiBa2lFd4l5Doq1JIebKJlMJZHPTow==
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)(346002)(376002)(136003)(39830400003)(366004)(396003)(110136005)(316002)(83380400001)(38100700002)(166002)(2906002)(55016002)(52536014)(7696005)(76116006)(66556008)(71200400001)(66446008)(64756008)(8676002)(86362001)(5660300002)(66946007)(186003)(8936002)(478600001)(66476007)(4326008)(9326002)(122000001)(53546011)(9686003)(6506007)(33656002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?C3+4ab1fCEadIJyYv7sCz3Y02xyYa4G3QghikARl6UYxpgWg0CWL0b2qmx?= =?iso-8859-1?Q?QcfNRYjKxoXsviHVb6AM2YJR/uHr8Qvr7Ris+B1Y1C5+izuVPjevdL52LK?= =?iso-8859-1?Q?XsFIsFe/pyUS/RWW7IRoA33txpEngEgOypCrHg927t3ATxfu+yr5IPFV+G?= =?iso-8859-1?Q?q0NsWzx5iVmbcx/+vwr/geQZPDcGtbnEiYcksNumec5z+hvGPgL91Zrin2?= =?iso-8859-1?Q?gtDL1vm0B4We+/4zeDbPkBBl5TrpafaYDIqqqseXNhHZO+AsJ+WG15UQp3?= =?iso-8859-1?Q?L88qscRt/Wx+5uaAAw4NxV3cnj29aM82T75muVHECZxZm+agz/qeMlSgWD?= =?iso-8859-1?Q?0hr3mnOfx+b/3ai734cjSTHlikQH0XycN1E/7GeNGRSLJuy4JolmiDeV68?= =?iso-8859-1?Q?LP+9nrKCLWXu4Ndf6Cbk2qUuy6rngmslkEKTG7Y/njvhntyoQxVzmrRoOz?= =?iso-8859-1?Q?G+kq+utfDd4oelHeAtC0tV48Umex83tf7geTaSDGS0at7ELRWlQT1nBaKh?= =?iso-8859-1?Q?QZRBOnu/iyuG0pDzT8cuRMbK/dT97ckOyr70NfX2O9Ff5vvQEsrndDTsn5?= =?iso-8859-1?Q?prSagFE1mF205GerrZCqbSS+l6WLzua+fvW35mS67gRwaiPUjumZyZW5kQ?= =?iso-8859-1?Q?JhMVAFjEJc/Arg409rLVdQBc5qupWiIG8nB8QLTFqpnAnCNXYlOntiXAx3?= =?iso-8859-1?Q?yUXNKqbviFCIQeDwLznS9OVb1JOs418yF620mPNrmnUlZDEK1fFeebLkGb?= =?iso-8859-1?Q?zKra7+ydRH+ywyyHk0bJJiDgDdYWk72hXu0/r+AHxaniLRTWLrW84iAFTu?= =?iso-8859-1?Q?UdGFUZNLp4vOshlRh0xRzXmxYwDXS/PmNDUPNrS6M6ARwV4t/WBykuOfXP?= =?iso-8859-1?Q?QURVzlyKQU+zR4fdLaR01fA9U9TN5zYUtD0jcqSHh7MUlvFzynu96S0I9B?= =?iso-8859-1?Q?pu/HnO4iNqrPnFVQ9EjATv1juI+VSFWKqPaPY1ENt8gGls/ATQKHDJhqc7?= =?iso-8859-1?Q?eYzt99MyeJwAKwqllaJq3aA+vNtkTpvbF7M9gmHrY/GF50dU5pgxs2J0fB?= =?iso-8859-1?Q?PntE0nycbAXXMKAwaNv2qS5VuN7uHzNE9CyFI8AX6holdYMWF2JLnzPlPm?= =?iso-8859-1?Q?tm0IArsHo9COtN785MPluvzGelkGSD7b4E9Xm+WEcVyp5Lw37g6XPqXXS8?= =?iso-8859-1?Q?n858p+jqLLwfJNdmJSAeBOc2LO8tVXRdMD1neyi2FzYyQJdQzYo8fFsC6W?= =?iso-8859-1?Q?wD8c45PEzglX9JtGVEB6weA4ULO9E2NhayGlQNZ+M3gdhPQDGYqlA5z2Yw?= =?iso-8859-1?Q?NX8XqhdYgMhAWzLyCqYs1O/9wCWvYb1kDBvWC4nKGchwAkL0dOwlpVrCrk?= =?iso-8859-1?Q?g5ckxw/fS3b0+r8K0TfDNUOrsN4g/52bEOQh8pwfWoQ8RYOT2xSqYPWbdp?= =?iso-8859-1?Q?jRnzofFzQSYrrxZL?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB42063DEA31BA4160BAA3034DC20D9MN2PR13MB4206namp_"
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: f8295036-f934-4a0a-9947-08d93269bdcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2021 14:59:58.6390 (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: hCzL4S7ZRSPsgNzPMo4HQXMls4lsGEo5hNcyg0ARoeRLUE8jDqtRMJFSr5WnGs8kmUvj9ovreg9vlfFG81S7fA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR13MB4738
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/j5iESNTdjoJS2hp6TbF1bhNw360>
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\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2021 15:00:11 -0000

Hi Bruno,

Latest version covers most of your comments I think. Please see inline.

From: bruno.decraene@orange.com <bruno.decraene@orange.com>
Sent: Tuesday, June 8, 2021 12:19 PM
To: James Guichard <jguichar@futurewei.com>om>; spring@ietf.org
Cc: draft-ietf-spring-nsh-sr@ietf.org
Subject: RE: WG Last Call draft-ietf-spring-nsh-sr

Hi Jim,

Thanks for your reply.
Please see inline [Bruno]

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, May 18, 2021 5:13 PM
To: DECRAENE Bruno TGI/OLN <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>; spring@ietf.org<mailto:spring@ietf.org>
Cc: draft-ietf-spring-nsh-sr@ietf.org<mailto:draft-ietf-spring-nsh-sr@ietf.org>
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Hi Bruno,

Following up on this. Please see inline.

From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Sent: Tuesday, February 9, 2021 1:41 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: draft-ietf-spring-nsh-sr@ietf.org<mailto: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 below some additional comments.

===
SR-MPLS  §6.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 label 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, this prefix 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 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].

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 as the indicator as described by the 1st paragraph in the new text, or 2) use an SFF label as described by the second paragraph.

[Bruno] There are two options but the text currently says that the first option MUST be used ("the prefix-SID associated with the tail-end of the SFC MUST be advertised with the CONTINUE operation") which seems to nullifies the second paragraph ("Alternatively, ").
So may be some rephrasing may be needed to indeed allow both options.

Jim> Covered in latest version.

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 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 and forward the NSH packet to the SF associated with the prefix SID.

[Bruno] OK for SRv6.

For SR-MPLS, how does this work? Draft says "In the case of SR-MPLS this will be a prefix SID [RFC8402<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8402&data=04%7C01%7Cjguichar%40futurewei.com%7Cdcd09bcf14b84c5ab81608d92a991953%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637587659333473559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7p4OEBu%2Fztrqd3ZxPPAg0D4bSwgGSptR%2Ba%2FerR7zLkg%3D&reserved=0>]"

 - Can it use the "regular" prefix SID? (draft only says that It is RECOMMENDED that a specific prefix-SID be allocated at each node for use by the SFC application for this purpose.)

 - If not, does it needs a specific & dedicated IP address? (RFC8402 seem to mandate that a Prefix Segment be an IGP prefix segment and that a single prefix-SID be advertised per tuple <prefix, topology, algorithm>

 - How does the ingress know that this Prefix SID is to be used for SR-based SFC? And only to be used for SR-based SFC?

Jim> In MPLS (including SR-MPLS) nodes uses labels as they please.  So yes, an SFF that may also be an MPLS switch needs to advertise separate labels to indicate that they are used for SFF processing (looking at the NSH).  As far as I know, MPLS / SR-MPLS has never standardized how this is indicated / coordinated.  By assumption, the PCE / Ingress classifier knows what labels to use.



Jim