idnits 2.17.1 draft-chen-ospf-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 1376 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: 'RFC5392' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'RFC5329' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC6805' is defined on line 263, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF 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 OSPF Extensions for Broadcast Inter-AS TE Link 17 draft-chen-ospf-ias-lk-05 19 Abstract 21 This document presents extensions to the Open Shortest Path First 22 (OSPF) for advertising broadcast inter-AS Traffic Engineering (TE) 23 links. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 11, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 3. Information on Inter-AS TE Link . . . . . . . . . . . . . . . 3 62 4. Extensions to OSPF . . . . . . . . . . . . . . . . . . . . . 3 63 4.1. sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.2.1. OSPF Router Procedure . . . . . . . . . . . . . . . . 4 66 4.2.2. Super Node Procedure . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Connections among different Autonomous Systems (ASes) may be point- 78 to-point (P2P) links and broadcast links. For a P2P inter-AS TE 79 link, RFC 5392 defines a new Opaque LSA, the Inter-AS-TE-v2 LSA, for 80 advertising the OSPFv2 link; and a new OSPFv3 LS type, Inter-AS-TE-v3 81 LSA, for advertising the OSPFv3 link. 83 Both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA contain one top 84 level TLV: 86 2 - Link TLV 88 The Link TLV describes a single link and includes a set of sub-TLVs. 90 The Link ID sub-TLV defined in RFC 3630 MUST NOT be used in the Link 91 TLV of an Inter-AS-TE-v2 LSA, and the Neighbor ID sub-TLV defined in 92 RFC 5329 MUST NOT be used in the Link TLV of an Inter-AS-TE-v3 LSA. 94 Instead, the remote ASBR is identified by the inclusion of Remote AS 95 Number sub-TLV and IPv4/IPv6 Remote ASBR ID sub-TLV, which is defined 96 in RFC 5392. 98 For a P2P inter-AS link, the information about its remote ASBR for 99 replacing its link ID may be configured. For a broadcast inter-AS 100 link, its link ID is the interface IP address of the designated 101 router (DR) of the link in OSPF. Since no OSPF runs over any 102 broadcast inter-AS link, no DR or backup DR (BDR) is selected. It is 103 hard to configure a replacement for DR and BDR. 105 This document presents extensions to OSPF for advertising broadcast 106 inter-AS TE links through defining a new sub-TLV for a broadcast link 107 without configuring any replacement for DR and BDR on the link. 109 2. Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Information on Inter-AS TE Link 117 For a broadcast link connecting multiple ASBRs in a number of ASes, 118 on each of the ASBRs X, the following information about the link may 119 be obtained: 121 1) Link Type: Multi-access 122 2) Local IP address with mask length 123 3) Traffic engineering metric 124 4) Maximum bandwidth 125 5) Maximum reservable bandwidth 126 6) Unreserved bandwidth 127 7) Administrative group 128 8) SRLG 130 No remote IP address or link ID (i.e., DR's interface address) may be 131 obtained. 133 4. Extensions to OSPF 135 4.1. sub-TLVs 137 Two new sub-TLVs are defined. One is for local IPv4 address with 138 mask length; and the other is for local IPv6 address with mask 139 length. 141 The format of the sub-TLV for a local IPv4 address with mask length 142 is shown as follows. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type (stTBD1) | Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | IPv4 Address (4 bytes) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Mask Length | 152 +-+-+-+-+-+-+-+-+ 154 The IPv4 Address indicates the local IPv4 address of a link. The 155 Mask Length indicates the length of the IPv4 address mask. 157 The format of the sub-TLV for a local IPv6 address with mask length 158 is illustrated below. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type (stTBD2) | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | IPv6 Address (16 bytes) | 166 ~ ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Mask Length | 169 +-+-+-+-+-+-+-+-+ 171 The IPv6 Address indicates the local IPv6 address of a link. The 172 Mask Length indicates the length of the IPv6 address mask. 174 4.2. Procedures 176 4.2.1. OSPF Router Procedure 178 For a broadcast inter-AS link connecting to multiple ASBRs, each of 179 the ASBRs as an OSPF router advertises an LSA (Inter-AS-TE-v2 LSA for 180 OSPFv2 or Inter-AS-TE-v3 LSA for OSPFv3) with a link TLV containing 181 sub-TLVs for the information such as 1) 10 8) on the broadcast link 182 described in Section 3. 184 When TE is enabled on an inter-AS link and the link is up, the ASBR 185 SHOULD advertise this link using the normal procedures for OSPF-TE. 186 When either the link is down or TE is disabled on the link, the ASBR 187 SHOULD withdraw the advertisement. When there are changes to the TE 188 parameters for the link (for example, when the available bandwidth 189 changes), the ASBR SHOULD re-advertise the link but MUST take 190 precautions against excessive re-advertisements. 192 4.2.2. Super Node Procedure 194 Suppose that there is a super node, which just receives LSAs from 195 each of ASes (or domains) through a passive OSPF adjacency between 196 the super node and an ASBR or ABR in the AS or domain. 198 For a new broadcast link connecting multiple routers with no link ID 199 configured, when the super node receives an LSA containing the link 200 attached to router X, it stores the link from X into its TED. It 201 finds the link's remote end P using the link's local IP address with 202 network mask. P is a Pseudo node identified by the local IP address 203 of the DR selected from the routers connected to the link. After 204 finding P, it associates the link attached to X with P and the link 205 connected to P with X. If P is not found, a new Pseudo node P is 206 created. The super node associates the link attached to X with P and 207 the link attached to P with X. This creates a bidirectional 208 connection between X and P. 210 The first router and second router from which the super node receives 211 an LSA containing the link are selected as the DR and BDR 212 respectively. After the DR is down, the BDR node becomes the DR and 213 the router other than the DR with the largest (or smallest) local IP 214 address connecting to the link is selected as the BDR. 216 When the old DR is down and the BDR becomes the new DR, the super 217 node updates its TED through removing the link between each of 218 routers X and old P (the Pseudo node corresponding to the old DR) and 219 adding a link between each of routers X (still connecting to the 220 broadcast link) and new P (the Pseudo node corresponding to the new 221 DR). 223 5. Security Considerations 225 The mechanism described in this document does not raise any new 226 security issues for the OSPF protocols. 228 6. IANA Considerations 230 This section specifies requests for IANA allocation. 232 7. Acknowledgement 234 The authors would like to thank all for their valuable comments on 235 this draft. 237 8. References 239 8.1. Normative References 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, 243 DOI 10.17487/RFC2119, March 1997, 244 . 246 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 247 Support of Inter-Autonomous System (AS) MPLS and GMPLS 248 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 249 January 2009, . 251 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 252 "Traffic Engineering Extensions to OSPF Version 3", 253 RFC 5329, DOI 10.17487/RFC5329, September 2008, 254 . 256 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 257 (TE) Extensions to OSPF Version 2", RFC 3630, 258 DOI 10.17487/RFC3630, September 2003, 259 . 261 8.2. Informative References 263 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 264 Path Computation Element Architecture to the Determination 265 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 266 DOI 10.17487/RFC6805, November 2012, 267 . 269 Authors' Addresses 271 Huaimo Chen 272 Futurewei 273 Boston, MA 274 USA 276 EMail: Huaimo.chen@futurewei.com 278 Mehmet Toy 279 Verizon 280 USA 282 EMail: mehmet.toy@verizon.com 283 Xufeng Liu 284 Volta Networks 285 McLean, VA 286 USA 288 EMail: xufeng.liu.ietf@gmail.com 290 Lei Liu 291 Fujitsu 292 USA 294 EMail: liulei.kddi@gmail.com 296 Zhenqiang Li 297 China Mobile 298 No.32 Xuanwumenxi Ave., Xicheng District 299 Beijing 100032 300 P.R. China 302 EMail: li_zhenqiang@hotmail.com 304 Yi Yang 305 IBM 306 NC 307 USA 309 EMail: yyang1998@gmail.com