[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                           Cengiz Alaettinoglu
Expires  May 17, 1996                                                USC/ISI
draft-ietf-rps-dpa-00.txt                                     November, 1995


         BGP Destination Preference Attribute Extension to Ripe-181



Status of this Memo

This document extends Ripe-181 to enable the setting of the DPA attribute
during route announcements.

This document is an Internet Draft, and can be found as
draft-ietf-rps-dpa-00.txt in any standard internet drafts repository.
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.
Internet Drafts may be updated, replaced, or obsoleted by other documents at
any time.  It is not appropriate to use Internet Drafts as reference
material, or to cite them other than as a ``working draft'' or ``work in
progress.''

Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet Draft.


1  Introduction

Ripe-181 [2] is a language to specify routing policy constraints for
inter-domain routing in the Internet.  Ripe-181 allows the specification of
both import policy constraints (by specifying as-in and interas-in
attributes) and export policy constraints (by specifying as-out and
interas-out attributes).

The Destination Preference Attribute (DPA) [3] is recently added to the
BGP [4] routing protocol.  This attribute can be used by an autonomous
system (AS) to specify a globally transitive preference in its routing
announcement via BGP so that the upstream BGP speakers can use this
preference to favor certain path for return traffic.

This document extends Ripe-181 to enable the setting of the DPA attribute
during route announcements.  It is assumed that the reader is familiar with
BGP, DPA and Ripe-181.
Internet Draft          BGP DPA Extension to Ripe-181         November, 1995

2  Extended Attributes

In [1], we introduced four new policy attributes for the aut-num object,
extended-as-in, extended-as-out, extended-interas-in, and
extended-interas-out to augment the as-in, as-out, interas-in, and
interas-out attributes respectively.  We use extended-interas-out attributes
to describe the DPA attribute processing in Ripe-181.

The extended-interas-out attributes have the following syntax (please refer
to RIPE-181 [2] and Reference [1] for the details of their syntax and
semantics):

   extended-interas-out: to <aut-num> <local-rid> <neighbor-rid> [<metric>]
                         announce <extended routing policy expression>.


2.1  Setting the DPA Attribute

In the extended-interas-out attribute, <metric> is optional and is defined
as follows:

          (<metric-type>=<value>)

Currently, there is only one metric-type defined which is "metric-out".  We
add another metric-type, "DPA".  The valid values for the "DPA" metric-type
is non-negative integers where smaller integers represents higher
preferences.  The semantics of "(DPA=<value>)" is that the resulting route
announcement contains a DPA attribute, where the AS number of the DPA
attribute equals the AS number of the aut-num object and the preference of
the DPA attribute equals <value>.

If more than one metric-type needs to be set for a route announcement, for
example both metric-out and DPA, it can be done placing a semicolon between
them.

Here are some examples:

   aut-num: AS1
   extended-as-out: to AS2 announce AS1
   extended-as-out: to AS3 announce AS1
   extended-interas-out: to AS2 128.9.8.8/32 128.9.8.9/32
                         (DPA=5) announce AS1
   extended-interas-out: to AS3 128.9.8.8/32 128.9.8.7/32
                         (metric-out=1;DPA=6) announce AS1

The routes that are announced to AS2 have a DPA attribute with AS AS1 and
preference 5, whereas routes that are announced to AS3 have a DPA attribute
with preference 6.  If an AS, say AS4, receives both of these routes from
both AS2 and AS3 it may use the value of the DPA attribute and prefer the
routes through AS2.


Cengiz Alaettinoglu              Expires  May 17, 1996              [Page 2]


Internet Draft          BGP DPA Extension to Ripe-181         November, 1995

Note that we do not allow specification of a DPA attribute in
extended-as-out.  This is because the Ripe-181 does not allow specification
of any action in an as-out attribute.


3  Concluding Remarks

In this document, we have presented extensions to Ripe-181 which allows
setting the DPA attribute on route announcements.  Our solution is similar
to how the MUTLI_EXIT_DISCRIMINATOR attribute is handled in Ripe-181.

DPA attribute is an optional transitive attribute which means that not all
the routers need to understand it.  Our extension does not allow the
specification of whether the routers of an AS understands and uses the DPA
attribute in route selection.  This information may be useful for routing
policy analysis tools to mimic the Internet's routing more closely.  A
general solution may be for an AS to list the optional attributes it does
not understand.  RPS working group may consider a solution to this.


4  Acknowledgments

I thank Ramesh Govindan and Tony Bates for various discussions and
suggestions.


References

[1] C. Alaettinoglu and J. Yu. Autonomous System Path Expression Extension
    to Ripe-181. Technical report, July 1995. Available as
    ftp://ftp.isi.edu/rps/doc/aspath.txt.gz.
[2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg,
    M. Terpstra, and J. Yu. Representation of IP Routing Policies in a
    Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam,
    Netherlands, October 1994.

[3] E. Chen and T. Bates. Destination Preference Attribute for BGP.
    Internet Draft draft-ietf-idr-bgp-dpa-02.txt, July 1995.

[4] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Request for
    Comment RFC-1654, Network Information Center, July 1994.


Author's Present Addresses

Cengiz Alaettinoglu
Information Sciences Institute
University of Southern California
Marina del Rey, CA 90292
e-mail:  cengiz@isi.edu


Cengiz Alaettinoglu              Expires  May 17, 1996              [Page 3]