Re: [spring] IPR call for draft-ietf-spring-nsh-sr

"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com> Tue, 09 February 2021 20:41 UTC

Return-Path: <wim.henderickx@nokia.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 858983A0AB5 for <spring@ietfa.amsl.com>; Tue, 9 Feb 2021 12:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.151
X-Spam-Level:
X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 lEPy8aTfiNYT for <spring@ietfa.amsl.com>; Tue, 9 Feb 2021 12:41:25 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2124.outbound.protection.outlook.com [40.107.20.124]) (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 7F18B3A0A6F for <spring@ietf.org>; Tue, 9 Feb 2021 12:41:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gJXZxrjFlTCr/nICKgpXgOa91cIYe8VfoxMIaKV6EBLh+1GHIRSvmnQoyMTThVfIU6HxZmUdxblENiyRv9yWm0eks34kGCFyxIUtY+Gf91+PbSwLKRVYMeqgU+V02l5ZAVYaIwGgU/ob6ym85jZSeuXAFYfML4duz8eff4rrDWyc6f5EisJMT0rgxTBjP09Fq9neuy9s+GAalJQJNc9kYNLpa7wx/9/b2WugVtOeBnJRO1piXDR2+VLLgsNUHiLTgVg9G29kzFyRVwP3tNkPIwTxYX2s8tAhyNT/gP7hyOKooBpJSMW0+vY52vDSP9b8WWoM0rUrK6uzgEuuWF9sPg==
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=0jnFR1enXtcR5SIB2XVgb3dnyEd+cTmBQDdAu7zHyNk=; b=NVsGcy1EKYU0n9GlR61TXbGcnqt2h1dAvmQyCO6qhCHKcIuyYP2+nqRAHOW93K+GK0cAb/2oTjdgPUBlB70+M6L3N97jSwQkIEZzYWN2RR2Lpaw4IR7Yz2/FcEmFZR08ZN80HK5wimk3fIxWZORM8XYTxk+JBsbp0IICl/Rmo7dp4K61VY0FG5s8E2e+IzAA16oacjT2BgAEdrKuTnCzH9bd125ZZzm0zhZU5fBP/Ka+BcraUmuOScnWI/Jbah/rb8MrbHoBvwVGqAHt6/7w2SNWiHKL02OT+AP3/2DahXCzIuO+wbluE6kE4iCWEWG9C8QaJSCqNetoXv8Ne6zbZA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0jnFR1enXtcR5SIB2XVgb3dnyEd+cTmBQDdAu7zHyNk=; b=SK4sDVoMMh/CVGuWuXK8IVtUEy3rl+17ktbpSRAdffqJzZEWXYbbeDjCBe8SjWNK53dKdphZKA/4p6eFwVexMyLbnjNXiDpN21EG8pQ0kSl/zlptBXxSiuFC10qYRNuKcpcViYj0yxWGusQ3bqOWcoRnr5pYhNXQH/17377an+Q=
Received: from (2603:10a6:208:7a::20) by AM0PR07MB5443.eurprd07.prod.outlook.com (2603:10a6:208:109::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.15; Tue, 9 Feb 2021 20:41:23 +0000
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com ([fe80::ed49:971c:692a:d9dd]) by AM0PR07MB4497.eurprd07.prod.outlook.com ([fe80::ed49:971c:692a:d9dd%6]) with mapi id 15.20.3846.025; Tue, 9 Feb 2021 20:41:23 +0000
From: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] IPR call for draft-ietf-spring-nsh-sr
Thread-Index: Adb/DFmscfU4Dv+nQ5iq2dZ1uEWZOgABrFyAAAZQ7QA=
Date: Tue, 9 Feb 2021 20:41:22 +0000
Message-ID: <19282786-933F-4D5E-B31F-51133B4B7A42@nokia.com>
References: <12940_1612893971_6022CF13_12940_476_1_53C29892C857584299CBF5D05346208A490C492D@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <11f0e908-95ee-959a-3bfa-aadb6502de7c@joelhalpern.com>
In-Reply-To: <11f0e908-95ee-959a-3bfa-aadb6502de7c@joelhalpern.com>
Accept-Language: nl-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.45.21011103
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [81.82.181.214]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0857630e-70fd-4737-b237-08d8cd3b1025
x-ms-traffictypediagnostic: AM0PR07MB5443:
x-microsoft-antispam-prvs: <AM0PR07MB544318CC22A9B8ECD0396920838E9@AM0PR07MB5443.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vVmaLVacaW2200k19ao9RgEfF07JyZui4nTJ43BzWJs9lTymqkas1paiq8181nlzKBNAJliFSyg1JSkw4P1sZF9WUNAV8E15wVa4qz9A3+SqK+g46XYYIkL5kjO24ezZUbah6Sd97d1oeuo6PmhcaGT+7Mbu6IVRDxoD47ogKEU1UTqlOWbCzaCtWidtQUsfooLk0goj1Yesi9JnPYubX587qnZEauM+1sgg7/Ndy4K3lLDo3J72zIWydC8jsvOwWgW3DrSMlpmMZmp4EpnO9XAjBjEDVVvYn2GZlQsamxmYHrU6LOPmWObpA0gfObpvVfyfnkzrwg4Uyp1zu+AZXCpDKNqFD4U47luE7jDC82rRL6JAMXXtZlUYPNp1+Udvh9gAX58yJetzwoHG08evgX0AcyfXOBE04YWHtZYWuXp//gcgW7Ub85H7Bgwki80s/cVTtj/FicjwPHMUUwVjnRnP61uQFKbRLIIwDAH5DIEbJS8sv3slxmbpRYFgiTanTt/dyEc1pEojMINEptGao6L9BX0EWifTcXayRzOVwyFsJ1NhJHVt1FbMZAJ1VtltJ/jJi3NNx8EDK7FMb6fTFkNJNZ05wtb62rCfhPcb6QzggAFEDX5BmHgG2l4ifmm0xd9iChN6WoYinTkIOMX6KQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4497.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(36756003)(110136005)(186003)(66946007)(83380400001)(86362001)(2906002)(30864003)(316002)(66574015)(5660300002)(26005)(33656002)(66446008)(66556008)(66476007)(6512007)(55236004)(478600001)(966005)(6506007)(64756008)(53546011)(76116006)(8936002)(71200400001)(6486002)(8676002)(2616005)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?YUdyeGROOW5iRTVEWnh4R3ZINDd5RUx0VXRoWkd0UzNnWjdZaGE2b3VYUFpT?= =?utf-8?B?L2FZVTNSbG5wRll3Yjk2a1ZxcS9BSC9wdTBGbi9EZDdlNFpZaGZGNmJqUTJD?= =?utf-8?B?aGs5RTl5NndvVVJUUEFpK1VvQUZPZEZQTEVpUVMyN3U2RUR4Y3NmeWVTbnlC?= =?utf-8?B?RjBCVk5ZTDc4NHZ3Z3JkYTVLTlhHbm9IQmxoajZWM1MvaENxUm1UNDJxRFQ3?= =?utf-8?B?aFh6bTI1eEZTcUgyNnRpTWl1RmJhTGRrQWFURXl2WTFTY1RwY3lpdThIMzZ1?= =?utf-8?B?SlNVTzZPOXJkVGVxSUFwZkZWQUFLcXhpOWEzbnhYWmRzTk9nemhvS2NjUnVm?= =?utf-8?B?TDZSQUNEV3MvWVB5UkwzV2xTTUVwSXZvKy95aXFBalRUZHlKSDR4OFRNQytw?= =?utf-8?B?U0RYcm00RlpFMEg5YWl4c01EejhFMzdURkorNTE4T3cwQW1Zczh1ZWgzMWdI?= =?utf-8?B?OUlvaU5aS0VCR0NCT1pkNFR0RmJnRU91S0FTZ1gweFptNHFLazgyL3NPZ3py?= =?utf-8?B?Q2U4REF4UHhKdS9CZitNZ2NrM0U1WUU1TDk3OVRaL2doSVpuRkI5bEFxbkRz?= =?utf-8?B?VFY3STdRTkViVDA0dXdQKytNRzR2YWVsZzRpT3JJdjY4UFNKM1o5eFlrdkJr?= =?utf-8?B?bng2d1MyQzNFYW0rYmxzRUNuSG42czVCQ1FUY1orTUgyT1c4b0hORUtPRlZD?= =?utf-8?B?cTllN01FL3l3amQwdmQxcWVBdWREajU5ZWJwT2N0ckt6cUdhTXJZcE1nZVN0?= =?utf-8?B?NWJZZkFEanMxRE1xOWhmRDc0eEd2SlZaV3ZoMHFwRXAzTmpLV2VXYmZrenNK?= =?utf-8?B?ak9QcEUyRkxvOEUzOEZabFV1UDlQcGRnSUM2Y21rYjdhZjRoZ3UxNU5zeXZj?= =?utf-8?B?ajRSaG9VN2EvRVcwSzg2MzdiZytMNlZCTDdQWG9ET0VDMmxidSs4YVRXL3RM?= =?utf-8?B?Y0NHMWQ1V0V1RkpzUnpYYkVHc0RVc1JWNkZBa3cwRWk3REhuVFFwODEvUlBO?= =?utf-8?B?Nmg5UkJjZk9uMzNXcGxWb0FORkg2VEpVRVZ3YWlIZWpoZDVJclkzNTZSQmdF?= =?utf-8?B?T1luR2YyZjlhOWNIeXFBRzVpWVFlSG5RVmN6UnJGeCtneVBYY1BwSFZuTW1T?= =?utf-8?B?bFpGTVJnVkJzNGFxb0dPWEJPSXpnOFJQZU81eU04YTg0Sk80ditESUR6Q215?= =?utf-8?B?RzBHQW5hS1h2Ukh5U3dzTXFIVEp3dnl4Q0RINDJvSllFL2ZDa1pSZ3pnM3pV?= =?utf-8?B?b0QyK2hJTUNOdExBZTV5aG9TNUszUE5JaENFR1RvcFhJSVVGbnRWRTJyWnNk?= =?utf-8?B?Ti9STmp3TW5JUzkzR0k2S3JwdzIvWmwvYUc5VExIVU9vaHVibjF6cGl0d3Va?= =?utf-8?B?b3FSVmt1ZDFJVUwybStWTm00SUtoNzV3QzZyZml6RGZWNzBud0ViZno5WTZE?= =?utf-8?B?Y2xDS3RrL2hRMVhwKzlUUGhtTkpuQksxRDNWZXJNR2VaeGNZWmY0U2syMDFy?= =?utf-8?B?ZVFRdGVuSDlpL3hTaVZnRkJ6cXQ4bWRFaXlSUUJ6Z2FpVFQySElLR05rcGF4?= =?utf-8?B?eFNmSHMxMjFaekJ6NklzakJrRGRuK05mZmkwbmt0ZjJvUFBoV0p5WVQ0aUFv?= =?utf-8?B?bkhpQ2laRTFlSmRWT3pocWVIRFhxV1hwZ1lEUE92UnpQbk1wdjRIdytXcSsw?= =?utf-8?B?SmtHbFVzeE12TmhSS1k5WE4zVG9waTYxM0RsUjJ5d0gzTVNkc0VWNGZvVndi?= =?utf-8?B?emFPSCs4VkN3NHc1UGtRV2Y0QWZFYWxsMWZBTkhIRDBKdzlQQmd4THdxUjQ1?= =?utf-8?B?b0hJci9ENzN3dU1KMmUyQT09?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <5F44C32E7022D04D81EE0EC26C85B136@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB4497.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0857630e-70fd-4737-b237-08d8cd3b1025
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2021 20:41:22.9216 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 40mPxieMWgq/7xoYZMjpLDqZ//9/gJBWHRhaNbBoiNfHrizn6Znn/wEAXZWQ9MoGiAcQKH846ztu9m669fB3HC5fZSaDSCcgnPqK9xj/Tiw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5443
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/cQ2Yt4KxWkmQHbvUdPrfqPDOvJA>
Subject: Re: [spring] IPR call for 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: Tue, 09 Feb 2021 20:41:29 -0000

As a co-athor, not aware of IPR related to this draft

On 09/02/2021, 19:40, "spring on behalf of Joel M. Halpern" <spring-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:

    As a contributor, I do not know of any undisclosed IPR on this draft.

    Yours,'
    Joel

    On 2/9/2021 1:06 PM, bruno.decraene@orange.com wrote:
    > Hi authors, contributors, WG
    > 
    > Authors of draft-ietf-spring-nsh-sr have asked for WG last call.
    > 
    > In preparation of the WGLC on draft-ietf-spring-nsh-sr [1], this email 
    > starts a poll for IPR.
    > 
    > If you are aware of IPR that applies to draft-ietf-spring-nsh-sr please 
    > respond to this email and keep the mailing list in copy.
    > 
    > If you are aware of IPR, please indicate whether it has been disclosed 
    > in accordance to the IETF IPR rules (detailed are described in RFCs 
    > 3979, 4879, 3669 and 5378).
    > 
    > If you are an *author or contributor* please respond to this email, on 
    > the SPRING mailing list, regardless of whether or not you're aware of 
    > any IPR.
    > 
    > If you are not an author or contributor, please explicitly respond only 
    > if you're aware of IPR that has not yet been disclosed.
    > 
    > Thanks,
    > 
    > Regards,
    > 
    > Bruno, Jim, Joel
    > 
    > [1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr
    > 
    > *From**:*spring [mailto:spring-bounces@ietf.org] *On Behalf Of 
    > *bruno.decraene@orange.com
    > *Sent:* Monday, November 2, 2020 4:26 PM
    > *To:* spring@ietf.org; draft-ietf-spring-nsh-sr@ietf.org
    > *Subject:* [spring] draft-ietf-spring-nsh-sr
    > 
    > Hi authors, WG,
    > 
    > Authors of draft-ietf-spring-nsh-sr have asked for WG last call.
    > 
    > Before initiating it, I’ve done a review of the draft as document shepherd.
    > 
    > Please find below some comments.
    > 
    > ---
    > 
    > It’s not crystal clear to me what the scope and the goal of the document 
    > are.
    > 
    > -From the abstract, it’s an informative description of two applications 
    > scenarios
    > 
    > -From section 5, it’s a specification of how to integrate NSH and SR.
    > 
    > oAlthough it’s only really specified for SRv6 and not SR-MPLS.
    > 
    > Please clarify to update the document as needed.
    > 
    > ----
    > 
    > IdNits reports for 2 errors. [1]
    > 
    > ** Downref: Normative reference to an Informational RFC: RFC 7665
    > 
    > -Probably the only really normative reference is in the security 
    > section. Do you think that a reference to RFC8300 could be used instead 
    > (8300 has a large security consideration section)?
    > 
    > -I noticed that 8300 had the same issue. What was the feedback from AD 
    > at the time?
    > 
    > ** There are 4 instances of too long lines in the document, the longest one
    > 
    > being 82 characters in excess of 72.
    > 
    > Could you please correct in the next version of the draft?
    > 
    > [1] 
    > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-nsh-sr-03.txt 
    > <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-nsh-sr-03.txt>
    > 
    > -----
    > 
    > Abstract
    > 
    > The abstract feels like the document is informational (e.g.,This 
    > document describes two application scenarios”)
    > 
    > But the document asks for an IANA allocation requiring a STD track 
    > document, so the draft needs to be std track.
    > 
    > Do you think that you could add that the document defines the 
    > encapsulation of NSH for SR-MPLS and SRv6?
    > 
    > ----
    > 
    > The introduction section seems to be coming from the SFC WG.
    > 
    > -May be adding some text about SPRING?
    > 
    > -Although this is a personal opinion, I find some sentences a bit 
    > marketing oriented. Could you please have a look? E.g.
    > 
    > o“The SFC architecture has the merit to not make assumptions”
    > What about “The SFC architecture does not make assumptions”? This seems 
    > more neutral.
    > 
    > o“Among all these approaches, the IETF endorsed a transport-independent
    > 
    > -SFC encapsulation scheme: NSH [RFC8300  <https://tools.ietf.org/html/rfc8300>]; which is the most mature SFC encapsulation solution. »
    > I’m not sure how much “is the most mature” is true or not. I’m not sure 
    > that the SPRING WG needs to make such statement nor that it is best 
    > placed to make such statement.
    > I’m not sure about “the IETF endorsed a transport-independentSFC 
    > encapsulation scheme”. Idem with regards to SPRING WG. I’m not sure that 
    > this is a typical statement in RFC. If so, it feels like the IETF would 
    > have equally endorsed transport-depending SFC encapsulation scheme. 
    > [RFC8595] https://tools.ietf.org/html/rfc8595 
    > <https://tools.ietf.org/html/rfc8595>
    > 
    > -“This design is pragmatic”
    > Looks like an opinion. Plus I’m not sure that the SPRING WG needs to 
    > judge the work of the SFC WG.
    > 
    > ----
    > 
    > §2
    > 
    > “The two SR flavors, namely SR-MPLS [RFC8660  <https://tools.ietf.org/html/rfc8660>] and SRv6 [RFC8754  <https://tools.ietf.org/html/rfc8754>],”
    > 
    > May be :s/flavors/data plane
    > 
    > “Further considerations such as simplifying classification at 
    > intermediate SFs”
    > 
    > I’m not sure that simplifying classification is the main point of adding 
    > NSH. RFC8595 does not refers to this. A priori SR supports a single 
    > initial classification.
    > 
    > ----
    > 
    > §2
    > 
    > “A classifier SHOULD assign an NSH Service Path Identifier (SPI) per
    > 
    > SR policy so that different traffic flows that use the same NSH
    > 
    > Service Function Path (SFP) but different SR policy can coexist on
    > 
    > the same SFP without conflict during SFF processing.”
    > 
    > Is the above sentence applicable to both applications scenarios or only 
    > for the second one (SR-based SFC with integrated NSH service plane)?
    > 
    > In the current text, it’s applicable to both while I’m not sure that 
    > it’s applicable to “NSH-based SFC with SR-based transport plane”where 
    > the transport plane (hence the SR policy) is independent of the service 
    > plane.
    > 
    > ---
    > 
    > « hierarchical SFC [RFC8459  <https://tools.ietf.org/html/rfc8459>] »
    > 
    > Does this document specifically covers hierarchical SFC (hence 
    > hierarchical SFC & SR)? Is this reference really pertinent?
    > 
    > ---
    > 
    > §3
    > 
    > Section 3 barely speaks about SR. Is this really a SPRING document?
    > 
    > When SR is refered to, there is nothing specific to SR.
    > 
    > e.g. “After removing the outer transport encapsulation, that may or may 
    > not be SR-MPLS or SRv6,”
    > 
    > If the document is related to the integration of SFC and SR, surely the 
    > encapsulation is either SR-MPLS or SRv6 (rather than may or may not be SR).
    > 
    > May be indicating that in this scenario, there is a priori one SR-policy 
    > per SF (while in the next scenario, there is a single SR-policy for the 
    > whole service chain). That would talk about SR and may provide a key 
    > distinction between both.
    > 
    > “ 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.
    > 
    > There are several ways to achieve this but its specification is
    > 
    > outside the scope of this document.”
    > 
    > I agree that this is necessary.
    > 
    > But why is the maintext related to SR-MPLS in this scenario, not 
    > specifying the behaviour?
    > 
    > Idon’t follow the logic of specifying it for SRv6 (and hence requiring 
    > this document to be standard track while otherwise it could be an 
    > informational document describing two scenarios) and not specifying it 
    > for SR-MPLS.
    > 
    > Note that this text is duplicated in §5.1. And 5.1 is nearly defining 
    > one proposition, so why not saying that this is a solution? (there is no 
    > need to define the encoding for the control plane since this part would 
    > likely not be in a spring document) (a
    > 
    > specific prefix-SID be allocated at each node for use by the SFC
    > 
    > application for this purpose.)
    > 
    > ---
    > 
    > §4
    > 
    > The benefits of this scheme include:
    > 
    > […].
    > 
    > oIt simplifies the SFF (i.e., the SR router) by nullifying the
    > 
    > needs for re-classification and SR proxy.
    > 
    > Regarding the need for reclassification, it seems to me that SR alone 
    > can nullify
    > 
    > Regarding the need for SR proxy, the behaviour described seems very 
    > close to a SR proxy “The SFF strips
    > 
    > the SR information of the packet, updates the SR information, and
    > 
    > saves it to a cache indexed by the NSH SPI.This saved SR
    > 
    > information is used to encapsulate and forward the packet(s) coming
    > 
    > back from the SF. »
    > 
    > oIt provides a unique and standard way to pass metadata to SFs.
    > 
    > Note that currently there is no solution for SR-MPLS to carry
    > 
    > metadata and there is no solution to pass metadata to SR-unaware
    > 
    > SFs.
    > 
    > RFC8595 provides another standard way to pass meta data for SR-MPLS.
    > 
    > https://tools.ietf.org/html/rfc8595#section-12 
    > <https://tools.ietf.org/html/rfc8595#section-12>
    > 
    > ---
    > 
    > §7.2
    > 
    > “Encapsulation of NSH following SRv6 may be indicated either by
    > 
    > encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the
    > 
    > Next Header field of the SRH, or by indicating an IP protocol number
    > 
    > for NSH in the Next Header of the SRH. “
    > 
    > Why is there a need for two solutions?
    > 
    > If so, what are the applicability statement or pro&con of each?
    > 
    > For interop purpose, which one is mandatory and which one is optional?
    > 
    > Thanks,
    > 
    > Regards,
    > 
    > --Bruno
    > 
    > _________________________________________________________________________________________________________________________
    > 
    > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
    > 
    > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
    > 
    > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
    > 
    > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
    > 
    > This message and its attachments may contain confidential or privileged information that may be protected by law;
    > 
    > they should not be distributed, used or copied without authorisation.
    > 
    > If you have received this email in error, please notify the sender and delete this message and its attachments.
    > 
    > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
    > 
    > Thank you.
    > 
    > _________________________________________________________________________________________________________________________
    > 
    > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
    > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
    > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
    > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
    > 
    > This message and its attachments may contain confidential or privileged information that may be protected by law;
    > they should not be distributed, used or copied without authorisation.
    > If you have received this email in error, please notify the sender and delete this message and its attachments.
    > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
    > Thank you.
    > 
    > 
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    > https://www.ietf.org/mailman/listinfo/spring
    > 

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring