idnits 2.17.1 draft-zhu-idr-bgp-ls-path-mtu-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 30, 2018) is 2098 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Zhu 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Hu 5 Expires: January 1, 2019 G. Yan 6 J. Yao 7 Huawei Technologies 8 June 30, 2018 10 BGP-LS Extensions for Advertising Path MTU 11 draft-zhu-idr-bgp-ls-path-mtu-00 13 Abstract 15 BGP Link State (BGP-LS) describes a mechanism by which link-state and 16 TE information can be collected from networks and shared with 17 external components using the BGP routing protocol. The centralized 18 controller (PCE/SDN) completes the service path calculation based on 19 the information transmitted by the BGP-LS and delivers the result to 20 the Path Computation Client (PCC) through the PCEP protocol. 22 Segment Routing (SR) leverages the source routing paradigm, which can 23 be directly applied to the MPLS architecture with no change on the 24 forwarding plane and applied to the IPv6 architecture, with a new 25 type of routing header, called SRH. The SR uses the IGP protocol as 26 the control protocol. Compared to the MPLS tunneling technology, the 27 SR does not require signaling. Therefore, the SR does not support 28 the negotiation of the Path MTU. Since Multiple labels or SRv6 SIDs 29 are pushed in the packets, it is more likely that the MTU exceeds the 30 limit in the SR tunneling technology. 32 This document specify the extension to BGP Link State (BGP-LS) to 33 carry maximum transmission unit (MTU) messages. The PCE/SDN 34 calculates the Path MTU while completing the service path calculation 35 based on the information transmitted by the BGP-LS. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on January 1, 2019. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 78 2. Deploying scenarios . . . . . . . . . . . . . . . . . . . . . 4 79 3. BGP_LS Extensions for Path MTU . . . . . . . . . . . . . . . 5 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 85 7.2. Informative References . . . . . . . . . . . . . . . . . 6 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 88 1. Introduction 90 [RFC7752]describes the implementation mechanism of BGP-LS by which 91 link-state and TE information can be collected from networks and 92 shared with external components using the BGP routing protocol 93 [RFC4271]. BGP-LS allows the necessary Link-State Database (LSDB) 94 and Traffic Engineering Database (TED) information to be collected 95 from the IGP within the network, filtered according to configurable 96 policy, and distributed to the PCE as necessary. 98 The appropriate MTU size guarantees efficient data transmission. If 99 the MTU size is too small and the packet size is large, fragmentation 100 may occur too much and packets are discarded by the QoS queue. If 101 the MTU configuration is too large, packet transmission may be slow. 102 PathMTU is the maximum length of a packet that can pass through a 103 path without fragmentation. [RFC1191] describes a technique for 104 dynamically discovering the maximum transmission unit (MTU) of an 105 arbitrary internet path. 107 The traditional MPLS tunneling technology has signaling for 108 establishing a path. [RFC3988] defines the mechanism for 109 automatically discovering the Path MTU of LSPs of LDP tunnels. For a 110 certain FEC, the LSR compares the MTU advertised by all downstream 111 devices with the MTU of the FEC output interface in the local device, 112 and calculates the minimum value for the upstream device. 114 [RFC3209] specify the mechanism of MTU signaling in RSVP-TE. The 115 ingress node of the RSVP-TE tunnel sends a Path message to the 116 downstream device. The Adspec object in the Path message carries the 117 MTU. Each node along the tunnel receives a Path message, compares 118 the MTU value in the Adspec object with the interface MTU value and 119 MPLS MTU configured on the physical output interface of the local 120 tunnel , obtains the minimum MTU value, and puts it into the newly 121 constructed Path message and continues to send it to the downstream 122 equipment. Thus, the MTU carried in the Path message received by the 123 Egress node is the minimum value of the path MTU. The Egress node 124 brings the negotiated Path MTU back to the Ingress node through the 125 Resv message. 127 Segment Routing (SR) described in [I-D.ietf-spring-segment-routing] 128 leverages the source routing paradigm. Segment Routing can be 129 directly applied to the MPLS architecture with no change on the 130 forwarding plane [I-D.ietf-spring-segment-routing-mpls] and applied 131 to the IPv6 architecture with a new type of routing header called the 132 SR header (SRH) [I-D.ietf-6man-segment-routing-header]. 133 [I-D.ietf-idr-bgp-ls-segment-routing-ext] defines SR extensions to 134 BGP-LS and specifies the TLVs and sub-TLVs for advertising SR 135 information. Based on the SR information reported by the BGP-LS, the 136 SDN can calculate the end-to-end explicit SR-TE paths or SR Policies. 138 Nevertheless, Segment Routing is a tunneling technology based on the 139 IGP protocol as the control protocol, and there is no signaling for 140 establishing the path. so the Segment Routing tunnel cannot currently 141 support the negotiation mechanism of the MTU. Multiple labels or 142 SRv6 SIDs are pushed in the packets. This causes the length of the 143 packets encapsulated in the Segment Routing tunnel to increase during 144 packet forwarding. This is more likely to cause MTU overrun than 145 traditional MPLS. 147 This document specify the extension to BGP Link State (BGP-LS) to 148 carry maximum transmission unit (MTU) messages. 150 2. Deploying scenarios 152 This document suggests a solution to extension to BGP Link State 153 (BGP-LS) to carry maximum transmission unit (MTU) messages. The MTU 154 information of the link is acquired through the process of collecting 155 link state and TE information by BGP-LS. Concretely, a router 156 maintains one or more databases for storing link-state information 157 about nodes and links in any given area. The router's BGP process 158 can retrieve topology from these LSDBs and distribute it to a 159 consumer, either directly or via a peer BGP speaker (typically a 160 dedicated Route Reflector). As for how IGP collects link MTU 161 information and stores it in LSDB, which is beyond the scope of this 162 article. 164 As per [RFC7752], the collection of link-state and TE information and 165 its distribution to consumers is shown in the following figure. 167 +-----------+ 168 | Consumer | 169 +-----------+ 170 ^ 171 | 172 +-----------+ 173 | BGP | +-----------+ 174 | Speaker | | Consumer | 175 +-----------+ +-----------+ 176 ^ ^ ^ ^ 177 | | | | 178 +---------------+ | +-------------------+ | 179 | | | | 180 +-----------+ +-----------+ +-----------+ 181 | BGP | | BGP | | BGP | 182 | Speaker | | Speaker | . . . | Speaker | 183 +-----------+ +-----------+ +-----------+ 184 ^ ^ ^ 185 | | | 186 IGP IGP IGP 188 Figure 1: Collection of Link-State and TE Information 190 3. BGP_LS Extensions for Path MTU 192 [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link 193 NLRI or a Prefix NLRI. The corresponding BGP-LS attribute is a Node 194 Attribute, a Link Attribute or a Prefix Attribute. [RFC7752] defines 195 the TLVs that map link-state information to BGP-LS NLRI and the BGP- 196 LS attribute. Therefore, according to this document, a new sub TLV 197 is added to the Link Attribute TLV. 199 The format of the sub-TLV is as shown below. 201 x TYPE - TBD 202 x LENGTH - Total length of the value field, it should be 2 203 x VALUE - 2-byte MTU value of the link 205 No. of Octets 206 +-----------------+ 207 | MTU value | 2 208 +-----------------+ 210 Figure 2. Sub-TLV Format for MTU 212 Whenever there is a change in MTU value represented by Link Attribute 213 TLV, BGP-LS should re-originate the respective TLV with the new MTU 214 value. 216 4. IANA Considerations 218 This document requests assigning a new code-points from the BGP-LS 219 Link Descriptor and Attribute TLVs registry as specified in sections 220 3. 222 5. Security Considerations 224 This document does not introduce security issues beyond those 225 discussed in RFC7752. 227 6. Acknowledgements 229 The authors of this document would like to thank Gang Yan, Peng Wu, 230 Zhenbin Li and Gang Zhao for their comments. 232 7. References 234 7.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, 238 DOI 10.17487/RFC2119, March 1997, 239 . 241 7.2. Informative References 243 [I-D.ietf-6man-segment-routing-header] 244 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 245 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 246 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 247 progress), June 2018. 249 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 250 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 251 and M. Chen, "BGP Link-State extensions for Segment 252 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 253 (work in progress), May 2018. 255 [I-D.ietf-spring-segment-routing] 256 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 257 Litkowski, S., and R. Shakir, "Segment Routing 258 Architecture", draft-ietf-spring-segment-routing-15 (work 259 in progress), January 2018. 261 [I-D.ietf-spring-segment-routing-mpls] 262 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 263 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 264 data plane", draft-ietf-spring-segment-routing-mpls-14 265 (work in progress), June 2018. 267 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 268 DOI 10.17487/RFC1191, November 1990, 269 . 271 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 272 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 273 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 274 . 276 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 277 Signalling Extensions for the Label Distribution 278 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 279 . 281 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 282 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 283 DOI 10.17487/RFC4271, January 2006, 284 . 286 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 287 S. Ray, "North-Bound Distribution of Link-State and 288 Traffic Engineering (TE) Information Using BGP", RFC 7752, 289 DOI 10.17487/RFC7752, March 2016, 290 . 292 Authors' Addresses 294 Yongqing Zhu 295 China Telecom 296 109, West Zhongshan Road, Tianhe District. 297 Guangzhou 510000 298 China 300 Email: zhuyq@gsta.com 302 Zhibo Hu 303 Huawei Technologies 304 Huawei Bld., No.156 Beiqing Rd. 305 Beijing 100095 306 China 308 Email: huzhibo@huawei.com 310 Gang Yan 311 Huawei Technologies 312 Huawei Bld., No.156 Beiqing Rd. 313 Beijing 100095 314 China 316 Email: yangang@huawei.com 318 Junda Yao 319 Huawei Technologies 320 Huawei Bld., No.156 Beiqing Rd. 321 Beijing 100095 322 China 324 Email: yaojunda@huawei.com