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

<bruno.decraene@orange.com> Fri, 16 December 2016 14:47 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C01D412963E; Fri, 16 Dec 2016 06:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.389
X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id riD47pij8kKs; Fri, 16 Dec 2016 06:47:04 -0800 (PST)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878FE129663; Fri, 16 Dec 2016 06:47:01 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 92A91A08A5; Fri, 16 Dec 2016 15:46:59 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 697061A2999; Fri, 16 Dec 2016 15:46:59 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Fri, 16 Dec 2016 15:46:59 +0100
From: <bruno.decraene@orange.com>
To: "draft-ietf-spring-ipv6-use-cases@ietf.org" <draft-ietf-spring-ipv6-use-cases@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: draft-ietf-spring-ipv6-use-cases - shepherd review
Thread-Index: AdJXqlEYjoPjwSyiQZm/+o0EBVlxZg==
Date: Fri, 16 Dec 2016 14:46:58 +0000
Message-ID: <17317_1481899619_5853FE63_17317_744_1_53C29892C857584299CBF5D05346208A1ECC6721@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/pbPqN80dlMovtyZ1AZBVDe67EIM>
Cc: "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Subject: [spring] draft-ietf-spring-ipv6-use-cases - shepherd review
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 14:47:07 -0000

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,

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


   "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

"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:
Some references are outdated (cf idnits), in particular [I-D.previdi-6man-segment-routing-header].

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