OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
draft-ietf-l3vpn-ospfv3-pece-11

State changed to Approved-announcement to be sent::Revised ID Needed from Approved-announcement to be sent::Point Raised - writeup needed.
Although the comments could be addressed by a set editor's notes, I quick re-spin will more likely ensure that none of the necessary edits get overlooked.

[Ballot comment]
Fred Baker made in his OPS-DIR review a couple of comments which are not show stoppers but deserve being answered and clarified if necessary in the text:

1. The introduction mentions the use of OSPFv2 for IPv4 and OSPFv3 for IPv6. With the advent of OSPFv3 address families, mentioned in section 6, it is possible to use OSPFv3 for IPv4, enabling one protocol and one configuration to be used for both network layer protocols. I would expect that this might be a useful thing to comment on in the introduction.

2. The one question I was left asking was why the document mentioned MPLS in 20 places but did nothing with MPLS other than mention that it was used in BGP/MPLS VPNs. The routing technology could just as easily be used on any other PE-CE link; the point is that it is between an OSPFv3 instance in the PE and a correspondent on the CE router, enabling a customer to communicate with an upstream in a manner that enabled the upstream to trust routing information without the customer needing to obtain an AS number and operate a BGP configuration. That's not an impediment; the document only chose to specify that configuration. But the narrowness of specification left me puzzled.

[Ballot comment]
Fred Baker made in his OPS-DIR review a couple of comments which are not show stoppers but deserve being ansered and clarified if necessary in the text:

1. The introduction mentions the use of OSPFv2 for IPv4 and OSPFv3 for IPv6. With the advent of OSPFv3 address families, mentioned in section 6, it is possible to use OSPFv3 for IPv4, enabling one protocol and one configuration to be used for both network layer protocols. I would expect that this might be a useful thing to comment on in the introduction.

2. The one question I was left asking was why the document mentioned MPLS in 20 places but did nothing with MPLS other than mention that it was used in BGP/MPLS VPNs. The routing technology could just as easily be used on any other PE-CE link; the point is that it is between an OSPFv3 instance in the PE and a correspondent on the CE router, enabling a customer to communicate with an upstream in a manner that enabled the upstream to trust routing information without the customer needing to obtain an AS number and operate a BGP configuration. That's not an impediment; the document only chose to specify that configuration. But the narrowness of specification left me puzzled.

[Ballot comment]
- Who's the document shepherd? Tracker note says Ben, iesg writeup
says Danny. Probably a typo somewhere or a change, but might be worth
fixing.

- The abstract is confusing. It says "We had BGP/MPLS for IPv4; then
we added IPv6; then we added OSPFv2 and now in this document, we add
OSPFv3." Telling the reader about IPv4/IPv6 just seems distracting
here.

- NLRI & NSSA not expanded on 1st use.

- Is it safe to use a NULL domain ID? If I do that then
an incoming message can easily be confusing?

- Section 7 refers to rfc 4659 section 11 and 4577 section 6.
4659 section 11 refers to 2545 section 5 and 4364 section 13.
4577 refers to 4364 and 4365.
2545 says "nothing new here."
4364 is updated by 4577, 4684 and 5462.
4577 says "cryptographic authentication" SHOULD be used and
MUST be implemented but doesn't say what "cryptographic
authentication" really means.
I stopped following the breadcrumbs at that point;-)
Can't we do this better and simpler?

IANA understands that, upon approval of this document, there is a single
IANA action that needs to be completed.

In the IPv6 Address Specific Extended Community registry contained in
the Border Gateway Protocol (BGP) Extended Communities registries
located at:

http://www.iana.org/assignments/bgp-extended-communities

a parameter which was allocated through early allocation is to be made
permanent as follows:

Registry Name: IPv6 Address Specific Extended Community
Reference: [RFC5701]
Range Registration Procedures
------------------------------------------ ---------------------------
0x0000-0x00ff transitive communities First Come First Served
0x4000-0x40ff non-transitive communities First Come First Served

Registry:
Type Value Name Reference
------------ --------------------------------------- ---------
0x0002 IPv6 address specific Route Target [RFC5701]
0x0003 IPv6 address specific Route Origin [RFC5701]
0x0004 OSPFv3 Route Attributes [RFC-to-be]

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (OSPFv3 as a PE-CE routing protocol) to Proposed Standard


