"Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version", Jeffrey Haas, 18-Feb-09. ( bytes)

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4.

"Dissemination of flow specification rules", Pedro Roque Marques, Nischal Sheth, Robert Raszuk, Barry Greene, Jared Mauch, Danny McPherson, 26-May-09. ( bytes)

This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements.

"Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 26-Jan-09. ( bytes)

Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice.

"Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4)", Jeffrey Haas, 18-Feb-09. ( bytes)

This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations.

"BGP Support for Four-octet AS Number Space", Quaizar Vohra, Enke Chen, 17-Apr-09. ( bytes)

Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity.

"Error Handling for Optional Transitive BGP Attributes", John Scudder, Enke Chen, 16-Apr-09. ( bytes)

According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable in the case of optional transitive attributes. This document revises BGP's error-handling rules for optional transitive attributes, and provides guidelines for the authors of documents defining new optional transitive attributes. It also revises the error handling procedures for several existing optional transitive attributes.

"BGP Link Bandwidth Extended Community", Pradosh Mohapatra, Rex Fernando, 21-Apr-09. ( bytes)

This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing.

"The Accumulated IGP Metric Attribute for BGP", Rex Fernando, Pradosh Mohapatra, Eric Rosen, James Uttaro, 8-May-09. ( bytes)

Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so.

"Advertisement of the best external route in BGP", Pedro Roque Marques, Rex Fernando, Enke Chen, Pradosh Mohapatra, 14-May-09. ( bytes)

The base BGP specifications prevent a BGP speaker from advertising any route that is not the best route for a BGP destination. This document specifies a modification of this rule. Routes are divided into two categories, "external" and "internal". A specification is provided for choosing a "best external route" (for a particular value of the Network Layer Reachability Information). A BGP speaker is then allowed to advertise its "best external route" to its internal BGP peers, even if that is not the best route for the destination. The document explains why advertising the best external route can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. The document also generalizes the notions of "internal" and "external" so that they can be applied to Route Reflector Clusters and Autonomous System Confederations.

Return to Internet-Draft directory.

Return to IETF home page.