Hi authors,
As the document shepherd, I have reviewed draft-ietf-spring-ipv6-use-cases.
I'm generally fine with the document, but do have some comments. Please find
them below.
Best regards,
Bruno
===== Major comments
Section 2.3.0 (intro of 2.3) and 2.3.1 are related to Service Function Chaining
and Data Center Network Overlay use cases.
Hence they have an adherence with the SFC and NVO3 WG.
Have those WG been presented this document, kept up to date, and are aligned
with the requirements as written?
Besides, those texts are unchanged since early 2014, while the situation may
have change since then, especially since both SFC and NVO3 WG are "recent".
Especially SFC which has been formed at the same period (23/12/2013). A priori,
their work is likely to have progressed since then, which does not seem
reflected in this draft.
===== Minor comments
§2 IPv6 SPRING use cases
There are a few paragraphs ("In addition....in the above use case.") which
describes that the lack of MPLS support for IPv6 only networks is a use case
for the IPv6 SR dataplane. However it seems to me that MPLS SR support IPv6
FEC/segment hence would have been a solution for such use case. So it does not
seem to me a use case mandating a new dataplane (IPv6 SR).
On a related point, the term "IPv6-only" does not seem well defined as it could
sometime means "non-IPv4" and sometimes "non-MPLS", which is different.
---
"In addition it is worth to note that in today's MPLS dual-stack
networks IPv4 traffic is labeled while IPv6 traffic is usually
natively routed, not label-switched. Therefore in order to be able
to provide Traffic Engineering "like" capabilities for IPv6 traffic
additional/alternative encapsulation mechanisms would be required."
The first observation does not seem enough to require the new of a new
data-plane. As discussed above, this may be caused by a lack of support for
IPv6 in existing MPLS signaling protocols. MPLS SR seems to be a valid option.
So it does not seem to be a use case mandating a new dataplane (IPv6 SR).
---
" 2. There is a strict lack of an MPLS dataplane"
May be adding "in a portion of the end to end path". (as some may have MPLS in
the core, yet not in the access/DC/home network...)
---
"This section will describe some scenarios where MPLS may not be
present and it will highlight how the SPRING architecture could be
used to address such use cases, particularly, when an MPLS data plane
is neither present nor desired."
May be rephrasing to avoid saying twice in the same sentence that MPLS is not
present.
---
" In any environment with requirements such as those listed above, an
IPv6 data plane provides a powerful combination of capabilities for a
network operator to realize benefits in explicit routing, protection
and restoration, high routing scalability, traffic engineering,
service chaining, service differentiation and application flexibility
via programmability."
[...]
" In addition to the use cases described in this document the SPRING
architecture can be applied to all the use cases described in
[RFC7855] for the SPRING MPLS data plane, when an IPv6 data plane is
present. Here there is a summary of those use cases:
1. Traffic Engineering
2. Disjoint paths in dual-plane networks
3. Fast Reroute: Protecting node and adjacency segments
4. OAM/monitoring
5. Egress Peering Engineering"
I feel that there is redundancy with those 2 paragraphs. In particular the
catalog of usages/benefits is duplicated.
---
§2.2
It's not clear to me what "egress vectoring" is. (May be because this Access
Network section seems to refer to a specific access techno (DOCSIS) which I'm
not familiar with.) Could you add a reference?
---
§2.3
"A service provider may choose to have these service functions
performed external to the routing infrastructure, specifically on
either dedicated physical servers or within VMs running on a
virtualization platform."
It's not clear to me what is meant by "routing infrastructure", especially when
opposed to servers/VM. Indeed, routers can now run in servers/VM. So may be
rephrasing the whole point would help.
---
Introduction part (2.3.0) is mostly related to service chaining, although this
is not reflected by the title. It is referencing two WG documents from the SFC
WG. Does this mean that the SFC WG is presenting those requirements in the
SPRING WG? This may require involving the SFC WG in this last call. And some
elaboration why the SFC WG solutions are not adequate/enough. (e.g. is this a
need to combine both routing instructions and service instruction in order to
both choose the route and the sequence of services function? In particular when
NHS meta data is not needed?)
This service chaining text seems to originate from
draft-martin-spring-segment-routing-ipv6-use-cases-00 i.e .from march 2014. And
the text is unchanged since
draft-martin-spring-segment-routing-ipv6-use-cases-01 i.e from April 4,
2014.This seems like a long time in this domain: mostly the whole duration of
the SFC WG. Is this still aligned with the work that the SFC WG has done in
that 2.5 years period?
---
2.3.1 is mostly related to VPN overlay. In the IETF, this seem in scope to the
NVO3 WG. Does this mean that the NVO3 WG is presenting those requirements in
the SPRING WG? This may require involving the NVO3 WG in this last call.
Especially since NVO3 seems to have enough encapsulation techniques to deal
with, and it's not clear to me that NVO3 needs one more.
Besides, this section seems to come from 2014 and
draft-baker-openstack-ipv6-model which has expired 18 month ago. 2014 may be a
long time ago in the DC environment. Is this approach still up to date/relevant?
----
"The 128-bit PE Ingress ID in the Segment Router Header (SRH) policy list"
Name of the field and structure seems to have changed in the 6MAN draft.
possibly:
:s/PE Ingress ID/Ingress Node TLV
:s/policy list/Optional TLV objects
----
2.3.4
"The details about using Segment Routing together with NSH will be described in
a separate document."
This sentence has been written in March 2014 in
draft-martin-spring-segment-routing-ipv6-use-cases-00. What's the update on
this?
I would expect that either his separate document has been written and should be
reference, or this subject has not generated enough interest and hence is dead.
Also this section seems to say that IPv6 SR does not replace NHS. While section
2.3.0 (intro of 2.3) seems to say that service chaining is a use case for IPv6
SR.
More generally, I'm a bit surprised that this section has never been updated
since the creation of the doc in early 2014. Has nothing changed this then? As
this been implemented and deployed? What's the feedback?
===== Nits:
Reference:
Some references are outdated (cf idnits), in particular
[I-D.previdi-6man-segment-routing-header].
§2.3
"The term "Service Function Chain", as defined in [RFC7498], it is used"
:s/it is/is
_________________________________________________________________________________________________________________________
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
