Signalling Path MTU via BGP Attributes

Internet-Draft	BGP MTU Attribute	December 2024
Misell, et al.	Expires 15 June 2025	[Page]

Discussion

This note is to be removed before publishing as an RFC.¶

Source for this draft and an issue tracker can be found at https://github.com/TheEnbyperor/draft-blahaj-idr-bgp-mtu.¶

A ford of BIRD implementing this draft can be found at https://github.com/theenbyperor/bird.¶

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 15 June 2025.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

To help achieve the highest possible MTU end-to-end, this document extends BGP-4 to aid network operators in this effort by signalling the MTU for each route.¶

A new BGP capability declaring the link MTU is specified in Section 4.¶

An optional, non-transitive attribute, called "Path MTU", is specified in Section 5. It allows network administrators to use Path MTU in their route selection. The main focus/applicability is the Internet (IPv4 and IPv6 unicast route advertisements).¶

The BGP attribute defined in this document can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC4760]). Usage of this BGP attribute for other Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations is not defined herein but may be specified in future specifications.¶

1.1. Requirements Language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [BCP14] (RFC2119,RFC8174) when, and only when, they appear in all capitals, as shown here.¶

1.2. Terminology

The terms "MTU" in this document signifies the Maximum Transmission Unit for a given BGP address family.¶

2. Assumptions

All MTU values are measured in bytes at layer 3.¶

Each BGP speaker is configured with the following values:¶

Link MTU: Maximum packet size the BGP speaker can process through its own ASN¶
Fallback MTU: Maximum packet size if no per-route information is supplied (usually 1500 bytes)¶

It is also assumed that the FIB used by the BGP speaker supports per-destination MTU values, such as is the case for the Linux kernel.¶

3. Theory of Operation

A BGP speaker advertises the link MTU capability as follows:¶

The link MTU capability is announced only if a BGP speaker understands the Path MTU route attribute¶
The link MTU capability is set to the configured local Link MTU, as defined above¶

When establishing a session with a peer, a BGP speaker does the following:¶

If the peer advertises the link MTU capability, compute the effective link MTU as the minimum of the locally configured link MTU and the link MTU advertised by the peer¶
If the peer link MTU is different from the local link MTU, an implementation SHOULD emit a warning¶

When announcing a route:¶

If the session does not have an effective link MTU, then this part is ignored.¶
Otherwise, if the route already has a path MTU attribute¶
- If the effective link MTU is smaller than the value in the attribute, update the path MTU value in the attribute to the value of the effective link MTU¶
- Leave the origin ASN in the attribute as-is¶
If the route does not already have a path MTU attribute, add a new attribute with¶
- The MTU value set to the effective link MTU¶
- The ASN set to the local ASN¶

When installing a route into the FIB:¶

If the route has no path MTU attribute, install the route with the fallback MTU.¶
If the ASN appearing in the path MTU attribute is different from the originating ASN from the AS path, ignore the attribute and install the route with the fallback MTU.¶
Otherwise, compute the route MTU as the minimum of the effective link MTU and the value in the path MTU attribute, and install the route with this route MTU.¶

4. Link MTU Capability

A new BGP capability with ID XXX is defined with the following contents:¶

0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|fl.|          Link MTU         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags: 2 bits; flags are reserved for future use and MUST be 0.¶
Link MTU: 14 bits; The BGP speakers MTU for the link a BGP session is being negotiated over.¶

5. Path MTU Attribute

A new optional, non-transitive BGP attribute with ID XXX is defined with the following contents:¶

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Origin ASN                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|fl.|          Path MTU         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Origin ASN: 32 bits; the first ASN along the path to support this attribute.¶
Flags: 2 bits; flags are reserved for future use and MUST be 0.¶
Link MTU: 14 bits; The MTU for a route.¶

6. IANA Considerations

6.1. Capability

Per this document, IANA is requested to add one new entry to the "Capability Codes" registry defined in [RFC5492]. This entry is defined below:¶

Table 1: New entries
Value	Description	Reference
TBD	Link MTU	This document

6.2. Path Attribute

Per this document, IANA is requested to add one new entry to the "BGP Path Attributes" registry defined in [RFC4271]. This entry is defined below:¶

Table 2: New entries
Value	Code	Reference
TBD	Path MTU	This document

7. References

7.1. Normative References

[BCP14]: Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC4271]: Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4760]: Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC5492]: Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.