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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 09 February 2021 18:40 UTC

Return-Path: <jmh@joelhalpern.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 5AD883A1115 for <spring@ietfa.amsl.com>; Tue, 9 Feb 2021 10:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=joelhalpern.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 2FzNwn3iN9me for <spring@ietfa.amsl.com>; Tue, 9 Feb 2021 10:40:33 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 31B053A1114 for <spring@ietf.org>; Tue, 9 Feb 2021 10:40:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DZsCN62p4z6GJl9; Tue, 9 Feb 2021 10:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612896032; bh=lGd7I1aTxIZoztez1BQ/AZzVv8V5HOjnaJab4PwY0eo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=n8n/sozPIGdXdMNmm/d/9aFYA5wpRkW6pa3nZIwKtZGdnco6efwtezfFL3i6G2p1k MwR++JPM777tHLTsaX6SMQs7QLm0+wMVygrqPCru8kPZjMVX/3A+p1JApN2ZcbKoP/ 0znkp7A3Ji5VtE0sqNSTHJRDXdFT+kH6GnHvc2oY=
X-Quarantine-ID: <Lg5yL2TbGhHZ>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DZsCN2Lf1z6GM84; Tue, 9 Feb 2021 10:40:32 -0800 (PST)
To: bruno.decraene@orange.com, "spring@ietf.org" <spring@ietf.org>
References: <12940_1612893971_6022CF13_12940_476_1_53C29892C857584299CBF5D05346208A490C492D@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <11f0e908-95ee-959a-3bfa-aadb6502de7c@joelhalpern.com>
Date: Tue, 9 Feb 2021 13:40:31 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <12940_1612893971_6022CF13_12940_476_1_53C29892C857584299CBF5D05346208A490C492D@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/uSQDCwkW751CWMJrM98ilj_cCGk>
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 18:40:35 -0000

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
>