Skip to main content

Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
RFC 4684

Revision differences

Document history

Date Rev. By Action
2020-01-21
02 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
02 (System) Notify list changed from rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net to rcallon@juniper.net, rick@rhwilder.net
2012-08-22
02 (System) post-migration administrative database adjustment to the Yes position for Mark Townsley
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Alex Zinin
2006-11-16
02 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-11-16
02 Amy Vezza [Note]: 'RFC 4684' added by Amy Vezza
2006-11-14
02 (System) RFC published
2006-04-24
02 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-04-17
02 Amy Vezza IESG state changed to Approved-announcement sent
2006-04-17
02 Amy Vezza IESG has approved the document
2006-04-17
02 Amy Vezza Closed "Approve" ballot
2006-04-14
02 (System) Removed from agenda for telechat - 2006-04-13
2006-04-13
02 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Amy Vezza
2006-04-13
02 Jari Arkko
[Ballot comment]
Some nits found when reading the document:

> should distribute VPN routes with the specific target torwards the

s/torwards/towards/

> This mechanism is …
[Ballot comment]
Some nits found when reading the document:

> should distribute VPN routes with the specific target torwards the

s/torwards/towards/

> This mechanism is applicable to any BGP NLRI that controls the
> distribution of routing information based on Route Targets, such as
> BGP L2VPNs [?] and VPLS [9].

Missing reference.
2006-04-13
02 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-04-13
02 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-04-12
02 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-04-12
02 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-04-12
02 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-04-12
02 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to Yes from Discuss by Mark Townsley
2006-04-09
02 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-04-06
02 Mark Townsley
IMPLEMENTATION REPORT

-------- Original Message --------
Subject: Fwd: Re: draft-ietf-l3vpn-rt-constrain-02
Date: Wed, 15 Mar 2006 16:14:48 -0500
From: Ross Callon <rcallon@juniper.net>
To: townsley@cisco.com …
IMPLEMENTATION REPORT

-------- Original Message --------
Subject: Fwd: Re: draft-ietf-l3vpn-rt-constrain-02
Date: Wed, 15 Mar 2006 16:14:48 -0500
From: Ross Callon <rcallon@juniper.net>
To: townsley@cisco.com


