Subject: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 5 Aug 2014 18:44:01 +0000

Hi!

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs.  For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-ipv6-only-gap-01 (Gap Analysis for Operating IPv6-only MPLS Networks)
Reviewer: Alvaro Retana
Review Date: Aug. 5, 2014.
IETF LC End Date: Aug. 8, 2014.
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:

This draft covers a wide variety of technology to find gaps that may prevent the use of IPv6-only MPLS networks.  It does so in a concise and clear form, an easy read.  I believe that this work is very valuable given, as the draft puts it, that "IPv6 is an integral part of modern network deployments".

I do have a couple of high-level items I want to bring up.  Because I assume that these may have already been discussed in the appropriate WG(s) I'm not listing them as major issues, and will defer to what the consensus has been so far.

  1.  Why do we need to publish this document?  As I said above, I believe the work is valuable, but it captures the state in time (today!) of the gaps — it points to work that already solved a potential gap, or is in the process of solving them.  A significant portion of the gaps are already being addressed.  Given the importance of IPv6, if published, soon this document will have to be updated to say "nothing breaks".  Again, the work is important, but it may be better suited to be a "living document" as a guide for what still needs to be addressed.  If it is to be published, I would suggest avoiding links to work in progress, but limiting the content to identifying the gaps..and then letting the solution drafts/RFCs point back to this document..  (ala requirements -> solution)
  2.  It is interesting to me that this draft came through the mpls WG, and not one of the operations-focused groups..which presumably would be in a better position to evaluate the needs described.  Given that the document is already in WG Last Call, I'm assuming that the alignment has already been discussed and that proper cross-WG reviews have occurred.

Major Issues:

No major issues found.

Minor Issues:

  *   Some terminology was not expanded before/when it was first used: we all know what MPLS is, but others like LSR, LER, FEC, L2VPN, EVPN, NG-mVPN, etc. should be expanded.
  *   Section 3.1 (MPLS Data Plane): "In the case where an IPv4 prefix is resolved over an IPv6 LSP, an IPv6 Explicit Null label cannot immediately preceed an IPv4 packet."  Is there a reference for this statement or is this a requirement to fill in the gap?  If it is a requirement, do we need to add 2119 language?
  *   When a gap exists, you classify it as "major" or "minor".  What is the criteria used?  I would imagine that given that it is a gap analysis, the objective is to point out the needs, not characterize them (if I need a "minor" gap to be filled in order for my network deployment to operate, it becomes "major" to me).
  *   The introduction to the draft talks about "gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks" ("IPv6-only (no IPv4 provisioned on the device)"), which gives the impression that no IPv4 is present in the network at all.   However, several gaps are identified that occur in "mixed" networks, where islands of IPv4/IPv6 exist.  I would suggest clarifying the scope of the document in the introduction.  Some of the places where these scenarios are discussed include:  3.2.2. (Multipoint LDP), 3.3.2. (L3VPN),  3.4.1. (Extended ICMP) and 3.4.2. (LSP Ping).
  *   3.3.1.1. (EVPN)  If the EVPN work is out of the scope of the document, then take it out.  Another option may be to talk about any gaps in the current work.  Same comment for section 3.3.2.4.3. (PE-PE Multicast Routing Protocol).
  *   3.3.2. (L3VPN)  the text says that the gaps in RFC4364 (no VPN-IPv6 address and a 128 bit next-hop) have been addressed in RFC 4659, but it then identifies the gap and says that "RFC4364 must be updated".  What would that update be?
  *   Sections 3.3.2.4.3. (PE-PE Multicast Routing Protocol), 3.3.3. (MPLS-TP) and 3.4.5. (MPLS-TP OAM) are included, but out of scope..  Should they be removed?  If not, then a short justification in the text would be nice.
  *   3.4. (MPLS OAM)  This sentence "All of these mechanisms work in pure IPv6 environments." gives the impression that all the mechanisms work correctly and that there are no gaps..but then several gaps are listed.
  *   Table 1: IPv6-only MPLS Gaps.  The table doesn't include all the gaps identified.  For example, 3.2.2. (Multipoint LDP) is not included in the table, even though a major gap was identified.  In this case, the work in the table for LDP may also address the gap in mLDP, but that is not pointed out in the table..  In short, the table is not complete.
  *   Security Considerations.  This section talks about security considerations in current specifications..but it leaves out mention of the fact that new specifications (to close the gaps) should (MUST ?) consider the effect of IPv6.

Nits:

  *   Section 2 (Use Case):  s/at least one/one (general)
  *   Section 3 (Gap Analysis).  You wrote: "This gap analysis aims to answer the question, "what breaks when one attempts to use MPLS features on a network of IPv6-only devices?"  While I understand what you're asking, in reality you're trying to answer "what doesn't work..".  Breaking implies that it may work for a while and then stop doing so.
  *   Section 3.1 (MPLS Data Plane):  s/preceed/precede
  *   3.2.2. (Multipoint LDP)  A reference back to the LDP section would be nice in point 1.
  *   3.2.2. (Multipoint LDP) - Point 2.  s/lookup against root address/lookup against the root address
  *   3.2.2. (Multipoint LDP) s/through the procedures similar to RFC6512/through procedures similar to RFC6512    BTW, the last sentence in this same paragraph seems redundant to me.
  *   3.2.3. (RSVP- TE)  s/procedures &enhancements/procedures and enhancements
  *   3.3.2. (L3VPN)   The gap section includes the following text: "Discussed in further detail below".  It would be nice to have an actual reference to the section instead of the text.
  *   Even though sections 3.3.2.1 and 3.3.2.2 are subsections of 3.3.2, with so many scenarios being covered, it gets hard to keep track of where something was described.  It would be very nice to include references to where "use case #2" was defined in sac of those subsections.
  *   3.3.2.4. (NG-MVPN)  s/over MPLS VPN backbone/over an MPLS VPN backbone
  *   3.3.2.4.2. (P-Tunnel Instantiation)
     *   ". . .covered in previous sections".  References please.
     *   "PIM Tree and Ingress Replication are out of the scope of this document.." because..  Either explain why or remove them from the list right before.
  *   3.4.1. (Extended ICMP)  s/supported by IPv6-only infrastructure/supported by an IPv6-only infrastructure
  *
3.4.2. (LSP Ping)  s/LSP Ping packets are UDP packets over both IPv4 and IPv6/LSP Ping packets are UDP packets over either IPv4 or IPv6
  *   There is some uneven treatment in the description of the support/gaps.  It would be nice to provide the same level of detail everywhere (if needed).  For example, 3.2.3.2 (RSVP-TE-P2MP) plainly mentions that RFC4875 covers the support for IPv6..while 3.4.3 (BFD OAM) mentions where IPv6 support us defined but it also points to the specific sections.  IMHO, the additional detail is not needed (unless very specific points need to be made).