Network Working Group E. Chen Internet Draft Editor Expiration Date: December 2006 Cisco Systems Implementation Survey for BGP ORF and Prefix-ORF draft-chen-bgp-orf-survey-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides an implementation report for these two documents: "Cooperative Route Filtering Capability for BGP-4" and "Address Prefix Based Outbound Route Filter for BGP-4". Chen [Page 1] Internet Draft draft-chen-bgp-orf-survey-00.txt June 2006 1. Summary This document provides an implementation report for these two documents: "Cooperative Route Filtering Capability for BGP-4" [1], and "Address Prefix Based Outbound Route Filter for BGP-4" [2]. Each response is listed. The editor makes no claim as to the accuracy of the information provided. The following organizations reported having implementations of the drafts: Cisco Systems, IP Infusion, and Redback Networks. 2. Implementation Forms 2.1. Cisco Systems Person filling out this form: Keyur Patel (keyupate@cisco.com) Implementation (software version): IOS 12.2S and beyond List the ORF types that are implemented in your implementation: a) communities ORF: No b) extended communities ORF: Yes c) prefix ORF: Yes Does your implementation follow the normal procedures for handling a ROUTE-REFRESH request that does not carry ORF entries? Yes Does your implementation defer route advertisements as specified in the specification after receiving ORF entries with "when-to-refresh" set to DEFER? Yes How does your implementation handle route advertisements after receiving ORF entries with "when-to-refresh" set to IMMEDIATE? a) re-advertise all routes in the Adj-RIB-OUT for the AFI/SAFI (i.e., follow the normal ROUTE-REFRESH procedure), but take Chen [Page 2] Internet Draft draft-chen-bgp-orf-survey-00.txt June 2006 the ORF entries into account. Yes b) maintain extra state and do not re-advertise the routes that have not been effected by the ORF entries, as suggested by the specification. No Does your implementation follow all other procedures specified in the Operation Section of the specification? Yes Has there been any interoperability testing? List the ORF types tested. No Are there parts of the specification that are unclear where the implementor had to exercise some judgment that may impact the implementation and/or interoperability? a) ORF base spec: No b) Prefix-ORF spec: No 2.2. IP Infusion Person filling out this form: Dilip Pandit (dpandit@ipinfusion.com) Implementation (software version): ZebOS 7.3 List the ORF types that are implemented in your implementation: a) communities ORF: No b) extended communities ORF: No c) prefix ORF: Yes Does your implementation follow the normal procedures for handling a ROUTE-REFRESH request that does not carry ORF entries? Chen [Page 3] Internet Draft draft-chen-bgp-orf-survey-00.txt June 2006 Yes Does your implementation defer route advertisements as specified in the specification after receiving ORF entries with "when-to-refresh" set to DEFER? Yes How does your implementation handle route advertisements after receiving ORF entries with "when-to-refresh" set to IMMEDIATE? a) re-advertise all routes in the Adj-RIB-OUT for the AFI/SAFI (i.e., follow the normal ROUTE-REFRESH procedure), but take the ORF entries into account. Yes b) maintain extra state and do not re-advertise the routes that have not been effected by the ORF entries, as suggested by the specification. No Does your implementation follow all other procedures specified in the Operation Section of the specification? Yes Has there been any interoperability testing? List the ORF types tested. Yes, tested the prefix-ORF with Cisco IOS. Are there parts of the specification that are unclear where the implementor had to exercise some judgment that may impact the implementation and/or interoperability? a) ORF base spec: No b) Prefix-ORF spec: No 2.3. Redback Networks Person filling out this form: Albert Tian (tian@redback.com) Chen [Page 4] Internet Draft draft-chen-bgp-orf-survey-00.txt June 2006 Implementation (software version): SE2.6.7 and beyond List the ORF types that are implemented in your implementation: a) communities ORF: No b) extended communities ORF: No c) prefix ORF: Yes Does your implementation follow the normal procedures for handling a ROUTE-REFRESH request that does not carry ORF entries? Yes Does your implementation defer route advertisements as specified in the specification after receiving ORF entries with "when-to-refresh" set to DEFER? Yes How does your implementation handle route advertisements after receiving ORF entries with "when-to-refresh" set to IMMEDIATE? a) re-advertise all routes in the Adj-RIB-OUT for the AFI/SAFI (i.e., follow the normal ROUTE-REFRESH procedure), but take the ORF entries into account. Yes b) maintain extra state and do not re-advertise the routes that have not been effected by the ORF entries, as suggested by the specification. No Does your implementation follow all other procedures specified in the Operation Section of the specification? Yes Has there been any interoperability testing? List the ORF types tested. Yes, tested the Prefix-ORF with Cisco. Chen [Page 5] Internet Draft draft-chen-bgp-orf-survey-00.txt June 2006 Are there parts of the specification that are unclear where the implementor had to exercise some judgment that may impact the implementation and/or interoperability? a) ORF base spec: No b) Prefix-ORF spec: No 3. Acknowledgments The editor would like to thank Dilip Pandit, Keyur Patel, and Albert Tian for submitting the implementation forms. 4. References [1] E. Chen, and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", draft-ietf-idr-route-filter-13.txt. [2] E. Chen, and S. Sangli, "Address Prefix Based Outbound Route Filter for BGP-4", draft-ietf-idr-bgp-prefix-orf-03.txt. 5. Editor's Address Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 EMail: enkechen@cisco.com 6. Full Copyright Notice 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 the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE Chen [Page 6] Internet Draft draft-chen-bgp-orf-survey-00.txt June 2006 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chen [Page 7]