One document matched: draft-rekhter-ext-communities-survey-01.txt

Differences from draft-rekhter-ext-communities-survey-00.txt

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 <jhaas@nexthop.com>

   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 <jenny@redback.com>

   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 <tappan@cisco.com>

   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
   <ghankins@riverstonenet.com>

   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
   <kaarthik@torrentnet.com>

   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 <vora@laurelnetworks.com>

   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
   <BRijsman@unispherenetworks.com>

   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]