Scenarios and Analysis for Introducing IPv6 into ISP Networks
draft-ietf-v6ops-isp-scenarios-analysis-03

[Ballot discuss]
One of the reasons for doing the scenario analysis is to indentify
holes in our transition mechanisms, i.e., to identify follow-on
work. The document even says:

>    An ISP offering IPv4 service will find different ways to add IPv6 to
>    this service. This document discusses a small set of scenarios for
>    the introduction of IPv6 into an ISP's IPv4 network. It evaluates the
>    relevance of the existing transition mechanisms in the context of
>    these deployment scenarios, and points out the lack of essential
>    functionality in these methods to the ISP's operation of an IPv6
>    service.

But, the document doesn't actually seem to identify holes or state
there are none.

Is there followon work needed in this space? If so, what is it? Either
way, the document should say something about what followon work (if
any) is needed.

[Ballot comment]
>    Large end sites are usually running managed network. 

doesn't parse.

>    Even though the RIR policies on getting IPv6 prefixes require the
>    assignment of at least 200 /48 prefixes to the customers, this type
>    of transit provider obtains an allocation nonetheless, as the number
>    of customers their customers serve is significant. The whole backbone

This isn't entirely true, and has been changing. Best not to include
details of the RIR requirement, since its not critical to this
document.

[Ballot comment]
Reference
  [BCP38UPD]      F. Baker, P. Savola "Ingress Filtering for
                  Multihomed Networks"
                  Work in progress
Should be updated to point to RFC 3704 (BCP84)

[Ballot comment]
Reviewed by Mark Allman, Gen-ART

This document is mostly fine to publish as an informational RFC.

  + It could really use a pass to get rid of alot of "this", "these" and
    "its".  In some places it is very confusing what the author is
    actually referring to.

  + More references to various bits of the technology would be nice
    (e.g., to Teredo (among others); although maybe I just missed this
    one).

  + Some statements could be shored up a bit.  E.g., on page 10 it is
    noted that "RIPng is not appropriate in most contexts".  It'd be
    nice if there was a small bit of explanation or a reference here.

The document doesn't hurt.  I am not sure how much I thought it would
help -- everything seems pretty straightforward.  And, it is not clear
that this is really an "experience" piece.  That said, there is some
decent stuff in here, too.

[Ballot comment]
In section 1.1: s/present document/document/

  Please expand "IX", "DS", and "ACLs" the first time they are used.

  I do not understand the dotted line between the Network and Service
  Operation box and the Customer Connection 1 box on Figure 1.  There
  is no discussion that provides insight.  There is also no discussion
  of the Peering postion of the figure.

  In section 4.1.1:
    s/1) and 2)/Approaches 1) and 2)/
    s/However, 1)/However, approach 1)/
    s/2) may not be possible/Approach 2) may not be possible/
    s/equivalent to 4)/equivalent to approach 4)/

  In section 4.3: s/IPv4 or IPv6 only/IPv4- or IPv6-only/

  In section 5.2: s/Radius traffic/RADIUS traffic/

  An informational reference for RADIUS is needed.

[Ballot comment]
The document doesn't discuss provisioning at all.  I'm willing to be told that that's out of scope, but billing and accounting are mentioned.  More generally, all of these are operations support systems, and most of these tend to have v4-specific assumptions built in.

The relative scarcity of v6-capable firewalls is an obstacle to many managed services.

[Ballot comment]
The document doesn't discuss provisioning at all.  I'm willing to be told that that's out of scope, but billing and accounting are mentioned.  It's not a trivial issue -- the operations support systems often have v4-specific assumptions built in, and all of these will need to change.

[Ballot discuss]
The document doesn't discuss provisioning at all.  I'm willing to be told that that's out of scope, but billing and accounting are mentioned.  It's not a trivial issue -- the operations support systems often have v4-specific assumptions built in, and all of these will need to change.

[Ballot discuss]
Section 7 suggests that the ISP may transition to IPv6 only networks in some
parts of its network.  I believe the draft-dnsop-IPv6-transport-guidelines
makes  v4 access to DNS services a SHOULD; I think that means this section
needs to note that some services will either need to maintain v4 connectivity
or that those services cannot be located on v6-only segments.

The interdomain aspects of the deployment also seem weak.  Figure 1
notes that there are peering sessions and 4.3.2 notes that BGP sessions
can be used to carry IPv6 data, but the steps for deploying the
ability to carry v6 traffic outside the single ISP's network.  If there is a
separate document discussing this, it should be referenced; if not,
additional text describing where that process belongs in the overall
process (and what it entails) is needed.