>X-JNPR-Received-From: outside
>X-BrightmailFiltered: true
>X-Brightmail-Tracker: AAAAAA==
>X-IronPort-AV: i="4.02,195,1139212800";
>    d="txt'?scan'208"; a="533929020:sNHT36071340"
>X-IronPort-AV: i="4.02,195,1139212800";
>    d="txt'?scan'208"; a="1785251920:sNHT86667032"
>Date: Wed, 15 Mar 2006 11:32:46 -0800
>From: Keyur <keyupate@cisco.com>
>User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
>rv:1.7.2) Gecko/20040804 Netscape/7.2
>X-Accept-Language: en-us, en
>To: Ross Callon <rcallon@juniper.net>
>CC: roque@juniper.net, rbonica@juniper.net, luyuanfang@att.com,
>        lmartini@cisco.com, rraszuk@cisco.com, jguichar@cisco.com
>Subject: Re: draft-ietf-l3vpn-rt-constrain-02
>X-OriginalArrivalTime: 15 Mar 2006 19:32:12.0206 (UTC)
>FILETIME=[2853F4E0:01C64867]
>X-Scanned-By: MIMEDefang 2.39
>
>Ross:
>        I submitted the implementation report after the IEFT draft
> deadline. I got an email from "ids" stating it needs the WG Chair's
> approval for them to post the draft before the meeting. Attached is the
> copy of the implementation report.
>
>-Keyur
>
>Ross Callon wrote:
>
>>What is the implementation status of "Constrained VPN
>>Route Distribution" <draft-ietf-l3vpn-rt-constrain-02>? Has
>>it been implemented? If so, has multi-vendor interoperability
>>been demonstrated? Have their been deployments?
>>Thanks, Ross
>
>
>INTERNET-DRAFT                                  Keyur Patel
>draft-ietf-l3vpn-rt-constrain-implementation  Pedro Marques
>                                                Robert Raszuk
>Category                                          Standards
>Expires: September 2006                          March 2006
>
>      Implementation Survey for Constrained VPN Route Distribution
>          <draft-ietf-l3vpn-rt-constrain-implementation-00.txt>
>
>
>Status of this Memo
>
>
>    This document is an Internet-Draft and is subject to all provisions
>    of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/1id-abstracts.html
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
>
>    This document is a product of the l3vpn Working Group WG.  Comments
>    should be addressed to the authors, or the mailing list at
>    l3vpn@ietf.org.
>
>
>Copyright Notice
>
>    Copyright (C) The Internet Society (2006). All Rights Reserved.
>
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                                          [Page 1]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>Abstract
>
>
>    This document provides an implementation report for the Constrain
>    Route Distribution defined in [RT-CONSTRAIN]. After a brief summary,
>    each response is listed. The following organizations reported having
>    implementation of Constrain Route Distribution: Cisco Systems,
>    Juniper Networks.
>
>    The authors did not verify the accuracy of the information  provided
>    by respondents or by any alternative means.  The respondents are
>    experts with the implementations they reported on, and their
>    responses are considered authoritative for the implementations for
>    which their responses represent.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                                          [Page 2]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>Table of Contents
>
>
>    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    2. Implementation Forms . . . . . . . . . . . . . . . . . . . . .  4
>    3. Implementation Survey Forms. . . . . . . . . . . . . . . . . .  4
>    4. Cisco Systems, Inc.. . . . . . . . . . . . . . . . . . . . . .  5
>    4.1. Juniper Networks, Inc.. . . . . . . . . . . . . . . . . . .  6
>    5. Security Considerations. . . . . . . . . . . . . . . . . . . .  7
>    6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  8
>    7. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
>    7.1. Normative References. . . . . . . . . . . . . . . . . . . .  9
>    8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  10
>    9. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  10
>    10. Intellectual Property . . . . . . . . . . . . . . . . . . . .  11
>    11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  11
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                                          [Page 3]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>1.  Introduction
>
>
>    Constrained Route Distribution mechanism is an extension of the  MP-
>    BGP procedures that allow BGP speakers to exchange Route Target
>    reachability information.  This information can be used to build a
>    route distribution graph in order to limit the propagation of VPN
>    NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) within BGP-4.
>
>    This document provides an implementation report for the Constrain
>    Route Distribution defined in [RT-CONSTRAIN].
>
>    The authors did not verify the accuracy of the information  provided
>    by respondents or by any alternative means.  The respondents are
>    experts with the implementations they reported on, and their
>    responses are considered authoritative for the implementations for
>    which their responses represent.
>
>
>
>2.  Implementation Forms
>
>
>      Contact and implementation information for person filling out this
>      form:
>
>        Name: Keyur Patel
>        Email: keyupate@cisco.com
>        Vendor: Cisco Systems Inc
>        Release: IOS
>
>        Name: Robert Raszuk
>        Email: raszuk@cisco.com
>        Vendor: Cisco Systems Inc
>        Release: IOS
>
>        Name: Pedro Marques
>        Email: pedro@juniper.net
>        Vendor: Juniper Networks
>        Release: JunOS
>
>
>
>3.  Implementation Survey Forms
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                              Section 3.  [Page 4]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>4.  Cisco Systems, Inc.
>
>
>    Does your implementation follow the procedures outlined in the Inter-
>    AS VPN Route Distribution section of [RT-Constrain]?
>
>    YES
>
>    Does your implementation follow the procedures outlined in the Intra-
>    AS VPN Route Distribution section of [RT-Constrain]?
>
>    YES
>
>    Does your implementation follow the procedures outlined in the Route
>    Target membership NLRI advertisements section of [RT-Constrain]?
>
>    YES
>
>    Does your implementation follow the procedures outlined in the
>    Capability Advertisment section of [RT-Constrain]?
>
>    YES
>
>    Does your implementation follow the procedures outlined in the
>    Operation Section of [RT-Constrain]?
>
>    YES
>
>    Does your implementation use the End-of-RIB marker usage defined in
>    [RT-Constrain].
>
>    YES
>
>    Does your implementation use aggregated route target prefixes as
>    aggreated outbound filters?
>
>    NO
>
>    Does your implementation recognize the default route target filter to
>    permit all the vpn routes?
>
>    YES
>
>    Does your implementation perform RT based filtering for both, VPNv4
>    as well as VPNv6 routes?
>
>    YES
>
>
>
>
>Patel, Marques, Raszuk                              Section 4.  [Page 5]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>    List other implementations that you have tested for [RT-Constrain]
>
>
>
>
>4.1.  Juniper Networks, Inc.
>
>
>    Does your implementation follow the procedures outlined in the Inter-
>    AS VPN Route Distribution section of [RT-Constrain]?
>
>
>    Does your implementation follow the procedures outlined in the Intra-
>    AS VPN Route Distribution section of [RT-Constrain]?
>
>
>    Does your implementation follow the procedures outlined in the Route
>    Target membership NLRI advertisements section of [RT-Constrain]?
>
>    YES
>
>    Does your implementation follow the procedures outlined in the
>    Capability Advertisment section of [RT-Constrain]?
>
>    YES
>
>    Does your implementation follow the procedures outlined in the
>    Operation Section of [RT-Constrain]?
>
>
>    Does your implementation use the End-of-RIB marker usage defined in
>    [RT-Constrain].
>
>
>    Does your implementation use aggregated route target prefixes as
>    aggreated outbound filters?
>
>
>    Does your implementation recognize the default route target filter to
>    permit all the vpn routes?
>
>
>    Does your implementation perform RT based filtering for both, VPNv4
>    as well as VPNv6 routes?
>
>
>    List other implementations that you have tested for [RT-Constrain]
>
>
>
>
>Patel, Marques, Raszuk                            Section 4.1.  [Page 6]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>5.  Security Considerations
>
>
>    This document does not address any security issues.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                              Section 5.  [Page 7]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>6.  IANA Considerations
>
>
>    No parameters are defined in this document
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                              Section 6.  [Page 8]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>7.  References
>
>7.1.  Normative References
>
>
>    [RT-CONSTRAIN]  Marques, P., Bonica, R., Fang, L., Matini, L.,
>              Raszuk, R., Patel, K., and Guichard, J., "Constrained
>              VPN Route Distribution",          draft-ietf-l3vpn-rt-
>    constrain-02.txt, June 2005.
>
>    [BGP-4]        Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
>                    (BGP-4)", RFC 1771, March 1995.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                            Section 7.1.  [Page 9]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>8.  Authors' Addresses
>
>
>    Keyur Patel
>    Cisco Systems
>    email: keyupate@cisco.com
>
>    Robert Raszuk
>    Cisco Systems
>    email: rraszuk@cisco.com
>
>    Pedro Marques
>    Juniper Networks
>    email: pedro@juniper.net
>
>
>
>9.  Full Copyright Statement
>
>    Copyright (C) The Internet Society (2006). This document is subject
>    to the rights, licenses and restrictions contained in BCP 78 and
>    except as set forth therein, the authors retain all their rights.
>
>
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
>
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
>
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
>
>Patel, Marques, Raszuk                            Section 9.  [Page 10]
>INTERNET-DRAFT          Expires: September 2006              March 2006
>
>
>10.  Intellectual Property
>
>
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
>
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository at
>    http://www.ietf.org/ipr.
>
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at ietf-
>    ipr@ietf.org.
>
>
>11.  Acknowledgement
>
>
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Patel, Marques, Raszuk                            Section 11.  [Page 11]
2006-04-06
02 Mark Townsley Placed on agenda for telechat - 2006-04-13 by Mark Townsley
2006-04-06
02 Mark Townsley
[Note]: 'Remaining discuss before the new IESG was inaugerated was held by Alex for implementation reports (which have since been submitted). Ross, as Alex''s successor, …
[Note]: 'Remaining discuss before the new IESG was inaugerated was held by Alex for implementation reports (which have since been submitted). Ross, as Alex''s successor, has entered a "Yes" position.' added by Mark Townsley
2006-04-06
02 Mark Townsley Note field has been cleared by Mark Townsley
2006-04-05
02 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon by Ross Callon
2006-01-09
02 Mark Townsley State Changes to IESG Evaluation::External Party from IESG Evaluation::Point Raised - writeup needed by Mark Townsley
2006-01-09
02 Mark Townsley State Changes to IESG Evaluation::Point Raised - writeup needed from IESG Evaluation::AD Followup by Mark Townsley
2006-01-09
02 Mark Townsley [Note]: 'Need Implementation Report from Chairs' added by Mark Townsley
2005-12-20
02 Mark Townsley [Ballot discuss]
Need implementation report.
2005-12-20
02 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to Discuss from Yes by Mark Townsley
2005-09-30
02 Alex Zinin [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin
2005-09-29
02 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-09-29
02 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2005-09-29
02 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-09-29
02 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-09-29
02 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2005-09-29
02 Bert Wijnen
[Ballot comment]
Missing IANA considerations Section as per:

$ idnits draft-ietf-l3vpn-rt-constrain-02.txt
idnits 1.77 (21 Aug 2005)

draft-ietf-l3vpn-rt-constrain-02.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  …
[Ballot comment]
Missing IANA considerations Section as per:

$ idnits draft-ietf-l3vpn-rt-constrain-02.txt
idnits 1.77 (21 Aug 2005)

draft-ietf-l3vpn-rt-constrain-02.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack an IANA Considerations section.

Also:

  !! Missing Reference for citation: [?]
  P005 L008:    BGP L2VPNs [?] and VPLS [9].
2005-09-29
02 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2005-09-29
02 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-09-29
02 Alex Zinin
[Ballot discuss]
Major points:

1. Can we please have a proper implementation & interop report for this
    spec?

2. Questions on section 6 …
[Ballot discuss]
Major points:

1. Can we please have a proper implementation & interop report for this
    spec?

2. Questions on section 6 "Operation":

>    When a BGP speaker receives a BGP UPDATE that advertises or withdraws
>    a given Route Target membership NLRI, it should examine the RIB-OUTs
>    of VPN NLRIs and re-evaluate the advertisement status of routes that
>    match the Route Target in question.
>
>    A BGP speaker should generate the minimum set of BGP VPN route
>    updates necessary to transition between the previous and current
>    state of the route distribution graph that is derived from Route
>    Target membership information.

    Does this mean that the BGP speaker may have to send withdraws as
    well, or is the remote peer assumed to have deleted unwanted routes
    on its own?

As a comment, the document isn't consistent on using 2119 language.
E.g.:

> 6.  Operation
>
>    A VPN NLRI route should be advertised to a peer that participates in

Is this a "SHOULD" above?

>    When a BGP speaker receives a BGP UPDATE that advertises or withdraws
>    a given Route Target membership NLRI, it should examine the RIB-OUTs

ditto
2005-09-29
02 Alex Zinin [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin
2005-09-29
02 Bill Fenner [Ballot comment]
Note: -01 was Last Called in the idr WG in April, with no comments received.  -02 contains no major changes from -01.
2005-09-29
02 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-09-28
02 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-09-28
02 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-09-28
02 Russ Housley
[Ballot discuss]
Section 2 says:
  >
  > This proposal extends the RFC2547bis [3] ORF work to include support
  > for multiple autonomous …
[Ballot discuss]
Section 2 says:
  >
  > This proposal extends the RFC2547bis [3] ORF work to include support
  > for multiple autonomous systems, and asymmetric VPN topologies such
  > as hub-and-spoke.
  >
  Two points.  First, if we are going to publish this as a standards
  track RFC, then it is not a "proposal" any more.  Second, it seems
  that this document is an updates to [3].  If so, the title page
  header, the abstract, and the introduction should indicate this
  situation.
2005-09-28
02 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-09-28
02 Mark Townsley
Proto Questionairre

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward …
Proto Questionairre

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

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?

The document was reviewed by the L3VPN and the IDR WGs.

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

Not after the IDR review.
 
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 whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.
 
The document is supported by service providers who want the capability for their deployments.

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 is a solid consensus for this document. Active participants in the WG with routing experience appear to support it. Concerns that were raised in the first version of the document were addressed.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).
 
8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: 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.)

