idnits 2.17.1 draft-peng-lsr-flex-algo-l2bundles-05.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 (December 7, 2020) is 1230 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-lsr-flex-algo-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L Y. Zhu 3 Internet-Draft China telecom 4 Intended status: Standards Track S. Peng 5 Expires: June 10, 2021 R. Chen 6 ZTE Corporation 7 G. Mirsky 8 ZTE Corp. 9 December 7, 2020 11 IGP Flexible Algorithm with L2bundles 12 draft-peng-lsr-flex-algo-l2bundles-05 14 Abstract 16 IGP Flex Algorithm proposes a solution that allows IGPs themselves to 17 compute constraint based paths over the network, and it also 18 specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 19 locators to steer packets along the constraint-based paths. This 20 document describes how to create Flex-algo plane with L2bundles 21 scenario. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 10, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Color set on L2 Bundle Member . . . . . . . . . . . . . . . . 3 60 4. Flex-algo plane with L2 link resource . . . . . . . . . . . . 3 61 4.1. Best-effort . . . . . . . . . . . . . . . . . . . . . . . 3 62 4.2. Traffic Engineering . . . . . . . . . . . . . . . . . . . 4 63 5. Flex-algo L2bundles Use-cases . . . . . . . . . . . . . . . . 5 64 5.1. Flex-algo L2bundles Examples . . . . . . . . . . . . . . 5 65 6. IGP L2 Bundle Member Extensions . . . . . . . . . . . . . . . 6 66 6.1. ISIS L2 Bundle Member EAG advertisement . . . . . . . . . 6 67 6.2. OSPF L2 Bundle Member EAG advertisement . . . . . . . . . 6 68 6.3. FAD Flags Extensions . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] proposes a solution that 78 allows IGPs themselves to compute constraint based paths over the 79 network, and it also specifies a way of using Segment Routing 80 [RFC8402] Prefix-SIDs and SRv6 locators to steer packets along the 81 constraint-based paths. It specifies a set of extensions to ISIS, 82 OSPFv2 and OSPFv3 that enable a router to send TLVs that identify (a) 83 calculation-type, (b) specify a metric-type, and (c )describe a set 84 of constraints on the topology, that are to be used to compute the 85 best paths along the constrained topology. A given combination of 86 calculation-type, metric-type, and constraints is known as an FAD 87 (Flexible Algorithm Definition). 89 [RFC8668] and [I-D.ketant-lsr-ospf-l2bundles] introduces the ability 90 for IS-IS and OSPF respectively to advertise the link attributes of 91 Layer 2 (L2) Bundle Members. Especially, the link attribute 92 "Administrative Group" and "Extended Administrative Group" could be 93 individual to each L2 Bundle Member for purpose of Flex-algo plane 94 construction, where multiple Flex-algo planes share the same Layer 3 95 parent interface and each Flex-algo plane has dedicated L2 Bundle 96 Member. 98 This document describes how to create Flex-algo plane with L2bundles 99 scenario. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Color set on L2 Bundle Member 111 Traffic Engineering affinity (also termed as Color) is often to be 112 set on the Layer 3 interface and be flooded by IGP-TE. However, when 113 the Layer 3 interface is a Layer 2 interface bundle, operators can 114 config individual color for each L2 Bundle Member. So that IGP link- 115 state database will contain the TE affinity attribute of L2 Bundle 116 Member, as well as Layer 3 parrent interface. 118 Note that Layer 3 interface can join to IGP instance explicitly, but 119 L2 Bundle Member not. 121 The TE affinity of the Layer 3 parrent interface can be a combined 122 value of all L2 Bundle Members. For example, if the Layer 3 parrent 123 interface contains three L2 Bundle Members, each with color "RED", 124 "GREEN", "BLUE" respectively, the Layer 3 parrent interface will have 125 color "RED|GREEN|BLUE". 127 4. Flex-algo plane with L2 link resource 129 4.1. Best-effort 131 [I-D.ietf-lsr-flex-algo] defines the color-based link resource 132 selection rules in FAD to construct the expected Flex-algo plane. 133 Each node in the Flex-algo plane will maintain the best path to other 134 destination nodes. In the case of L2bundles scenario, each node need 135 check the outgoing Layer 2 bundle interface, to see which L2 Bundle 136 Member does exactly belong to the Flex-algo plane. 138 For the node who originate the l2-bundle interface, the forwarding 139 information of the FIB entry with outgoing Layer 2 bundle interface 140 will exactly select the L2 Bundle Member that belongs to the Flex- 141 algo plane to forward packets. 143 For example, three Flex-algo plane share the same Layer 3 parrent 144 interface including three L2 Bundle Members each with color "RED", 145 "GREEN", "BLUE" respectively, and each Flex-algo plane with link 146 selection rule "Include-Any RED", "Include-Any GREEN", "Include-Any 147 BLUE" respectively, Flex-algo SHOULD NOT simply select the Layer 3 148 parrent interface for all Flex-algo plane, but need continue to 149 select individual L2 Bundle Member for each specific Flex-algo plane. 150 As a reslut, the FIB entry within Flex-algo RED plane will exactly 151 choose the L2 Bundle Members with color "RED" to forward packets, the 152 FIB entry within Flex-algo GREEN plane will exactly choose the L2 153 Bundle Members with color "GREEN" to forward packets, and the FIB 154 entry within Flex-algo BLUE plane will exactly choose the L2 Bundle 155 Members with color "BLUE" to forward packets. 157 The above processing is a local optimization for each node who 158 originate l2-bundle interface. 160 In addition, for a remote node which received l2-bundle advertisement 161 originated from other nodes, if that l2-bundle is in the flex-algo 162 based path to a destination node, it must confirm which L2 Bundle 163 Member belongs to the flex-algo plane and check that L2 Bundle Member 164 really meets the constraints defined in the related FAD. This 165 processing is necessary when Flex-algo is used to optimize SID stack 166 depth for an SR-TE policy, e.g, the SR-TE policy defines TE affinity 167 to select individual L2 Bundle Member and the SID list may contain 168 Adjacency-SID for a specific L2 Bundle Member as described in 169 [RFC8668] and [I-D.ketant-lsr-ospf-l2bundles]. Thus the flex-algo 170 based path must be consistent with the original path of the optimized 171 SR-TE policy, i.e, within the flex-algo plane when each node 172 determine its next-hop towards a destination, the determination must 173 be based on the above confirmation and check of L2 Bundle Members. 175 4.2. Traffic Engineering 177 A segment list contains SIDs advertised specifically for the given 178 algorithm is possible, such as an inter-domain path contains multiple 179 Flex-algo domains, a TI-LFA backup path within the Flex-algo plane, 180 or an optimized TE path avoiding congested link within the Flex-algo 181 plane. When the headend or controller compute these SR-TE paths 182 within the specific flex-algo plane, in addition to the algorithm 183 based Prefix-SID towards the loose node, an Adjacency-SID can also be 184 used to strictly steer the packets along the expected L3 link. 185 However, if the L3 link is a l2-bundle interface, it is necessary to 186 see which L2 Bundle Member exactly belongs to the specific Flex-algo 187 plane and use the Adjacency-SID for that member. 189 [RFC8668] and [I-D.ketant-lsr-ospf-l2bundles] have defined Adjacency- 190 SID for each L2 Bundle Member, that can be used to isolate flows 191 among multiple Flex-algo planes, when these Flex-algo planes share 192 the same Layer 3 parrent interface. A specific Adjacency-SID for a 193 specific L2 Bundle Member can be contained in the SID list of the SR 194 path within the flex-algo plane and steer the packets to that member. 196 5. Flex-algo L2bundles Use-cases 198 In some operator's networks, a large number of bundled links are 199 deployed to improve the bandwidth. However, for a specific l2bundle, 200 each member has different capabilities, such as different delay, 201 bandwidth, AG/EAG, etc. When the path of an SR policy needs to go 202 through an Layer 2 interface bundle, operators want to choose the 203 individual member link to meet business requirements. Different SR 204 policy may choose different member links, according to different set 205 of constraints. 207 When Flex algorithm is enabled in the above networks, even all flex- 208 algo planes share all Layer 2 interface bundles, i.e, all FA planes 209 have the same structure, an important requirement to Flex-algo is 210 that the constraint based computation of Flex-algo must consider how 211 to select member links to meet service's criterias. In addition, 212 different flex-algo planes can also have different structures, with 213 different set of nodes and links, to meet more strict business 214 requirements. 216 The extended behavior of flex-algo introduced in this document can 217 meet the above requirement, and exactly it is independent with the 218 structure of flex-algo plane. 220 5.1. Flex-algo L2bundles Examples 222 Let's describe the requirement with the following example. 224 S======A=====B======C=====D 225 \ / 226 \___________E__________/ 228 Figure 1: Flex-algo L2bundles Example 230 An SR policy from headend S to endpoint D is created, with color 231 template {min delay}. Suppose the macthed link is the upper member 232 link of l2bundles interface between S-A, A-B, B-C, C-D. All of them 233 have delay 10ms. So that the computed segment list would be . 237 Suppose the delay of the lower member link of l2bundles interface 238 between S-A, A-B, B-C, C-D are all 100ms. That means the delay of 239 the bundles L3 interface between S-A, A-B, B-C, C-D are all 100ms 240 (i.e, subject to the member who have the largest delay). Also 241 suppose the delay of the L3 link between S-E, E-D are all 50ms. 243 If flex-algo (eg, algorithm 128) is enabled in the above network to 244 optimize the stack depth of the above SR polcy, the related FAD would 245 also be {min delay}. However, if all nodes in the network only see L3 246 interface resouce, then at node S the computed result to destination 247 D would be next-hop E, and at node E the computed result to 248 destination D would be next-hop D. Obviously, after stack 249 optimization the flex-algo path S-E-D is not consistent with the 250 original path (S-A-B-C-D) of SR policy. 252 Thus it will be benefit for flex-algo to see L2 member link during 253 CSPF computation. And, each node in the network, instead of only 254 headend, must perform the same behavior to check L2 member link 255 resouce, otherwise there may be a loop. 257 6. IGP L2 Bundle Member Extensions 259 6.1. ISIS L2 Bundle Member EAG advertisement 261 [RFC8668] defined TLV-25 for ISIS to advertise the link attributes of 262 L2 Bundle Members, and mentioned that the traditional "Administrative 263 group (color) Sub-TLV" and "Extended Administrative Group Sub-TLV" 264 may appear in TLV-25 and MAY be shared by multiple L2 Bundle Members. 265 If we want to advertise unique EAG values for each bundle member, we 266 can use multiple L2 Bundle Attribute Descriptors with each specify a 267 single bundle member. So it is sufficient to construct Flex-algo 268 plane to select L2 link resource. 270 6.2. OSPF L2 Bundle Member EAG advertisement 272 [I-D.ketant-lsr-ospf-l2bundles] defined "L2 Bundle Member Attributes 273 sub-TLV" for OSPF/OSPFv3 to advertise the link attributes of L2 274 Bundle Members, and mentioned that the traditional "Administrative 275 group (color) Sub-TLV" and "Extended Administrative Group Sub-TLV" 276 are applicable in "L2 Bundle Member Attributes sub-TLV". Because 277 there is "L2 Bundle Member Attributes sub-TLV" per L2 Bundle Member, 278 it is also sufficient to construct Flex-algo plane to select L2 link 279 resource. 281 6.3. FAD Flags Extensions 283 A new flag (L-flag) is introduced to both ISIS Flexible Algorithm 284 Definition Flags Sub-TLV and OSPF Flexible Algorithm Definition Flags 285 Sub-TLV (defined in [I-D.ietf-lsr-flex-algo]), to let each node to 286 check L2 member link resouce of interface bundle during flex- 287 algorithm path calculation. 289 0 1 2 3 4 5 6 7... 290 +-+-+-+-+-+-+-+-+... 291 |M|L| | ... 292 +-+-+-+-+-+-+-+-+... 294 Figure 2 296 where: 298 L-flag: introduced by this document. When set, the traffic 299 engineering resouce or attributes of L2 member link of interface 300 bundle MUST be checked and used during flex-algorithm path 301 calculation. 303 7. IANA Considerations 305 This document need not define new sub-TLV to IGP for Flex-algo 306 combined with l2bundles. 308 8. Security Considerations 310 There are no new security issues introduced by the extensions in this 311 document. 313 9. Acknowledgements 315 TBD 317 10. Normative References 319 [I-D.ietf-lsr-flex-algo] 320 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 321 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 322 algo-13 (work in progress), October 2020. 324 [I-D.ketant-lsr-ospf-l2bundles] 325 Talaulikar, K. and P. Psenak, "Advertising L2 Bundle 326 Member Link Attributes in OSPF", draft-ketant-lsr-ospf- 327 l2bundles-02 (work in progress), June 2020. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 335 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 336 May 2017, . 338 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 339 Decraene, B., Litkowski, S., and R. Shakir, "Segment 340 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 341 July 2018, . 343 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 344 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 345 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 346 December 2019, . 348 Authors' Addresses 350 Yongqing Zhu 351 China telecom 353 Email: zhuyq8@chinatelecom.cn 355 Shaofu Peng 356 ZTE Corporation 357 No.68 Zijinghua Road, Yuhuatai District 358 Nanjing 359 China 361 Email: peng.shaofu@zte.com.cn 363 Ran Chen 364 ZTE Corporation 365 No.50 Software Avenue, Yuhuatai District 366 Nanjing 367 China 369 Email: chen.ran@zte.com.cn 371 Greg Mirsky 372 ZTE Corp. 374 Email: gregimirsky@gmail.com