Wireline Incremental IPv6
draft-ietf-v6ops-wireline-incremental-ipv6-06

[Ballot comment]
I have no objection to the publication of this document.

Some small thoughts...

---

Section 2

      - The operator will want to minimize the level of disruption to
      the existing and new subscribers by minimizing the number of
      technologies and functions that are needed to mediate any given
      set of subscribers flows (overall preference for Native IP flows)

I can believe that "The operator will want to minimize the level of
disruption to the existing and new subscribers" and I can believe that
the operator will want to minimize "the number of technologies and
functions that are needed to mediate any given set of subscribers flows"
but I don't see the linkage between these two points. It does not follow
to me that reducing the number of technologies necessarily reduces the
disruption: indeed it could be the reverse. How about making these two
issues into separate assumptions?

---
                                           
Section 3 (petty nit)

  When faced with the challenges described in the introduction,
  operators may need to consider a phased approach when adding IPv6 to
  an existing subscriber base.

s/need/want/

[Ballot comment]

  Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 27-Aug-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07716.html

[Ballot discuss]
I have a concern about the way in which the deployment of CGN is
presented in a document addressing deployment of IPv6.  Section 4.2
describes CGN as "beneficial for those operators who offer Dual Stack
services to subscriber endpoints once they exhaust their pools of IPv4
addresses," which stays within the scope of the document.  However,
parts of section 5.4 might be interpreted as suggesting CGN solely for
the purpose of extending the use of IPv4 without a simultaneous
deployment of IPv6.  For example, the second sentence of section 5.4
and figure 5 both describe the use of CGN without any reference to
IPv6.  Section 5.4 needs some wordsmithing to ensure that CGN is only
described, in this document, as an adjunct to IPv6 deployment.

[Ballot comment]
1. s/DHCPv6/DHCPv4/ in the last sentence of section 4.2?

2. Section 5.5 is a bit asymmetric in its description of providing
legacy IPv4 service across an IPv6-only access network.  NAT64
provides access to IPv4 content to IPv6-only hosts, and DS-Lite
provides continued access to IPv4 content to IPv4-only hosts.  But
those two technologies are portrayed as sort of complementary in the
first paragraph of the section.  Additionally, there is no mention of
how to provide access to IPv6 content to IPv4-only hosts.

3. In conjunction with the mention of IPv4 address reclamation in
section 3, the document might mention the availability of IPv4
addresses through whatever secondary markets might develop.

4. Another problem with transition technologies to mention in section
3.5 is the potential difficulty of traffic analysis and management of
tunneled traffic.

[Ballot comment]
I have no problems with the publication of this document, but have a few non-blocking comments/questions...

1. I was surprised to not find any mention of an analysis of hardware capabilities in the Phase 0 discussion in Section 5.  It seems to me like it would be useful to have a good understanding of what capabilities key devices have in my network.  It would have a direct impact on an IPv6 roll-out plan if a software or hardware upgrade would be needed.

2. The order of transition technologies in section 4 seemed haphazard.  It may be cleaner to group the technologies (e.g., early IPv6 deployment, IPv4 life support mechanisms, etc.).

3. Was any consideration given to including a discussion on the potential impact of IPv6 on the overall network architecture?  For example, what if I wanted to use SLAAC + stateless DHCPv6 to configure my hosts?  I may want to consider topology changes from my current IPv4 architecture to increase reachability to DHCPv6 servers.

IANA has reviewed draft-ietf-v6ops-wireline-incremental-ipv6-05, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Wireline Incremental IPv6) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Wireline Incremental IPv6'
  as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-08-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Operators worldwide are in various stages of preparing for, or
  deploying IPv6 into their networks.  The operators often face
  difficult challenges related to both IPv6 introduction along with
  those related to IPv4 run out.  Operators will need to meet the
  simultaneous needs of IPv6 connectivity and continue support for IPv4
  connectivity for legacy devices with a stagnant supply of IPv4
  addresses.  The IPv6 transition will take most networks from an IPv4-
  only environment to an IPv6 dominant environment with long transition
  period varying by operator.  This document helps provide a framework
  for wireline providers who are faced with the challenges of
  introducing IPv6 along with meeting the legacy needs of IPv4
  connectivity utilizing well defined and commercially available IPv6
  transition technologies.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ballot/


No IPR declarations have been submitted directly on this I-D.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
>
> This document is recommended as "informational"; it is essentially a white paper describing a phased approach to operational deployment of IPv6.
>
> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
>
> Technical Summary
>
> Operators worldwide are in various stages of preparing for, or
> deploying IPv6 into their networks. The operators often face
> difficult challenges related to both IPv6 introduction along with
> those related to IPv4 run out. Operators will need to meet the
> simultaneous needs of IPv6 connectivity and continue support for IPv4
> connectivity for legacy devices with a stagnant supply of IPv4
> addresses. The IPv6 transition will take most networks from an IPv4-
> only environment to an IPv6 dominant environment with long transition
> period varying by operator. This document helps provide a framework
> for wireline providers who are faced with the challenges of
> introducing IPv6 along with meeting the legacy needs of IPv4
> connectivity utilizing well defined and commercially available IPv6
> transition technologies.
>
> Working Group Summary
>
> The working group process was pretty straightforward. To the shepherd's knowledge, while every operator has not taken (or considered) taking every step laid out, there is no dissent regarding the approach. What the framework lays out is what steps make sense at the various decision points and how they should be thought through.
>
> Document Quality
>
> The framework is well written and has stood up under review.
>
> Personnel
>
> Who is the Document Shepherd? Who is the Responsible Area Director?
>
> The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica.
>
> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
>
> The shepherd read the initial document, followed the working group discussion and spoke with the authors privately, and read the ultimate outcome. The document is clear and understandable.
>
> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
>
> No. The acknowledgements section notes a number of people who have commented or contributed text.
>
> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
>
> This is not, in my view, required. The document contains no formal language, and imposes no protocol specifics.
>
> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
>
> The shepherd is comfortable with the document, and working group discussion has not surfaced remaining issues.
>
> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
>
> Yes.
>
> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
>
> Not to my knowledge.
>
> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
>
> As noted in the acknowledgements, working group discussion was robust and broad. I would describe this as having broad consensus.
>
> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
>
> No.
>
> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
>
> I found no nits.
>
> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
>
> N/A
>
> (13) Have all references within this document been identified as either normative or informative?
>
> The references are list as normative and informative.
>
> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
>
> There are no such references.
>
> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
>
> An informational document cannot have downward references.
>
> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
>
> This document uses other RFCs, but does not update them.
>
> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
>
> The document doesn't depend on IANA registries or create new ones.
>
> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
>
> N/A
>
> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
>
> N/A