draft-ietf-isis-reverse-metric-12.txt | draft-ietf-isis-reverse-metric-12-review.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: March 28, 2019 Apple, Inc. | |||
M. Abrahamsson | M. Abrahamsson | |||
T-Systems Nordic | T-Systems Nordic | |||
August 20, 2018 | September 24, 2018 | |||
IS-IS Routing with Reverse Metric | IS-IS Routing with Reverse Metric | |||
draft-ietf-isis-reverse-metric-12 | draft-ietf-isis-reverse-metric-12 | |||
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 | |||
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 March 28, 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 . . . . . . . . . . . . . 12 | |||
Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13 | Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
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. | |||
1.1. Node and Link Isolation | 1.1. Node and Link Isolation | |||
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 Traffic Engineering (TE) 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 Extended | ||||
IS Reachability sub-TLVs [RFC5305]. | ||||
The Reverse Metric TLV may be optionally 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. If an IS-IS node received of IS-IS Reverse Metric TLV | ||||
in the PDU other than the IS-IS Hello PDU, this TLV MUST be ignored. | ||||
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 Reverse Metric TLV MAY include sub-TLVs when an IS-IS router | |||
wishes to signal to its neighbor to raise its Traffic Engineering | wishes to signal to its neighbor to raise its Traffic Engineering | |||
(TE) Metric over the link. In this document, only the "Traffic | (TE) Metric over the link. The Sub-TLV Type 18, the "Traffic | |||
Engineering Default Metric" sub-TLV [RFC5305], sub-TLV Type 18, is | Engineering Default Metric" sub-TLV [RFC5305], is defined to be | |||
defined and MAY be included in the Reverse Metric TLV, because that | included in the Reverse Metric TLV. Upon receiving this Traffic | |||
is a similar 'reverse metric' operation to be used in TE | Engineering METRIC sub-TLV in a Reverse Metric TLV, a node SHOULD add | |||
computations. Upon receiving this TE METRIC sub-TLV in a Reverse | the received Traffic Engineering Default Metric offset value to its | |||
Metric TLV, a node SHOULD add the received TE metric offset value to | existing, configured Traffic Engineering Default Metric within its | |||
its existing, configured TE default metric within its Extended IS | Extended IS Reachability TLV. Use of other sub-TLVs is outside the | |||
Reachability TLV. Use of other sub-TLVs is outside the scope of this | scope of this document. The "sub-TLV Len" value MUST be set to zero | |||
document. The "sub-TLV Len" value MUST be set to zero when an IS-IS | when an IS-IS router does not have Traffic Engineering sub-TLVs that | |||
router does not have TE sub-TLVs that it wishes to send to its IS-IS | it wishes to send to its IS-IS neighbor. | |||
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. | ||||
4. Security Considerations | 4. Security Considerations | |||
The enhancement in this document makes it possible for one IS-IS | The enhancement in this document makes it possible for one IS-IS | |||
router to manipulate the IS-IS default metric and, optionally, | router to manipulate the IS-IS Default Metric and, optionally, | |||
Traffic Engineering parameters of adjacent IS-IS neighbors. Although | Traffic Engineering parameters of adjacent IS-IS neighbors. Although | |||
IS-IS routers within a single Autonomous System nearly always are | IS-IS routers within a single Autonomous System nearly always are | |||
under the control of a single administrative authority, it is highly | under the control of a single administrative authority, it is highly | |||
RECOMMENDED that operators configure authentication of IS-IS PDUs to | RECOMMENDED that operators configure authentication of IS-IS PDUs to | |||
mitigate use of the Reverse Metric TLV as a potential attack vector, | mitigate use of the Reverse Metric TLV as a potential attack vector, | |||
particularly on multi-access LANs. | particularly on multi-access LANs. | |||
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 20 | |||
[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 | ||||
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March | ||||
2009, <https://www.rfc-editor.org/info/rfc5443>. | ||||
[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>. | |||
End of changes. 35 change blocks. | ||||
128 lines changed or deleted | 126 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/ |