idnits 2.17.1 draft-chen-isis-ias-lk-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 6, 2021) is 1178 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5316' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'RFC6805' is defined on line 244, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track M. Toy 5 Expires: July 10, 2021 Verizon 6 X. Liu 7 Volta Networks 8 L. Liu 9 Fujitsu 10 Z. Li 11 China Mobile 12 Y. Yang 13 IBM 14 January 6, 2021 16 ISIS Extensions for Broadcast Inter-AS TE Link 17 draft-chen-isis-ias-lk-06 19 Abstract 21 This document presents extensions to the ISIS protocol for 22 advertising broadcast inter-AS Traffic Engineering (TE) links. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 10, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 3. Information on Inter-AS TE Link . . . . . . . . . . . . . . . 3 61 4. Extensions to ISIS . . . . . . . . . . . . . . . . . . . . . 3 62 4.1. sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2.1. ISIS Router Procedure . . . . . . . . . . . . . . . . 4 65 4.2.2. Super Node Procedure . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 8.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 Connections among different Autonomous Systems (ASes) may be point- 77 to-point (P2P) links and broadcast links. For a P2P inter-AS TE 78 link, RFC 5316 defines a new TLV, the inter-AS reachability TLV, for 79 advertising the link. 81 It also defines three new sub-TLVs for inclusion in the inter-AS 82 reachability TLV to carry the information about the neighboring AS 83 number and the remote ASBR ID of an inter-AS link. 85 For a P2P inter-AS link, the information about its remote ASBR may be 86 configured. For a broadcast inter-AS link, no item configured 87 corresponds to the designated router (DR) of the link in ISIS. Since 88 no ISIS runs over any broadcast inter-AS link, no DR is selected. It 89 is hard to configure an item corresponding to the DR on a broadcast 90 link. 92 This document presents extensions to ISIS for advertising broadcast 93 inter-AS TE links through defining a new sub-TLV for a broadcast link 94 without configuring any item corresponding to the DR on the link. 96 2. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Information on Inter-AS TE Link 104 For a broadcast link connecting multiple ASBRs in a number of ASes, 105 on each of the ASBRs X, the following information about the link may 106 be obtained: 108 1) Link Type: Multi-access 109 2) Local IP address with mask length 110 3) Traffic engineering metric 111 4) Maximum bandwidth 112 5) Maximum reservable bandwidth 113 6) Unreserved bandwidth 114 7) Administrative group 115 8) SRLG 117 No remote IP address or item corresponding to the DR (i.e., DR's 118 interface address) may be obtained. 120 4. Extensions to ISIS 122 4.1. sub-TLVs 124 Two new sub-TLVs are defined. One is for local IPv4 address with 125 mask length; and the other is for local IPv6 address with mask 126 length. 128 The format of the sub-TLV for a local IPv4 address with mask length 129 is shown as follows. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Type (stTBD1) | Length | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | IPv4 Address (4 bytes) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Mask Length | 139 +-+-+-+-+-+-+-+-+ 141 The IPv4 Address indicates the local IPv4 address of a link. The 142 Mask Length indicates the length of the IPv4 address mask. 144 The format of the sub-TLV for a local IPv6 address with mask length 145 is illustrated below. 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type (stTBD2) | Length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | IPv6 Address (16 bytes) | 153 ~ ~ 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Mask Length | 156 +-+-+-+-+-+-+-+-+ 158 The IPv6 Address indicates the local IPv6 address of a link. The 159 Mask Length indicates the length of the IPv6 address mask. 161 4.2. Procedures 163 4.2.1. ISIS Router Procedure 165 For a broadcast inter-AS link connecting to multiple ASBRs, each of 166 the ASBRs as an ISIS router advertises an LSP with an inter-AS 167 reachability TLV, which contains sub-TLVs for the information such as 168 1) 10 8) about the broadcast link described in Section 3. It does 169 not contain any sub-TLVs indicating remote ASBR, instead, it includes 170 a sub-TLV for the local IP address with network mask. 172 When TE is enabled on an inter-AS link and the link is up, the ASBR 173 SHOULD advertise this link using the normal procedures for ISIS-TE. 174 When either the link is down or TE is disabled on the link, the ASBR 175 SHOULD withdraw the advertisement. When there are changes to the TE 176 parameters for the link (for example, when the available bandwidth 177 changes), the ASBR SHOULD re-advertise the link but MUST take 178 precautions against excessive re-advertisements. 180 4.2.2. Super Node Procedure 182 Suppose that there is a super node, which just receives LSPs from 183 each of ASes (or domains) through a passive ISIS adjacency between 184 the super node and an ASBR or a normal router in the AS or domain. 186 For a new broadcast link connecting multiple routers, when the super 187 node receives an LSP containing the link attached to router X, it 188 stores the link from X into its TED. It finds the link's remote end 189 P using the link's local IP address with network mask. P is a Pseudo 190 node identified by the local IP address of the DR selected from the 191 routers connected to the link. After finding P, it associates the 192 link attached to X with P and the link connected to P with X. If P 193 is not found, a new Pseudo node P is created. The super node 194 associates the link attached to X with P and the link attached to P 195 with X. This creates a bidirectional connection between X and P. 197 The first router and second router from which the super node receives 198 an LSP containing the link are selected as the DR and BDR 199 respectively. After the DR is down, the BDR becomes the DR and the 200 router other than the DR with the largest (or smallest) local IP 201 address connecting to the link is selected as the BDR. 203 When the old DR is down and the BDR becomes the new DR, the super 204 node updates its TED through removing the link between each of 205 routers X and old P (the Pseudo node corresponding to the old DR) and 206 adding a link between each of routers X (still connecting to the 207 broadcast link) and new P (the Pseudo node corresponding to the new 208 DR). 210 5. Security Considerations 212 The mechanism described in this document does not raise any new 213 security issues for the ISIS protocols. 215 6. IANA Considerations 217 This section specifies requests for IANA allocation. 219 7. Acknowledgement 221 The authors would like to thank all for their valuable comments on 222 this draft. 224 8. References 226 8.1. Normative References 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, 230 DOI 10.17487/RFC2119, March 1997, 231 . 233 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 234 Support of Inter-Autonomous System (AS) MPLS and GMPLS 235 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 236 December 2008, . 238 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 239 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 240 2008, . 242 8.2. Informative References 244 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 245 Path Computation Element Architecture to the Determination 246 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 247 DOI 10.17487/RFC6805, November 2012, 248 . 250 Authors' Addresses 252 Huaimo Chen 253 Futurewei 255 Boston, MA 256 USA 258 EMail: hchen@futurewei.com 260 Mehmet Toy 261 Verizon 263 , 264 USA 266 EMail: mehmet.toy@verizon.com 268 Xufeng Liu 269 Volta Networks 271 McLean, VA 272 USA 274 EMail: xufeng.liu.ietf@gmail.com 275 Lei Liu 276 Fujitsu 278 USA 280 EMail: liulei.kddi@gmail.com 282 Zhenqiang Li 283 China Mobile 284 No.32 Xuanwumenxi Ave., Xicheng District 285 Beijing 100032 286 P.R. China 288 EMail: li_zhenqiang@hotmail.com 290 Yi Yang 291 IBM 293 , NC 294 USA 296 EMail: yyang1998@gmail.com