idnits 2.17.1 draft-peng-lsr-flex-algo-l2bundles-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: For example, three Flex-algo plane share the same Layer 3 parrent interface including three L2 Bundle Members each with color "RED", "GREEN", "BLUE" respectively, and each Flex-algo plane with link selection rule "Include-Any RED", "Include-Any GREEN", "Include-Any BLUE" respectively, Flex-algo SHOULD not simply select the Layer 3 parrent interface to all Flex-algo plane, but need continue to select individual L2 Bundle Member to the specific Flex-algo plane. As a reslut, the FIB entry within Flex-algo RED plane will exactly choose the L2 Bundle Members with color "RED" to forward packets, the FIB entry within Flex-algo GREEN plane will exactly choose the L2 Bundle Members with color "GREEN" to forward packets, and the FIB entry within Flex-algo BLUE plane will exactly choose the L2 Bundle Members with color "BLUE" to forward packets. -- The document date (March 30, 2020) is 1488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4915' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 240, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-06 == Outdated reference: A later version (-02) exists of draft-ketant-lsr-ospf-l2bundles-01 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L P. Shaofu 3 Internet-Draft C. Ran 4 Intended status: Informational ZTE Corporation 5 Expires: October 1, 2020 G. Mirsky 6 ZTE Corp. 7 March 30, 2020 9 IGP Flexible Algorithm with L2bundles 10 draft-peng-lsr-flex-algo-l2bundles-01 12 Abstract 14 IGP Flex Algorithm proposes a solution that allows IGPs themselves to 15 compute constraint based paths over the network, and it also 16 specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 17 locators to steer packets along the constraint-based paths. This 18 document describes how to create Flex-algo plane with L2bundles 19 scenario. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 1, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Color set on L2 Bundle Member . . . . . . . . . . . . . . . . 3 58 4. Flex-algo plane with L2 link resource . . . . . . . . . . . . 3 59 4.1. Best-effort . . . . . . . . . . . . . . . . . . . . . . . 3 60 4.2. Traffic Engineering . . . . . . . . . . . . . . . . . . . 4 61 5. IGP L2 Bundle Member EAG advertisement . . . . . . . . . . . 4 62 5.1. ISIS L2 Bundle Member EAG advertisement . . . . . . . . . 4 63 5.2. OSPF L2 Bundle Member EAG advertisement . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] proposes a solution that 73 allows IGPs themselves to compute constraint based paths over the 74 network, and it also specifies a way of using Segment Routing (SR) 75 Prefix-SIDs and SRv6 locators to steer packets along the constraint- 76 based paths. It specifies a set of extensions to ISIS, OSPFv2 and 77 OSPFv3 that enable a router to send TLVs that identify (a) 78 calculation-type, (b) specify a metric-type, and (c )describe a set 79 of constraints on the topology, that are to be used to compute the 80 best paths along the constrained topology. A given combination of 81 calculation-type, metric-type, and constraints is known as an FAD 82 (Flexible Algorithm Definition). 84 [RFC8668] and [I-D.ketant-lsr-ospf-l2bundles] introduces the ability 85 for IS-IS and OSPF respectively to advertise the link attributes of 86 Layer 2 (L2) Bundle Members. Especially, the link attribute 87 "Administrative Group" and "Extended Administrative Group" could be 88 individual to each L2 Bundle Member for purpose of Flex-algo plane 89 construction, where multiple Flex-algo planes share the same Layer 3 90 parent interface and each Flex-algo plane has dedicated L2 Bundle 91 Member. 93 This document describes how to create Flex-algo plane with L2bundles 94 scenario. 96 2. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 3. Color set on L2 Bundle Member 106 Traffic Engineering affinity (also termed as Color) is often to be 107 set on the Layer 3 interface and be flooded by IGP-TE. However, when 108 the Layer 3 interface is a Layer 2 interface bundle, operators can 109 config individual color for each L2 Bundle Member. So that IGP link- 110 state database will contain the TE affinity attribute of L2 Bundle 111 Member, as well as Layer 3 parrent interface. 113 Note that Layer 3 interface can join to IGP instance explicitly, but 114 L2 Bundle Member not. 116 The TE affinity of the Layer 3 parrent interface can be a combined 117 value of all L2 Bundle Members. For example, if the Layer 3 parrent 118 interface contains three L2 Bundle Members, each with color "RED", 119 "GREEN", "BLUE" respectively, the Layer 3 parrent interface will have 120 color "RED|GREEN|BLUE". 122 4. Flex-algo plane with L2 link resource 124 4.1. Best-effort 126 [I-D.ietf-lsr-flex-algo] defines the color-based link resource 127 selection rules in FAD to construct the expected Flex-algo plane. 128 Each node in the Flex-algo plane will establish the SPT with self as 129 root node, to maintain the best path to other nodes and get the FIB 130 entry based on that. The root node need check the outgoing Layer 2 131 interface bundle interface, to see which L2 Bundle Member does 132 exactly belong to the Flex-algo plane. The forwarding information of 133 the FIB entry with outgoing Layer 2 interface bundle interface will 134 exactly select the L2 Bundle Member that belongs to the Flex-algo 135 plane to forward packets. 137 For example, three Flex-algo plane share the same Layer 3 parrent 138 interface including three L2 Bundle Members each with color "RED", 139 "GREEN", "BLUE" respectively, and each Flex-algo plane with link 140 selection rule "Include-Any RED", "Include-Any GREEN", "Include-Any 141 BLUE" respectively, Flex-algo SHOULD not simply select the Layer 3 142 parrent interface to all Flex-algo plane, but need continue to select 143 individual L2 Bundle Member to the specific Flex-algo plane. As a 144 reslut, the FIB entry within Flex-algo RED plane will exactly choose 145 the L2 Bundle Members with color "RED" to forward packets, the FIB 146 entry within Flex-algo GREEN plane will exactly choose the L2 Bundle 147 Members with color "GREEN" to forward packets, and the FIB entry 148 within Flex-algo BLUE plane will exactly choose the L2 Bundle Members 149 with color "BLUE" to forward packets. 151 4.2. Traffic Engineering 153 A segment list contains SIDs advertised specifically for the given 154 algorithm is possible, such as an inter-domain path contains multiple 155 Flex-algo planes, a TI-LFA backup path within the Flex-algo plane, or 156 an optimized TE path avoiding congested link within the Flex-algo 157 plane. In these cases, an Adjacency segment could be used to steer 158 the packets along the expected L2 Bundle Member that belongs to the 159 specific Flex-algo plane. 161 [RFC8668] and [I-D.ketant-lsr-ospf-l2bundles] have defined Adjacency- 162 SID for each L2 Bundle Member, that can be used to isolate flows 163 among multiple Flex-algo planes, when these Flex-algo planes share 164 the same Layer 3 parrent interface. A specific Adjacency-SID for a 165 specific L2 Bundle Member will steer the packets to that member. 167 5. IGP L2 Bundle Member EAG advertisement 169 5.1. ISIS L2 Bundle Member EAG advertisement 171 [RFC8668] defined TLV-25 for ISIS to advertise the link attributes of 172 L2 Bundle Members, and mentioned that the traditional "Administrative 173 group (color) Sub-TLV" and "Extended Administrative Group Sub-TLV" 174 may appear in TLV-25 and MAY be shared by multiple L2 Bundle Members. 175 If we want to advertise unique EAG values for each bundle member, we 176 can use multiple L2 Bundle Attribute Descriptors with each specify a 177 single bundle member. 179 5.2. OSPF L2 Bundle Member EAG advertisement 181 [I-D.ketant-lsr-ospf-l2bundles] defined "L2 Bundle Member Attributes 182 sub-TLV" for OSPF/OSPFv3 to advertise the link attributes of L2 183 Bundle Members, and mentioned that the traditional "Administrative 184 group (color) Sub-TLV" and "Extended Administrative Group Sub-TLV" 185 are applicable in "L2 Bundle Member Attributes sub-TLV". Because 186 there is "L2 Bundle Member Attributes sub-TLV" per L2 Bundle Member, 187 it is also sufficient to construct Flex-algo plane to select L2 link 188 resource. 190 6. IANA Considerations 192 This document need not define new sub-TLV to IGP for Flex-algo 193 combined with l2bundles. 195 7. Security Considerations 197 There are no new security issues introduced by the extensions in this 198 document. 200 8. Acknowledgements 202 TBD 204 9. Normative References 206 [I-D.ietf-lsr-flex-algo] 207 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 208 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 209 algo-06 (work in progress), February 2020. 211 [I-D.ketant-lsr-ospf-l2bundles] 212 Talaulikar, K. and P. Psenak, "Advertising L2 Bundle 213 Member Link Attributes in OSPF", draft-ketant-lsr-ospf- 214 l2bundles-01 (work in progress), January 2020. 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 222 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 223 RFC 4915, DOI 10.17487/RFC4915, June 2007, 224 . 226 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 227 Topology (MT) Routing in Intermediate System to 228 Intermediate Systems (IS-ISs)", RFC 5120, 229 DOI 10.17487/RFC5120, February 2008, 230 . 232 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 233 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 234 . 236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 238 May 2017, . 240 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 241 Decraene, B., Litkowski, S., and R. Shakir, "Segment 242 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 243 July 2018, . 245 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 246 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 247 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 248 December 2019, . 250 Authors' Addresses 252 Peng Shaofu 253 ZTE Corporation 254 No.68 Zijinghua Road, Yuhuatai District 255 Nanjing 256 China 258 Email: peng.shaofu@zte.com.cn 260 Chen Ran 261 ZTE Corporation 262 No.50 Software Avenue, Yuhuatai District 263 Nanjing 264 China 266 Email: chen.ran@zte.com.cn 268 Greg Mirsky 269 ZTE Corp. 271 Email: gregimirsky@gmail.com