draft-ietf-isis-reverse-metric-12.txt   draft-ietf-isis-reverse-metric-13.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: February 21, 2019 Apple, Inc. Expires: April 5, 2019 Apple, Inc.
M. Abrahamsson M. Abrahamsson
T-Systems Nordic T-Systems Nordic
August 20, 2018 October 2, 2018
IS-IS Routing with Reverse Metric IS-IS Routing with Reverse Metric
draft-ietf-isis-reverse-metric-12 draft-ietf-isis-reverse-metric-13
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 February 21, 2019. This Internet-Draft will expire on April 5, 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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . 3
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. Point-To-Point Link Procedures . . . . . . . . . . . . . 8 3.4. LDP/IGP Synchronization on LANs . . . . . . . . . . . . . 8
3.5. LDP/IGP Synchronization on LANs . . . . . . . . . . . . . 8 3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9
3.6. Operational Guidelines . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . 12 Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 13
Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13 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.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
and have traffic bidirectionally shift away from that link gracefully and have traffic bidirectionally shift away from that link gracefully
to alternate, viable paths. to alternate, viable paths.
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 TE metric in the The metric value in the "reverse metric" TLV and the Traffic
sub-TLV being advertised is an offset or relative metric to be added Engineering metric in the sub-TLV being advertised is an offset or
to the existing local link and TE metric values of the receiver. relative metric to be added to the existing local link and Traffic
Engineering metric values of the receiver.
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 composed of a 1 octet field of Flags, a 3 The Reverse Metric TLV is a new TLV to be used inside IS-IS Hello
octet field containing an IS-IS Metric Value, and a 1 octet Traffic PDU. This TLV is used to support the IS-IS Reverse Metric mechanism
Engineering (TE) sub-TLV length field representing the length of a that allows a "reverse metric" to be send to the IS-IS neighbor.
variable number of Extended Intermediate System (IS) Reachability
sub-TLVs. If the "sub-TLV len" is non-zero, then the Value field
MUST also contain one or more Extended IS Reachability sub-TLVs.
The Reverse Metric TLV is optional. The Reverse Metric TLV may be
present in any IS-IS Hello PDU. A sender MUST only transmit a single
Reverse Metric TLV in a IS-IS Hello PDU. If a received IS-IS Hello
PDU contains more than one Reverse Metric TLV, an implementation
SHOULD ignore all the Reverse Metric TLVs and treat it as an error
condition.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reverse Metric TLV Figure 1: Reverse Metric TLV
TYPE: TBD (be replaced by the value that IANA allocates) The Value part of the Reverse Metric TLV is composed of a 3 octet
field containing an IS-IS Metric Value, a 1 octet field of Flags, and
a 1 octet Reverse Metric sub-TLV length field representing the length
of a variable number of sub-TLVs. If the "sub-TLV len" is non-zero,
then the Value field MUST also contain one or more sub-TLVs.
The Reverse Metric TLV MAY be present in any IS-IS Hello PDU. A
sender MUST only transmit a single Reverse Metric TLV in a IS-IS
Hello PDU. If a received IS-IS Hello PDU contains more than one
Reverse Metric TLV, an implementation MUST ignore all the Reverse
Metric TLVs.
TYPE: 16
LENGTH: variable (5 - 255 octets) LENGTH: variable (5 - 255 octets)
VALUE: VALUE:
Flags (1 octet) Flags (1 octet)
Metric (3 octets) Metric (3 octets)
sub-TLV length (1 octet) sub-TLV length (1 octet)
sub-TLV data (0 - 250 octets) sub-TLV data (0 - 250 octets)
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |U|W| | Reserved |U|W|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1: Flags Figure 2: Flags
The Metric field contains a 24-bit unsigned integer. This value is a The Metric field contains a 24-bit unsigned integer. This value is a
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. 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
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
in the range of 0 - (2^24 - 2) when a "wide" Traffic Engineering
metric value is used, (Extended IS Reachability TLV) [RFC5305]
[RFC5817].
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 Reverse Metric TLV to each node's existing Default Metric in the
the Pseudonode LSP. If the "Whole LAN" bit is not set (0), then a Pseudonode LSP. If the "Whole LAN" bit is not set (0), then a DIS
DIS SHOULD add the received Metric value in the Reverse Metric TLV to SHOULD add the received Metric value in the Reverse Metric TLV to the
the existing "default metric" in the Pseudonode LSP for the single existing "default metric" in the Pseudonode LSP for the single node
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 value to the "default
metric" is limited to (2^24-1). This "U" bit applies to both the metric" is limited to (2^24-1). This "U" bit applies to both the
default metric in the Extended IS Reachability TLV and the TE default metric in the Extended IS Reachability TLV and the Traffic
default-metric sub-TLV of the link. This is only relevant to the IS- Engineering Default Metric sub-TLV of the link. This is only
IS "wide" metric mode. relevant to the IS-IS "wide" metric mode.
The Reverse Metric TLV can include sub-TLVs when an IS-IS router The Reserved bits of Flags field MUST be set to zero and MUST be
wishes to signal to its neighbor to raise its Traffic Engineering ignored when received.
(TE) Metric over the link. In this document, only the "Traffic
Engineering Default Metric" sub-TLV [RFC5305], sub-TLV Type 18, is The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router
defined and MAY be included in the Reverse Metric TLV, because that wishes to signal additional information to its neighbor. In this
is a similar 'reverse metric' operation to be used in TE document, the Reverse Metric Traffic Engineering Metric sub-TLV, with
computations. Upon receiving this TE METRIC sub-TLV in a Reverse Type 18, is defined. This Traffic Engineering Metric contains a
Metric TLV, a node SHOULD add the received TE metric offset value to 24-bit unsigned integer. This sub-TLV is optional, if it appears
its existing, configured TE default metric within its Extended IS more than once then the entire Reverse Metric TLV MUST be ignored.
Reachability TLV. Use of other sub-TLVs is outside the scope of this Upon receiving this Traffic Engineering METRIC sub-TLV in a Reverse
document. The "sub-TLV Len" value MUST be set to zero when an IS-IS Metric TLV, a node SHOULD add the received Traffic Engineering Metric
router does not have TE sub-TLVs that it wishes to send to its IS-IS offset value to its existing, configured Traffic Engineering Default
neighbor. Metric within its Extended IS Reachability TLV. The use of other
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
Engineering sub-TLVs that it wishes to send to its IS-IS neighbor.
3. Elements of Procedure 3. Elements of Procedure
3.1. Processing Changes to Default Metric 3.1. Processing Changes to Default Metric
The Metric field, in the Reverse Metric TLV, is a "reverse offset It is important to use the same IS-IS metric type on both ends of the
metric" that will either be in the range of 0 - 63 when a "narrow" link and in the entire IS-IS area or level. On the receiving side of
IS-IS metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or the 'reverse-metric' TLV, the accumulated value of configured metric
in the range of 0 - (2^24 - 2) when a "wide" Traffic Engineering and the reverse-metric needs to be limited to 63 in "narrow" metric
metric value is used, (Extended IS Reachability TLV) [RFC5305] mode and to (2^24 - 2) in "wide" metric mode. This applies to both
[RFC5817]. It is important to use the same IS-IS metric mode on both the Default Metric of Extended IS Reachability TLV and the Traffic
ends of the link. On the receiving side of the 'reverse-metric' TLV, Engineering Default Metric sub-TLV in LSP or Pseudonode LSP for the
the accumulated value of configured metric and the reverse-metric "wide" metric mode case. If the "U" bit is present in the flags, the
needs to be limited to 63 in "narrow" metric mode and to (2^24 - 2) accumulated metric value is to be limited to (2^24 - 1) for both the
in "wide" metric mode. This applies to both the default metric of normal link metric and Traffic Engineering metric in IS-IS "wide"
Extended IS Reachability TLV and the TE default-metric sub-TLV in LSP metric mode.
or Pseudonode LSP for the "wide" metric mode case. If the "U" bit is
present in the flags, the accumulated metric value is to be limited
to (2^24 - 1) for both the normal link metric and TE metric in IS-IS
"wide" metric mode.
If an IS-IS router is configured to originate a TE Default Metric If an IS-IS router is configured to originate a Traffic Engineering
sub-TLV for a link, but receives a Reverse Metric TLV from its Default Metric sub-TLV for a link, but receives a Reverse Metric TLV
neighbor that does not contain a TE Default Metric sub-TLV, then the from its neighbor that does not contain a Traffic Engineering Default
IS-IS router MUST NOT change the value of its TE Default Metric sub- Metric sub-TLV, then the IS-IS router MUST NOT change the value of
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 in all Extended IS Reachability TLVs for all
topologies. If an M-ISIS router receives a Reverse Metric TLV with a topologies. If an M-ISIS router receives a Reverse Metric TLV with a
TE Default Metric sub-TLV, then the M-ISIS router MUST add the Traffic Engineering Default Metric sub-TLV, then the M-ISIS router
received TE Default Metric value to each of its TE Default Metric MUST add the received Traffic Engineering Default Metric value to
sub-TLVs in all of its MT Intermediate Systems TLVs. If an M-ISIS each of its Default Metric sub-TLVs in all of its MT Intermediate
router is configured to advertise TE Default Metric sub-TLVs for one Systems TLVs. If an M-ISIS router is configured to advertise Traffic
or more topologies, but does not receive a TE Default Metric sub-TLV Engineering Default Metric sub-TLVs for one or more topologies, but
in a Reverse Metric TLV, then the M-ISIS router MUST NOT change the does not receive a Traffic Engineering Default Metric sub-TLV in a
value in each of the TE Default Metric sub-TLVs for all topologies. Reverse Metric TLV, then the M-ISIS router MUST NOT change the value
in each of the Traffic Engineering Default Metric 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 TE sub-TLV also applies to the DIS. If a DIS is The Reverse Metric Traffic Engineering sub-TLV also applies to the
configured to apply TE over a link and it receives TE metric sub-TLV DIS. If a DIS is configured to apply Traffic Engineering over a link
in a Reverse Metric TLV, it should update the TE Default Metric sub- and it receives metric sub-TLV in a Reverse Metric TLV, it should
TLV value of the corresponding Extended IS Reachability TLV or insert update the Traffic Engineering Default Metric sub-TLV value of the
a new one if not present. corresponding Extended IS Reachability TLV or 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
Pseudonode LSP. When the DIS receives a properly formatted Reverse Pseudonode LSP.
Metric TLV with the W bit clear, the DIS MUST only add the default
metric contained in its Pseudonode LSP for the specific neighbor that
sent the corresponding Reverse Metric TLV.
As long as at least one IS-IS node on the LAN sending the signal to As long as at least one IS-IS node on the LAN sending the signal to
DIS with the W bit set, the DIS would add the metric value in the DIS with the W bit set, the DIS would add the metric value in the
Reverse Metric TLV to all neighbor adjacencies in the Pseudonode LSP, Reverse Metric TLV to all neighbor adjacencies in the Pseudonode LSP,
regardless if some of the nodes on the LAN advertise the Reverse regardless if some of the nodes on the LAN advertise the Reverse
Metric TLV without the W bit set. The DIS MUST use the reverse Metric TLV without the W bit set. The DIS MUST use the reverse
metric of the highest source MAC address Non-DIS advertising the metric of the highest source MAC address Non-DIS advertising the
Reverse Metric TLV with the W bit set. The DIS MUST use the metric Reverse Metric TLV with the W bit set.
value towards the nodes which explicitly advertise the Reverse Metric
TLV.
Local provisioning on the DIS to adjust the default metric(s) Local provisioning on the DIS to adjust the Default Metric(s) is
contained in the Pseudonode LSP MUST take precedence over received another way to insert Reverse Metric in the Pseudonode LSP towards an
Reverse Metric TLVs. For instance, local policy on the DIS may be IS-IS node on a LAN. In the case where Reverse Metric TLV is also
provisioned to ignore the W bit signaling on a LAN. used in the IS-IS Hello PDU of the node, the local provisioning MUST
take precedence over received Reverse Metric TLVs. For instance,
local policy on the DIS may be provisioned to ignore the W bit
signaling on a LAN.
Multi-Topology IS-IS [RFC5120] specifies there is no change to Multi-Topology IS-IS [RFC5120] specifies there is no change to
construction of the Pseudonode LSP, regardless of the Multi-Topology construction of the Pseudonode LSP, regardless of the Multi-Topology
capabilities of a multi-access LAN. If any MT capable node on the capabilities of a multi-access LAN. If any MT capable node on the
LAN advertises the Reverse Metric TLV to the DIS, the DIS should LAN advertises the Reverse Metric TLV to the DIS, the DIS should
update, as appropriate, the default metric contained in the update, as appropriate, the Default Metric contained in the
Pseudonode LSP. If the DIS updates the default metric in and floods Pseudonode LSP. If the DIS updates the Default Metric in and floods
a new Pseudonode LSP, those default metric values will be applied to a new Pseudonode LSP, those default metric values will be applied to
all topologies during Multi-Topology SPF calculations. all topologies during Multi-Topology SPF calculations.
3.4. Point-To-Point Link Procedures 3.4. LDP/IGP Synchronization on LANs
On a point-to-point link, there is already a "configured" IS-IS
interface metric to be applied over the link towards the IS-IS
neighbor.
When IS-IS receives the IIH PDU with the "Reverse Metric" on a point-
to-point link and if the local policy allows the supporting of
"Reverse Metric", it MUST add the metric value in "reverse metric"
TLV according to the rules described in Section 3.1 and Section 3.2.
3.5. LDP/IGP Synchronization on LANs
As described in [RFC6138] when a new IS-IS node joins a broadcast As described in [RFC6138] when a new IS-IS node joins a broadcast
network, it is unnecessary and sometimes even harmful for all IS-IS network, it is unnecessary and sometimes even harmful for all IS-IS
nodes on the LAN to advertise maximum link metric. [RFC6138] nodes on the LAN to advertise maximum link metric. [RFC6138]
proposes a solution to have the new node not advertise its adjacency proposes a solution to have the new node not advertise its adjacency
towards the pseudo-node when it is not in a "cut-edge" position. towards the pseudo-node when it is not in a "cut-edge" position.
With the introduction of Reverse Metric in this document, a simpler With the introduction of Reverse Metric in this document, a simpler
alternative solution to the above mentioned problem can be used. The alternative solution to the above mentioned problem can be used. The
Reverse Metric allows the new node on the LAN to advertise its Reverse Metric allows the new node on the LAN to advertise its
skipping to change at page 9, line 20 skipping to change at page 9, line 10
node on the LAN, besides setting the maximum link metric value (2^24 node on the LAN, besides setting the maximum link metric value (2^24
- 2) on the interface of the LAN for LDP IGP synchronization as - 2) on the interface of the LAN for LDP IGP synchronization as
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.6. Operational Guidelines 3.5. Operational Guidelines
A router MUST advertise a Reverse Metric TLV toward a neighbor only A router MUST advertise a Reverse Metric TLV toward a neighbor only
for the period during which it wants a neighbor to temporarily update for the operational maintenance window period during which it wants a
its IS-IS metric or TE parameters towards it. neighbor to temporarily update its IS-IS metric or Traffic
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 Routers that receive a Reverse Metric TLV MAY send a syslog message
or SNMP trap, in order to assist in rapidly identifying the node in or SNMP trap, in order to assist in rapidly identifying the node in
the network that is advertising an IS-IS metric or Traffic the network that is advertising an IS-IS metric or Traffic
Engineering parameters different from that which is configured Engineering parameters different from that which is configured
locally on the device. locally on the device.
When the link TE metric is raised to (2^24 - 1) [RFC5817], either due When the link Traffic Engineering metric is raised to (2^24 - 1)
to the reverse-metric mechanism or by explicit user configuration, [RFC5817], either due to the reverse-metric mechanism or by explicit
this SHOULD immediately trigger the CSPF re-calculation to move the user configuration, this SHOULD immediately trigger the CSPF re-
TE traffic away from that link. It is RECOMMENDED also that the CSPF calculation to move the Traffic Engineering traffic away from that
does the immediate CSPF re-calculation when the TE metric is raised link. It is RECOMMENDED also that the CSPF does the immediate CSPF
to (2^24 - 2) to be the last resort link. re-calculation when the Traffic 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 RECOMMENDED that implementations provide a capability to
disable any changes to a node's individual interface default metric disable any changes by Reverse Metric mechanism through neighbor's
or Traffic Engineering parameters based upon receiving a properly Hello PDUs. It can be to a node's individual interface Default
formatted Reverse Metric TLVs. Metric or Traffic Engineering parameters based upon receiving a
properly formatted Reverse Metric TLVs.
If an implementation enables this mechanism by default, it is
RECOMMENDED that it be disabled by the operators when not explicitly
using it.
4. Security Considerations 4. Security Considerations
The enhancement in this document makes it possible for one IS-IS Security concerns for IS-IS are addressed in [ISO10589], [RFC5304],
router to manipulate the IS-IS default metric and, optionally, [RFC5310], and with various deployment and operational security
Traffic Engineering parameters of adjacent IS-IS neighbors. Although considerations in [RFC7645]. The enhancement in this document makes
IS-IS routers within a single Autonomous System nearly always are it possible for one IS-IS router to manipulate the IS-IS Default
under the control of a single administrative authority, it is highly Metric and, optionally, Traffic Engineering parameters of adjacent
RECOMMENDED that operators configure authentication of IS-IS PDUs to IS-IS neighbors. Although IS-IS routers within a single Autonomous
mitigate use of the Reverse Metric TLV as a potential attack vector, System nearly always are under the control of a single administrative
particularly on multi-access LANs. authority, it is highly RECOMMENDED that operators configure
authentication of IS-IS PDUs to mitigate use of the Reverse Metric
TLV as a potential attack vector.
5. IANA Considerations 5. IANA Considerations
This document requests that IANA allocate from the IS-IS TLV IANA has allocated IS-IS TLV Codepoints of 16 for the Reverse Metric
Codepoints Registry a new TLV, referred to as the "Reverse Metric" TLV. This new TLV has the following attributes: IIH = y, LSP = n,
TLV, with the following attributes: IIH = y, LSP = n, SNP = n, Purge SNP = n, Purge = n.
= 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
Codepoints" registry. The name of the registry is "Sub-TLVs for Codepoints" registry. The name of the registry is "Sub-TLVs for
Reverse Metric TLV". The defined values are: Reverse Metric TLV". The defined values are:
0: Reserved 0: Reserved
1-17: Unassigned 1-17: Unassigned
18: Traffic Engineering Metric sub-TLV, as specified in this 18: Traffic Engineering Metric sub-TLV, as specified in this
skipping to change at page 11, line 24 skipping to change at page 11, line 24
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008, <https://www.rfc- DOI 10.17487/RFC5120, February 2008, <https://www.rfc-
editor.org/info/rfc5120>. editor.org/info/rfc5120>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
2009, <https://www.rfc-editor.org/info/rfc5443>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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-03 (work in progress), March 2017.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2009, <https://www.rfc-editor.org/info/rfc5443>. 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, [RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton,
"Graceful Shutdown in MPLS and Generalized MPLS Traffic "Graceful Shutdown in MPLS and Generalized MPLS Traffic
Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, Engineering Networks", RFC 5817, DOI 10.17487/RFC5817,
April 2010, <https://www.rfc-editor.org/info/rfc5817>. April 2010, <https://www.rfc-editor.org/info/rfc5817>.
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
"Signaling LDP Label Advertisement Completion", RFC 5919, "Signaling LDP Label Advertisement Completion", RFC 5919,
DOI 10.17487/RFC5919, August 2010, <https://www.rfc- DOI 10.17487/RFC5919, August 2010, <https://www.rfc-
editor.org/info/rfc5919>. editor.org/info/rfc5919>.
[RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for [RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for
Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138, Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138,
February 2011, <https://www.rfc-editor.org/info/rfc6138>. February 2011, <https://www.rfc-editor.org/info/rfc6138>.
[RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and
Authentication for Routing Protocol (KARP) IS-IS Security
Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015,
<https://www.rfc-editor.org/info/rfc7645>.
Appendix A. Node Isolation Challenges Appendix A. Node Isolation Challenges
On rare occasions, it is necessary for an operator to perform On rare occasions, it is necessary for an operator to perform
disruptive network maintenance on an entire IS-IS router node, i.e., disruptive network maintenance on an entire IS-IS router node, i.e.,
major software upgrades, power/cooling augments, etc. In these major software upgrades, power/cooling augments, etc. In these
cases, an operator will set the IS-IS Overload Bit (OL-bit) within cases, an operator will set the IS-IS Overload Bit (OL-bit) within
the Link State Protocol Data Units (LSPs) of the IS-IS router about the Link State Protocol Data Units (LSPs) of the IS-IS router about
to undergo maintenance. The IS-IS router immediately floods its to undergo maintenance. The IS-IS router immediately floods its
updated LSPs to all IS-IS routers in the IS-IS domain. Upon receipt updated LSPs to all IS-IS routers in the IS-IS domain. Upon receipt
of the updated LSPs, all IS-IS routers recalculate their Shortest of the updated LSPs, all IS-IS routers recalculate their Shortest
 End of changes. 36 change blocks. 
137 lines changed or deleted 157 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/