--- 1/draft-ietf-lsr-flex-algo-04.txt 2019-11-04 03:13:27.883560357 -0800 +++ 2/draft-ietf-lsr-flex-algo-05.txt 2019-11-04 03:13:27.947561976 -0800 @@ -1,24 +1,24 @@ Network Working Group P. Psenak, Ed. Internet-Draft Cisco Systems Intended status: Standards Track S. Hegde -Expires: March 21, 2020 Juniper Networks, Inc. +Expires: May 7, 2020 Juniper Networks, Inc. C. Filsfils K. Talaulikar Cisco Systems, Inc. A. Gulko Thomson Reuters - September 18, 2019 + November 4, 2019 IGP Flexible Algorithm - draft-ietf-lsr-flex-algo-04.txt + draft-ietf-lsr-flex-algo-05.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 March 21, 2020. + This Internet-Draft will expire on May 7, 2020. Copyright Notice Copyright (c) 2019 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 @@ -57,70 +57,71 @@ 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.1. ISIS Flexible Algorithm Definition Sub-TLV . . . . . . . 5 + 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 . . 8 6. Sub-TLVs of ISIS FAD Sub-TLV . . . . . . . . . . . . . . . . 9 6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV . . . 9 6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV . 10 - 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV . 10 + 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV . 11 6.4. ISIS Flexible Algorithm Definition Flags Sub-TLV . . . . 11 7. Sub-TLVs of OSPF FAD TLV . . . . . . . . . . . . . . . . . . 12 7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV . . . 12 7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV . 13 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV . 13 7.4. OSPF Flexible Algorithm Definition Flags Sub-TLV . . . . 13 8. ISIS Flex-Algorithm Prefix Metric Sub-TLV . . . . . . . . . . 14 9. OSPF Flex-Algorithm Prefix Metric Sub-TLV . . . . . . . . . . 15 10. Advertisement of Node Participation in a Flex-Algorithm . . . 16 - 10.1. Advertisement of Node Participation for Segment Routing 16 + 10.1. Advertisement of Node Participation for Segment Routing 17 10.2. Advertisement of Node Participation for Other Applications . . . . . . . . . . . . . . . . . . . . . . 17 11. Advertisement of Link Attributes for Flex-Algorithm . . . . . 17 12. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 18 12.1. Multi-area and Multi-domain Considerations . . . . . . . 19 13. Flex-Algorithm and Forwarding Plane . . . . . . . . . . . . . 20 13.1. Segment Routing MPLS Forwarding for Flex-Algorithm . . . 20 13.2. SRv6 Forwarding for Flex-Algorithm . . . . . . . . . . . 21 - 13.3. Other Applications' Forwarding for Flex-Algorithm . . . 21 + 13.3. Other Applications' Forwarding for Flex-Algorithm . . . 22 14. Backward Compatibility . . . . . . . . . . . . . . . . . . . 22 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 16.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 22 - 16.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 22 - 16.1.2. Flexible Algorithm Definition Metric-Type Registry . 22 - 16.2. Flex-Algorithm Definition Flags Registry . . . . . . . . 23 - 16.3. ISIS IANA Considerations . . . . . . . . . . . . . . . . 23 - 16.3.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . 23 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 16.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 23 + 16.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 23 + 16.1.2. Flexible Algorithm Definition Metric-Type Registry . 23 + 16.2. Flex-Algorithm Definition Flags Registry . . . . . . . . 24 + 16.3. ISIS IANA Considerations . . . . . . . . . . . . . . . . 24 + 16.3.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . 24 16.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237 . . . . 24 16.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub- TLV . . . . . . . . . . . . . . . . . . . . . . . . 24 16.4. OSPF IANA Considerations . . . . . . . . . . . . . . . . 25 16.4.1. OSPF Router Information (RI) TLVs Registry . . . . . 25 - 16.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs . . . . . . . . 25 - 16.4.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . 25 + 16.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs . . . . . . . . 26 + 16.4.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . 26 16.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV - Registry . . . . . . . . . . . . . . . . . . . . . . 25 - 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 - 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 18.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 18.2. Informative References . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 + Registry . . . . . . . . . . . . . . . . . . . . . . 26 + 16.4.5. Link Attribute Applications Registry . . . . . . . . 27 + 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 18.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 18.2. Informative References . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 @@ -179,20 +180,25 @@ Flexible Algorithm Participation - per application configuration state that expresses whether the node is participating in a particular Flexible Algorithm. IGP Algorithm - value from the the "IGP Algorithm Types" registry defined under "Interior Gateway Protocol (IGP) Parameters" IANA registries. IGP Algorithms represents the triplet (Calculation Type, Metric, Constraints), where the second and third elements of the triple MAY not exist. + ABR - Area Border Router. In ISIS terminology it is also known as + L1/L2 router. + + ASBR - Autonomous System Border Router. + 4. Flexible Algorithm Many possible constraints may be used to compute a path over a network. Some networks are deployed as multiple planes. A simple form of constraint may be to use a particular plane. A more sophisticated form of constraint can include some extended metric as described in [RFC7810]. Constraints which restrict paths to links with specific affinities or avoid links with specific affinities are also possible. Combinations of these are also possible. @@ -247,21 +253,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | + + | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: - Type: TBD, suggested value 26 + Type: 26 Length: variable, dependent on the included Sub-TLVs Flex-Algorithm: Single octet value between 128 and 255 inclusive. Metric-Type: Type of metric to be used during the calculation. Following values are defined: 0: IGP Metric @@ -311,30 +317,30 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | + + | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: - Type: TBD, suggested value 16 + Type: 16 Length: variable, dependent on the included Sub-TLVs - Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255 inclusive. Metric-Type: as described in Section 5.1 Calc-Type: as described in Section 5.1 + Priority: as described in Section 5.1 Sub-TLVs - optional sub-TLVs. When multiple OPSF FAD TLVs, for the same Flexible-Algorithm, are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information LSA. If the OSPF FAD TLV, for the same Flex-Algorithm, appears in multiple Router Information LSAs that have different flooding scopes, the OSPF FAD TLV in the Router Information LSA with the area-scoped flooding scope @@ -650,21 +656,22 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Flex-Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: - Type: TBD, suggested value 6 + Type: 6 + Length: 5 octets Flex-Algorithm: Single octet value between 128 and 255 inclusive. Metric: 4 octets of metric information ISIS FAPM Sub-TLV MAY appear multiple times in its parent TLV. If it appears more then once with the same Flex-Algorithm value, the first appearance MUST be used and any subsequent ones MUST be ignored. @@ -707,21 +713,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Flex-Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: - Type: TBD, suggested value for OSPFv2 is 3, for OSPFv3 is 26 + Type: 3 for OSPFv2, 26 for OSPFv3 Length: 8 octets Flex-Algorithm: Single octet value between 128 and 255 inclusive. Reserved: Must be set to 0, ignored at reception. Metric: 4 octets of metric information OSPF FAPM Sub-TLV MAY appear multiple times in its parent TLV. If it @@ -772,36 +778,43 @@ Application specific Flex-Algorithm participation advertisements MAY be topology specific or MAY be topology independent, depending on the application itself. Application specific advertisement for Flex-Algorithm participation MUST be defined for each application and is outside of the scope of this document. 11. Advertisement of Link Attributes for Flex-Algorithm - Various link include or exclude rules can be part of the Flex- - Algorithm definition. These rules use Admin Groups (AG) as defined - in [RFC5305], or Extended Administrative Groups (EAG) as defined in - [RFC7308]. + Various link attributes may be used during the Flex-Algorithm path + calculation. For example, include or exclude rules based on link + affinities can be part of the Flex-Algorithm definition as defined in + Section 6 and Section 7. - To advertise a link affinity in a form of the AG or EAG that is used - during Flex-Algorithm calculation, an Application Specific Link - Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV - of Extended Link TLV as described in - [I-D.ietf-ospf-te-link-attr-reuse] MUST be used. The advertisement - MUST indicate that it is usable by the Flex-Algorithm application. + Link attribute advertisements that are to be used during Flex- + Algorithm calculation MUST use the Application Specific Link + Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or + [I-D.ietf-ospf-te-link-attr-reuse]. - If the link Flex-Algorithm application affinities are advertised in a - form of the AG inside the Application Specific Link Attributes sub- - TLV, these are mapped to the affinities specified in the FAD Sub-TLVs - as defined in [RFC7308]. + A new Application Identifier Bit is defined to indicate that the ASLA + advertisement is associated with the Flex-Algorithm application. + + This bit is set in the Standard Application Bit Mask (SABM) defined + in [I-D.ietf-isis-te-app] or [I-D.ietf-ospf-te-link-attr-reuse]: + + Bit-3: Flexible Algorithm (X-bit) + + ASLA Admin Group Advertisements to be used by the Flexible Algorithm + Application MAY use either the Administrative Group or Extended + Administrative Group encodings. If the Administrative Group encoding + is used then the first 32 bits of the corresponding FAD sub-TLVs are + mapped to the link attribute advertisements as specified in RFC 7308. 12. Calculation of Flexible Algorithm Paths A router MUST be configured to participate in a given Flex-Algorithm K and MUST use the FAD selected based on the rules defined in Section 5.3 before it can compute any path for that Flex-Algorithm. As described in Section 10, participation for any particular Flex- Algorithm MUST be advertised on a per application basis. Calculation of the paths for any particular Flex-Algorithm MUST be application @@ -853,50 +866,72 @@ 4. If the Flex-Algorithm definition uses other than IGP metric (Section 5), and such metric is not advertised for the particular link in a topology for which the computation is done, such link MUST be pruned from the computation. A metric of value 0 MUST NOT be assumed in such case. 12.1. Multi-area and Multi-domain Considerations Any IGP Shortest Path Tree calculation is limited to a single area. - Same applies to Flex-Algorithm calculations. Given that the - computing router may not have the visibility to the topology of - remote areas, the Flex-Algorithm specific path to an inter-area or + This applies to Flex-Algorithm calculations as well. Given that the + computing router does not have the visibility of the topology of next + areas or domain, the Flex-Algorithm specific path to an inter-area or inter-domain prefix will be computed for the local area only. The egress L1/L2 router (ABR in OSPF), or ASBR for inter-domain case, will be selected based on the best path for the given Flex-Algorithm in the local area and such egress ABR or ASBR router will be responsible to compute the best Flex-Algorithm specific path over the next area or domain. This may produce an end-to-end path, which is - sub-optimal based on Flex-Algorithm constraints. + sub-optimal based on Flex-Algorithm constraints. In cases where the + ABR or ASBR has no reachability to a prefix for a given Flex- + Algorithm in a next area or domain, the traffic may get dropped by + the ABR/ASBR. - To allow the best end-to-end path for a prefix for a given Flex- - Algorithm to be computed, an ABR or ASBR MAY set the Flex-Algorithm - prefix metric (Section 8, Section 9) when advertising the prefix - between areas or domains. Such metric will be equal to the metric to - reach the prefix for a given Flex-Algorithm in a source area or - domain. This is similar in nature to how the metric is set when - prefixes are advertised between areas or domains for default - algorithm. + To allow the optimal end-to-end path for a inter-area or inter-domain + prefixes for any Flex-Algorithm to be computed, the FAPM has been + defined in Section 8 and Section 9. + + If the FAD selected based on the rules defined in Section 5.3 + includes the M-flag, an ABR or ASBR MUST include the FAPM (Section 8, + Section 9) when advertising the prefix between areas or domains. + Such metric will be equal to the metric to reach the prefix for a + given Flex-Algorithm in a source area or domain. This is similar in + nature to how the metric is set when prefixes are advertised between + areas or domains for default algorithm. + + If the FAD selected based on the rules defined in Section 5.3 + includes the M-flag, FAPM MUST be used during calculation of prefix + reachability for the inter-area and external prefixes. If the FAPM + for the Flex-Algorithm is not advertised with the inter-area or + external prefix reachability advertisement, the prefix MUST be + considered as unreachable for that Flex-Algorithm. Flex-Algorithm prefix metrics MUST NOT be used during the Flex- Algorithm computation unless the FAD selected based on the rules defined in Section 5.3 includes the M-Flag, as described in (Section 6.4 or Section 7.4). - If the FAD selected based on the rules defined in Section 5.3 - includes the M-flag, Flex-Algorithm prefix metrics MUST be used - during calculation when advertised with the prefix. If the Flex- - Algorithm prefix metric is not advertised with the prefix, the - standard IGP metric advertised with the prefix MUST be used. + If the FAD selected based on the rules defined in Section 5.3 does + not includes the M-flag, it is NOT RECOMMENDED to use the Flex- + Algoritm for inter-area or inter-domain prefix reachability. The + reason is that without the explicit Flex-Algorithm Prefix Metric + advertisement it is not possible to conclude whether the ABR or ASBR + has reachability to the inter-area or inter-domain prefix for a given + Flex-Algorithm in a next area or domain. Sending the Flex-Algoritm + traffic for such prefix towards the ABR or ASBR may result in traffic + looping or black-holing. + + FAPM MUST NOT be advertised with ISIS L1 or L2 intra-area, OSPFv2 + intra-area or OSPFv3 intra area routes. If the FAPM is advertised + for these route-types, it MUST be ignored during prefix reachability + calculation. M-flag in FAD is not applicable to prefixes advertised as SRv6 locators. ISIS SRv6 Locator TLV includes the Algorithm and Metric fields [I-D.ietf-lsr-isis-srv6-extensions]. When the ISIS SRv6 Locator is advertised between areas or domains, the metric field in the Locator TLV MUST be used irrespective of the M flag in the FAD advertisement. 13. Flex-Algorithm and Forwarding Plane @@ -1070,32 +1104,32 @@ Reference: This document (Section 6.4, Section 7.4). 16.3. ISIS IANA Considerations 16.3.1. Sub TLVs for Type 242 This document makes the following registrations in the "sub-TLVs for TLV 242" registry. - Type: TBD (suggested value 26). + 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 This document makes the following registrations in the "Sub-TLVs for for TLVs 135, 235, 236, and 237" registry. - Type: TBD (suggested value 6). + Type: 6 Description: Flex-Algorithm Prefix Metric. Reference: This document (Section 8). 16.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 @@ -1121,48 +1154,53 @@ Type: 3 Description: Flexible Algorithm Include-All Admin Group Reference: This document (Section 6.3). Type: 4 Description: Flexible Algorithm Definition Flags + Reference: This document (Section 6.4). 16.4. OSPF IANA Considerations 16.4.1. OSPF Router Information (RI) TLVs Registry This specification updates the OSPF Router Information (RI) TLVs - Registry with the following value: + Registry. - o TBD (suggested value 16) - Flexible Algorithm Definition TLV + Type: 16 + + Description: Flexible Algorithm Definition TLV. + + Reference: This document (Section 5.2). 16.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs This document makes the following registrations in the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry. - Type: TBD (suggested value 3). + Type: 3 Description: Flex-Algorithm Prefix Metric. Reference: This document (Section 9). 16.4.3. OSPFv3 Extended-LSA Sub-TLVs This document makes the following registrations in the "OSPFv3 Extended-LSA Sub-TLVs" registry. - Type: TBD (suggested value 26). + Type: 26 Description: Flex-Algorithm Prefix Metric. Reference: This document (Section 9). 16.4.4. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry This document creates the following registry: Registry: OSPF Flexible Algorithm Definition TLV sub-TLV @@ -1205,20 +1242,31 @@ Reference: This document (Section 7.4). 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 + + This document registers following bit in the Link Attribute + Applications registry: + + Bit-3 + + Description: Flexible Algorithm (X-bit) + + Reference: This document (Section 11). + 17. 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 @@ -1234,44 +1282,44 @@ [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-25 (work in progress), May 2019. [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-06 (work in progress), April 2019. + ietf-isis-te-app-09 (work in progress), October 2019. [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-02 - (work in progress), July 2019. + IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03 + (work in progress), October 2019. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- extensions-23 (work in progress), January 2019. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-27 (work in progress), December 2018. [I-D.ietf-ospf-te-link-attr-reuse] Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., - and J. Drake, "OSPF Link Traffic Engineering (TE) - Attribute Reuse", draft-ietf-ospf-te-link-attr-reuse-08 - (work in progress), August 2019. + and J. Drake, "OSPF Link Traffic Engineering Attribute + Reuse", draft-ietf-ospf-te-link-attr-reuse-10 (work in + progress), October 2019. [I-D.li-ospf-ospfv3-srv6-extensions] Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", draft-li-ospf- ospfv3-srv6-extensions-05 (work in progress), August 2019. [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in