idnits 2.17.1 draft-wang-lsr-stub-link-attributes-03.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 11, 2022) is 834 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) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-07) exists of draft-dunbar-lsr-5g-edge-compute-03 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-inter-as-topology-ext-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Hu 5 Expires: July 15, 2022 Huawei Technologies 6 G. Mishra 7 Verizon Inc. 8 A. Lindem 9 Cisco Systems 10 J. Sun 11 ZTE Corporation 12 January 11, 2022 14 Advertisement of Stub Link Attributes 15 draft-wang-lsr-stub-link-attributes-03 17 Abstract 19 This document describes the mechanism that can be used to 20 differentiate the stub links from the normal interfaces within ISIS 21 or OSPF domain. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 15, 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. Consideration for Identifying Stub Link . . . . . . . . . . . 3 60 4. Protocol Extension for Stub Link Attributes . . . . . . . . . 3 61 4.1. OSPF Stub-Link TLV . . . . . . . . . . . . . . . . . . . 4 62 4.2. ISIS Stub-link Sub-TLV . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Stub links are used commonly within an operators enterprise or 74 service provider networks. One of the most common use cases for stub 75 links is in a data center Layer 2 and Layer 3 Top of Rack(TOR) switch 76 where the inter connected links between the TOR switches and uplinks 77 to the core switch are only a few links and a majority of the links 78 are Layer 3 VLAN switched virtual interface trunked between the TOR 79 switches serving Layer 2 broadcast domains. In this scenario all the 80 VLANs are made as stub links as it is recommended to limit the number 81 of network LSAs between routers and switches to avoid unnecessary 82 hello processing overhead. 84 Another common use case is an inter-AS routing scenario where the 85 same routing protocol but different IGP instance is running between 86 the adjacent BGP domains. Using stub link on the inter-AS 87 connections can ensure that prefixes contained within a domain are 88 only reachable within the domain itself and not allow the link state 89 database to be merged between domain which could result in 90 undesirable consequences. 92 For operator which runs different IGP domains that interconnect with 93 each other via the stub links, there is desire to obtain the inter-AS 94 topology information as described in 95 [I-D.ietf-idr-bgpls-inter-as-topology-ext]. If the router that runs 96 BGP-LS within one IGP domain can distinguish stub links from other 97 normal interfaces, it is then easy for the router to report these 98 stub links using BGP-LS to a centralized PCE controller. 100 Draft [I-D.dunbar-lsr-5g-edge-compute] describes the case that edge 101 compute server attach the network and needs to flood some performance 102 index information to the network to facilitate the network select the 103 optimized application resource. The edge compute server will also 104 not run IGP protocol. 106 And, stub links are normally the boundary of one IGP domain, knowing 107 them can facilitate the operators to apply various policies on such 108 interfaces, for example, to secure their networks, or filtering the 109 incoming traffic with scrutiny. 111 But OSPF and ISIS have no position to identify such stub links and 112 their associated attributes now. 114 This document defines the protocol extension for OSPFv2/v3 and ISIS 115 to indicate the stub links and their associated attributes. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119] . 123 3. Consideration for Identifying Stub Link 125 OSPF[RFC5392] defines the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA 126 to carry the TE information about inter-AS links. These LSAs can be 127 used to transfer the information about the stub link which is located 128 at the boundary of one AS. This document defines the Stub-Link TLV 129 within these LSAs to identify the stub link and transfer the 130 associated attributes then. 132 ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE 133 information about inter-AS links. This TLV can be used to transfer 134 the information about the stub link which is located at the boundary 135 of one AS. This document defines the Stub-Link TLV to identify the 136 stub link and transfer the associated attributes. 138 4. Protocol Extension for Stub Link Attributes 140 The following sections define the protocol extension to indicate the 141 stub link and its associated attributes in OSPFv2/v3 and ISIS. 143 4.1. OSPF Stub-Link TLV 145 This document defines the OSPF Stub-Link TLV to describe stub link of 146 a single router. This Stub-Link TLV is only applicable to the Inter- 147 AS-TE-v2 LSA and Inter-AS-TE-v3 LSA. Inclusion in other LSA MUST be 148 ignored. 150 The OSPF Stub-Link TLV which is under the IANA codepoint "Top Level 151 Types in TE LSAs" has the following format: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type(Stub-Link) | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Link Type | AT | Prefix Length | Reserved | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Link Prefix(variable) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Sub-TLVs (variable) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: OSPF Stub-Link TLV 166 Type: The TLV type. The value is 7(TBD) for OSPF Stub-Link 168 Length: Variable, dependent on sub-TLVs 170 Link Type: Define the type of the stub-link. This document defines 171 the followings type: 173 o 0: Reserved 175 o 1: Numbered AS boundary link 177 o 2: Unnumbered AS boundary link 179 o 3: Loopback link 181 o 4: Vlan interface link 183 o 5-255: For future extension 185 AT: Address Type. 1 for IPv4, 2 for IPv6 187 Prefix Length: The length of the interface address, in octet. 189 Link Prefix: The prefix of the stub-link. It's length is determined 190 by the field "Prefix Length". 192 Sub-TLVs: Existing sub-TLV that defined within "Open Shortest Path 193 First (OSPF) Traffic Engineering TLVs" for TE Link TLV(Value 2) can 194 be included if necessary. If the stub-link is "Unnumbered AS 195 boundary link", then the "Remote AS number" , "IPv4 Remote ASBR ID", 196 "IPv6 Remote ASBR ID" sub-TLV MUST be included to facilitate the 197 pairing of inter-AS link. 199 If this TLV is advertised multiple times in the same Inter-AS-TE-v2/ 200 v3 LSA, only the first instance of the TLV is used by receiving 201 OSPFv2/v3 routers. This situation SHOULD be logged as an error. 203 If this TLV is advertised multiple times for the same link in 204 different Inter-AS-TE-v2/v3 LSA originated by the same OSPFrouter, 205 the OSPFStub-Link TLV in these LSAs with the smallest Opaque ID is 206 used by receiving OSPFrouters. This situation may be logged as a 207 warning. 209 It is RECOMMENDED that OSPF routers advertising OSPF Stub-Link TLVs 210 in different OSPF Inter-AS-TE v2/v3 LSAs re-originate these LSAs in 211 ascending order of Opaque ID to minimize the disruption. 213 This document creates a registry for Stub-Link attributes in 214 Section 6. 216 4.2. ISIS Stub-link Sub-TLV 218 This document defines the ISIS Stub-Link TLV to describes stub link 219 of a single router. 221 The ISIS Stub-Link TLV has the following format: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type(Stub-Link) | Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Link Type | AT | Prefix Length | Reserved | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Link Prefix(variable) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Sub-TLVs(Variable) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 2: ISIS Stub-Link Sub-TLV 236 Type: ISIS TLV codepoint. Value is 151(TBD) for stub-link TLV. 238 Length: Variable, dependent on sub-TLVs 239 Link Type: Define the type of the stub-link. This document defines 240 the followings type: 242 o 0: Reserved 244 o 1: Numbered AS boundary link 246 o 2: Unnumbered AS boundary link 248 o 3: Loopback link 250 o 4: Vlan interface link 252 o 5-255: For future extension 254 AT: Address Type. 1 for IPv4, 2 for IPv6 256 Prefix Length: The length of the interface address, in octet. 258 Link Prefix: The prefix of the stub-link. It's length is determined 259 by the field "Prefix Length". 261 Sub-TLVs: Existing sub-TLVs that defined within "IS-IS Sub-TLVs for 262 TLVs Advertising Neighbor Information " can be included if necessary. 263 If the stub-link is "Unnumbered AS boundary link", then the "Remote 264 AS number" , "IPv4 Remote ASBR ID", "IPv6 Remote ASBR ID" sub-TLV 265 MUST be included to facilitate the pairing of inter-AS link. 267 5. Security Considerations 269 Security concerns for ISIS are addressed in [RFC5304] and[RFC5310] 271 Security concern for OSPFv3 is addressed in [RFC4552] 273 Advertisement of the additional information defined in this document 274 introduces no new security concerns. 276 6. IANA Considerations 278 IANA is requested to the allocation in following registries: 280 +===========================+======+===========================+ 281 | Registry | Type | Meaning | 282 +===========================+======+===========================+ 283 |Top Level Types in TE LSAs | 7 |OSPF Stub-Link TLV | 284 +---------------------------+------+---------------------------+ 285 |ISIS Top-Level TLV | 151 |IS-IS Stub-Link TLV | 286 +---------------------------+------+---------------------------+ 287 Figure 3: IANA Allocation for newly defined TLVs 289 7. Acknowledgement 291 Thanks Shunwan Zhang, Peter Psenak, Tony Li, Les Ginsberg, Dhruv 292 Dhody, Jeff Tantsura and Robert Raszuk for their suggestions and 293 comments on this idea. 295 8. References 297 8.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 305 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 306 . 308 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 309 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 310 2008, . 312 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 313 and M. Fanto, "IS-IS Generic Cryptographic 314 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 315 2009, . 317 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 318 Support of Inter-Autonomous System (AS) MPLS and GMPLS 319 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 320 December 2008, . 322 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 323 Support of Inter-Autonomous System (AS) MPLS and GMPLS 324 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 325 January 2009, . 327 8.2. Informative References 329 [I-D.dunbar-lsr-5g-edge-compute] 330 Dunbar, L., Chen, H., and A. Wang, "IGP Extension for 5G 331 Edge Computing Service", draft-dunbar-lsr-5g-edge- 332 compute-03 (work in progress), January 2022. 334 [I-D.ietf-idr-bgpls-inter-as-topology-ext] 335 Wang, A., Chen, H., Talaulikar, K., and S. Zhuang, "BGP-LS 336 Extension for Inter-AS Topology Retrieval", draft-ietf- 337 idr-bgpls-inter-as-topology-ext-10 (work in progress), 338 October 2021. 340 Authors' Addresses 342 Aijun Wang 343 China Telecom 344 Beiqijia Town, Changping District 345 Beijing 102209 346 China 348 Email: wangaj3@chinatelecom.cn 350 Zhibo Hu 351 Huawei Technologies 352 Huawei Bld., No.156 Beiqing Rd. 353 Beijing 100095 354 China 356 Email: huzhibo@huawei.com 358 Gyan S. Mishra 359 Verizon Inc. 360 13101 Columbia Pike 361 Silver Spring MD 20904 362 United States of America 364 Email: gyan.s.mishra@verizon.com 365 Acee Lindem 366 Cisco Systems 367 No. 301 Midenhall Way 368 Cary NC 27513 369 United States of America 371 Email: acee@cisco.com 373 Jinsong Sun 374 ZTE Corporation 375 No. 68, Ziijnhua Road 376 Nan Jing 210012 377 China 379 Email: sun.jinsong@zte.com.cn