idnits 2.17.1 draft-chen-isis-ias-lk-01.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 (September 11, 2017) is 2412 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 231, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC6805' is defined on line 242, 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 Huawei Technologies 4 Intended status: Standards Track M. Toy 5 Expires: March 15, 2018 Verizon 6 X. Liu 7 Jabil 8 L. Liu 9 Fujitsu 10 Z. Li 11 China Mobile 12 Y. Yang 13 Sockrate 14 September 11, 2017 16 ISIS Extensions for Broadcast Inter-AS TE Link 17 draft-chen-isis-ias-lk-01 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 http://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 March 15, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 60 3. Information on Inter-AS TE Link . . . . . . . . . . . . . . . . 3 61 4. Extensions to ISIS . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2.1. ISIS Router Procedure . . . . . . . . . . . . . . . . . 5 65 4.2.2. Super Node Procedure . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 Connections among different Autonomous Systems (ASes) may be point- 76 to-point (P2P) links and broadcast links. For a P2P inter-AS TE 77 link, RFC 5316 defines a new TLV, the inter-AS reachability TLV, for 78 advertising the link. 80 It also defines three new sub-TLVs for inclusion in the inter-AS 81 reachability TLV to carry the information about the neighboring AS 82 number and the remote ASBR ID of an inter-AS link. 84 For a P2P inter-AS link, the information about its remote ASBR may be 85 configured. For a broadcast inter-AS link, no item configured 86 corresponds to the designated router (DR) of the link in ISIS. Since 87 no ISIS runs over any broadcast inter-AS link, no DR is selected. It 88 is hard to configure an item corresponding to the DR on a broadcast 89 link. 91 This document presents extensions to ISIS for advertising broadcast 92 inter-AS TE links through defining a new sub-TLV for a broadcast link 93 without configuring any item corresponding to the DR on the link. 95 2. Conventions Used in This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Information on Inter-AS TE Link 103 For a broadcast link connecting multiple ASBRs in a number of ASes, 104 on each of the ASBRs X, the following information about the link may 105 be obtained: 107 1) Link Type: Multi-access 108 2) Local IP address with mask length 109 3) Traffic engineering metric 110 4) Maximum bandwidth 111 5) Maximum reservable bandwidth 112 6) Unreserved bandwidth 113 7) Administrative group 114 8) SRLG 116 No remote IP address or item corresponding to the DR (i.e., DR's 117 interface address) may be obtained. 119 4. Extensions to ISIS 121 4.1. sub-TLVs 123 Two new sub-TLVs are defined. One is for local IPv4 address with 124 mask length; and the other is for local IPv6 address with mask 125 length. 127 The format of the sub-TLV for a local IPv4 address with mask length 128 is shown as follows. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type (stTBD1) | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | IPv4 Address (4 bytes) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Mask Length | 138 +-+-+-+-+-+-+-+-+ 140 The IPv4 Address indicates the local IPv4 address of a link. The 141 Mask Length indicates the length of the IPv4 address mask. 143 The format of the sub-TLV for a local IPv6 address with mask length 144 is illustrated below. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type (stTBD2) | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | IPv6 Address (16 bytes) | 152 ~ ~ 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Mask Length | 155 +-+-+-+-+-+-+-+-+ 157 The IPv6 Address indicates the local IPv6 address of a link. The 158 Mask Length indicates the length of the IPv6 address mask. 160 4.2. Procedures 161 4.2.1. ISIS Router Procedure 163 For a broadcast inter-AS link connecting to multiple ASBRs, each of 164 the ASBRs as an ISIS router advertises an LSP with an inter-AS 165 reachability TLV, which contains sub-TLVs for the information such as 166 1) 10 8) about the broadcast link described in Section 3. It does 167 not contain any sub-TLVs indicating remote ASBR, instead, it includes 168 a sub-TLV for the local IP address with network mask. 170 When TE is enabled on an inter-AS link and the link is up, the ASBR 171 SHOULD advertise this link using the normal procedures for ISIS-TE. 172 When either the link is down or TE is disabled on the link, the ASBR 173 SHOULD withdraw the advertisement. When there are changes to the TE 174 parameters for the link (for example, when the available bandwidth 175 changes), the ASBR SHOULD re-advertise the link but MUST take 176 precautions against excessive re-advertisements. 178 4.2.2. Super Node Procedure 180 Suppose that there is a super node, which just receives LSPs from 181 each of ASes (or domains) through a passive ISIS adjacency between 182 the super node and an ASBR or a normal router in the AS or domain. 184 For a new broadcast link connecting multiple routers, when the super 185 node receives an LSP containing the link attached to router X, it 186 stores the link from X into its TED. It finds the link's remote end 187 P using the link's local IP address with network mask. P is a Pseudo 188 node identified by the local IP address of the DR selected from the 189 routers connected to the link. After finding P, it associates the 190 link attached to X with P and the link connected to P with X. If P is 191 not found, a new Pseudo node P is created. The super node associates 192 the link attached to X with P and the link attached to P with X. This 193 creates a bidirectional connection between X and P. 195 The first router and second router from which the super node receives 196 an LSP containing the link are selected as the DR and BDR 197 respectively. After the DR is down, the BDR becomes the DR and the 198 router other than the DR with the largest (or smallest) local IP 199 address connecting to the link is selected as the BDR. 201 When the old DR is down and the BDR becomes the new DR, the super 202 node updates its TED through removing the link between each of 203 routers X and old P (the Pseudo node corresponding to the old DR) and 204 adding a link between each of routers X (still connecting to the 205 broadcast link) and new P (the Pseudo node corresponding to the new 206 DR). 208 5. Security Considerations 210 The mechanism described in this document does not raise any new 211 security issues for the ISIS protocols. 213 6. IANA Considerations 215 This section specifies requests for IANA allocation. 217 7. Acknowledgement 219 The authors would like to thank all for their valuable comments on 220 this draft. 222 8. References 224 8.1. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 228 RFC2119, March 1997, 229 . 231 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 232 Support of Inter-Autonomous System (AS) MPLS and GMPLS 233 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 234 December 2008, . 236 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 237 Engineering", RFC 5305, DOI 10.17487/RFC5305, 238 October 2008, . 240 8.2. Informative References 242 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 243 Path Computation Element Architecture to the Determination 244 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 245 DOI 10.17487/RFC6805, November 2012, 246 . 248 Authors' Addresses 250 Huaimo Chen 251 Huawei Technologies 252 Boston, MA, 253 USA 255 EMail: Huaimo.chen@huawei.com 257 Mehmet Toy 258 Verizon 259 USA 261 EMail: mehmet.toy@verizon.com 263 Xufeng Liu 264 Jabil 265 McLean, VA 266 USA 268 EMail: Xufeng_Liu@jabil.com 270 Lei Liu 271 Fujitsu 272 USA 274 EMail: lliu@us.fujitsu.com 276 Zhenqiang Li 277 China Mobile 278 No.32 Xuanwumenxi Ave., Xicheng District 279 Beijing 100032 280 P.R. China 282 EMail: li_zhenqiang@hotmail.com 284 Yi Yang 285 Sockrate 286 NC 287 USA 289 EMail: yyang1998@gmail.com