draft-ietf-isis-reverse-metric-16.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: May 8, 2019 Apple, Inc. Expires: June 6, 2019 Apple, Inc.
M. Abrahamsson M. Abrahamsson
T-Systems Nordic T-Systems Nordic
November 4, 2018 December 3, 2018
IS-IS Routing with Reverse Metric IS-IS Routing with Reverse Metric
draft-ietf-isis-reverse-metric-16 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 May 8, 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Node and Link Isolation . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 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 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 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 Hello (IIH) PDU to the neighbor or pseudo-node to adjust the routing
on the inbound direction. 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 27 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 6, line 17 skipping to change at page 6, line 27
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 21 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 21 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
For the use case in Section 1.1, a router SHOULD limit the duration For the use case in Section 1.1, a router SHOULD limit the period of
of advertising a Reverse Metric TLV towards a neighbor only for the advertising a Reverse Metric TLV towards a neighbor only for the
period of operational window. duration of network maintenance window.
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 IS-IS metric changes by Reverse Metric mechanism through capability to disable any IS-IS metric changes by Reverse Metric
neighbor's Hello PDUs. It can be to a node's individual interface mechanism through neighbor's Hello PDUs.
Default 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 14, line 11 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. 23 change blocks. 
66 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/