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