There are two normative references to IDs. So, this draft cannot precede either

draft-ietf-idr-bgp4-20.txt or
draft-ietf-idr-restart-10.txt

to the editor's queue.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary
  - Working Group Summary
  - Protocol Quality

Technical summary

This document addresses scaling issues for VPN routing information maintained at route reflectors. It extends the RFC2547bis approach using “Cooperative Route Filtering� between router reflectors for support multiple autonomous systems and asymmetric VPN topologies such as hub-and-spoke. The solution uses MP-BGP UPDATE messages to propagate Route Target membership information. Received Route Target membership information can then be used to restrict advertisement of VPN NLRI to peers that have advertised their respective Route Targets, effectively building a route distribution graph. In this model, VPN NLRI routing information flows in the inverse direction of Route Target membership information.

This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets, such as BGP L2VPNs [L2VPN] and VPLS [VPLS].




WG summary

There were several detailed issued which were raised when the document was submitted to the WG. Constructive comments led to modifications to the document which addressed the concerns that were raised.

Protocol Quality

Both CISCO and Juniper have implemented this protocol.
2005-09-28
02 Scott Hollenbeck [Ballot comment]
7 authors?
2005-09-28
02 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-09-28
02 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Undefined by Brian Carpenter
2005-09-28
02 Brian Carpenter
[Ballot comment]
Infested with undefined acronyms. Is there a reference for these acronyms?

