| Internet-Draft | ISIS-CRH | August 2021 |
| Kaneriya, et al. | Expires 3 March 2022 | [Page] |
Source nodes can use the IPv6 Compressed Routing Header (CRH) to steer packets through a specified path. This document defines IS-IS extensions that support the CRH.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 March 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Source nodes can use the IPv6 Compressed Routing Header (CRH) [I-D.bonica-6man-comp-rtg-hdr] to steer packets through a specified path. This document defines IS-IS extensions that support the CRH.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Router CAPABILITY TLV [RFC7981] MAY contain exactly one CRH sub-TLV. The CRH sub-TLV indicates that the advertising node can process the CRH.¶
The CRH sub-TLV MAY contain sub-sub-TLVs. No sub-sub-TLVs are currently defined.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Max CRH Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 depicts the CRH sub-TLV. The CRH sub-TLV contains the following fields:¶
Note 1: According to [RFC8200], all IPv6 Routings header include a "Hdr Ext Len" field. That field specifies the length of the Routing header in 8-octet units, not including the first 8 octets. The same unit of measure was chosen for the "Max CRH Len" field in the CRH sub-TLV.¶
The following TLVs MAY contain one or more Prefix SID sub-TLVs:¶
The Prefix SID sub-TLV is valid only when its parent TLV specifies a prefix length of 128. In this case, it binds the SID that it contains to the prefix (i.e., IPv6 address) that its parent TLV contains. This information is used to construct the mapping table described in [I-D.bonica-6man-comp-rtg-hdr].¶
When the parent TLV is propagated across level boundaries, the Prefix SID sub-TLV SHOULD be kept.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID
+-+-+-+-+-+-+-+
Figure 2 depicts the Prefix SID sub-TLV. It contains the following fields:¶
The following TLVs can contain one or more Adjacency SID sub-TLVs:¶
The Adjacency SID sub-TLV is valid only when its parent TLV also contains an IPv6 Neighbor Address sub-TLVs [RFC6119]. In this case, the SID contained by the Adjacency SID sub-TLV is bound to the IPv6 address contained by the IPv6 Neighbor Address sub-TLV. This information is used to construct the mapping table described in [I-D.bonica-6man-comp-rtg-hdr].¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3 depicts the Adjacency SID sub-TLV. It contains the following fields:¶
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
Figure 4 depicts Adjacency SID Sub-TLV flags. They include the following:¶
In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the Pseudonode-LSP (PN-LSP) including all neighbors of the DIS.¶
When the CRH is used, each router in the LAN MAY advertise its Adjacency SIDs of each of its neighbors. Since, on LANs, each router only advertises one adjacency to the DIS (and doesn't advertise any other adjacency), each router advertises the set of Adjacency SIDs (for each of its neighbors) inside a newly defined sub-TLV part of the TLV advertising the adjacency to the DIS (e.g.: TLV-22).¶
The following TLVs can contain one or more LAN Adjacency SID sub-TLVs:¶
The LAN Adjacency SID sub-TLV binds an IPv6 address to a SID. The sub-TLV contains both the IPv6 address and the SID. This information is used to construct the mapping table described in [I-D.bonica-6man-comp-rtg-hdr].¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID (ID length octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5 depicts the Adjacency SID sub-TLV. It contains the following fields:¶
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
Figure 6 depicts Adjacency SID Sub-TLV flags. They include the following:¶
IANA is requested to add a new sub-TLV in the Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV) Registry [capreg].¶
This document requests the creation of a new IANA managed registry for sub-sub-TLVs of the CRH sub-TLV. The registration procedure is "Expert Review" as defined in [RFC7370]. Suggested registry name is "sub-sub-TLVs for CRH sub-TLV". No sub- sub-TLVs are defined by this document except for the reserved value.¶
IANA is requested to add a new entry in the Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) Registry [loosereg].¶
IANA is requested to add the following entries in the Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) Registry [strictreg].¶
The first entry follows:¶
The second entry follows:¶
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310].¶
Thanks to Ram Santhanakrishnan for his comments on this document.¶