The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:
- 'OSPFv3 as a PE-CE routing protocol'
  as a Proposed Standard

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 2011-12-04. 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


  Many Service Providers (SPs) offer Virtual Private Network (VPN)
  services to their customers using a technique in which Customer Edge
  (CE) routers are routing peers of Provider Edge (PE) routers.  The
  Border Gateway Protocol (BGP) is used to distribute the customer's
  routes across the provider's IP backbone network, and Multiprotocol
  Label Switching (MPLS) is used to tunnel customer packets across the
  provider's backbone.  This is known as a "BGP/MPLS IP VPN".
  Originally only IPv4 was supported and it was later extended to
  support IPv6 VPNs as well.  Extensions were later added for the
  support of the Open Shortest Path First protocol version 2 (OSPFv2)
  as a PE-CE routing protocol for the IPv4 VPNs.  This document extends
  those specifications to support OSPF version 3 (OSPFv3) as a PE-CE
  routing protocol.  The OSPFv3 PE-CE functionality is identical to
  that of OSPFv2 except for the differences described in this document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/


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

(1.a) Who is the Document Shepherd for this document? Has the
  Document Shepherd personally reviewed this version of the
  document and, in particular, does he or she believe this
  version is ready for forwarding to the IESG for publication?

Ben Niven-Jenkins is the Document Shepherd for draft-ietf-l3vpn-ospfv3-pece. I have personally reviewed the -09 version of the document and believe that this version is ready for forwarding to the IESG for publication as a Standards Track RFC.

(1.b) Has the document had adequate review both from key WG members
  and from key non-WG members? Does the Document Shepherd have
  any concerns about the depth or breadth of the reviews that
  have been performed? 

Publication of the document was originally requested in September 2009 and approved by the IESG in December 2009.

In response to comments received since the approval, the authors decided to make a further update to the document and the unusual step of unapproving this document was taken and the document was returned to the WG for additional work.

The document was updated and jointly WG Last Called in OSPF and L3VPN which led to further updates and a second joint WG Last Call.

No outstanding comments exist and it is my opinion that the document has received extensive review and is now ready to be published.

(1.c) Does the Document Shepherd have concerns that the document
  needs more review from a particular or broader perspective,
  e.g., security, operational complexity, someone familiar with
  AAA, internationalization or XML?

No

(1.d) Does the Document Shepherd have any specific concerns or
  issues 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. Has an IPR disclosure related to this document
  been filed? If so, please include a reference to the
  disclosure and summarize the WG discussion and conclusion on
  this issue.

No concerns and no IPR disclosures have been filed.

(1.e) 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 during the joint OSPF and L3VPN WG Last Calls on the document.

(1.f) 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
  entered into the ID Tracker.)

No, not to my knowledge.