Broken reference in section 2: BGP L2VPNs [?] . Let's hope this …
[Ballot comment]
Infested with undefined acronyms. Is there a reference for these acronyms?

Broken reference in section 2: BGP L2VPNs [?] . Let's hope this isn't normative.

More on acronyms from Gen-ART review by John Loughney:

1) Abstract full of acronyms, please expand.
2) Desperately needs a terminology section, as some of the terminology
is quite specific to VPN technology.

I'd recommend a document revision with the above 2 points addressed.
2005-09-28
02 Brian Carpenter
[Ballot comment]
Infested with undefined acronyms. Is there a reference for routing acronyms?

Broken reference in section 2: BGP L2VPNs [?] . Let's hope this …
[Ballot comment]
Infested with undefined acronyms. Is there a reference for routing acronyms?

Broken reference in section 2: BGP L2VPNs [?] . Let's hope this isn't normative.
2005-09-28
02 Brian Carpenter [Ballot Position Update] New position, Undefined, has been recorded for Brian Carpenter by Brian Carpenter
2005-09-27
02 Russ Housley
[Ballot discuss]
Section 2 says:
  >
  > This proposal extends the RFC2547bis [3] ORF work to include support
  > for multiple autonomous …
[Ballot discuss]
Section 2 says:
  >
  > This proposal extends the RFC2547bis [3] ORF work to include support
  > for multiple autonomous systems, and asymmetric VPN topologies such
  > as hub-and-spoke.
  >
  Two points.  First, if we are going to publish this as a standards
  track RFC, then it is not a "proposal" any more.  Second, it seems
  that this document is an updates to [3].  If so, the title page
  header, the abstract, and the introduction should indicate this
  situation.

  The security considerations talk about filtering.  Should this section
  reference BCP 38 (Network Ingress Filtering: Defeating Denial of
  Service Attacks which employ IP Source Address Spoofing) and BCP 84
  (Ingress Filtering for Multihomed Networks)?
