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 |