4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
draft-wu-softwire-4over6-04

State Change Notice email list have been change to chmetz@cisco.com, xing@cernet.edu.cn, jianping@cernet.edu.cn, xmw@csnet1.cs.tsinghua.edu.cn, cy@csnet1.cs.tsinghua.edu.cn, draft-wu-softwire-4over6@tools.ietf.org, rfc-ise@rfc-editor.org from chmetz@cisco.com, xing@cernet.edu.cn, jianping@cernet.edu.cn, xmw@csnet1.cs.tsinghua.edu.cn, cy@csnet1.cs.tsinghua.edu.cn, draft-wu-softwire-4over6@tools.ietf.org, rfc-editor@rfc-editor.org

[Ballot comment]
I sent my Discuss issue in an email to the RFC Editor as follows...

Hi,

During IESG review of this draft I raised two issues.

1. Experimental or Informational?

Normally an Experimental I-D would describe an experiment that is to be run.
In that case, it would include a description of the scope of the experiment,
how the experiment will be measured, the way that the success of the
experiment will be judged, and the proposed next steps depending on the
success or failure of the experiment.

In this case, however, it looks like the experiment has already been run. If
this is a record of an experiment that is now
concluded, I think that the I-D should be classed as Informational. If the
experiment is intended to continue, I think a section should be added to
describe the on-going experiment.

2. Definition of protocol extensions?

Section 1 says...

  This document defines
  extensions to MP-BGP employed to communicate tunnel end-point
  information and establish 4over6 tunnels between dual-stack Provider
  Edge (PE) routers positioned at the edge of the IPv6 backbone
  network.

This is not consistent with the an experiment (or with Experimental status).
The wording used in the Abstract is subtly different, and better. Would it
work to replace this text with:

  This document describes experimental
  extensions to MP-BGP employed to communicate tunnel end-point
  information and establish 4over6 tunnels between dual-stack Provider
  Edge (PE) routers positioned at the edge of the IPv6 backbone
  network.

[Ballot discuss]
I welcome the fact that this document has been brought forward.

Normally an Experimental I-D would describe an experiment that is to be
run. In that case, it would include a description of the scope of the
experiment, how the experiment will be measured, the way that the
success of the experiment will be judged, and the proposed next steps                   
depending on the success or failure of the experiment.

In this case, however, it looks like you have already run the
experiment. If this is a record of your experiment that is now
concluded, I think that you should class the I-D as Informational. If
the experiment is intended to continue, I think you should add a
seciton to describe the on-going experiment.

---

Section 1 says...

  This document defines
  extensions to MP-BGP employed to communicate tunnel end-point
  information and establish 4over6 tunnels between dual-stack Provider
  Edge (PE) routers positioned at the edge of the IPv6 backbone
  network.

This is not consistent with the Experimental status. The wording used
in the Abstract is subtly different, and better. Would it work to
replace this text with:

  This document describes experimental
  extensions to MP-BGP employed to communicate tunnel end-point
  information and establish 4over6 tunnels between dual-stack Provider
  Edge (PE) routers positioned at the edge of the IPv6 backbone
  network.

IANA comments:

Upon approval of this document, IANA will make the following
changes in the "Subsequent Address Family Identifiers (SAFI)"
registry at
http://www.iana.org/assignments/safi-namespace

OLD:
Value Description Reference
----- ----------------
67 BGP 4over6 SAFI [Cui]

NEW:
Value Description
----- ----------------
67 BGP 4over6 SAFI [RFC-wu-softwire-4over6-03]

This document was submitted to the RFC Editor to be published as an
Experimental Independent Submission: draft-wu-softwire-4over6-03.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.

Five week timeout expires on 23 November 2009.
Note that we have added an extra week because of the upcoming IETF
proceedings.


4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions

The emerging and growing deployment of IPv6 networks will introduce
cases where connectivity with IPv4 networks crossing IPv6 transit
backbones is desired. This document describes a mechanism for
automatic discovery and creation of IPv4 over IPv6 tunnels via
extensions to multi- protocol BGP. It is targeted at connecting
islands of IPv4 networks across an IPv6-only backbone without the
need for a manually configured overlay of tunnels. The mechanisms
described in this document have been implemented, tested and
deployed on the large research IPv6 network in China.