Skip to main content

Constrain Attribute announcement within BGP
draft-keyupate-idr-bgp-attribute-announcement-01

Document Type Replaced Internet-Draft (idr WG)
Expired & archived
Authors Keyur Patel , Jim Uttaro , Bruno Decraene , Wim Henderickx , Jeffrey Haas
Last updated 2016-09-17 (Latest revision 2016-03-16)
Replaced by draft-ietf-idr-bgp-attribute-announcement
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state Adopted by a WG
Document shepherd (None)
IESG IESG state Replaced by draft-ietf-idr-bgp-attribute-announcement
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

[RFC4271] defines four different categories of BGP Path attributes. The different Path attribute categories can be identified by the attribute flag values. These flags help identify if an attribute is optional or well-known, Transitive or non-Transitive, Partial, or of an Extended length type. BGP attribute announcement depends on whether an attribute is a well-known or optional, and whether an attribute is a transitive or non-transitive. BGP implementations MUST recognize all well-known attributes. The well-known attributes are always Transitive. It is not required for BGP implementations to recognise all the Optional attributes. The Optional attributes could be Transitive or Non-Transitive. BGP implementations MUST store and forward any Unknown Optional Transitive attributes and ignore and drop any Unknown Optional Non-Transitive attributes. Currently, there is no way to confine the scope of Path attributes within a given Autonomous System (AS) or a given BGP member-AS in Confederation. This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation

Authors

Keyur Patel
Jim Uttaro
Bruno Decraene
Wim Henderickx
Jeffrey Haas

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)