idnits 2.17.1 draft-wang-lsr-stub-link-attributes-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 22, 2021) is 940 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-00 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-inter-as-topology-ext-09 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: March 26, 2022 Huawei Technologies 6 G. Mishra 7 Verizon Inc. 8 A. Lindem 9 Cisco Systems 10 J. Sun 11 ZTE Corporation 12 September 22, 2021 14 Advertisement of Stub Link Attributes 15 draft-wang-lsr-stub-link-attributes-01 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 March 26, 2022. 40 Copyright Notice 42 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 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 sub-TLV within this 136 TLV to identify the 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 | 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: AS boundary link 177 o 2: Loopback link 179 o 3: Vlan interface link 181 o 4-255: For future extension 183 Prefix Length: The length of the interface address, in octet. 185 Link Prefix: The prefix of the stub-link. It's length is determined 186 by the field "Prefix Length". 188 Sub-TLVs: Existing sub-TLV that defined within "Open Shortest Path 189 First (OSPF) Traffic Engineering TLVs" for TE Link TLV(Value 2) can 190 be included if necessary. 192 If this TLV is advertised multiple times in the same Inter-AS-TE-v2/ 193 v3 LSA, only the first instance of the TLV is used by receiving 194 OSPFv2/v3 routers. This situation SHOULD be logged as an error. 196 If this TLV is advertised multiple times for the same link in 197 different Inter-AS-TE-v2/v3 LSA originated by the same OSPFrouter, 198 the OSPFStub-Link TLV in these LSAs with the smallest Opaque ID is 199 used by receiving OSPFrouters. This situation may be logged as a 200 warning. 202 It is RECOMMENDED that OSPF routers advertising OSPF Stub-Link TLVs 203 in different OSPF Inter-AS-TE v2/v3 LSAs re-originate these LSAs in 204 ascending order of Opaque ID to minimize the disruption. 206 This document creates a registry for Stub-Link attributes in 207 Section 6. 209 4.2. ISIS Stub-link Sub-TLV 211 This document defines the ISIS Stub-Link sub-TLV to describes stub 212 link of a single router. This Stub-Link sub-TLV is only applicable 213 to the Inter-AS Reachability TLV. Inclusion in other TLV MUST be 214 ignored. 216 The ISIS Stub-Link sub-TLV which is under the IANA codepoint "Sub- 217 TLVs for TLVs 22, 23, 25, 141, 222, and 223" has the following 218 format: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type(Stub-Link) | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Link Type | Prefix Length | Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Link Prefix(variable) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Sub-TLVs(Variable) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: ISIS Stub-Link Sub-TLV 233 Type: ISIS sub-TLV codepoint. Value is 45(TBD) for stub-link TLV. 235 Length: Variable, dependent on sub-TLVs 237 Link Type: Define the type of the stub-link. This document defines 238 the followings type: 240 o 0: Reserved 242 o 1: AS boundary link 244 o 2: Loopback link 246 o 3: Vlan interface link 248 o 4-255: For future extension 250 Prefix Length: The length of the interface address, in octet. 252 Link Prefix: The prefix of the stub-link. It's length is determined 253 by the field "Prefix Length". 255 Sub-TLVs: Existing sub-TLVs that defined within "Sub-TLVs for TLVs 256 22, 23, 25, 141, 222, and 223" can be included if necessary. 258 5. Security Considerations 260 Security concerns for ISIS are addressed in [RFC5304] and[RFC5310] 262 Security concern for OSPFv3 is addressed in [RFC4552] 264 Advertisement of the additional information defined in this document 265 introduces no new security concerns. 267 6. IANA Considerations 269 IANA is requested to the allocation in following registries: 271 +===========================+======+===========================+ 272 | Registry | Type | Meaning | 273 +===========================+======+===========================+ 274 |Top Level Types in TE LSAs | 7 |OSPF Stub-Link TLV | 275 +---------------------------+------+---------------------------+ 276 |Sub-TLVs for TLVs 22, 23, | | | 277 | 25, 141, 222, and 223 | 45 |IS-IS Stub-Link sub-TLV | 278 +---------------------------+------+---------------------------+ 279 Figure 3: IANA Allocation for newly defined TLVs 281 7. Acknowledgement 283 Thanks Shunwan Zhang, Tony Li, Les Ginsberg, Acee Lindem, Dhruv 284 Dhody, Jeff Tantsura and Robert Raszuk for their suggestions and 285 comments on this idea. 287 8. References 289 8.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 297 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 298 . 300 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 301 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 302 2008, . 304 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 305 and M. Fanto, "IS-IS Generic Cryptographic 306 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 307 2009, . 309 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 310 Support of Inter-Autonomous System (AS) MPLS and GMPLS 311 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 312 December 2008, . 314 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 315 Support of Inter-Autonomous System (AS) MPLS and GMPLS 316 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 317 January 2009, . 319 8.2. Informative References 321 [I-D.dunbar-lsr-5g-edge-compute] 322 Dunbar, L., Chen, H., and C. Telecom, "IS-IS & OSPF 323 extension for 5G Edge Computing Service", draft-dunbar- 324 lsr-5g-edge-compute-00 (work in progress), July 2021. 326 [I-D.ietf-idr-bgpls-inter-as-topology-ext] 327 Wang, A., Chen, H., Talaulikar, K., and S. Zhuang, "BGP-LS 328 Extension for Inter-AS Topology Retrieval", draft-ietf- 329 idr-bgpls-inter-as-topology-ext-09 (work in progress), 330 September 2020. 332 Authors' Addresses 334 Aijun Wang 335 China Telecom 336 Beiqijia Town, Changping District 337 Beijing 102209 338 China 340 Email: wangaj3@chinatelecom.cn 342 Zhibo Hu 343 Huawei Technologies 344 Huawei Bld., No.156 Beiqing Rd. 345 Beijing 100095 346 China 348 Email: huzhibo@huawei.com 350 Gyan S. Mishra 351 Verizon Inc. 352 13101 Columbia Pike 353 Silver Spring MD 20904 354 United States of America 356 Email: gyan.s.mishra@verizon.com 358 Acee Lindem 359 Cisco Systems 360 No. 301 Midenhall Way 361 Cary NC 27513 362 United States of America 364 Email: acee@cisco.com 366 Jinsong Sun 367 ZTE Corporation 368 No. 68, Ziijnhua Road 369 Nan Jing 210012 370 China 372 Email: sun.jinsong@zte.com.cn