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"
<[email protected] on behalf of [email protected]> wrote:
As a contributor, I do not know of any undisclosed IPR on this draft.
Yours,'
Joel
On 2/9/2021 1:06 PM, [email protected] 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:[email protected]] *On Behalf Of
> *[email protected]
> *Sent:* Monday, November 2, 2020 4:26 PM
> *To:* [email protected]; [email protected]
> *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
> [email protected]
> https://www.ietf.org/mailman/listinfo/spring
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
