idnits 2.17.1 draft-wang-lsr-passive-interface-attribute-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2020) is 1282 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 (-15) 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: April 24, 2021 Huawei Technologies 6 G. Mishra 7 Verizon Inc. 8 October 21, 2020 10 Passive Interface Attribute 11 draft-wang-lsr-passive-interface-attribute-05 13 Abstract 15 This document describes the mechanism that can be used to 16 differentiate the passive interfaces from the normal interfaces 17 within ISIS or OSPF domain. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 24, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 3 55 3. Consideration for flagging passive interface . . . . . . . . 3 56 4. Prefix Attribute for Passive Interface . . . . . . . . . . . 3 57 4.1. ISIS Prefix Attribute for Passive Interface . . . . . . . 3 58 4.2. OSPF Prefix Attribute for Passive Interface . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 8.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 Passive interfaces are used commonly within an operators enterprise 70 or service provider networks. One of the most common use cases for 71 passive interface is in a data center Layer 2 and Layer 3 TOR(Top of 72 Rack) switch where the inter connected links between the TOR switches 73 and uplinks to the Core switch are only a few links and a majority of 74 the links are Layer 3 VLAN Switched Virtual Interface Default 75 Gateways trunked between the TOR switches serving Layer 2 broadcast 76 domains. In this scenario all the VLANs are made passive as it is 77 recommended to limit the number of network LSAs between routers and 78 switches to avoid unnecessary hello processing overhead. 80 Another common use case is an inter-as routing scenario where the 81 same routing protocol but different IGP instance is running between 82 the adjacent BGP domains. Using passive interface on the inter-as 83 tiepoint connections can ensure that prefixes contained within a 84 domain are only reachable within the domain itself and not allow the 85 link state database to be merged between domain which could result in 86 undesirable consequences. 88 For operator which runs different IGP domains that interconnect with 89 each other via the passive interfaces, there is desire to obtain the 90 inter-as topology information as described in 91 [I-D.ietf-idr-bgpls-inter-as-topology-ext]. If the router that runs 92 BGP-LS within one IGP domain can distinguish passive interfaces from 93 other normal interfaces, it is then easy for the router to report 94 these passive links using BGP-LS to centralized PCE controller. 96 On the other hand, passive interfaces are normally the boundary of 97 one IGP domain, knowing them can facilitate the operators to apply 98 various policies on such interfaces, for example, to secure their 99 networks, or filtering the incoming traffic with scrutiny. 101 But OSPF and ISIS have no position to flag such passive interface 102 now. 104 This document defines the protocol extension for OSPF and ISIS to 105 indicate the prefix that comes from passive interface. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119] . 113 3. Consideration for flagging passive interface 115 ISIS [RFC5029] defines the Link-Attributes Sub-TLV to carry the link 116 attribute information, but this Sub-TLV can only be carried within 117 the TLV 22, which is used to described the attached neighbor. For 118 passive interface, there is no ISIS neighbor, then it is not 119 appropriate to use this Sub-TLV to indicate the passive attribute of 120 the interface. 122 OSPFv2[RFC2328] defines link type field within Router LSA, the type 3 123 for connections to a stub network can be used to identified the 124 passive interface. But in OSPFv3 [RFC5340], type 3 within the 125 Router-LSA has been reserved. The information that associated with 126 stub network has been put in the Intra-Area-Prefix-LSAs. 128 It is necessary for ISIS and OSPF to extend the protocol to flag the 129 passive interface then. 131 4. Prefix Attribute for Passive Interface 133 Considering there is no IGP neighbor for the passive interface, we 134 select to define the attribute of the prefix that associated with the 135 passive interface, similar as the treatment of stub link type in OSPF 136 v3. 138 4.1. ISIS Prefix Attribute for Passive Interface 140 [RFC7794] defines the "IPv4/IPv6 Extended Reachability Attribute 141 Flags" sub-TLV to advertise the additional flags associated with a 142 given prefix advertisement. We propose new bit(Bit 5 is desired) to 143 be assigned by the IANA for the passive interface attribute, as 144 illustrated in Figure 2: 146 0 1 2 3 4 5 6 7 147 +-+-+-+-+-+-+-+-+ 148 |X|R|N|E|A|U| | | 149 +-+-+-+-+-+-+-+-+ 150 Figure 2: Prefix Attribute Flags 152 U-flag: Unactive Flag(Bit 5) 153 Set for local interface that is configured as passive interface. 155 When the interfaces on one router be configured as passive interface, 156 the U-flag bit will be set in the "IPv4/IPv6 Extended Reachability 157 Attribute Flags" sub-TLV. This sub-TLV will be included in the TLV 158 135, TLV 235, TLV 236 and TLV 237 as necessary and be flooded within 159 the ISIS domain. 161 4.2. OSPF Prefix Attribute for Passive Interface 163 [RFC5340] defines the "Prefix Option field" in "Intra-Area-Prefix- 164 LSAs" to describe the prefix capabilities. The bits in this field 165 can be defined to flag the prefix coming from the passive interface. 166 We propose new bit(Bit 0 is desired) to be assigned by the IANA for 167 the passive interface, as illustrated in Figure 3: 169 0 1 2 3 4 5 6 7 170 +--+--+--+--+--+-+--+--+ 171 | U| E| N|DN| P|x|LA|NU| 172 +--+--+--+--+--+-+--+--+ 174 Figure 3: The Prefix Options Field 176 U-flag: Unactive Flag(Bit 0) 177 Set for local interface that is configured as passive interface. 179 When the interfaces on one router is configured as passive interface, 180 the U-flag bit will be set in the "Prefix Option field" of Intra- 181 Area-Prefix-LSAs. 183 The router that receives such advertisement can then easily 184 distinguish the passive interfaces from the normal interface, and 185 reports them to the PCE controller if it runs the BGP-LS protocol. 187 5. Security Considerations 189 Security concerns for ISIS are addressed in [RFC5304] and[RFC5310] 191 Security concern for OSPFv3 is addressed in [RFC4552] 193 Advertisement of the additional information defined in this document 194 introduces no new security concerns. 196 6. IANA Considerations 198 IANA is requested to allocate the U-bit (Bit position 5 is desired) 199 from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry of 200 ISIS TLV codepoint. 202 IANA is requested to allocate the U-bit(Bit position 0 is desired) 203 from the "OSPFv3 Prefix Options" registry of OSPFv3 Parameters 204 codepoint. 206 7. Acknowledgement 208 Thanks Shunwan Zhang, Tony Li, Les Ginsberg, Acee Lindem, Peter 209 Psenak, Dhruv Dhody, Jeff Tantsura and Robert Raszuk for their 210 suggestions and comments on this idea. 212 8. References 214 8.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 222 DOI 10.17487/RFC2328, April 1998, 223 . 225 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 226 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 227 . 229 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 230 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 231 September 2007, . 233 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 234 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 235 2008, . 237 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 238 and M. Fanto, "IS-IS Generic Cryptographic 239 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 240 2009, . 242 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 243 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 244 . 246 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 247 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 248 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 249 March 2016, . 251 8.2. Informative References 253 [I-D.ietf-idr-bgpls-inter-as-topology-ext] 254 Wang, A., Chen, H., Talaulikar, K., and S. Zhuang, "BGP-LS 255 Extension for Inter-AS Topology Retrieval", draft-ietf- 256 idr-bgpls-inter-as-topology-ext-09 (work in progress), 257 September 2020. 259 Authors' Addresses 261 Aijun Wang 262 China Telecom 263 Beiqijia Town, Changping District 264 Beijing 102209 265 China 267 Email: wangaj3@chinatelecom.cn 269 Zhibo Hu 270 Huawei Technologies 271 Huawei Bld., No.156 Beiqing Rd. 272 Beijing 100095 273 China 275 Email: huzhibo@huawei.com 276 Gyan S. Mishra 277 Verizon Inc. 278 13101 Columbia Pike 279 Silver Spring MD 20904 280 United States of America 282 Email: gyan.s.mishra@verizon.com