draft-ietf-isis-reverse-metric-15.txt | draft-ietf-isis-reverse-metric-15-rev.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 19, 2019 Apple, Inc. | Expires: April 24, 2019 Apple, Inc. | |||
M. Abrahamsson | M. Abrahamsson | |||
T-Systems Nordic | T-Systems Nordic | |||
October 16, 2018 | October 21, 2018 | |||
IS-IS Routing with Reverse Metric | IS-IS Routing with Reverse Metric | |||
draft-ietf-isis-reverse-metric-15 | draft-ietf-isis-reverse-metric-15-rev | |||
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 19, 2019. | This Internet-Draft will expire on April 24, 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 . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. Processing Changes to Default Metric . . . . . . . . . . 6 | 3.1. Processing Changes to Default Metric . . . . . . . . . . 6 | |||
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 . . . . . . . . . . . . . 8 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
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 . . . . . . . . . . . . . . . . . 11 | |||
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 | ||||
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 5, line 38 | skipping to change at page 5, line 44 | |||
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 | |||
skipping to change at page 9, line 34 | skipping to change at page 9, line 43 | |||
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 re- | |||
calculation to move the Traffic Engineering traffic away from that | calculation to move the Traffic Engineering traffic away from that | |||
link. It is RECOMMENDED also that the CSPF does the immediate CSPF | link. It is RECOMMENDED also that the CSPF does the immediate CSPF | |||
re-calculation when the Traffic Engineering metric is raised to (2^24 | re-calculation when the Traffic Engineering metric is raised to (2^24 | |||
- 2) to be the last resort link. | - 2) to be the last resort link. | |||
It is RECOMMENDED that implementations provide a capability to | It is RECOMMENDED that implementations provide a capability to | |||
disable any changes by Reverse Metric mechanism through neighbor's | disable any IS-IS metric changes by Reverse Metric mechanism through | |||
Hello PDUs. It can be to a node's individual interface Default | neighbor's Hello PDUs. It can be to a node's individual interface | |||
Metric or Traffic Engineering parameters based upon receiving a | Default Metric or Traffic Engineering parameters based upon receiving | |||
properly formatted Reverse Metric TLVs. | 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. Although IS-IS routers within a single Autonomous | |||
System nearly always are under the control of a single administrative | System nearly always are under the control of a single administrative | |||
authority, it is highly RECOMMENDED that operators configure | authority, it is highly recommended that operators configure | |||
authentication of IS-IS PDUs to mitigate use of the Reverse Metric | authentication of IS-IS PDUs to mitigate use of the Reverse Metric | |||
TLV as a potential attack vector. | 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 | |||
skipping to change at page 10, line 32 | skipping to change at page 10, line 42 | |||
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 | |||
Raszuk, 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 38 | skipping to change at page 11, line 52 | |||
[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>. | |||
End of changes. 14 change blocks. | ||||
18 lines changed or deleted | 26 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |