Re: [spring] draft-ietf-spring-nsh-sr

["Joel M. Halpern" <[e-mail]>]

We will work on these comments.

On the downref, when we did the IETF LC for what became RFC 8300, we 
explicitly included the downref to 7665.  There is a standard IETF 
procedure for that case.

In this case, we will look to see if 8300 would be a better reference. 
At first glance, it would.

Yours,
Joel

On 11/2/2020 10:25 AM, [e-mail] wrote:
> 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.
> 
> ----
> 
> IdNitsreports 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
> 
> -----
> 
> 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
> 
> -“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 main text related to SR-MPLS in this scenario, not 
> specifying the behaviour?
> 
> I don’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 forthis  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
> 
> backfrom  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
> 
> ---
> 
> §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.
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>