BGP Available Paths Count Extended Community

Introduction This document defines a new BGP Opaque Extended Community to carry the number of paths available for an arbitrary prefix. BGP speakers that receive this extended community can configure local instance to influence their decision process by preferring routes with a higher number of paths over others. defines a BGP extension to send multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. However, if the ADD-PATH capability is not possible to use between BGP speakers, Available Paths Count Extended Community can be another way to prefer a prefix which has more paths.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Available Paths Count Extended Community This is an Transitive Opaque Extended Community with the following encoding:

The value of the high-order octet of the extended Type field is 0x03, which indicates it is transitive.
The value of the low-order octet of the extended Type field as assigned by IANA is TBD.
Reserved field MUST be set to 0 and ignored upon the receipt of this community.
The last octet of the extended community is an unsigned integer that gives the count of the available paths for an arbitrary prefix.

Deployment Considerations If the BGP speaker supports the extension defined in this document, it SHOULD attach the Available Paths Count Extended Community to BGP UPDATE messages sent to iBGP peers implicitly. The receiving BGP speaker, SHOULD derive a count of available paths from the last octet of the extended community if present. An implementation SHOULD NOT send more than one instance of the Available Paths Count extended community. By default, an implementation SHOULD NOT send this extended community to eBGP peers. However, it SHOULD be possible to configure an implementation to send or accept the community when configured. The implementation SHOULD provide a way to explicitly disable sending this community. Also, the implementation could provide an OPTIONAL way to involve Available Paths Count Extended Community into the best path selection process. The prefix with the higher count of paths SHOULD win. If at least one of the routes does not have Available Paths Count Extended Community, the best path selection process is not affected, and this step is ignored. If both routes have the community, defined in this extension, the normal BGP decision is changed so that the Available Paths Count Extended Community is checked before Multi Exit Discriminator (MED). It MUST be possible to enable or disable this extra step (comparing Available Paths Count Extended Community) in the best path selection process. If the count of paths changed, the implementation SHOULD NOT send an UPDATE immediately. Available Paths Count Extended Community SHOULD be adjusted only when the best path changes.

IANA Considerations This memo requests IANA assign a number from the Transitive Opaque Extended Community Sub-Types registry for "Available Paths Count" extended community. Registration procedures come under the First Come First Served.