idnits 2.17.1 draft-chen-ospf-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 2411 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 245, but no explicit reference was found in the text == Unused Reference: 'RFC5329' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC6805' is defined on line 262, 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 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 OSPF Extensions for Broadcast Inter-AS TE Link 17 draft-chen-ospf-ias-lk-01 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 http://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 March 15, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 61 3. Information on Inter-AS TE Link . . . . . . . . . . . . . . . . 3 62 4. Extensions to OSPF . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2.1. OSPF Router Procedure . . . . . . . . . . . . . . . . . 5 66 4.2.2. Super Node Procedure . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 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 5392 defines a new Opaque LSA, the Inter-AS-TE-v2 LSA, for 79 advertising the OSPFv2 link; and a new OSPFv3 LS type, Inter-AS-TE-v3 80 LSA, for advertising the OSPFv3 link. 82 Both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA contain one top 83 level TLV: 85 2 - Link TLV 87 The Link TLV describes a single link and includes a set of sub-TLVs. 89 The Link ID sub-TLV defined in RFC 3630 MUST NOT be used in the Link 90 TLV of an Inter-AS-TE-v2 LSA, and the Neighbor ID sub-TLV defined in 91 RFC 5329 MUST NOT be used in the Link TLV of an Inter-AS-TE-v3 LSA. 93 Instead, the remote ASBR is identified by the inclusion of Remote AS 94 Number sub-TLV and IPv4/IPv6 Remote ASBR ID sub-TLV, which is defined 95 in RFC 5392. 97 For a P2P inter-AS link, the information about its remote ASBR for 98 replacing its link ID may be configured. For a broadcast inter-AS 99 link, its link ID is the interface IP address of the designated 100 router (DR) of the link in OSPF. Since no OSPF runs over any 101 broadcast inter-AS link, no DR or backup DR (BDR) is selected. It is 102 hard to configure a replacement for DR and BDR. 104 This document presents extensions to OSPF for advertising broadcast 105 inter-AS TE links through defining a new sub-TLV for a broadcast link 106 without configuring any replacement for DR and BDR on the link. 108 2. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Information on Inter-AS TE Link 116 For a broadcast link connecting multiple ASBRs in a number of ASes, 117 on each of the ASBRs X, the following information about the link may 118 be obtained: 120 1) Link Type: Multi-access 121 2) Local IP address with mask length 122 3) Traffic engineering metric 123 4) Maximum bandwidth 124 5) Maximum reservable bandwidth 125 6) Unreserved bandwidth 126 7) Administrative group 127 8) SRLG 129 No remote IP address or link ID (i.e., DR's interface address) may be 130 obtained. 132 4. Extensions to OSPF 134 4.1. sub-TLVs 136 Two new sub-TLVs are defined. One is for local IPv4 address with 137 mask length; and the other is for local IPv6 address with mask 138 length. 140 The format of the sub-TLV for a local IPv4 address with mask length 141 is shown as follows. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type (stTBD1) | Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | IPv4 Address (4 bytes) | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Mask Length | 151 +-+-+-+-+-+-+-+-+ 153 The IPv4 Address indicates the local IPv4 address of a link. The 154 Mask Length indicates the length of the IPv4 address mask. 156 The format of the sub-TLV for a local IPv6 address with mask length 157 is illustrated below. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type (stTBD2) | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | IPv6 Address (16 bytes) | 165 ~ ~ 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Mask Length | 168 +-+-+-+-+-+-+-+-+ 170 The IPv6 Address indicates the local IPv6 address of a link. The 171 Mask Length indicates the length of the IPv6 address mask. 173 4.2. Procedures 175 4.2.1. OSPF Router Procedure 177 For a broadcast inter-AS link connecting to multiple ASBRs, each of 178 the ASBRs as an OSPF router advertises an LSA (Inter-AS-TE-v2 LSA for 179 OSPFv2 or Inter-AS-TE-v3 LSA for OSPFv3) with a link TLV containing 180 sub-TLVs for the information such as 1) 10 8) on the broadcast link 181 described in Section 3. 183 When TE is enabled on an inter-AS link and the link is up, the ASBR 184 SHOULD advertise this link using the normal procedures for OSPF-TE. 185 When either the link is down or TE is disabled on the link, the ASBR 186 SHOULD withdraw the advertisement. When there are changes to the TE 187 parameters for the link (for example, when the available bandwidth 188 changes), the ASBR SHOULD re-advertise the link but MUST take 189 precautions against excessive re-advertisements. 191 4.2.2. Super Node Procedure 193 Suppose that there is a super node, which just receives LSAs from 194 each of ASes (or domains) through a passive OSPF adjacency between 195 the super node and an ASBR or ABR in the AS or domain. 197 For a new broadcast link connecting multiple routers with no link ID 198 configured, when the super node receives an LSA containing the link 199 attached to router X, it stores the link from X into its TED. It 200 finds the link's remote end P using the link's local IP address with 201 network mask. P is a Pseudo node identified by the local IP address 202 of the DR selected from the routers connected to the link. After 203 finding P, it associates the link attached to X with P and the link 204 connected to P with X. If P is not found, a new Pseudo node P is 205 created. The super node associates the link attached to X with P and 206 the link attached to P with X. This creates a bidirectional 207 connection between X and P. 209 The first router and second router from which the super node receives 210 an LSA containing the link are selected as the DR and BDR 211 respectively. After the DR is down, the BDR node becomes the DR and 212 the router other than the DR with the largest (or smallest) local IP 213 address connecting to the link is selected as the BDR. 215 When the old DR is down and the BDR becomes the new DR, the super 216 node updates its TED through removing the link between each of 217 routers X and old P (the Pseudo node corresponding to the old DR) and 218 adding a link between each of routers X (still connecting to the 219 broadcast link) and new P (the Pseudo node corresponding to the new 220 DR). 222 5. Security Considerations 224 The mechanism described in this document does not raise any new 225 security issues for the OSPF protocols. 227 6. IANA Considerations 229 This section specifies requests for IANA allocation. 231 7. Acknowledgement 233 The authors would like to thank all for their valuable comments on 234 this draft. 236 8. References 238 8.1. Normative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 242 RFC2119, March 1997, 243 . 245 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 246 Support of Inter-Autonomous System (AS) MPLS and GMPLS 247 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 248 January 2009, . 250 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 251 "Traffic Engineering Extensions to OSPF Version 3", 252 RFC 5329, DOI 10.17487/RFC5329, September 2008, 253 . 255 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 256 (TE) Extensions to OSPF Version 2", RFC 3630, 257 DOI 10.17487/RFC3630, September 2003, 258 . 260 8.2. Informative References 262 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 263 Path Computation Element Architecture to the Determination 264 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 265 DOI 10.17487/RFC6805, November 2012, 266 . 268 Authors' Addresses 270 Huaimo Chen 271 Huawei Technologies 272 Boston, MA, 273 USA 275 EMail: Huaimo.chen@huawei.com 277 Mehmet Toy 278 Verizon 279 USA 281 EMail: mehmet.toy@verizon.com 283 Xufeng Liu 284 Jabil 285 McLean, VA 286 USA 288 EMail: Xufeng_Liu@jabil.com 290 Lei Liu 291 Fujitsu 292 USA 294 EMail: lliu@us.fujitsu.com 295 Zhenqiang Li 296 China Mobile 297 No.32 Xuanwumenxi Ave., Xicheng District 298 Beijing 100032 299 P.R. China 301 EMail: li_zhenqiang@hotmail.com 303 Yi Yang 304 Sockrate 305 NC 306 USA 308 EMail: yyang1998@gmail.com