(1.g) Has the Document Shepherd personally verified that the
  document satisfies all ID nits? (See the Internet-Drafts Checklist
  and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
  not enough; this check needs to be thorough. Has the document
  met all formal review criteria it needs to, such as the MIB
  Doctor, media type and URI type reviews?

The idnits tools reports "There are 2 instances of lines with non-RFC5735-compliant IPv4 addresses in the document.  If these are example addresses, they should be changed." However the instances referred to are references to sections in another RFC  and so this is a false error on the part of the idnits tool and not a failing of the document.

There are no MIB or other elements in the document that would warrant review. As such, I have no concerns here.

(1.h) Has the document split its references into normative and
  informative? 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
  strategy for their completion? Are there normative references
  that are downward references, as described in [RFC3967]? If
  so, list these downward references to support the Area
  Director in the Last Call procedure for them [RFC3967].

The document splits its references into normative and informative. All normative references are to published RFCs. There are no downward references.


(1.i) Has the Document Shepherd verified that the document IANA
  consideration section exists and is consistent with the body
  of the document? If the document specifies protocol
  extensions, are reservations requested in appropriate IANA
  registries? Are the IANA registries clearly identified? If
  the document creates a new registry, does it define the
  proposed initial contents of the registry and an allocation
  procedure for future registrations? Does it suggest a
  reasonable name for the new registry? See [RFC5226]. If the
  document describes an Expert Review process has Shepherd
  conferred with the Responsible Area Director so that the IESG
  can appoint the needed Expert during the IESG Evaluation?

The document does not specify any protocol extensions that require the creation of new IANA registries or that require allocation of code points in existing registries.

However, A early draft of this document resulted in the allocation of OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Extended Community. This allocation is no longer required. IANA is requested to mark the OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Extended Community registry as deprecated.

(1.j) Has the Document Shepherd verified that sections of the
  document that are written in a formal language, such as XML
  code, BNF rules, MIB definitions, etc., validate correctly in
  an automated checker?

No section of this document is written in a formal language.

(1.k) 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
  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The initial BGP/MPLS IP VPN specification enabled PE routers to learn routes within customer sites through static routing, or through a dynamic routing protocol instantiated on the PE-CE link.

Specifically, RFC4364 includes support for dynamic routing protocols such as BGP, RIP, and OSPFv2. The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks specification (RFC4577) further updates the operation of OSPFv2 as the PE-CE routing protocol by detailing additional extensions to enable intra-domain routing connectivity between OSPFv2-based customer sites.

This document defines the mechanisms required to enable the operation of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs.  In doing so, it reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for IPv6 VPNs defined in RFC4659, and OSPFv2 as the PE-CE routing protocol defined in RFC4577.  This document also includes the specifications for maintaining intra-domain routing connectivity between OSPFv3-based customer sites across a SP backbone.

Working Group Summary
  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This document is a product of L3VPN WG. The document underwent WG Last Calls in both the L3VPN and OSPF WGs.

Document Quality
  Are there existing implementations of the protocol?

I am aware of one existing implementation.

  Have a significant number of vendors indicated their plan
  to implement the specification?

I do not know. However there is already one implementation that I am aware of.

  Are there any reviewers that merit special mention as
  having done a thorough review, e.g., one that resulted in
  important changes or a conclusion that the document had no
  substantive issues?

Not to the best of my knowledge.

  If there was a MIB Doctor, Media Type or other expert
  review, what was its course (briefly)? In the case of a
  Media Type review, on what date was the request posted?

No such review was conducted as it was not considered necessary.

IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "IPv6 Address Specific Extended Community"
registry at
http://www.iana.org/assignments/bgp-extended-communities

Type Value Name Reference
---------- ------------------------ ---------
0x0004 OSPFv3 Route Attributes [RFC-l3vpn-ospfv3-pece-03]


We understand the above to be the only IANA Action for this document.

Proto writeup by Danny McPherson:

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

  The Document Shepherd is myself (Danny McPherson). I believe that
  the 03 version is ready for forwarding to the IESG for publication
  as an Internet Standards Track RFC.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

  The document passed the L3VPN WG Last Call in April 2009, although
  we received no comments on the document during the Last Call.  No
  outstanding comments exist.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

  No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

  No.

  (1.e)  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 during the WG Last Call on the document,
  and the utility of this specification is straight-forward, as well
  as both obvious and intuitive.

  (1.f)  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
          entered into the ID Tracker.)

    No, not to my knowledge.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

    The idnits tool reports only one issue, with the formatting of IP
    addresses contained in the text of the document.  This can be 
resolved
    with RFC editor comments, or via an I-D update IF required after 
IESG
    and IETF-wide review.  There are no MIB or other elements in the 
