[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 RFC 3765

Internet Engineering Task Force                            Geoff. Huston
Internet Draft                                                   Telstra
Document: draft-ietf-ptomaine-nopeer-00.txt                   April 2002
                                                   Expires: October 2002


              NOPEER community for BGP route scope control

Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026 [1].

    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.

    Comments on this draft should be directed to gih@telstra.net.

Abstract

    This document proposes the use of a scope control BGP community.
    This proposed well-known advisory transitive community is intended
    to allow an origin AS to specify the extent to which a specific
    route should be externally propagated. In particular this community,
    termed here as NOPEER, allows an origin AS to specify that a route
    with this attribute need not be advertised across bilateral peer
    connections.

1. Introduction

    BGP today has a limited number of commonly defined mechanisms that
    allow a route to be propagated across some subset of the routing
    system. The NOEXPORT community allows a BGP speaker to specify that
    redistribution should extend only to the neighbouring AS. Providers
    commonly define a number of communities that allow their neighbours
    to specify how advertised routes should be re-advertised. Current



Huston                                                          [Page 1]


Internet Draft                   NOPEER                       April 2002


    operational practice is that such communities are defined on as AS
    by AS basis, and while they allow an AS to influence the re-
    advertisement behaviour of routes passed from a neighbouring AS,
    they do not allow this scope definition ability to be passed in a
    transitive fashion to a remote AS.

    Advertisement scope specification is of most use in specifying the
    boundary conditions of route propagation. The specification can take
    on a number of forms, including as AS transit hop count, a set of
    target ASs, the presence of a particular route object, or a
    particular characteristic of the inter-AS connection.

    There are a number of motivations for controlling the scope of
    advertisement of route prefixes, including support of limited
    transit services where advertisements are restricted to certain
    transit providers, and various forms of selective transit in a
    multi-homed environment.

    This proposal does not attempt to address all such motivations of
    scope control, and addresses in particular the situation of both
    multi-homing and traffic engineering. The commonly adopted
    operational technique is that the originating AS advertises an
    encompassing aggregate route to all multi-home neighbours, and also
    selectively advertises a collection of more specific routes. This
    implements a form of destination-based traffic engineering with some
    level of fail over protection. The more specific routes typically
    cease to lever any useful traffic engineering outcome beyond a
    certain radius of redistribution, and a means of advising that such
    routes need not to be distributed beyond such a point is of some
    value in moderating one of the factors of continued route table
    growth.

    Analysis of the BGP routing tables reveals a significant use of the
    technique of advertising more specific prefixes in addition to
    advertising a covering aggregate. In an effort to ameliorate some of
    the effects of this practice, in terms of overall growth of the BGP
    routing tables in the Internet and the associated burden of global
    propagation of dynamic changes in the reachability of such more
    specific address prefixes, this draft proposes the use of a
    transitive BGP route attribute that is intended to allow more
    specific route tables entries to be discarded from the BGP tables
    under appropriate conditions. Specifically, this attribute, NOPEER,
    allows a remote AS not to advertise a route object to a neighbour AS
    when the two AS's are interconnected under the conditions of some
    form of sender keep all arrangement, as distinct from some form of
    provider / customer arrangement.

2. Proposal



Huston                                                          [Page 2]


Internet Draft                   NOPEER                       April 2002


    The proposal is to define a new well-known bgp transitive community,
    NOPEER.

    The intended semantics of this attribute is to allow an AS to
    interpret the presence of this community as an advisory
    qualification to re advertisement of a route prefix, permitting an
    AS not to re advertise the route prefix to all external bilateral
    peer neighbour AS's. It is consistent with the intended semantics
    that an AS may filter received prefixes that are received across a
    peering session that the receiver regards as a bilateral peer
    sessions.

3. Motivation

    The size of the BGP routing table has been increasing at an
    accelerating rate since late 1998. At the time of writing (April
    2002) the BGP forwarding table contains over 100,000 entries, and
    the three year growth rate of this table shows a trend rate which
    can be correlated to a compound growth rate of no less than 40% per
    year [2].

    One of the aspects of the current BGP routing table is the
    widespread use of the technique of advertising both an aggregate and
    a number of more specific address prefixes. For example, the table
    may contain a routing entry for the prefix 10.0.0.0/23 and also
    contain entries for the prefixes 10.0.0.0/24 and 10.0.1.0/24. In
    this example the specific routes fully cover the aggregate
    announcement. Sparse coverage of aggregates with more specifics is
    also observed, where, for example, routing entries for 10.0.0.0/8
    and 10.0.1.0/24 both exist in the routing table. In total, these
    more specific route entries occupy some 52% of the routing table[3],
    so that more than one half of the routing table does not add
    additional address reachability information into the routing system,
    but instead is used to impose a finer level of detail on existing
    reachability information.

    There are a number of motivations for having both an aggregate route
    and a number of more specific routes in the routing table, including
    various forms of multi-homed configurations, where there is a
    requirement to specify a different reachability policy for a part of
    the advertised address space.

    One of the observed common requirements in the multi-homed network
    configuration is that of undertaking some form of load balancing of
    incoming traffic across a number of external connections to a number
    of different neighbouring ASs. If, for example, an AS wishes to use
    a multi-homed configuration for routing-based load balancing and
    some form of mutual fail over between the multiple access



Huston                                                          [Page 3]


Internet Draft                   NOPEER                       April 2002


    connections for incoming traffic, then one approach is for the AS to
    advertise the same aggregate address prefix to a number of its
    upstream transit providers, and then advertise a number of more
    specifics to individual upstream providers. In such a case all of
    the traffic destined to the more specific address prefixes will be
    received only over those connections where the more specific has
    been advertised. If the neighbour BGP peering session of the more
    specific advertisement fails, the more specific will cease to be
    announced and incoming traffic will then be passed to the
    originating network based on the path associated with the
    advertisement of the encompassing aggregate. In this situation the
    more specific routes are not automatically subsumed by the presence
    of the aggregate at any remote AS. Both the aggregate and the
    associated more specifics are redistributed across the entire
    external BGP routing domain. In many cases, particularly those
    associated with desire to undertake traffic engineering and service
    resilience, the more specific routes are redistributed well beyond
    the scope where there is any outcomes in terms of traffic
    differentiation.

    To the extent that remote analysis of BGP tables can observe this
    form of configuration, the number of entries in the BGP forwarding
    table where more specific entries share a common origin AS with
    their immediately enclosing aggregates comprise some 20% of the
    total number of FIB entries. Using a slightly stricter criteria
    where the AS path of the more specific route matches the immediately
    enclosing aggregate, the number of more specific routes comprises
    some 13% of the number of FIB entries [3].

    One protocol mechanism that could be useful in this context is to
    allow the originator of an advertisement to state some additional
    qualification on the redistribution of the advertisement, allowing a
    remote AS to suppress further redistribution under some originator-
    specified criteria.

    The redistribution qualification condition can be specified either
    by enumeration or by classification. Enumeration would encompass the
    use of a well-known transitive extended community to specify a list
    of remote AS's where further redistribution is not advised. The
    weakness of this approach is that the originating AS would need to
    constantly revise this enumerated AS list to reflect the changes in
    inter-AS topology, as, otherwise, the more specific routes would
    leak beyond the intended redistribution scope. An approach of
    classification allows an originating AS to specify the conditions
    where further redistribution is not advised without having to refer
    to the particular AS's where a match to such conditions are
    anticipated.




Huston                                                          [Page 4]


Internet Draft                   NOPEER                       April 2002


    The approach proposed here to specifying the redistribution boundary
    condition is one based on the type of bilateral inter-AS peering.
    Where one AS can be considered as a customer, and the other AS can
    be considered as a contracted agent of the customer, or provider,
    then the relationship is one where the provider, as an agent of the
    customer, carries the routes and associated policy associated with
    the routes. Where neither AS can be considered as a customer of the
    other, then the relationship is one of bilateral peering, and
    neither AS can be considered as an agent of the other in
    redistributing policies associated with routes. This latter
    arrangement is commonly referred to as a "sender keep all peer"
    relationship, or "peering". This peer boundary can be regarded as a
    logical point where the redistribution of additional reachability
    policy imposed by the origin AS on a route is no longer an imposed
    requirement.

    This approach allows an originator of a prefix to attach a commonly
    defined policy to a route prefix, indicate that a route should be
    re-advertised conditionally, based on the characteristics of the
    inter-AS connection.

4. IANA considerations

    Adoption of this proposal would imply the request to IANA for the
    registration of a new BGP well-known transitive community field from
    IANA.

5. Security considerations

    This proposal has the capability to introduce additional security
    concerns into BGP by allowing the potential for denial of service
    attacks for an address prefix range being launched by a remote AS.

    Unauthorized addition of this community to a route prefix by a
    transit provider where this is no covering aggregate route prefix
    may cause a denial of service attack based on denial of reachability
    to the prefix. Even in the case that there is a covering aggregate,
    if the more specific route has a different origin AS than the
    aggregate, the addition of this community by a transit AS may cause
    a denial of service attack on the origin AS of the more specific
    prefix.

    BGP is already vulnerable to a denial of service attack based on the
    injection of false routing information. It is possible to use this
    community to limit the redistribution of a false route entry such
    that its visibility can be limited and detection and rectification
    of the problem can be more difficult under the circumstances of
    limited redistribution.



Huston                                                          [Page 5]


Internet Draft                   NOPEER                       April 2002


References

    [1] "The Internet Standards Process -- Revision 3", S. Bradner, RFC
        2026, October 1996.

        [2] "Commentary in Inter-Domain Routing in the Internet", G.
        Huston, RFC 3221, December 2001.

        [3] Analysis of BGP table data - http://bgp.potaroo.net

Author's Address

        Geoff Huston
        Telstra
        Email: gih@telstra.net




































Huston                                                          [Page 6]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/