BGP-LS Extensions for Advertising Path MTU
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|Authors||Yongqing Zhu , Zhibo Hu, Shuping Peng , Robbins Mwehair , Edmore Chingwena|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Network Working Group Y. Zhu Internet-Draft China Telecom Intended status: Standards Track Z. Hu Expires: January 14, 2021 S. Peng Huawei Technologies R. Mwehaire MTN Uganda Ltd. E. Chingwena MTN Cameroon Ltd. July 13, 2020 BGP-LS Extensions for Advertising Path MTU draft-zhu-idr-bgp-ls-path-mtu-03 Abstract BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture with no change on the forwarding plane and applied to the IPv6 architecture, with a new type of routing header, called SRH. The SR uses the IGP protocol as the control protocol. Compared to the MPLS tunneling technology, the SR does not require additional signaling. Therefore, the SR does not support the negotiation of the Path MTU. Since Multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path mtu of SR tunnel. This document specify the extension to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The PCE/SDN calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. Requirements Language 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 RFC 2119 [RFC2119]. Zhu, et al. Expires January 14, 2021 [Page 1] Internet-Draft BGP-LS Extensions for Advertising Path MTU July 2020 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 January 14, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deploying scenarios . . . . . . . . . . . . . . . . . . . . . 4 3. BGP_LS Extensions for Path MTU . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Zhu, et al. Expires January 14, 2021 [Page 2] Internet-Draft BGP-LS Extensions for Advertising Path MTU July 2020 1. Introduction [RFC7752]describes the implementation mechanism of BGP-LS by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol [RFC4271]. BGP-LS allows the necessary Link-State Database (LSDB) and Traffic Engineering Database (TEDB) information to be collected from the IGP within the network, filtered according to configurable policy, and distributed to the PCE as necessary. The appropriate MTU size guarantees efficient data transmission. If the MTU size is too small and the packet size is large, fragmentation may occur too much and packets are discarded by the QoS queue. If the MTU configuration is too large, packet transmission may be slow. PathMTU is the maximum length of a packet that can pass through a path without fragmentation. [RFC1191] describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. The traditional MPLS tunneling technology has signaling for establishing a path. [RFC3988] defines the mechanism for automatically discovering the Path MTU of LSPs of LDP tunnels. For a certain FEC, the LSR compares the MTU advertised by all downstream devices with the MTU of the FEC output interface in the local device, and calculates the minimum value for the upstream device. [RFC3209] specify the mechanism of MTU signaling in RSVP-TE. The ingress node of the RSVP-TE tunnel sends a Path message to the downstream device. The Adspec object in the Path message carries the MTU. Each node along the tunnel receives a Path message, compares the MTU value in the Adspec object with the interface MTU value and MPLS MTU configured on the physical output interface of the local tunnel , obtains the minimum MTU value, and puts it into the newly constructed Path message and continues to send it to the downstream equipment. Thus, the MTU carried in the Path message received by the Egress node is the minimum value of the path MTU. The Egress node brings the negotiated Path MTU back to the Ingress node through the Resv message. Segment Routing (SR) described in [RFC8402] leverages the source routing paradigm. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane [RFC8660] and applied to the IPv6 architecture with a new type of routing header called the SR header (SRH) [I-D.ietf-6man-segment-routing-header]. [I-D.ietf-idr-bgp-ls-segment-routing-ext] defines SR extensions to BGP-LS and specifies the TLVs and sub-TLVs for advertising SR Zhu, et al. Expires January 14, 2021 [Page 3] Internet-Draft BGP-LS Extensions for Advertising Path MTU July 2020 information. Based on the SR information reported by the BGP-LS, the SDN can calculate the end-to-end explicit SR-TE paths or SR Policies. Nevertheless, Segment Routing is a tunneling technology based on the IGP protocol as the control protocol, and there is no additional signaling for establishing the path. so the Segment Routing tunnel cannot currently support the negotiation mechanism of the MTU. Multiple labels or SRv6 SIDs are pushed in the packets. This causes the length of the packets encapsulated in the Segment Routing tunnel to increase during packet forwarding. This is more likely to cause packet size exceed than traditional MPLS packet size. This document specify the extension to BGP Link State (BGP-LS) to carry link maximum transmission unit (MTU) messages. 2. Deploying scenarios This document suggests a solution to extension to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages. The MTU information of the link is acquired through the process of collecting link state and TE information by BGP-LS. Concretely, a router maintains one or more databases for storing link-state information about nodes and links in any given area. The router's BGP process can retrieve topology from these LSDBs and distribute it to a consumer, either directly or via a peer BGP speaker (typically a dedicated Route Reflector). [RFC7176] specifies the ISIS mechanism and extensions for link MTU Sub-TLV. As per [RFC7752], the collection of link-state and TE information and its distribution to consumers is shown in the following figure. Zhu, et al. Expires January 14, 2021 [Page 4] Internet-Draft BGP-LS Extensions for Advertising Path MTU July 2020 +-----------+ | Consumer | +-----------+ ^ | +-----------+ | BGP | +-----------+ | Speaker | | Consumer | +-----------+ +-----------+ ^ ^ ^ ^ | | | | +---------------+ | +-------------------+ | | | | | +-----------+ +-----------+ +-----------+ | BGP | | BGP | | BGP | | Speaker | | Speaker | . . . | Speaker | +-----------+ +-----------+ +-----------+ ^ ^ ^ | | | IGP IGP IGP Figure 1: Collection of Link-State and TE Information 3. BGP_LS Extensions for Path MTU [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link NLRI or a Prefix NLRI. The corresponding BGP-LS attribute is a Node Attribute, a Link Attribute or a Prefix Attribute. [RFC7752] defines the TLVs that map link-state information to BGP-LS NLRI and the BGP- LS attribute. Therefore, according to this document, a new sub TLV is added to the Link Attribute TLV. The format of the sub-TLV is as shown below. x TYPE - TBD x LENGTH - Total length of the value field, it should be 2 x VALUE - 2-byte MTU value of the link No. of Octets +-----------------+ | MTU value | 2 +-----------------+ Figure 2. Sub-TLV Format for MTU Zhu, et al. Expires January 14, 2021 [Page 5] Internet-Draft BGP-LS Extensions for Advertising Path MTU July 2020 Whenever there is a change in MTU value represented by Link Attribute TLV, BGP-LS should re-originate the respective TLV with the new MTU value. 4. IANA Considerations This document requests assigning a new code-points from the BGP-LS Link Descriptor and Attribute TLVs registry as specified in sections 3. 5. Security Considerations This document does not introduce security issues beyond those discussed in RFC7752. 6. Acknowledgements 7. Contributors Gang Yan Huawei China Email:email@example.com Junda Yao Huawei China Email:firstname.lastname@example.org 8. References 8.1. Normative References [RFC2119] 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>. 8.2. Informative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-26 (work in progress), October 2019. Zhu, et al. Expires January 14, 2021 [Page 6] Internet-Draft BGP-LS Extensions for Advertising Path MTU July 2020 [I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 (work in progress), June 2019. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>. [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, <https://www.rfc-editor.org/info/rfc3988>. [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>. [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <https://www.rfc-editor.org/info/rfc7176>. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>. Zhu, et al. Expires January 14, 2021 [Page 7] Internet-Draft BGP-LS Extensions for Advertising Path MTU July 2020 Authors' Addresses Yongqing Zhu China Telecom 109, West Zhongshan Road, Tianhe District. Guangzhou 510000 China Email: email@example.com Zhibo Hu Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: firstname.lastname@example.org Shuping Peng Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: email@example.com Robbins Mwehaire MTN Uganda Ltd. Uganda Email: Robbins.Mwehair@mtn.com Edmore Chingwena MTN Cameroon Ltd. Cameroon Email: Edmore.Chingwena@mtn.com Zhu, et al. Expires January 14, 2021 [Page 8]