idnits 2.17.1 draft-chen-isis-ias-lk-05.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 (July 10, 2020) is 1379 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: January 11, 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 July 10, 2020 16 ISIS Extensions for Broadcast Inter-AS TE Link 17 draft-chen-isis-ias-lk-05 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 January 11, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 254 Boston, MA 255 USA 257 EMail: hchen@futurewei.com 259 Mehmet Toy 260 Verizon 261 USA 263 EMail: mehmet.toy@verizon.com 265 Xufeng Liu 266 Volta Networks 267 McLean, VA 268 USA 270 EMail: xufeng.liu.ietf@gmail.com 272 Lei Liu 273 Fujitsu 274 USA 276 EMail: liulei.kddi@gmail.com 277 Zhenqiang Li 278 China Mobile 279 No.32 Xuanwumenxi Ave., Xicheng District 280 Beijing 100032 281 P.R. China 283 EMail: li_zhenqiang@hotmail.com 285 Yi Yang 286 IBM 287 NC 288 USA 290 EMail: yyang1998@gmail.com