Hi Roberta, Thanks for the update and for addressing my comments. I'll write the write'up ASAP (ETA end of this week)
FYI some typo: OLD: and the achieve larger scale NEW: and to achieve larger scale OLD: a solution relaying on IPv6 NEW: a solution relying on IPv6 No need to refresh the draft for this. Thanks --Bruno > -----Original Message----- > From: Roberta Maglione (robmgl) [mailto:[email protected]] > Sent: Friday, December 23, 2016 10:37 AM > To: DECRAENE Bruno IMT/OLN; [email protected]; > [email protected] > Cc: [email protected]; Stefano Previdi (sprevidi); Christian Martin > (martincj) > Subject: RE: draft-ietf-spring-ipv6-use-cases - shepherd review > > 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: [email protected] [mailto:[email protected]] > Sent: Friday, December 16, 2016 3:47 PM > To: [email protected]; [email protected] > Cc: [email protected] > 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. _________________________________________________________________________________________________________________________ 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
