Re: [spring] draft-ietf-spring-ipv6-use-cases - shepherd review

["Roberta Maglione (robmgl)" <[e-mail]>]

Hello Bruno,
Thanks for your comments, we are going to address them and post an updated version of the document after the Holidays.
Please see  initial answers inline.
Regards
Roberta

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, December 16, 2016 3:47 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: draft-ietf-spring-ipv6-use-cases - shepherd review

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.

[RM] we are going the re-work theses sections to update the text in there.

===== 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).

[RM] Agree with you that  when MPLS is present MPLS SR with IPv6 FEC/segment is a viable solution. However it was pointed out in the mailing list by Wes George (https://www.ietf.org/mail-archive/web/spring/current/msg00832.html ) that MPLS in IPv6 only environment still has some gaps as described in RFC 7439. Specific text was added to address that comment.
We can definitely re-word the text in this section, to clarify the meaning.

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.
[RM] will clarify this point thanks

---
  "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).


[RM] agree with you, the intention here was to capture current common deployments for dual-stack networks where most of the times IPv4 is labeled switched while IPv6 is natively routed, given the current gaps for MPLS on IPv6 only networks.


---
"   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...)

[RM] okay

---
   "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. 

[RM] will do

---
"   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.

[RM] will simplify the text and remove redundant text

---
§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?  

[RM] will 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.

[RM] will re-phrase the sentence

---
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?

[RM] will re-work the section and update the text

---
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?

[RM] will re-work the section and update the text

----
"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

[RM] will fix this

===== 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

[RM] ok will fix both of them

Thanks again for the comments.
Regards
Roberta
_________________________________________________________________________________________________________________________

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.