idnits 2.17.1 draft-zhou-idr-bgp-srmpls-elp-02.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 date (February 22, 2021) is 1158 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-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Yao. Liu 3 Internet-Draft Shaofu. Peng 4 Intended status: Standards Track ZTE Corp. 5 Expires: August 26, 2021 February 22, 2021 7 BGP Extension for SR-MPLS Entropy Label Position 8 draft-zhou-idr-bgp-srmpls-elp-02 10 Abstract 12 This document proposes extensions for BGP to indicate the entropy 13 label position in the SR-MPLS label stack when distributing SR Policy 14 candidate paths. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 26, 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions used in this document . . . . . . . . . . . . . . 3 52 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 54 3. Entropy Labels in SR-MPLS Scenario with a Controller . . . . 3 55 4. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 8.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 Segment Routing (SR) leverages the source routing paradigm. Segment 67 Routing can be instantiated on MPLS data plane which is referred to 68 as SR-MPLS [RFC8660]. SR-MPLS leverages the MPLS label stack to 69 construct the SR path. 71 Entropy labels (ELs) [RFC6790] are used in the MPLS data plane to 72 provide entropy for load-balancing. The idea behind the entropy 73 label is that the ingress router computes a hash based on several 74 fields from a given packet and places the result in an additional 75 label named "entropy label". Then, this entropy label can be used as 76 part of the hash keys used by an LSR. Using the entropy label as 77 part of the hash keys reduces the need for deep packet inspection in 78 the LSR while keeping a good level of entropy in the load-balancing. 80 [RFC8662] proposes to use entropy labels for SR-MPLS networks and 81 mutiple < ELI, EL> pairs may be inserted in the SR-MPLS label stack. 82 The ingress node may decide the number and position of the ELI/ELs 83 which need to be inserted into the label stack, that is termed as ELP 84 (Entropy Label Position). In some cases, centralized controllers are 85 used to perform the TE path computation for intra or inter-domain 86 scenarios, thus it is also the responsibility of the controller to 87 calculate ELP and inform it to the headend of the SR-TE path. 89 [I-D.ietf-idr-segment-routing-te-policy] defines the specific process 90 of how the controller/PCE in the SR network passes the path 91 calculation result of the SR-TE policy to the headend of the network 92 through BGP. 94 This document proposes extensions for BGP to indicate the ELP in the 95 segment list when distribute SR Policy candidate paths using BGP for 96 SR-MPLS networks. 98 2. Conventions used in this document 100 2.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 2.2. Terminology and Acronyms 110 EL: Entropy Label 112 ELI: Entropy Label Indicator 114 ELC: Entropy Label Capability 116 ERLD: Entropy Readable Label Depth 118 ELP: Entropy Label Position 120 MSD: Maximum SID Depth 122 3. Entropy Labels in SR-MPLS Scenario with a Controller 124 [RFC8662] proposes to use entropy labels for SR-MPLS networks. The 125 Entropy Readable Label Depth (ERLD) is defined as the number of 126 labels which means that the router will perform load-balancing using 127 the ELI/EL. An appropriate algorithm should consider the following 128 criteria: 130 o a limited number of < ELI, EL> pairs SHOULD be inserted in the SR- 131 MPLS label stack; 133 o the inserted positions SHOULD be whithin the ERLD of a maximize 134 number of transit LSRs; 136 o a minimum number of < ELI, EL> pairs SHOULD be inserted while 137 satisfying the above criteria. 139 As shown in Figure 1, in SR-MPLS inter-domain scenario, an path from 140 A to Z is required, a centralized controller performs the computation 141 of the end-to-end path, along which traffic load-balancing is 142 required. The controller can also be used to perform the computation 143 of the the Entropy Label Position (ELP) of the segment list that 144 corresponds to the path. The ELP includs the number and the position 145 of the ELI/ELs. 147 Multiple limitations MUST be taken into account by the controller 148 during path calculation, including Entropy Readable Label Depth 149 (ERLD) and Maximum SID Depth (MSD) etc. The ERLD is defined as the 150 number of labels which means that the node will perform load- 151 balancing using the ELI/EL pairs. And each ELI/EL pair must be 152 within the ERLD of the node. The Maximum SID Depth (MSD) defines the 153 maximum number of any kind of labels(service, entropy, transport, 154 etc.) and it is a limit when the ingress node imposing ELI/EL pairs 155 on the SR label stack. 157 The controller can get ERLD value and MSD via protocols. The ERLD 158 value can be advertised via IS-IS[I-D.ietf-isis-mpls-elc], 159 OSPF[I-D.ietf-ospf-mpls-elc], BGP- 160 LS[I-D.ietf-idr-bgp-ls-segment-routing-ext]. [RFC8476], [RFC8491], 161 and[RFC8814] provide examples of advertisement of the MSD. 163 As specified in section 7.2 [RFC8662], other criteria includes 164 segment type, preference for a part of the path, and etc. It's a 165 matter of implementation. 167 .................... .................... ..................... 168 . . . . . . 169 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 170 .| A |-------| B |------ | C |------| X |-------| Y |------| Z | . 171 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 172 . domain 1 . . domain 2 . . domain 3 . 173 .................... .................... ..................... 175 Figure 1: Entropy Labels in SR-MPLS Inter-Domain Scenario 177 4. BGP Extensions 179 The Segment Flags for Segment Sub-TLVs are defined in 180 Section 2.4.4.2.12 of [I-D.ietf-idr-segment-routing-te-policy]. In 181 this document, the ELP information is transmitted by extending the 182 flags of Segment Sub-TLVs. 184 0 1 2 3 4 5 6 7 185 +-+-+-+-+-+-+-+-+ 186 |V|A|S|B|E| | 187 +-+-+-+-+-+-+-+-+ 189 E-Flag: This flag, when set, indicates that presence of < ELI, EL> 190 label pairs which are inserted after this segment. E-Flag is 191 applicable to Segment Types A, C, D, E, F, G and H. If E-Flag 192 appears with Segment Types B, I, J and K, it MUST be ignored. . 194 5. Operations 196 Node A receives an SR Policy NLRI with an Segment List sub-TLV from 197 the controller. The Segment List sub-TLV contains multiple Segment 198 sub-TLVs, for example, , the E-Flags of S3 199 and S6 are set, it indicates that if load-balancing is required, two 200 pairs SHOULD be inserted into the label stack of the SR-TE 201 forwarding entry, respectively after the Label for S3 and Label for 202 S6. 204 The value of EL is supplemented by the ingress node according to 205 load-balancing function of the appropriate keys extracted from a 206 given packet. After inserting ELI/ELs, the label stack on the 207 ingress node would be . 210 6. Security Considerations 212 TBD 214 7. IANA Considerations 216 This document requests bit 4 for Entropy Label Flag. 218 Bit Description Reference 219 ------------------------------------------------------------------ 220 4 Entropy Label Position Flag(E-Flag) This document 222 8. References 224 8.1. Normative References 226 [I-D.ietf-idr-segment-routing-te-policy] 227 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 228 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 229 Routing Policies in BGP", draft-ietf-idr-segment-routing- 230 te-policy-11 (work in progress), November 2020. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 238 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 239 RFC 6790, DOI 10.17487/RFC6790, November 2012, 240 . 242 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 243 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 244 May 2017, . 246 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 247 Shakir, R., and J. Tantsura, "Entropy Label for Source 248 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 249 DOI 10.17487/RFC8662, December 2019, 250 . 252 8.2. Informative References 254 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 255 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 256 and M. Chen, "BGP Link-State extensions for Segment 257 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 258 (work in progress), June 2019. 260 [I-D.ietf-isis-mpls-elc] 261 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 262 and M. Bocci, "Signaling Entropy Label Capability and 263 Entropy Readable Label Depth Using IS-IS", draft-ietf- 264 isis-mpls-elc-13 (work in progress), May 2020. 266 [I-D.ietf-ospf-mpls-elc] 267 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 268 and M. Bocci, "Signaling Entropy Label Capability and 269 Entropy Readable Label Depth Using OSPF", draft-ietf-ospf- 270 mpls-elc-15 (work in progress), June 2020. 272 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 273 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 274 DOI 10.17487/RFC8476, December 2018, 275 . 277 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 278 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 279 DOI 10.17487/RFC8491, November 2018, 280 . 282 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 283 Decraene, B., Litkowski, S., and R. Shakir, "Segment 284 Routing with the MPLS Data Plane", RFC 8660, 285 DOI 10.17487/RFC8660, December 2019, 286 . 288 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 289 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 290 Using the Border Gateway Protocol - Link State", RFC 8814, 291 DOI 10.17487/RFC8814, August 2020, 292 . 294 Authors' Addresses 296 Liu Yao 297 ZTE Corp. 299 Email: liu.yao71@zte.com.cn 301 Peng Shaofu 302 ZTE Corp. 304 Email: peng.shaofu@zte.com.cn