--- 1/draft-ietf-lsr-flex-algo-07.txt 2020-07-10 06:13:12.553391172 -0700 +++ 2/draft-ietf-lsr-flex-algo-08.txt 2020-07-10 06:13:12.621392893 -0700 @@ -1,24 +1,24 @@ Network Working Group P. Psenak, Ed. Internet-Draft Cisco Systems Intended status: Standards Track S. Hegde -Expires: October 3, 2020 Juniper Networks, Inc. +Expires: January 11, 2021 Juniper Networks, Inc. C. Filsfils K. Talaulikar Cisco Systems, Inc. A. Gulko - Thomson Reuters - April 1, 2020 + Refinitiv + July 10, 2020 IGP Flexible Algorithm - draft-ietf-lsr-flex-algo-07.txt + draft-ietf-lsr-flex-algo-08.txt Abstract IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to enforce traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document proposes a solution that allows IGPs themselves to compute constraint based paths over the network. This document also specifies a way of using @@ -33,21 +33,21 @@ 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 October 3, 2020. + This Internet-Draft will expire on January 11, 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 @@ -56,21 +56,21 @@ 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. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Flexible Algorithm . . . . . . . . . . . . . . . . . . . . . 5 - 5. Flexible Algorithm Definition Advertisement . . . . . . . . . 5 + 5. Flexible Algorithm Definition Advertisement . . . . . . . . . 6 5.1. ISIS Flexible Algorithm Definition Sub-TLV . . . . . . . 6 5.2. OSPF Flexible Algorithm Definition TLV . . . . . . . . . 7 5.3. Common Handling of Flexible Algorithm Definition TLV . . 9 6. Sub-TLVs of ISIS FAD Sub-TLV . . . . . . . . . . . . . . . . 10 6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV . . . 10 6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV . 11 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV . 11 6.4. ISIS Flexible Algorithm Definition Flags Sub-TLV . . . . 11 6.5. ISIS Flexible Algorithm Exclude SRLG Sub-TLV . . . . . . 12 7. Sub-TLVs of OSPF FAD TLV . . . . . . . . . . . . . . . . . . 13 @@ -85,44 +85,48 @@ 10.1. Advertisement of Node Participation for Segment Routing 18 10.2. Advertisement of Node Participation for Other Applications . . . . . . . . . . . . . . . . . . . . . . 19 11. Advertisement of Link Attributes for Flex-Algorithm . . . . . 19 12. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 20 12.1. Multi-area and Multi-domain Considerations . . . . . . . 21 13. Flex-Algorithm and Forwarding Plane . . . . . . . . . . . . . 22 13.1. Segment Routing MPLS Forwarding for Flex-Algorithm . . . 22 13.2. SRv6 Forwarding for Flex-Algorithm . . . . . . . . . . . 23 13.3. Other Applications' Forwarding for Flex-Algorithm . . . 24 - 14. Backward Compatibility . . . . . . . . . . . . . . . . . . . 24 - 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 16.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 25 - 16.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 25 - 16.1.2. Flexible Algorithm Definition Metric-Type Registry . 25 - 16.2. Flex-Algorithm Definition Flags Registry . . . . . . . . 26 - 16.3. ISIS IANA Considerations . . . . . . . . . . . . . . . . 26 - 16.3.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . 26 - 16.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 . . . . 26 - 16.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub- - TLV . . . . . . . . . . . . . . . . . . . . . . . . 26 - 16.4. OSPF IANA Considerations . . . . . . . . . . . . . . . . 27 - 16.4.1. OSPF Router Information (RI) TLVs Registry . . . . . 27 - 16.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs . . . . . . . . 28 - 16.4.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . 28 - 16.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV - Registry . . . . . . . . . . . . . . . . . . . . . . 28 - 16.4.5. Link Attribute Applications Registry . . . . . . . . 29 - 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 - 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 18.1. Normative References . . . . . . . . . . . . . . . . . . 30 - 18.2. Informative References . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + 14. Operational considerations . . . . . . . . . . . . . . . . . 24 + 14.1. Inter-area Considerations . . . . . . . . . . . . . . . 24 + 14.2. Usage of SRLG Exclude Rule with Flex-Algorithm . . . . . 25 + 14.3. Max-metric consideration . . . . . . . . . . . . . . . . 26 + 15. Backward Compatibility . . . . . . . . . . . . . . . . . . . 26 + 16. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 17.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 27 + 17.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 27 + 17.1.2. IGP Metric-Type Registry . . . . . . . . . . . . . . 27 + 17.2. Flex-Algorithm Definition Flags Registry . . . . . . . . 27 + 17.3. ISIS IANA Considerations . . . . . . . . . . . . . . . . 28 + 17.3.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . 28 + 17.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 . . . . 28 + 17.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub- + TLV . . . . . . . . . . . . . . . . . . . . . . . . 28 + 17.4. OSPF IANA Considerations . . . . . . . . . . . . . . . . 29 + 17.4.1. OSPF Router Information (RI) TLVs Registry . . . . . 29 + 17.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs . . . . . . . . 30 + 17.4.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . 30 + 17.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV + Registry . . . . . . . . . . . . . . . . . . . . . . 30 + 17.4.5. Link Attribute Applications Registry . . . . . . . . 31 + 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 19.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 19.2. Informative References . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction An IGP computed path based on the shortest IGP metric must often be replaced by a traffic engineered path due to the traffic requirements which are not reflected by the IGP metric. Some networks engineer the IGP metric assignments in a way that the IGP Metric reflects the link bandwidth or delay. If, for example, the IGP metric is reflecting the bandwidth on the link and the application traffic is delay sensitive, the best IGP path may not reflect the best path from @@ -923,21 +926,21 @@ definition. If such exclude rule exists, check if any color that is part of the exclude rule is also set on the link. If such a color is set, the link MUST be pruned from the computation. 2. Check if any exclude SRLG rule is part of the Flex-Algorithm definition. If such exclude rule exists, check if the link is part of any SRLG that is also part of the SRLG exclude rule. If the link is part of such SRLG, the link MUST be pruned from the computation. - 4. Check if any include-any rule is part of the Flex-Algorithm + 3. Check if any include-any rule is part of the Flex-Algorithm definition. If such include-any rule exists, check if any color that is part of the include-any rule is also set on the link. If no such color is set, the link MUST be pruned from the computation. 4. Check if any include-all rule is part of the Flex-Algorithm definition. If such include-all rule exists, check if all colors that are part of the include-all rule are also set on the link. If all such colors are not set on the link, the link MUST be pruned from the computation. @@ -1095,66 +1098,148 @@ 13.3. Other Applications' Forwarding for Flex-Algorithm Any application that wants to use Flex-Algorithm specific forwarding needs to install some form of Flex-Algorithm specific forwarding entries. Application specific forwarding for Flex-Algorithm MUST be defined for each application and is outside of the scope of this document. -14. Backward Compatibility +14. Operational considerations + +14.1. Inter-area Considerations + + The scope of the FA computation is an area, so is the scope of the + FAD. In ISIS the Router Capability TLV in which the FAD Sub-TLV is + present MUST have the S-bit clear, which prevents it to be flooded + outside of level in which it was originated. Even though in OSPF the + FAD Sub-TLV can be flooded in the RI LSA that has AS flooding scope, + the FAD selection is performed for individual area in which it is + being used. + + There is no requirement for FAD for a particular Flex-Algorithm to be + identical in all areas in the network. For example, traffic for the + same Flex-Algorithm may be optimized for minimal delay (e.g., using + delay metric) in one area or level, while being optimized for + available bandwidth (e.g., using IGP metric) in the other area or + level. + + As described in Section 5.1, ISIS allows the re-generation of the + winning FAD from level 2, without any modification to it, into a + level 1 area. This allows the operator to configure the FAD in one + or multiple routers in the level 2, without the need to repeat the + same task in each level 1 area, if the intent is to have the same FAD + for the particular Flex-Algorithm across all levels. Similar can be + achieved in OSPF by using the AS flooding scope of the RI LSA in + which the FAD Sub-TLV for the particular Flex-Algoritm is advertised. + + Re-generation of FAD from level 1 area to level 2 area is not + supported in ISIS, so if the intent is to regenerate the FAD between + ISIS levels, the FAD MUST be defined on router(s) that are in level + 2. In OSPF the FAD definition can be done in any area and be + propagated to all router in AS by the AS flooding scope of the RI + LSA. + +14.2. Usage of SRLG Exclude Rule with Flex-Algorithm + + There are two different ways in which SRLG information can be used + with Flex-Algorithm: + + In a context of a single Flex-Algorithm, it can be used for + computation of backup paths, as described in + [I-D.ietf-rtgwg-segment-routing-ti-lfa]. This usage does not + require association of any specific SRLG constraint with the given + Flex-Algorithm definition. + + In the context of multiple Flex-Algorithms, it can be used for + creating disjoint sets of paths by pruning the links belonging to + a specific SRLG from the topology on which a specific Flex- + Algorithm computes its paths. This usage: + + Facilitates the usage of already deployed SRLG configurations + for setup of disjoint paths between two or more Flex- + Algorithms. + + Requires explicit association of a given Flex-Algorithm with a + specific set of SRLG constraints as defined in Section 6.5 and + Section 7.5. + + The two usages mentioned above are orthogonal. + +14.3. Max-metric consideration + + Both ISIS and OSPF have a mechanism to set the IGP metric on a link + to a value that would make the link either non-reachable or to serve + as the link of last resort. Similar functionality would be needed + for the Min Unidirectional Link Delay and TE metric, as these can be + used to compute Flex-Algorithm paths. + + The link can be made un-reachable for all Flex-Algorithms that use + Min Unidirectional Link Delay as metric, as described in Section 5.1, + by removing the Flex-Algorithm ASLA Min Unidirectional Link Delay + advertisement for the link. The link can be made the link of last + resort by setting the delay value in the Flex-Algorithm ASLA delay + advertisement for the link to the value of 16,777,215 (2^24 - 1). + + The link can be made un-reachable for all Flex-Algorithms that use TE + metric, as described in Section 5.1, by removing the Flex-Algorithm + ASLA TE metric advertisement for the link. The link can be made the + link of last resort by setting the TE metric value in the Flex- + Algorithm ASLA delay advertisement for the link to the value of (2^24 + - 1) in ISIS and (2^32 - 1) in OSPF. + +15. Backward Compatibility This extension brings no new backward compatibility issues. -15. Security Considerations +16. Security Considerations This draft adds two new ways to disrupt the IGP networks: An attacker can hijack a particular Flex-Algorithm by advertising a FAD with a priority of 255 (or any priority higher than that of the legitimate nodes). An attacker could make it look like a router supports a particular Flex-Algorithm when it actually doesn't, or vice versa. Both of these attacks can be addressed by the existing security extensions as described in [RFC5304] and [RFC5310] for ISIS, in [RFC2328] and [RFC7474] for OSPFv2 and in [RFC5340] and [RFC4552] for OSPFv3. -16. IANA Considerations - -16.1. IGP IANA Considerations +17. IANA Considerations +17.1. IGP IANA Considerations -16.1.1. IGP Algorithm Types Registry +17.1.1. IGP Algorithm Types Registry This document makes the following registrations in the "IGP Algorithm Types" registry: Type: 128-255. Description: Flexible Algorithms. Reference: This document (Section 4). -16.1.2. Flexible Algorithm Definition Metric-Type Registry +17.1.2. IGP Metric-Type Registry - IANA is requested to set up a registry called "Flexible Algorithm - Definition Metric-Type Registry" under a "Interior Gateway Protocol - (IGP) Parameters" IANA registries. The registration policy for this - registry is "Standards Action" ([RFC8126] and [RFC7120]). + IANA is requested to set up a registry called "IGP Metric-Type + Registry" under a "Interior Gateway Protocol (IGP) Parameters" IANA + registries. The registration policy for this registry is "Standards + Action" ([RFC8126] and [RFC7120]). Values in this registry come from the range 0-255. - This document registers following values in the "Flexible Algorithm - Definition Metric-Type Registry": + This document registers following values in the "IGP Metric-Type + Registry": Type: 0 Description: IGP metric Reference: This document (Section 5.1) Type: 1 Description: Min Unidirectional Link Delay [RFC7810] @@ -1157,67 +1242,69 @@ Type: 1 Description: Min Unidirectional Link Delay [RFC7810] Reference: This document (Section 5.1) Type: 2 Description: TE Default Metric [RFC5305] + Reference: This document (Section 5.1) -16.2. Flex-Algorithm Definition Flags Registry +17.2. Flex-Algorithm Definition Flags Registry IANA is requested to set up a registry called "ISIS Flex-Algorithm Definition Flags Registry" under a "Interior Gateway Protocol (IGP) Parameters" IANA registries. The registration policy for this registry is "Standards Action" ([RFC8126] and [RFC7120]). This document defines the following single bit in Flex-Algorithm Definition Flags registry: Bit # Name ----- ------------------------------ 0 Prefix Metric Flag (M-flag) Reference: This document (Section 6.4, Section 7.4). -16.3. ISIS IANA Considerations +17.3. ISIS IANA Considerations -16.3.1. Sub TLVs for Type 242 +17.3.1. Sub TLVs for Type 242 This document makes the following registrations in the "sub-TLVs for TLV 242" registry. Type: 26. Description: Flexible Algorithm Definition. Reference: This document (Section 5.1). -16.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 +17.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 This document makes the following registrations in the "Sub-TLVs for for TLVs 135, 235, 236, and 237" registry. Type: 6 Description: Flex-Algorithm Prefix Metric. Reference: This document (Section 8). -16.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV +17.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV This document creates the following Sub-Sub-TLV Registry: Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV + Registration Procedure: Expert review Reference: This document (Section 5.1) This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry: Type: 1 Description: Flexible Algorithm Exclude Admin Group @@ -1241,56 +1328,56 @@ Description: Flexible Algorithm Definition Flags Reference: This document (Section 6.4). Type: 5 Description: Flexible Algorithm Exclude SRLG Reference: This document (Section 6.5). -16.4. OSPF IANA Considerations +17.4. OSPF IANA Considerations -16.4.1. OSPF Router Information (RI) TLVs Registry +17.4.1. OSPF Router Information (RI) TLVs Registry This specification updates the OSPF Router Information (RI) TLVs Registry. Type: 16 Description: Flexible Algorithm Definition TLV. Reference: This document (Section 5.2). -16.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs +17.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs This document makes the following registrations in the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry. Type: 3 Description: Flex-Algorithm Prefix Metric. Reference: This document (Section 9). -16.4.3. OSPFv3 Extended-LSA Sub-TLVs +17.4.3. OSPFv3 Extended-LSA Sub-TLVs This document makes the following registrations in the "OSPFv3 Extended-LSA Sub-TLVs" registry. Type: 26 Description: Flex-Algorithm Prefix Metric. Reference: This document (Section 9). -16.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry +17.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry This document creates the following registry: Registry: OSPF Flexible Algorithm Definition TLV sub-TLV Registration Procedure: Expert review Reference: This document (Section 5.2) The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will @@ -1333,75 +1419,80 @@ Reference: This document (Section 7.5). Types in the range 32768-33023 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs. Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that covers the range being assigned. -16.4.5. Link Attribute Applications Registry +17.4.5. Link Attribute Applications Registry This document registers following bit in the Link Attribute - Applications registry: + Applications Registry: Bit-3 Description: Flexible Algorithm (X-bit) Reference: This document (Section 11). -17. Acknowledgements +18. Acknowledgements This draft, among other things, is also addressing the problem that the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve. All authors of that draft agreed to join this draft. Thanks to Eric Rosen, Tony Przygienda for their detailed review and excellent comments. Thanks to Cengiz Halit for his review and feedback during initial phase of the solution definition. Thanks to Kenji Kumaki for his comments. Thanks to William Britto A J. for his suggestions. -18. References +19. References -18.1. Normative References +19.1. Normative References [BCP14] , . [I-D.ietf-isis-te-app] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and - J. Drake, "IS-IS TE Attributes per application", draft- - ietf-isis-te-app-12 (work in progress), March 2020. + J. Drake, "IS-IS Application-Specific Link Attributes", + draft-ietf-isis-te-app-19 (work in progress), June 2020. [I-D.ietf-lsr-isis-srv6-extensions] Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extension to Support Segment Routing over - IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-07 - (work in progress), March 2020. + IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 + (work in progress), April 2020. + + [I-D.ietf-lsr-ospf-reverse-metric] + Talaulikar, K., Psenak, P., and H. Johnston, "OSPF Reverse + Metric", draft-ietf-lsr-ospf-reverse-metric-01 (work in + progress), June 2020. [I-D.ietf-lsr-ospfv3-srv6-extensions] Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", draft-ietf-lsr- ospfv3-srv6-extensions-00 (work in progress), February 2020. [I-D.ietf-ospf-te-link-attr-reuse] Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., - and J. Drake, "OSPF Link Traffic Engineering Attribute - Reuse", draft-ietf-ospf-te-link-attr-reuse-10 (work in - progress), October 2019. + and J. Drake, "OSPF Application-Specific Link Attributes", + draft-ietf-ospf-te-link-attr-reuse-16 (work in progress), + June 2020. [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1457,28 +1548,35 @@ [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, . [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, . -18.2. Informative References +19.2. Informative References [I-D.gulkohegde-routing-planes-using-sr] Hegde, S. and a. arkadiy.gulko@thomsonreuters.com, "Separating Routing Planes using Segment Routing", draft- gulkohegde-routing-planes-using-sr-00 (work in progress), March 2017. + [I-D.ietf-rtgwg-segment-routing-ti-lfa] + Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., + Francois, P., Voyer, D., Clad, F., and P. Camarillo, + "Topology Independent Fast Reroute using Segment Routing", + draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in + progress), March 2020. + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels", RFC 3906, DOI 10.17487/RFC3906, October 2004, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality @@ -1548,13 +1646,13 @@ Ketan Talaulikar Cisco Systems, Inc. S.No. 154/6, Phase I, Hinjawadi PUNE, MAHARASHTRA 411 057 India Email: ketant@cisco.com Arkadiy Gulko - Thomson Reuters + Refinitiv - Email: arkadiy.gulko@thomsonreuters.com + Email: arkadiy.gulko@refinitiv.com