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

From: "George, Wes" <[email-masked]>
Date: Wed, 20 Aug 2014 11:38:57 -0400

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)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 5, 2014 at 2:44 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 21 Aug 2014 17:30:28 +0000

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

Wes:

Hi!

Some comments in line..

Thanks,

Wes George

Comments:

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

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

. . .

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 22 Aug 2014 06:27:30 +0530

Hi Alvaro, Wes,

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

How about we move the pointers to any work-in-progress to address the
gaps to appendix, would that be a good compromise?

Dhruv

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Aug 2014 16:43:42 +0000

-----Original Message-----
From: Dhruv Dhody <[email-masked]>
Date: Thursday, August 21, 2014 at 8:57 PM
To: Alvaro Retana <[email-masked]>
Cc: Wes George <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01
Resent-From: <[email-masked]>
Resent-To: Carlos Pignataro <[email-masked]>, Loa Andersson
<[email-masked]>, Martin Vigoureux <[email-masked]>, Ross
Callon <[email-masked]>, <[email-masked]>, Wes George
<[email-masked]>, Alia Atlas <[email-masked]>, Adrian Farrel
<[email-masked]>
Resent-Date: Thursday, August 21, 2014 at 8:57 PM

>gaps to appendix, would that be a good compromise?

I agree with Alvaro¹s point that a draft cannot be checked as the solution
of a gap. I also believe there is no perfect answer to this one.

There is, however, another way in which draft-ietf-mpls-ipv6-only-gap
points to I-Ds: As a very detailed description of a Gap.
draft-ietf-mpls-ipv6-only-gap might have one paragraph / couple sentences
describing a gap, and then point to an I-D that details the gap (and might
or might not propose solutions).

In this context, there might not be one-size-fit-all for the I-D
references.

I would not want to loose the consolidated references, but perhaps we need
to be more precise about a why we are pointing to each I-D. Pointing as
expanding the gap is OK, and maybe moving the ³solution I-Ds² to an
Appendix is a good idea.

Thanks,

Carlos.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 22 Aug 2014 13:06:30 -0400

>expanding the gap is OK, and maybe moving the ³solution I-Ds² to an

I'm not convinced that much will be gained by such a change. It seems like
change for the sake of change. I will go along with it if WG consensus
pushes that direction, but my preference would be to leave the references
as-is. If we know something is in progress that is trying to address the
problem, why not document what we know in the same places as we discuss
the gaps? What value is there in hiding these things in an appendix just
because we aren't completely certain that what we believe will address the
gap will actually address the gap?

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Aug 2014 17:14:27 +0000

-----Original Message-----
From: <George>, Wes George <[email-masked]>
Date: Friday, August 22, 2014 at 1:06 PM
To: Carlos Pignataro <[email-masked]>, Dhruv Dhody
<[email-masked]>, Alvaro Retana <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01

>gap will actually address the gap?

Personally I do not have a particular preference between leaving citations
to I-Ds where they are or moving them (as co-editor I prefer leaving them
where they are :-)

But the point I think is important to clarify in the document is whether a
draft is referenced because it describes a gap or because it describes a
potential solution to a gap.

Thanks,

Carlos.

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

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 22 Aug 2014 23:04:51 +0530

> potential solution to a gap.

I agree that the clarification as Carlos suggested would help.

When I suggested moving the pointers-to-solutions to appendix, my
thoughts was -  since we do not have consensus on the solutions yet;
we could explicitly state that the aim of the pointers in this
appendix is to let the reader note that there are some proposed
solutions in IETF, but they are work in progress and do not have
consensus at the time of publication. There could be other solutions
proposed at future time and the pointers should not be considered
normative in any way. And a suitable text can be added for this.

Change for the sake of change was not my intention :)

Dhruv

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 22 Aug 2014 18:48:35 +0000

On 8/22/14 1:34 PM, "Dhruv Dhody" <[email-masked]> wrote:

>normative in any way.

Maybe we could make everyone happy if we add some "disclaimer" text
(similar to what Dhruv wrote above).  I'm thinking that it could go in
Section 4 (Gap Summary) (no need for an appendix).

This way we don't have to change the text anymore..we can leave the
references as-is..and we address any potential mishap to the WIP.

Thoughts?

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 22 Aug 2014 18:50:55 +0000

Carlos/Wes:

BTW, as I was taking another look at the -01 text (I know you have edits
ready to commit), there's a couple more minor comments related to the
references:

1. 3.2.1. (LDP) "Gap: Major, update to RFC 5036 in progress that should
close this gap."  The in-line reference points to rfc5036, but it should
point to I-D.ietf-mpls-ldp-ipv6.

2. 3.5. (MIBs) "Gap: Major. Work underway to update RFC3811.."  Same
thing, the reference to the update should point to
I-D.manral-mpls-rfc3811bis.

Thanks!

Alvaro.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Aug 2014 19:41:11 +0000

-----Original Message-----
From: Alvaro Retana <[email-masked]>
Date: Friday, August 22, 2014 at 2:48 PM
To: Dhruv Dhody <[email-masked]>, Carlos Pignataro
<[email-masked]>, Wes George <[email-masked]>

>references as-is..and we address any potential mishap to the WIP.

Works for me.

Thanks,

Carlos.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 25 Aug 2014 08:41:31 -0400

Alvaro -

What you're actually seeing is the automatic processing that sees
"RFCNNNN" and makes it a hyperlink in the HTML version. We didn't actually
add the reference to the work in progress there at all. I can add it.
Thanks,

Wes