Network Working Group Yakov Rekhter (Juniper Networks) Editor Internet Draft Expiration Date: January 2003 BGP Extended Communities Attribute - Implementation Survey draft-rekhter-ext-communities-survey-01.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document provides a survey of BGP-4 Extended Communities implementations. 3. Survey Summary This document provides a survey of BGP-4 Extended Communities [EXT- COMMUNITIES] implementations. After a brief summary, each response is listed. The editor, makes no claim as to the accuracy of the information provided. Rekhter [Page 1] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 4. Survey Forms 4.1. NextHop Technologies Organization: NextHop Technologies Person filling out this form: Jeffrey Haas Which Extended Communities do you support ? Explicit configuration is supported for: 2-octet AS specific Route Target IPv4 address specific Route Target 2-octet AS specific Route Origin IPv4 address specific Route Origin We also support the Opaque Extended Community into which anything can be put. Do you support the use the Extended Communities attribute to control which routing information it accepts or distributes to its peers ? Yes, we can run policy using Extended Communities. Do you support the ability of a router to append the Extended Community attribute to the route when propagating the route to its peers ? Yes. Do you support the ability of a router to modify the Extended Community attribute according to the local policy ? Yes - in the form of a add, add/delete, or delete operation. Do you support the ability to carry both the BGP Communities attribute and the Extended BGP Communities attribute ? Yes. Do you support the following: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Com- munities path attribute which contains the set union of all the Rekhter [Page 2] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 Extended Communities from all of the aggregated routes. The default behavior could be overriden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. We do the default. Does your implementation remove a non-transitive Extended Community from a route before advertising the route across the autonomous system boundary ? Yes, but not on AS confederation boundaries. Does your implementation preserve a non-transitive Extended Community of a route when advertising the route across the BGP Confederation boundary ? Yes. List other implementations that you tested for Extended Communities interoperability: Juniper 4.2. Redback Networks Organization: Redback Networks Person filling out this form: Jenny Yuan Which Extended Communities do you support ? 2-octet AS specific Route Target 4-octet AS specific Route Target IPv4 address specific Route Target 2-octet AS specific Route Origin 4-octet AS specific Route Origin IPv4 address specific Route Origin Do you support the use the Extended Communities attribute to control which routing information it accepts or distributes to its peers ? Yes. Do you support the ability of a router to append the Extended Community attribute to the route when propagating the route to its Rekhter [Page 3] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 peers ? Yes. Do you support the ability of a router to modify the Extended Community attribute according to the local policy ? Yes. Do you support the ability to carry both the BGP Communities attribute and the Extended BGP Communities attribute ? Yes. Do you support the following: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Com- munities path attribute which contains the set union of all the Extended Communities from all of the aggregated routes. The default behavior could be overriden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. We currently support only the default behavior, and will support using local policy to handle extended communities in aggregated routes when there is a requirement. Does your implementation remove a non-transitive Extended Community from a route before advertising the route across the autonomous system boundary ? Yes. Does your implementation preserve a non-transitive Extended Community of a route when advertising the route across the BGP Confederation boundary ? Yes. List other implementations that you tested for Extended Communities interoperability: Cisco, Juniper Rekhter [Page 4] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 4.3. Cisco Systems Organization: Cisco Systems Person filling out this form: Dan Tappan Which Extended Communities do you support ? Of the communities defined in [EXT-COMMUNITIES] 2-octet AS specific Route Target IPv4 address specific Route Target 2-octet AS specific Route Origin IPv4 address specific Route Origin Do you support the use the Extended Communities attribute to control which routing information it accepts or distributes to its peers ? Yes Do you support the ability of a router to append the Extended Community attribute to the route when propagating the route to its peers ? Yes Do you support the ability of a router to modify the Extended Community attribute according to the local policy ? Yes. Do you support the ability to carry both the BGP Communities attribute and the Extended BGP Communities attribute ? Yes. Do you support the following: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Com- munities path attribute which contains the set union of all the Extended Communities from all of the aggregated routes. The default behavior could be overriden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. Rekhter [Page 5] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 Yes. Does your implementation remove a non-transitive Extended Community from a route before advertising the route across the autonomous system boundary ? Yes Does your implementation preserve a non-transitive Extended Community of a route when advertising the route across the BGP Confederation boundary ? Yes. 4.4. Riverstone Networks Organization: Riverstone Networks Person filling out this form: Greg Hankins Which Extended Communities do you support ? Two-octet AS specific Route Target IPv4 address specific Route Target Two-octet AS specific Route Origin IPv4 address specific Route Origin Opaque Extended Community Do you support the use the Extended Communities attribute to control which routing information it accepts or distributes to its peers ? Yes. Do you support the ability of a router to append the Extended Community attribute to the route when propagating the route to its peers ? Yes. Do you support the ability of a router to modify the Extended Community attribute according to the local policy ? Yes. Do you support the ability to carry both the BGP Communities attribute and the Extended BGP Communities attribute ? Rekhter [Page 6] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 Yes. Do you support the following: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Com- munities path attribute which contains the set union of all the Extended Communities from all of the aggregated routes. The default behavior could be overriden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. Yes. Does your implementation remove a non-transitive Extended Community from a route before advertising the route across the autonomous system boundary ? Yes. Does your implementation preserve a non-transitive Extended Community of a route when advertising the route across the BGP Confederation boundary ? Yes. List other implementations that you tested for Extended Communities interoperability: We have tested interoperability with: cisco GSR, Juniper (both Juniper M routers and Juniper ERX), and Laurel ST-200. 4.5. Ericsson Organization: Ericsson Person filling out this form: Kaarthik Sivakumar Which Extended Communities do you support ? 2-octet AS specific Route Target IPv4 address specific Route Target 2-octet AS specific Route Origin IPv4 address specific Route Origin Rekhter [Page 7] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 Do you support the use the Extended Communities attribute to control which routing information it accepts or distributes to its peers ? Yes. Do you support the ability of a router to append the Extended Community attribute to the route when propagating the route to its peers ? Yes Do you support the ability of a router to modify the Extended Community attribute according to the local policy ? For Route Target. Do you support the ability to carry both the BGP Communities attribute and the Extended BGP Communities attribute ? Yes. Do you support the following: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Com- munities path attribute which contains the set union of all the Extended Communities from all of the aggregated routes. The default behavior could be overriden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. Yes. Does your implementation remove a non-transitive Extended Community from a route before advertising the route across the autonomous system boundary ? Yes. Does your implementation preserve a non-transitive Extended Community of a route when advertising the route across the BGP Confederation boundary ? No. List other implementations that you tested for Extended Communities Rekhter [Page 8] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 interoperability: Cisco and Juniper for Route Targets using MPLS/VPN environment. Cisco for Route Origin. 4.6. Laurel Networks Organization: Laurel Networks Person filling out this form: Manish Vora Which extended communities do you support ? Of the communities defined in [EXT-COMMUNITIES] 2-octet AS specific Route Target IPv4 address specific Route Target 2-octet AS specific Route Origin IPv4 address specific Route Origin Do you support the use the Extended Communities attribute to control which routing information it accepts or distributes to its peers ? Yes. Do you support the ability of a router to append the extended community attribute to the route when propagating the route to its peers ? Yes. Do you support the ability of a router to modify the extended community attribute according to the local policy ? Yes. Do you support the ability to carry both the BGP Communities attribute and the Extended BGP Communities attribute ? Yes. Do you support the following: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Com- munities path attribute which contains the set union of all the Rekhter [Page 9] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 Extended Communities from all of the aggregated routes. The default behavior could be overriden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. Yes. Does your implementation remove a non-transitive extended community from a route before advertising the route across the autonomous system boundary ? Yes. Does your implementation preserve a non-transitive extended community of a route when advertising the route across the BGP Confederation boundary. Yes. List other implementations that you tested for Extended Communities interoperability Juniper, Cisco. 4.7. Juniper Organization: Juniper Networks Person filling out this form: Bruno Rijsman Which Extended Communities do you support ? Of the communities defined in [EXT-COMMUNITIES] the implementation can send, receive, and act upon the following Extended Communities: 2-octet AS specific Route Target 4-octet AS specific Route Target IPv4 address specific Route Target 2-octet AS specific Route Origin 4-octet AS specific Route Origin IPv4 address specific Route Origin The implementation can also display and propagate all other Extended Communities including Link Bandwidth and Opaque. Rekhter [Page 10] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 Do you support the use the Extended Communities attribute to control which routing information it accepts or distributes to its peers ? Yes Do you support the ability of a router to append the Extended Community attribute to the route when propagating the route to its peers ? Yes Do you support the ability of a router to modify the Extended Community attribute according to the local policy ? Yes Do you support the ability to carry both the BGP Communities attribute and the Extended BGP Communities attribute ? Yes Do you support the following: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Com- munities path attribute which contains the set union of all the Extended Communities from all of the aggregated routes. The default behavior could be overriden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. Yes. Does your implementation remove a non-transitive Extended Community from a route before advertising the route across the autonomous system boundary ? Currently no, but we plan to change this as a result of this query. Does your implementation preserve a non-transitive Extended Community of a route when advertising the route across the BGP Confederation boundary ? Yes. Rekhter [Page 11] Internet Draft draft-rekhter-ext-communities-survey-01.txt July 2002 List other implementations that you tested for Extended Communities interoperability: Proved interoperability for at least "2-octet AS specific Route Target" with all of the following: -Laurel -Agilent -Juniper -IXIA -Lucent Springtide (beta code) -Riverstone (beta code) -AdTech -Cisco -Foundry 5. Security Considerations This document does not address any security issues. 6. IANA Considerations No parameters are defined in this document. 7. References [EXT-COMMUNITIES] Srihari R. Sangli, Dan Tappan, Yakov Rekhter, "BGP Extended Communities Attribute", work in progress 8. Author Information Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089 e-mail: yakov@juniper.net Rekhter [Page 12]