Internet-Draft BGP Available Paths Count Extended Commu January 2023
White & Abraitis Expires 13 July 2023 [Page]
Workgroup:
Interdomain Routing
Published:
Intended Status:
Standards Track
Expires:
Authors:
R. White
Akamai, Inc.
D. Abraitis
NetDef

BGP Available Paths Count Extended Community

Abstract

This document defines a new BGP Opaque Extended Community to carry the number of paths available for an arbitrary prefix.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on 13 July 2023.

Table of Contents

1. 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.

[RFC7911] 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.

2. Specification of Requirements

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 [RFC2119].

3. Available Paths Count Extended Community

This is an Transitive Opaque Extended Community [RFC4360] with the following encoding:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       0x03    |      TBD      |             Reserved          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Reserved                   |     Count     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
  1. The value of the high-order octet of the extended Type field is 0x03, which indicates it is transitive.
  2. The value of the low-order octet of the extended Type field as assigned by IANA is TBD.
  3. Reserved field MUST be set to 0 and ignored upon the receipt of this community.
  4. The last octet of the extended community is an unsigned integer that gives the count of the available paths for an arbitrary prefix.

4. 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.

5. 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.

6. Normative References

[RFC2119]
Bradner, S. and RFC Publisher, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4360]
Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, , <https://www.rfc-editor.org/info/rfc4360>.
[RFC7911]
Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, , <https://www.rfc-editor.org/info/rfc7911>.

Authors' Addresses

Russ White
Akamai, Inc.
Donatas Abraitis
NetDef