2005-09-27
02 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Undefined by Russ Housley
2005-09-27
02 Russ Housley [Ballot Position Update] New position, Undefined, has been recorded for Russ Housley by Russ Housley
2005-09-27
02 Mark Townsley Ballot has been issued by Mark Townsley
2005-09-27
02 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2005-09-27
02 Mark Townsley Ballot has been issued by Mark Townsley
2005-09-27
02 Mark Townsley Created "Approve" ballot
2005-09-22
02 Mark Townsley State Changes to IESG Evaluation from Waiting for Writeup by Mark Townsley
2005-09-21
02 Mark Townsley Placed on agenda for telechat - 2005-09-29 by Mark Townsley
2005-07-20
02 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-07-13
02 Michelle Cotton IANA Last Call Comments:
No IANA Considerations section.
We understand this document to have NO IANA Actions.
2005-07-06
02 Amy Vezza Last call sent
2005-07-06
02 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-07-05
02 Mark Townsley Last Call was requested by Mark Townsley
2005-07-05
02 (System) Ballot writeup text was added
2005-07-05
02 (System) Last call text was added
2005-07-05
02 (System) Ballot approval text was added
2005-07-05
02 Mark Townsley State Changes to Last Call Requested from AD Evaluation::AD Followup by Mark Townsley
2005-06-23
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-06-23
02 (System) New version available: draft-ietf-l3vpn-rt-constrain-02.txt
2005-06-08
02 Mark Townsley State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Mark Townsley
2005-06-08
02 Mark Townsley Note field has been cleared by Mark Townsley
2005-06-08
02 Mark Townsley State Changes to AD Evaluation from Expert Review::Revised ID Needed by Mark Townsley
2005-06-08
02 Mark Townsley State Changes to Expert Review::Revised ID Needed from Expert Review by Mark Townsley
2005-06-08
02 Mark Townsley
[Note]: 'Expert review by IDR through May 2. Monday, April 18, 2005, 11:27:42 AM, Yakov Rekhter wrote: >> Folks, >> draft-ietf-l3vpn-rt-constrain-01.txt has completed last call …
[Note]: 'Expert review by IDR through May 2. Monday, April 18, 2005, 11:27:42 AM, Yakov Rekhter wrote: >> Folks, >> draft-ietf-l3vpn-rt-constrain-01.txt has completed last call in the<br>>> L3VPN WG. The area directors have asked for it to be reviewed by<br>>> the IDR WG. >> The deadline for comments is May 2, 2005. >> Yakov. >> _______________________________________________<br>>> Idr mailing list<br>>> Idr@ietf.org<br>>> https://www1.ietf.org/mailman/listinfo/idr<br>' added by Mark Townsley
2005-04-20
02 Mark Townsley State Changes to Expert Review from AD Evaluation::Revised ID Needed by Mark Townsley
2005-04-20
02 Mark Townsley
[Note]: '<br>Expert review by IDR through May 2.<br><br>Monday, April 18, 2005, 11:27:42 AM, Yakov Rekhter wrote:<br><br>>> Folks,<br><br><br>>> draft-ietf-l3vpn-rt-constrain-01.txt has completed last call in the<br>>> L3VPN …
[Note]: '<br>Expert review by IDR through May 2.<br><br>Monday, April 18, 2005, 11:27:42 AM, Yakov Rekhter wrote:<br><br>>> Folks,<br><br><br>>> draft-ietf-l3vpn-rt-constrain-01.txt has completed last call in the<br>>> L3VPN WG. The area directors have asked for it to be reviewed by<br>>> the IDR WG.<br><br><br>>> The deadline for comments is May 2, 2005.<br><br><br>>> Yakov.<br><br><br>>> _______________________________________________<br>>> Idr mailing list<br>>> Idr@ietf.org<br>>> https://www1.ietf.org/mailman/listinfo/idr<br>' added by Mark Townsley
2005-04-13
02 Mark Townsley State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Mark Townsley
2005-04-13
02 Mark Townsley
[Note]: '<br><br>-------- Original Message --------<br>Subject: Re: [Fwd: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-05.txt]<br>Date: Wed, 13 Apr 2005 13:01:01 -0700 (PDT)<br>From: Rick Wilder <rick@rhwilder.net><br>To: W. Mark Townsley < …
[Note]: '<br><br>-------- Original Message --------<br>Subject: Re: [Fwd: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-05.txt]<br>Date: Wed, 13 Apr 2005 13:01:01 -0700 (PDT)<br>From: Rick Wilder <rick@rhwilder.net><br>To: W. Mark Townsley <townsley@cisco.com>, Rick Wilder <rick@rhwilder.net><br>CC: Ronald Bonica <rbonica@juniper.net>, Thomas Narten <br><narten@us.ibm.com>, zinin@psg.com, margaret@thingmagic.com, Ross Callon <br><rcallon@juniper.net><br><br><br><br>I did the form and then discovered there were a lot of "nits", so it <br>went back to the authors. I haven''t seen a re-submitted draft yet. As an <br>author, do you know the status, Ron?<br> <br>Rick<br><br><br>*/"W. Mark Townsley" <townsley@cisco.com>/* wrote:<br><br><br><br>    Rick Wilder wrote:<br>     > Right. I will do the form for draft-ietf-l3vpn-rt-constrain-01 in<br>    the morning.<br><br>    Has this been done? I don''t see it in my inbox, but perhaps I missed it.<br><br>    Thanks,<br><br>    - Mark' added by Mark Townsley
2005-03-25
02 Mark Townsley State Changes to AD Evaluation from Publication Requested by Mark Townsley
2005-03-11
02 Mark Townsley Shepherding AD has been changed to Mark Townsley from Thomas Narten
2004-12-10
02 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2004-09-14
01 (System) New version available: draft-ietf-l3vpn-rt-constrain-01.txt
2004-06-02
00 (System) New version available: draft-ietf-l3vpn-rt-constrain-00.txt