Gap Analysis for Operating IPv6-Only MPLS Networks
draft-ietf-mpls-ipv6-only-gap-04

Note: This ballot was opened for revision 03 and is now closed.

(Adrian Farrel) Yes

(Brian Haberman) Yes

(Ted Lemon) Yes

Comment (2014-11-24 for -03)
No email
send info
Sections 1 and 2 duplicate a great deal of text.   Please take the time to edit this down so that you aren't saying the same thing three paragraphs apart.

3.2.1:

   While LDP was
   designed to use an IPv4 or dual-stack IP network, it has a number of
   deficiencies that prohibit it from working in an IPv6-only network.

I think the word you're looking for here is "prevent," not "prohibit."

Aside from the above carping, this is a good document.   Thanks for doing it!

(Jari Arkko) No Objection

(Richard Barnes) No Objection

Comment (2014-11-24 for -03)
No email
send info
It would be helpful if you could summarize the findings of this analysis in the Abstract.  For example:

"While the MPLS data plane fully supports carriage of IPv6 packets, support for IPv6 among MPLS management protocols is mixed, with some protocols having major gaps.  For most major gaps, however, work is in progress to upgrade the relevant protocols."

(Benoît Claise) No Objection

Spencer Dawkins No Objection

Comment (2014-11-24 for -03)
No email
send info
This draft was pleasantly easy for a nonspecialist to read, most of the time. I struggled with these sections:

I lack understanding on this one:

3.3.3.  MPLS Transport Profile (MPLS-TP)

   MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and
   should not be affected by operation on an IPv6-only network.
   Therefore this is considered out of scope for this document, but is
   included for completeness.

   Although not required, MPLS-TP can use IP.  One such example is
   included in Section 3.2.6, where MPLS-TP identifiers can be derived
   from valid IPv4 addresses.

   Gap: None.

So, I would read this as saying that MPLS-TP identifiers can be derived from valid IP addresses, whether v4 or v6, if there's no gap, but I'm extrapolating beyond what the text says. You might want to clarify whether "None" is based on the first paragraph (doesn't require IP at all), or also on the second one (can use either version of IP).

I couldn't parse this one:

3.4.2.  Label Switched Path Ping (LSP Ping)

   Gap: Major.  LSP ping uses IPv4-mapped IPv6 addresses, IP version
   mismatches may cause dropped messages, unclear mapping from LSR
   Router ID to Downstream IP Address.

Is this saying IP version mismatches may cause unclear mapping? This might be as simple as s/messages, unclear/messages and unclear/, but I'm guessing.

This one's worse than section 3.3.3.  MPLS Transport Profile (MPLS-TP):

3.4.5.  MPLS Transport Profile (MPLS-TP) OAM

   As with MPLS-TP, MPLS-TP OAM RFC 6371 [RFC6371] does not require IP
   or existing MPLS OAM functions, and should not be affected by
   operation on an IPv6-only network.  Therefore, this is out of scope
   for this document, but is included for completeness.  Although not
   required, MPLS-TP can use IP.

   Gap: None.

Is this saying that MPLS-TP can use IPv6 and there's no gap, or is it saying that there's no gap because IP isn't required, and just helpfully pointing out that there may or may not be a gap for IPv6, but the reader will have to figure that out?

Nit: s/Identifed/Identified/, I think.

I agree with Richard's suggestion for a summary early in the document.

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Comment (2014-11-25 for -03)
No email
send info
section 1 2 3 are basically all introduction. it seems like that could be streamlined considerably and therefore ready more easily but it doesn't really impact the rest of the document.

(Barry Leiba) (was Discuss) No Objection

Comment (2014-11-24 for -03)
No email
send info
I submit that a good number of the references really are normative, in that understanding them is necessary in order to understand this document.  I'd like to see the authors sort that out, and make an appropriate split in the references, so readers can know which ones truly do just add extra detail (informative), and which provide necessary background (normative).  That said, I don't consider that important enough to this document to block on it, so this is a non-blocking comment.  I understand that the working group prefers not to do this for this document.  Thanks for considering the comment.

(Kathleen Moriarty) No Objection

Comment (2014-11-24 for -03)
No email
send info
Thanks for your work on this draft, it should be very helpful.  

Thanks for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05196.html

(Martin Stiemerling) No Objection