I erred in moving this forward - I didn't realize that there were some pending changes based on the GEN-ART review, and on the changes in 2858bis.  I will send a withdrawl message to the RFC Editor and wait for the revision from the authors.

[Ballot comment]
I think that this document exposes a problem in BGP, specifically the lack of a clear specification of how the NLRI and Next-Hop are defined. This document assumes that the two MUST be of the same address family, requiring the V4 NLRI address to be mapped into a V6 address in the process. Thus, implementations are forced to use the length of the NLRI (32 or 128 bits) and inspection of portions of the v6 address to determine if the address is actually a v4 NH or v6 NH. Despite being ugly, this type of encoding cannot be easily extended to support v4/v6 combinations, and is incompatible with v6 over a BGP/MPLS L3VPN.

I understand that this mechanism is widely implemented and deployed, thus it is probably far too late to make a substantial change without causing more harm than good (which is why this isn't a DISCUSS). I think IDR is going to have to address this with some of the upcoming softwires work.

[Ballot discuss]
I really don't want to hold this document up, but I've noticed that the
justification for this mechanism in the reference [ISPSCEN] (now RFC 4029)
is very weak. To fill this gap, one of the authors suggested this as
a new second paragraph in the Introduction:

The 6PE approach is required in addition to the use of standard tunnels, as it provides a solution for an MPLS environment where all tunnels are established dynamically, or for an environment where the effort to configure and maintain explicitly configured tunnels is not acceptable.

[Ballot comment]
There is no referece in this document to manageability or operational considerations. It would be useful to mention or refer to other documents that show how the methods of interconnection of IPv6 islands over an IPv4 MPLS cloud described in the documents will be configured and deployed, if there are any specific status or manitoring information that need to be watched by a network operator, and if the deployment of this technology has any impact on the existing MPLS network.

[Ballot comment]
Section 4., paragraph 18:
>    ASBRs in any transit ASes will also have
>    to use EBGP to pass along the labled IPv4 /32 routes.

  Nit: s/labled/labeled/

Section 5., paragraph 14:
>    [MP-BGP]    T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiproto-
>                col Extensions for BGP-4", RFC 2858.

  Unused Reference: 'MP-BGP' is defined on line 416, but not referenced
  (and it is normative)

[Ballot comment]
The last sentence in Section 2 says:
  >
  > As required by BGP specification, PE routers form a full peering
  > mesh unless Route Reflectors are used.
  >
  Please refer to a specific document.

Writeup from Yakov:

1. Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready to
forward to the IESG for publication?

Yes, the chair believes that this ID is ready for publication.

2. Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the depth
or breadth of the reviews that have been performed?

This document passed the IDR WG Last Call, although we received no
comments on the document during the Last Call.

I am not aware whether it was reviewed by the v6ops WG. If the
document has not been reviewed by the v6ops WG, then it may be
useful to arrange such a review.

3. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No, other than review from the v6ops WG.

4. Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or have concerns whether there really is a need for it. In any
event, if your issues have been discussed in the WG and the WG has
indicated it that it still wishes to advance the document, detail
those concerns in the write-up.

I have no concerns with this document.

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

There were no objections to this document within the IDR WG during
the IDR WG Last Call.

6. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email to the Responsible Area Director.

No threat of an appeal.

7. Have the chairs verified that the document adheres to all of the
ID Checklist items ?

Yes.

8. Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not also
ready for advancement or are otherwise in an unclear state? (note
here that the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)

The document is split into normative and informative references.
There are no normative references to IDs.

9. What is the intended status of the document? (e.g., Proposed Standard,
Informational?)

Proposed Standard.

10.  For Standards Track and BCP documents, the IESG approval announcement
includes a write-up section with the following sections:

[placed in writeup]