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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
