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

["George, Wes" <[e-mail]>]

Alvaro, thank you for the thorough review. Please find my responses below inline on behalf of the author team. We have an update in the edit buffer, awaiting a few updates to the EVPN section and possibly the L2VPN section (to incorporate any necessary discussion of RFC 7117), but I wanted to go ahead and respond now that most of the comments have been addressed in our edits at least.

Thanks,

Wes George

From: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 5, 2014 at 2:44 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01


Comments:

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.

WG] Cross-WG reviews haven't occurred, but we view MPLS's active participants as a superset of the participants of most of the MPLS-dependent WGs, and also a good source of cross-WG generalists and experts on MPLS. It's unclear to me what needs should be evaluated by the operations-focused WGs, given that the issue came from a problem that an actual operator experienced (namely, me) and I don't think that the need for MPLS to work on an IPv6-only or IPv6-primary network is particularly controversial anyway. If people believe that there isn't enough overlap, we can certainly solicit reviews from some of the other WGs involved. Awaiting AD/WG chair guidance.

We've discussed this question about whether to publish a gap analysis at all somewhat offline, but I'm including a few points for the record and for WG comment here. First, my expectation is that the gap analysis shouldn't proceed to RFC until a consensus exists that we have reasonably captured all of the existing gaps. In other words, this is a documentation of all of the gaps that we as a collective group of the Smart People Who Know About Such Things could think of, and explicit documentation of areas without gaps to confirm that we reviewed them to validate this. New gaps SHOULD NOT develop, as once a gap analysis like this is performed, it raises awareness so that people in the WG (and ADs) will ask of future work, "does this work on an IPv6-only MPLS network, does it depend on known gaps documented in RFCnnnn being addressed, or are additional changes necessary to make this work properly on IPv6-only?"
Second, I think this generally highlights a problem IETF-wide when it comes to gap analyses. Either the work is already in progress, and it serves as a method to catalog the issues to make sure we have them all being addressed, or it serves to identify places where future work is needed. The problem is that the IETF has no method defined to follow up on gap analyses to ensure that future work identified actually gets completed, short of the WG adding items to its charter to explicitly address these things. If the gap analysis spans WGs, or there isn't anyone interested in addressing the identified gap, it can sort of rot inside the analysis and gradually be forgotten. We're dealing with this question in sunset4 on the original set of IPv6 gap analyses that were done on RFCs 3790-96, because no one has a good sense for whether all of the gaps identified in those documents were addressed, or are indeed still relevant. This draft catalogs gaps with pointers to where the authors know there is already work being done, which serves to link the two, and ensures that it's as clear as possible where there are still outstanding gaps that need to be addressed, and it'd be reasonable to expect any follow-on documents that address gaps identified as TBD in this document to formally update this document so that the link is present between this document and the future documents addressing some of the gaps that it identified as not having fixes in progress. It's the best we can do with "frozen in time" documents like this, but I think it's acceptable.
Ultimately, I think your question is a larger issue and this gap analysis is no different than any other – the question of "should we publish" is really "should we publish any gap analysis as an RFC given the limitations of the series?" and that's not something we're going to solve here, so I think it's a matter of publishing the document if the content is helpful.


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.

WG] I believe this is fixed now

 *   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?

--It really comes from RFC 3032, and then RFC 4182. One example is present in RFC4798

However, after review, we've removed this text, because we don't think that this is actually a gap, and the text was confusing (even to your humble editor).

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

WG] Added text to the beginning of section 3 explaining the terms:

"A note about terminology: Gaps are typically characterized as "Major", "Minor" or "none". Major gaps refer to significant changes necessary in one or more standards to address the gap due to existing standards language having either missing functionality for IPv6-only operation or explicit languge requiring the use of IPv4 with no IPv6 alternatives defined. Minor gaps refer to changes necessary primarily to clarify existing standards language. Usually these changes are needed in order to explicitly codify IPv6 support in places where it is either implicit or omitted today, but the omission is unlikely to prevent IPv6-only operation."


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

WG] a few sentences before, the document says "any networks will need to start operating some or all of their network nodes either as primarily IPv6 (most functions use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4 provisioned on the device)" Do we simply need to add similar language to the next-to-last sentence, does the existing text make it clear now that I've highlighted it, or is more required?


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

WG] EVPN draft is pending IESG/IETF LC, so it's not so much of a work in progress anymore, and will likely hit publication prior to this document. I have emailed EVPN authors to request that they consider EVPN in the IPv6-only operation context of this draft, and either confirm that there are no gaps, that there are dependencies on gaps already identified, or resolve any gaps present that are unique to EVPN prior to LC. The section will be updated accordingly to remove the comments about it being out of scope and add a brief gap analysis based on the results of that discussion.


 *   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?

WG] You're right, this was really confusing as written. Made significant changes to this section. There are no gaps in 4364. The real problem is that 4659 updates 4364 and fixes those gaps, but it doesn't formally update 4364 in the metadata, so it looks like there are gaps extant in 4364. It also explicitly calls use case #2 out of scope.

I filed an erratum to fix 4659's metadata: http://www.rfc-editor.org/errata_search.php?rfc=4659&eid=4087


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

WG] clarified


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

WG] Made some wording changes in 3.4 and LSP ping section 3.4.2 for clarity.


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

WG] Fixed


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

WG] Fixed


Nits:

Global ACK. Couple of specific comments:

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

WG] changed to fails


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

WG] It's in the next paragraph, is further guidance really necessary?

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

WG] while these references could be added, it covers less than a page of text within one subsection. I'm not convinced this is an actual problem


 *   3.3.2.4.2. (P-Tunnel Instantiation)
    *   ". . .covered in previous sections".  References please.

WG] ack

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

WG] fixed, discussion added


 *   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

WG] ack

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

WG] authors believe that the detail is probably not absolutely necessary, but do see it as useful and therefore no reason to remove it.

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.