Early Review of draft-ietf-mpls-ipv6-only-gap-01
review-ietf-mpls-ipv6-only-gap-01-rtgdir-early-retana-2014-08-06-00

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

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.

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)

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