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

["Alvaro Retana (aretana)" <[e-mail]>]

On 8/20/14 11:38 AM, "George, Wes" <[e-mail]<mailto:[e-mail]>> wrote:

Wes:

Hi!

Some comments in line..

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.

I don't think it's controversial either.  You did a better job explaining my point: the need for this work "came from a problem that an actual operator experienced".  But I agree with you about the overlap in participation and yield to whatever the AD/WG chair suggest.


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.

I agree with pretty much everything [*] you wrote..specially the part about it being a wider issue that we're not going to solve here — and that shouldn't stop this work.  As I said at the beginning, I defer to the current consensus.


The summary of our offline discussion is very good.  I do want to bring up one point that you mentioned there:

"
WG] Given that these sorts of documents are ultimately snapshots in time, we are including everything that we know about, but we do have to be clear about the limits of what that means. We as the authors made the decision to limit that to existing RFCs, because if we open it to any drafts in progress, we end up not having a decent line to draw about when to declare things done – which drafts do we wait for, do we hold the doc because a new draft showed up that we need to evaluate, etc etc. I'm open to suggestions about alternate methods of defining that line, but it's a lot harder to analyze standards that are still fluid because they're actively being refined by the WG – is a gap in a draft really a gap, or is it simply a problem that must be addressed before the thing that draft is standardizing is actually ready to move to RFC? I think it's the latter, and that a gap is something that exists in a standard that has already been completed because it can't be updated to address that gap without a new draft, while an existing draft can be modified to address the issue with minimal effort.
"

I fully agree with you: the line for identifying gaps should be based on RFCs (not drafts).

[*] The part that I don't agree with is related to this line and the last couple of sentences of your second point above: "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."

Following your logic ("is a gap in a draft really a gap"), I don't think that a draft can categorically be referred to as solving a gap.  While we would hope that the draft progresses as expected and that it does address the gap..it may end up not covering it, being abandoned, moving in a different direction, etc.

I understand the reasoning behind pointing at the work in progress.  This discussion is one of those where there might be no ideal answer and we both might be right (at least in part).  I wanted to bring this point up for the record..and in case anyone has a brilliant solution.  We don't need to dwell on this..

. . .


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

I think you should add similar language to the next-to-last sentence; that is where you're describing what this document is doing. The text before it is ok, but it seems to provide some context on what's happening as people are moving..not defining the scope.

Thanks!

Alvaro.