| < draft-ietf-isis-reverse-metric-13.txt | draft-ietf-isis-reverse-metric-17.txt > | |||
|---|---|---|---|---|
| Networking Working Group N. Shen | Networking Working Group N. Shen | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Standards Track S. Amante | Intended status: Standards Track S. Amante | |||
| Expires: April 5, 2019 Apple, Inc. | Expires: June 6, 2019 Apple, Inc. | |||
| M. Abrahamsson | M. Abrahamsson | |||
| T-Systems Nordic | T-Systems Nordic | |||
| October 2, 2018 | December 3, 2018 | |||
| IS-IS Routing with Reverse Metric | IS-IS Routing with Reverse Metric | |||
| draft-ietf-isis-reverse-metric-13 | draft-ietf-isis-reverse-metric-17 | |||
| Abstract | Abstract | |||
| This document describes a mechanism to allow IS-IS routing to quickly | This document describes a mechanism to allow IS-IS routing to quickly | |||
| and accurately shift traffic away from either a point-to-point or | and accurately shift traffic away from either a point-to-point or | |||
| multi-access LAN interface during network maintenance or other | multi-access LAN interface during network maintenance or other | |||
| operational events. This is accomplished by signaling adjacent IS-IS | operational events. This is accomplished by signaling adjacent IS-IS | |||
| neighbors with a higher reverse metric, i.e., the metric towards the | neighbors with a higher reverse metric, i.e., the metric towards the | |||
| signaling IS-IS router. | signaling IS-IS router. | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on April 5, 2019. | This Internet-Draft will expire on June 6, 2019. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Node and Link Isolation . . . . . . . . . . . . . . . . . 2 | 1.1. Node and Link Isolation . . . . . . . . . . . . . . . . . 3 | |||
| 1.2. Distributed Forwarding Planes . . . . . . . . . . . . . . 3 | 1.2. Distributed Forwarding Planes . . . . . . . . . . . . . . 3 | |||
| 1.3. Spine-Leaf Applications . . . . . . . . . . . . . . . . . 3 | 1.3. Spine-Leaf Applications . . . . . . . . . . . . . . . . . 3 | |||
| 1.4. LDP IGP Synchronization . . . . . . . . . . . . . . . . . 3 | 1.4. LDP IGP Synchronization . . . . . . . . . . . . . . . . . 3 | |||
| 1.5. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . 3 | 1.5. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . 4 | |||
| 1.6. Specification of Requirements . . . . . . . . . . . . . . 4 | 1.6. Specification of Requirements . . . . . . . . . . . . . . 4 | |||
| 2. IS-IS Reverse Metric TLV . . . . . . . . . . . . . . . . . . 4 | 2. IS-IS Reverse Metric TLV . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 | 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 | |||
| 3.1. Processing Changes to Default Metric . . . . . . . . . . 6 | 3.1. Processing Changes to Default Metric . . . . . . . . . . 7 | |||
| 3.2. Multi-Topology IS-IS Support on Point-to-point links . . 7 | 3.2. Multi-Topology IS-IS Support on Point-to-point links . . 7 | |||
| 3.3. Multi-Access LAN Procedures . . . . . . . . . . . . . . . 7 | 3.3. Multi-Access LAN Procedures . . . . . . . . . . . . . . . 7 | |||
| 3.4. LDP/IGP Synchronization on LANs . . . . . . . . . . . . . 8 | 3.4. LDP/IGP Synchronization on LANs . . . . . . . . . . . . . 9 | |||
| 3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9 | 3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . 11 | 7.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
| Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12 | Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12 | |||
| Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 13 | Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 13 | |||
| Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 14 | Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 1. Introduction | 1. Introduction | |||
| The IS-IS [ISO10589] routing protocol has been widely used in | The IS-IS [ISO10589] routing protocol has been widely used in | |||
| Internet Service Provider IP/MPLS networks. Operational experience | Internet Service Provider IP/MPLS networks. Operational experience | |||
| with the protocol, combined with ever increasing requirements for | with the protocol, combined with ever increasing requirements for | |||
| lossless operations have demonstrated some operational issues. This | lossless operations have demonstrated some operational issues. This | |||
| document describes the issues and a mechanism for mitigating them. | document describes the issues and a mechanism for mitigating them. | |||
| This document defines the IS-IS "Reverse Metric" mechanism that | ||||
| allows an IS-IS node to send a "Reverse Metric" TLV through the IS-IS | ||||
| Hello (IIH) PDU to the neighbor or pseudo-node to adjust the routing | ||||
| metric on the inbound direction. | ||||
| 1.1. Node and Link Isolation | 1.1. Node and Link Isolation | |||
| IS-IS routing mechanism has the overload-bit, which can be used by | IS-IS routing mechanism has the overload-bit, which can be used by | |||
| operators to perform disruptive maintenance on the router. But in | operators to perform disruptive maintenance on the router. But in | |||
| many operational maintenance cases, it is not necessary to divert all | many operational maintenance cases, it is not necessary to divert all | |||
| the traffic away from this node. It is necessary to avoid only a | the traffic away from this node. It is necessary to avoid only a | |||
| single link during the maintenance. More detailed descriptions of | single link during the maintenance. More detailed descriptions of | |||
| the challenges can be found in Appendix A and Appendix B of this | the challenges can be found in Appendix A and Appendix B of this | |||
| document. | document. | |||
| skipping to change at page 4, line 19 ¶ | skipping to change at page 4, line 27 ¶ | |||
| This Reverse Metric mechanism is used for both point-to-point and | This Reverse Metric mechanism is used for both point-to-point and | |||
| multi-access LAN links. Unlike the point-to-point links, the IS-IS | multi-access LAN links. Unlike the point-to-point links, the IS-IS | |||
| protocol currently does not have a way to influence the traffic | protocol currently does not have a way to influence the traffic | |||
| towards a particular node on LAN links. This mechanism provides IS- | towards a particular node on LAN links. This mechanism provides IS- | |||
| IS routing the capability of altering traffic in both directions on | IS routing the capability of altering traffic in both directions on | |||
| either a point-to-point link or a multi-access link of an IS-IS node. | either a point-to-point link or a multi-access link of an IS-IS node. | |||
| The metric value in the "reverse metric" TLV and the Traffic | The metric value in the "reverse metric" TLV and the Traffic | |||
| Engineering metric in the sub-TLV being advertised is an offset or | Engineering metric in the sub-TLV being advertised is an offset or | |||
| relative metric to be added to the existing local link and Traffic | relative metric to be added to the existing local link and Traffic | |||
| Engineering metric values of the receiver. | Engineering metric values of the receiver, the accumulated metric | |||
| value is bounded as described in Section 2. | ||||
| 1.6. Specification of Requirements | 1.6. Specification of Requirements | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. IS-IS Reverse Metric TLV | 2. IS-IS Reverse Metric TLV | |||
| The Reverse Metric TLV is a new TLV to be used inside IS-IS Hello | The Reverse Metric TLV is a new TLV to be used inside an IS-IS Hello | |||
| PDU. This TLV is used to support the IS-IS Reverse Metric mechanism | PDU. This TLV is used to support the IS-IS Reverse Metric mechanism | |||
| that allows a "reverse metric" to be send to the IS-IS neighbor. | that allows a "reverse metric" to be sent to the IS-IS neighbor. | |||
| 0 1 2 3 | 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 | 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 | Flags | Metric | | Type | Length | Flags | Metric | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Metric (Continue) | sub-TLV Len |Optional sub-TLV | Metric (Continue) | sub-TLV Len |Optional sub-TLV | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: Reverse Metric TLV | Figure 1: Reverse Metric TLV | |||
| skipping to change at page 5, line 38 ¶ | skipping to change at page 6, line 5 ¶ | |||
| metric offset that a neighbor SHOULD add to the existing, configured | metric offset that a neighbor SHOULD add to the existing, configured | |||
| Default Metric for the IS-IS link [ISO10589]. Refer to "Elements of | Default Metric for the IS-IS link [ISO10589]. Refer to "Elements of | |||
| Procedure", in Section 3 for details on how an IS-IS router should | Procedure", in Section 3 for details on how an IS-IS router should | |||
| process the Metric field in a Reverse Metric TLV. | process the Metric field in a Reverse Metric TLV. | |||
| The Metric field, in the Reverse Metric TLV, is a "reverse offset | The Metric field, in the Reverse Metric TLV, is a "reverse offset | |||
| metric" that will either be in the range of 0 - 63 when a "narrow" | metric" that will either be in the range of 0 - 63 when a "narrow" | |||
| IS-IS metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or | IS-IS metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or | |||
| in the range of 0 - (2^24 - 2) when a "wide" Traffic Engineering | in the range of 0 - (2^24 - 2) when a "wide" Traffic Engineering | |||
| metric value is used, (Extended IS Reachability TLV) [RFC5305] | metric value is used, (Extended IS Reachability TLV) [RFC5305] | |||
| [RFC5817]. | [RFC5817]. As described below, when the U bit is set, the | |||
| accumulated value of the wide metric is in the range of 0 - (2^24 - | ||||
| 1), with (2^24 - 1) metric as non-reachable in IS-IS routing. The | ||||
| IS-IS metric value of (2^24 - 2) serves as the link of last resort. | ||||
| There are currently only two Flag bits defined. | There are currently only two Flag bits defined. | |||
| W bit (0x01): The "Whole LAN" bit is only used in the context of | W bit (0x01): The "Whole LAN" bit is only used in the context of | |||
| multi-access LANs. When a Reverse Metric TLV is transmitted from a | multi-access LANs. When a Reverse Metric TLV is transmitted from a | |||
| node to the Designated Intermediate System (DIS), if the "Whole LAN" | node to the Designated Intermediate System (DIS), if the "Whole LAN" | |||
| bit is set (1), then a DIS SHOULD add the received Metric value in | bit is set (1), then a DIS SHOULD add the received Metric value in | |||
| the Reverse Metric TLV to each node's existing Default Metric in the | the Reverse Metric TLV to each node's existing Default Metric in the | |||
| Pseudonode LSP. If the "Whole LAN" bit is not set (0), then a DIS | Pseudonode LSP. If the "Whole LAN" bit is not set (0), then a DIS | |||
| SHOULD add the received Metric value in the Reverse Metric TLV to the | SHOULD add the received Metric value in the Reverse Metric TLV to the | |||
| existing "default metric" in the Pseudonode LSP for the single node | existing "default metric" in the Pseudonode LSP for the single node | |||
| from whom the Reverse Metric TLV was received. Please refer to | from whom the Reverse Metric TLV was received. Please refer to | |||
| "Multi-Access LAN Procedures", in Section 3.3, for additional | "Multi-Access LAN Procedures", in Section 3.3, for additional | |||
| details. The W bit MUST be clear when a Reverse Metric TLV is | details. The W bit MUST be clear when a Reverse Metric TLV is | |||
| transmitted in an IIH PDU on a point-to-point link, and MUST be | transmitted in an IIH PDU on a point-to-point link, and MUST be | |||
| ignored when received on a point-to-point link. | ignored when received on a point-to-point link. | |||
| U bit (0x02): The "Unreachable" bit specifies that the metric | U bit (0x02): The "Unreachable" bit specifies that the metric | |||
| calculated by addition of the reverse metric value to the "default | calculated by addition of the reverse metric to the "default metric" | |||
| metric" is limited to (2^24-1). This "U" bit applies to both the | is limited to the maximum value of (2^24-1). This "U" bit applies to | |||
| default metric in the Extended IS Reachability TLV and the Traffic | both the default metric in the Extended IS Reachability TLV and the | |||
| Engineering Default Metric sub-TLV of the link. This is only | Traffic Engineering Default Metric sub-TLV of the link. This is only | |||
| relevant to the IS-IS "wide" metric mode. | relevant to the IS-IS "wide" metric mode. | |||
| The Reserved bits of Flags field MUST be set to zero and MUST be | The Reserved bits of Flags field MUST be set to zero and MUST be | |||
| ignored when received. | ignored when received. | |||
| The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router | The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router | |||
| wishes to signal additional information to its neighbor. In this | wishes to signal additional information to its neighbor. In this | |||
| document, the Reverse Metric Traffic Engineering Metric sub-TLV, with | document, the Reverse Metric Traffic Engineering Metric sub-TLV, with | |||
| Type 18, is defined. This Traffic Engineering Metric contains a | Type 18, is defined. This Traffic Engineering Metric contains a | |||
| 24-bit unsigned integer. This sub-TLV is optional, if it appears | 24-bit unsigned integer. This sub-TLV is optional, if it appears | |||
| more than once then the entire Reverse Metric TLV MUST be ignored. | more than once, then the entire Reverse Metric TLV MUST be ignored. | |||
| Upon receiving this Traffic Engineering METRIC sub-TLV in a Reverse | Upon receiving this Traffic Engineering METRIC sub-TLV in a Reverse | |||
| Metric TLV, a node SHOULD add the received Traffic Engineering Metric | Metric TLV, a node SHOULD add the received Traffic Engineering Metric | |||
| offset value to its existing, configured Traffic Engineering Default | offset value to its existing, configured Traffic Engineering Default | |||
| Metric within its Extended IS Reachability TLV. The use of other | Metric within its Extended IS Reachability TLV. The use of other | |||
| sub-TLVs is outside the scope of this document. The "sub-TLV Len" | sub-TLVs is outside the scope of this document. The "sub-TLV Len" | |||
| value MUST be set to zero when an IS-IS router does not have Traffic | value MUST be set to zero when an IS-IS router does not have Traffic | |||
| Engineering sub-TLVs that it wishes to send to its IS-IS neighbor. | Engineering sub-TLVs that it wishes to send to its IS-IS neighbor. | |||
| 3. Elements of Procedure | 3. Elements of Procedure | |||
| skipping to change at page 7, line 12 ¶ | skipping to change at page 7, line 34 ¶ | |||
| Metric sub-TLV, then the IS-IS router MUST NOT change the value of | Metric sub-TLV, then the IS-IS router MUST NOT change the value of | |||
| its Traffic Engineering Default Metric sub-TLV for that link. | its Traffic Engineering Default Metric sub-TLV for that link. | |||
| 3.2. Multi-Topology IS-IS Support on Point-to-point links | 3.2. Multi-Topology IS-IS Support on Point-to-point links | |||
| The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS) | The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS) | |||
| [RFC5120]. On point-to-point links, if an IS-IS router is configured | [RFC5120]. On point-to-point links, if an IS-IS router is configured | |||
| for M-ISIS, it MUST send only a single Reverse Metric TLV in IIH PDUs | for M-ISIS, it MUST send only a single Reverse Metric TLV in IIH PDUs | |||
| toward its neighbor(s) on the designated link. When an M-ISIS router | toward its neighbor(s) on the designated link. When an M-ISIS router | |||
| receives a Reverse Metric TLV, it MUST add the received Metric value | receives a Reverse Metric TLV, it MUST add the received Metric value | |||
| to its Default Metric in all Extended IS Reachability TLVs for all | to its Default Metric of the link in all Extended IS Reachability | |||
| topologies. If an M-ISIS router receives a Reverse Metric TLV with a | TLVs for all topologies. If an M-ISIS router receives a Reverse | |||
| Traffic Engineering Default Metric sub-TLV, then the M-ISIS router | Metric TLV with a Traffic Engineering Default Metric sub-TLV, then | |||
| MUST add the received Traffic Engineering Default Metric value to | the M-ISIS router MUST add the received Traffic Engineering Default | |||
| each of its Default Metric sub-TLVs in all of its MT Intermediate | Metric value to each of its Default Metric sub-TLVs in all of its MT | |||
| Systems TLVs. If an M-ISIS router is configured to advertise Traffic | Intermediate Systems TLVs. If an M-ISIS router is configured to | |||
| Engineering Default Metric sub-TLVs for one or more topologies, but | advertise Traffic Engineering Default Metric sub-TLVs for one or more | |||
| does not receive a Traffic Engineering Default Metric sub-TLV in a | topologies, but does not receive a Traffic Engineering Default Metric | |||
| Reverse Metric TLV, then the M-ISIS router MUST NOT change the value | sub-TLV in a Reverse Metric TLV, then the M-ISIS router MUST NOT | |||
| in each of the Traffic Engineering Default Metric sub-TLVs for all | change the value in each of the Traffic Engineering Default Metric | |||
| topologies. | sub-TLVs for all topologies. | |||
| 3.3. Multi-Access LAN Procedures | 3.3. Multi-Access LAN Procedures | |||
| On a Multi-Access LAN, only the DIS SHOULD act upon information | On a Multi-Access LAN, only the DIS SHOULD act upon information | |||
| contained in a received Reverse Metric TLV. All non-DIS nodes MUST | contained in a received Reverse Metric TLV. All non-DIS nodes MUST | |||
| silently ignore a received Reverse Metric TLV. The decision process | silently ignore a received Reverse Metric TLV. The decision process | |||
| of the routers on the LAN MUST follow the procedure in section | of the routers on the LAN MUST follow the procedure in section | |||
| 7.2.8.2 of [ISO10589], and use the "Two-way connectivity check" | 7.2.8.2 of [ISO10589], and use the "Two-way connectivity check" | |||
| during the topology and route calculation. | during the topology and route calculation. | |||
| The Reverse Metric Traffic Engineering sub-TLV also applies to the | The Reverse Metric Traffic Engineering sub-TLV also applies to the | |||
| DIS. If a DIS is configured to apply Traffic Engineering over a link | DIS. If a DIS is configured to apply Traffic Engineering over a link | |||
| and it receives metric sub-TLV in a Reverse Metric TLV, it should | and it receives Traffic Engineering Metric sub-TLV in a Reverse | |||
| update the Traffic Engineering Default Metric sub-TLV value of the | Metric TLV, it should update the Traffic Engineering Default Metric | |||
| corresponding Extended IS Reachability TLV or insert a new one if not | sub-TLV value of the corresponding Extended IS Reachability TLV or | |||
| present. | insert a new one if not present. | |||
| In the case of multi-access LANs, the "W" Flags bit is used to signal | In the case of multi-access LANs, the "W" Flags bit is used to signal | |||
| from a non-DIS to the DIS whether to change the metric and, | from a non-DIS to the DIS whether to change the metric and, | |||
| optionally Traffic Engineering parameters for all nodes in the | optionally, Traffic Engineering parameters for all nodes in the | |||
| Pseudonode LSP or solely the node on the LAN originating the Reverse | Pseudonode LSP or solely the node on the LAN originating the Reverse | |||
| Metric TLV. | Metric TLV. | |||
| A non-DIS node, e.g., Router B, attached to a multi-access LAN will | A non-DIS node, e.g., Router B, attached to a multi-access LAN will | |||
| send the DIS a Reverse Metric TLV with the W bit clear when Router B | send the DIS a Reverse Metric TLV with the W bit clear when Router B | |||
| wishes the DIS to add the Metric value to the Default Metric | wishes the DIS to add the Metric value to the Default Metric | |||
| contained in the Pseudonode LSP specific to just Router B. Other | contained in the Pseudonode LSP specific to just Router B. Other | |||
| non-DIS nodes, e.g., Routers C and D, may simultaneously send a | non-DIS nodes, e.g., Routers C and D, may simultaneously send a | |||
| Reverse Metric TLV with the W bit clear to request the DIS to add | Reverse Metric TLV with the W bit clear to request the DIS to add | |||
| their own Metric value to their Default Metric contained in the | their own Metric value to their Default Metric contained in the | |||
| skipping to change at page 9, line 12 ¶ | skipping to change at page 9, line 35 ¶ | |||
| described in [RFC5443], it SHOULD advertise the maximum metric offset | described in [RFC5443], it SHOULD advertise the maximum metric offset | |||
| value in the Reverse Metric TLV in its IIH PDU sent on the LAN. It | value in the Reverse Metric TLV in its IIH PDU sent on the LAN. It | |||
| SHOULD continue this advertisement until it completes all the LDP | SHOULD continue this advertisement until it completes all the LDP | |||
| label binding exchanges with all the neighbors over this LAN, either | label binding exchanges with all the neighbors over this LAN, either | |||
| by receiving the LDP End-of-LIB [RFC5919] for all the sessions or by | by receiving the LDP End-of-LIB [RFC5919] for all the sessions or by | |||
| exceeding the provisioned timeout value for the node LDP/IGP | exceeding the provisioned timeout value for the node LDP/IGP | |||
| synchronization. | synchronization. | |||
| 3.5. Operational Guidelines | 3.5. Operational Guidelines | |||
| A router MUST advertise a Reverse Metric TLV toward a neighbor only | For the use case in Section 1.1, a router SHOULD limit the period of | |||
| for the operational maintenance window period during which it wants a | advertising a Reverse Metric TLV towards a neighbor only for the | |||
| neighbor to temporarily update its IS-IS metric or Traffic | duration of network maintenance window. | |||
| Engineering parameters towards it. | ||||
| The use of Reverse Metric does not alter IS-IS metric parameters | The use of Reverse Metric does not alter IS-IS metric parameters | |||
| stored in a router's persistent provisioning database. | stored in a router's persistent provisioning database. | |||
| Routers that receive a Reverse Metric TLV MAY send a syslog message | If routers that receive a Reverse Metric TLV sends a syslog message | |||
| or SNMP trap, in order to assist in rapidly identifying the node in | or SNMP trap, this will assist in rapidly identifying the node in the | |||
| the network that is advertising an IS-IS metric or Traffic | network that is advertising an IS-IS metric or Traffic Engineering | |||
| Engineering parameters different from that which is configured | parameters different from that which is configured locally on the | |||
| locally on the device. | device. | |||
| When the link Traffic Engineering metric is raised to (2^24 - 1) | When the link Traffic Engineering metric is raised to (2^24 - 1) | |||
| [RFC5817], either due to the reverse-metric mechanism or by explicit | [RFC5817], either due to the reverse-metric mechanism or by explicit | |||
| user configuration, this SHOULD immediately trigger the CSPF re- | user configuration, this SHOULD immediately trigger the CSPF | |||
| calculation to move the Traffic Engineering traffic away from that | (Constrained Shortest Path First) re-calculation to move the Traffic | |||
| link. It is RECOMMENDED also that the CSPF does the immediate CSPF | Engineering traffic away from that link. It is RECOMMENDED also that | |||
| re-calculation when the Traffic Engineering metric is raised to (2^24 | the CSPF does the immediate CSPF re-calculation when the Traffic | |||
| - 2) to be the last resort link. | Engineering metric is raised to (2^24 - 2) to be the last resort | |||
| link. | ||||
| It is RECOMMENDED that implementations provide a capability to | It is advisable that implementations provide a configuration | |||
| disable any changes by Reverse Metric mechanism through neighbor's | capability to disable any IS-IS metric changes by Reverse Metric | |||
| Hello PDUs. It can be to a node's individual interface Default | mechanism through neighbor's Hello PDUs. | |||
| Metric or Traffic Engineering parameters based upon receiving a | ||||
| properly formatted Reverse Metric TLVs. | ||||
| If an implementation enables this mechanism by default, it is | If an implementation enables this mechanism by default, it is | |||
| RECOMMENDED that it be disabled by the operators when not explicitly | RECOMMENDED that it be disabled by the operators when not explicitly | |||
| using it. | using it. | |||
| 4. Security Considerations | 4. Security Considerations | |||
| Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], | Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], | |||
| [RFC5310], and with various deployment and operational security | [RFC5310], and with various deployment and operational security | |||
| considerations in [RFC7645]. The enhancement in this document makes | considerations in [RFC7645]. The enhancement in this document makes | |||
| it possible for one IS-IS router to manipulate the IS-IS Default | it possible for one IS-IS router to manipulate the IS-IS Default | |||
| Metric and, optionally, Traffic Engineering parameters of adjacent | Metric and, optionally, Traffic Engineering parameters of adjacent | |||
| IS-IS neighbors. Although IS-IS routers within a single Autonomous | IS-IS neighbors on point-to-point or LAN interfaces. Although IS-IS | |||
| System nearly always are under the control of a single administrative | routers within a single Autonomous System nearly always are under the | |||
| authority, it is highly RECOMMENDED that operators configure | control of a single administrative authority, it is highly | |||
| authentication of IS-IS PDUs to mitigate use of the Reverse Metric | recommended that operators configure authentication of IS-IS PDUs to | |||
| TLV as a potential attack vector. | mitigate use of the Reverse Metric TLV as a potential attack vector. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| IANA has allocated IS-IS TLV Codepoints of 16 for the Reverse Metric | IANA has allocated IS-IS TLV Codepoints of 16 for the Reverse Metric | |||
| TLV. This new TLV has the following attributes: IIH = y, LSP = n, | TLV. This new TLV has the following attributes: IIH = y, LSP = n, | |||
| SNP = n, Purge = n. | SNP = n, Purge = n. | |||
| This document also introduces a new registry for sub-TLVs of the | This document also introduces a new registry for sub-TLVs of the | |||
| Reverse Metric TLV. The registration policy is Expert Review as | Reverse Metric TLV. The registration policy is Expert Review as | |||
| defined in [RFC8126]. This registry is part of the "IS-IS TLV | defined in [RFC8126]. This registry is part of the "IS-IS TLV | |||
| skipping to change at page 10, line 33 ¶ | skipping to change at page 11, line 11 ¶ | |||
| 18: Traffic Engineering Metric sub-TLV, as specified in this | 18: Traffic Engineering Metric sub-TLV, as specified in this | |||
| document (Section 2) | document (Section 2) | |||
| 19-255: Unassigned | 19-255: Unassigned | |||
| 6. Acknowledgments | 6. Acknowledgments | |||
| The authors would like to thank Mike Shand, Dave Katz, Guan Deng, | The authors would like to thank Mike Shand, Dave Katz, Guan Deng, | |||
| Ilya Varlashkin, Jay Chen, Les Ginsberg, Peter Ashwood-Smith, Uma | Ilya Varlashkin, Jay Chen, Les Ginsberg, Peter Ashwood-Smith, Uma | |||
| Chunduri, Alexander Okonnikov, Jonathan Harrison, Dave Ward, Himanshu | Chunduri, Alexander Okonnikov, Jonathan Harrison, Dave Ward, Himanshu | |||
| Shah, Wes George, Danny McPherson, Ed Crabbe, Russ White, Robert | Shah, Wes George, Danny McPherson, Ed Crabbe, Russ White, Robert | |||
| Razsuk, Tom Petch and Acee Lindem for their comments and | Raszuk, Tom Petch, Stewart Bryant and Acee Lindem for their comments | |||
| contributions. | and contributions. | |||
| This document was produced using Marshall Rose's xml2rfc tool. | This document was produced using Marshall Rose's xml2rfc tool. | |||
| 7. References | 7. References | |||
| 7.1. Normative References | 7.1. Normative References | |||
| [ISO10589] | [ISO10589] | |||
| ISO, "Intermediate system to Intermediate system routeing | ISO, "Intermediate system to Intermediate system routeing | |||
| information exchange protocol for use in conjunction with | information exchange protocol for use in conjunction with | |||
| skipping to change at page 11, line 42 ¶ | skipping to change at page 12, line 14 ¶ | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| 7.2. Informative References | 7.2. Informative References | |||
| [I-D.shen-isis-spine-leaf-ext] | [I-D.shen-isis-spine-leaf-ext] | |||
| Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS | Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS | |||
| Routing for Spine-Leaf Topology", draft-shen-isis-spine- | Routing for Spine-Leaf Topology", draft-shen-isis-spine- | |||
| leaf-ext-03 (work in progress), March 2017. | leaf-ext-07 (work in progress), October 2018. | |||
| [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic | [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic | |||
| Authentication", RFC 5304, DOI 10.17487/RFC5304, October | Authentication", RFC 5304, DOI 10.17487/RFC5304, October | |||
| 2008, <https://www.rfc-editor.org/info/rfc5304>. | 2008, <https://www.rfc-editor.org/info/rfc5304>. | |||
| [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | |||
| and M. Fanto, "IS-IS Generic Cryptographic | and M. Fanto, "IS-IS Generic Cryptographic | |||
| Authentication", RFC 5310, DOI 10.17487/RFC5310, February | Authentication", RFC 5310, DOI 10.17487/RFC5310, February | |||
| 2009, <https://www.rfc-editor.org/info/rfc5310>. | 2009, <https://www.rfc-editor.org/info/rfc5310>. | |||
| skipping to change at page 13, line 49 ¶ | skipping to change at page 14, line 21 ¶ | |||
| In theory, use of a Network Management System (NMS) could improve the | In theory, use of a Network Management System (NMS) could improve the | |||
| accuracy of identifying the appropriate subset of routers attached to | accuracy of identifying the appropriate subset of routers attached to | |||
| either a point-to-point link or a multi-access LAN as well as | either a point-to-point link or a multi-access LAN as well as | |||
| signaling from the NMS to those devices, using a network management | signaling from the NMS to those devices, using a network management | |||
| protocol to adjust the IS-IS metrics on the pertinent set of | protocol to adjust the IS-IS metrics on the pertinent set of | |||
| interfaces. The reality is that NMSs are, to a very large extent, | interfaces. The reality is that NMSs are, to a very large extent, | |||
| not used within Service Provider's networks for a variety of reasons. | not used within Service Provider's networks for a variety of reasons. | |||
| In particular, NMSs do not interoperate very well across different | In particular, NMSs do not interoperate very well across different | |||
| vendors or even separate platform families within the same vendor. | vendors or even separate platform families within the same vendor. | |||
| The risks of misidentifying one side of a point-to-point link or one | ||||
| or more interfaces attached to a multi-access LAN and subsequently | ||||
| increasing its IS-IS metric and potentially increased latency, jitter | ||||
| or packet loss. This is unacceptable given the necessary performance | ||||
| requirements for a variety of reasons including the customer | ||||
| perception for near lossless operations and the associated demanding | ||||
| Service Level Agreement's (SLAs) for all network services. | ||||
| Appendix C. Contributors' Addresses | Appendix C. Contributors' Addresses | |||
| Tony Li | Tony Li | |||
| Email: tony.li@tony.li | Email: tony.li@tony.li | |||
| Authors' Addresses | Authors' Addresses | |||
| Naiming Shen | Naiming Shen | |||
| Cisco Systems | Cisco Systems | |||
| End of changes. 28 change blocks. | ||||
| 74 lines changed or deleted | 73 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||