document
    that would warrant review.  As such, I have no concerns here.

  (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

    The document split its references.  There are a large number of
    normative references, as with other L3VPN documents some of which
    may perhaps be a bit gratuitous, but all are published and available
    and I have no issues with the current approach and believe it to be
    in line with RFC editing processes.  Informative references include
    the BGP IPv6 Extended Communities document that is currently in
    processing, and an OSPFv3 AF support document.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

    This document defines a new BGP attribute in the "IPv6 Address 
Specific
    Extended Community" registry, making an assignment in the registry 
for
    "OSPFv3 Route Attributes" as Sub-type value 0x0004.
    draft-ietf-l3vpn-v6-ext-communities-02, as indicated in the 
informative
    reference above, is currently being progressed, and it's the 
document
    that called for creation of the IANA registry.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

  No section of this document is written in a formal language.

  (1.k)  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
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

    Many Service Providers (SPs) offer Virtual Private Network (VPN)
    services to their customers using a technique in which Customer Edge
    (CE) routers are routing peers of Provider Edge (PE) routers.  The
    Border Gateway Protocol (BGP) is used to distribute the customer's
    routes across the provider's IP backbone network, and Multiprotocol
    Label Switching (MPLS) is used to tunnel customer packets across the
    provider's backbone.  This is known as a "BGP/MPLS IP VPN".
    Originally only IPv4 was supported and it was later extended to
    support IPv6 VPNs as well.  Extensions were later added for the
    support of the Open Shortest Path First protocol version 2 (OSPFv2)
    as a PE-CE routing protocol for the IPv4 VPNs.  This document 
extends
    those specifications to support OSPF version 3 (OSPFv3) as a PE-CE
    routing protocol.  The OSPFv3 PE-CE functionality is identical to
    that of OSPFv2 except for the differences described in this 
document.

          Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

    This document is a product of L3VPN WG. There were no comments
    on the document during the WG Last Call, which was completed in
    mid April, 2009..

          Document Quality
            Are there existing implementations of the protocol?


  I do not know.

            Have a significant number of vendors indicated their plan
            to implement the specification?

  I do not know.

            Are there any reviewers that merit special mention as
            having done a thorough review, e.g., one that resulted
            in important changes or a conclusion that the document
            had no substantive issues?

  Not to the best of my knowledge.

            If there was a MIB Doctor, Media Type or other expert
            review, what was its course (briefly)?  In the case of
            a Media Type review, on what date was the request posted?

  Nope, none of the above.

Proto writeup by Danny McPherson:

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

  The Document Shepherd is myself (Danny McPherson). I believe that
  the 03 version is ready for forwarding to the IESG for publication
  as an Internet Standards Track RFC.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

  The document passed the L3VPN WG Last Call in April 2009, although
  we received no comments on the document during the Last Call.  No
  outstanding comments exist.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

  No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

  No.

  (1.e)  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 during the WG Last Call on the document,
  and the utility of this specification is straight-forward, as well
  as both obvious and intuitive.

  (1.f)  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
          entered into the ID Tracker.)

    No, not to my knowledge.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

    The idnits tool reports only one issue, with the formatting of IP
    addresses contained in the text of the document.  This can be 
resolved
    with RFC editor comments, or via an I-D update IF required after 
IESG
    and IETF-wide review.  There are no MIB or other elements in the 
document
    that would warrant review.  As such, I have no concerns here.

  (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

    The document split its references.  There are a large number of
    normative references, as with other L3VPN documents some of which
    may perhaps be a bit gratuitous, but all are published and available
    and I have no issues with the current approach and believe it to be
    in line with RFC editing processes.  Informative references include
    the BGP IPv6 Extended Communities document that is currently in
    processing, and an OSPFv3 AF support document.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

    This document defines a new BGP attribute in the "IPv6 Address 
Specific
    Extended Community" registry, making an assignment in the registry 
for
    "OSPFv3 Route Attributes" as Sub-type value 0x0004.
    draft-ietf-l3vpn-v6-ext-communities-02, as indicated in the 
informative
    reference above, is currently being progressed, and it's the 
document
    that called for creation of the IANA registry.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

  No section of this document is written in a formal language.

  (1.k)  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
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

    Many Service Providers (SPs) offer Virtual Private Network (VPN)
    services to their customers using a technique in which Customer Edge
    (CE) routers are routing peers of Provider Edge (PE) routers.  The
    Border Gateway Protocol (BGP) is used to distribute the customer's
    routes across the provider's IP backbone network, and Multiprotocol
    Label Switching (MPLS) is used to tunnel customer packets across the
    provider's backbone.  This is known as a "BGP/MPLS IP VPN".
    Originally only IPv4 was supported and it was later extended to
    support IPv6 VPNs as well.  Extensions were later added for the
    support of the Open Shortest Path First protocol version 2 (OSPFv2)
    as a PE-CE routing protocol for the IPv4 VPNs.  This document 
extends
    those specifications to support OSPF version 3 (OSPFv3) as a PE-CE
    routing protocol.  The OSPFv3 PE-CE functionality is identical to
    that of OSPFv2 except for the differences described in this 
document.

          Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

    This document is a product of L3VPN WG. There were no comments
    on the document during the WG Last Call, which was completed in
    mid April, 2009..

          Document Quality
            Are there existing implementations of the protocol?


  I do not know.

            Have a significant number of vendors indicated their plan
            to implement the specification?

  I do not know.

            Are there any reviewers that merit special mention as
            having done a thorough review, e.g., one that resulted
            in important changes or a conclusion that the document
            had no substantive issues?

  Not to the best of my knowledge.

            If there was a MIB Doctor, Media Type or other expert
            review, what was its course (briefly)?  In the case of
            a Media Type review, on what date was the request posted?

  Nope, none of the above.