idnits 2.17.1 draft-hegde-lsr-asla-any-app-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 (7 February 2022) is 801 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 8919 (Obsoleted by RFC 9479) ** Obsolete normative reference: RFC 8920 (Obsoleted by RFC 9492) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR S. Hegde 3 Internet-Draft R. Bonica 4 Intended status: Standards Track C. Bowers 5 Expires: 11 August 2022 Juniper Networks 6 R. Raszuk 7 NTT Network Innovations 8 Z. Li 9 Huawei Technologies 10 D. Voyer 11 Bell Canada 12 7 February 2022 14 The Application Specific Link Attribute (ASLA) Any Application Bit 15 draft-hegde-lsr-asla-any-app-01 17 Abstract 19 RFC 8919 and RFC 8920 define Application Specific Link Attributes 20 (ASLA). Each ASLA includes an Application Identifier Bit Mask. The 21 Application Identifier Bit Mask includes a Standard Application Bit 22 Mask (SABM) and a User Defined Application Bit Mask (UDABM). The 23 SABM and UDABM determine which applications can use the ASLA as an 24 input. 26 This document introduces a new bit to the Standard Application 27 Identifier Bit Mask. This bit is called the Any Application Bit 28 (i.e., the A-bit). If the A-bit is set, the link attribute can be 29 used by any application. This includes currently defined 30 applications as well as applications to be defined in the future. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 11 August 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. The Any Application Bit . . . . . . . . . . . . . . . . . . . 3 68 3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 77 1. Introduction 79 [RFC8919] and [RFC8920] define Application Specific Link Attributes 80 (ASLA). Each ASLA includes an Application Identifier Bit Mask. The 81 Application Identifier Bit Mask includes a Standard Application Bit 82 Mask (SABM) and a User Defined Application Bit Mask (UDABM). 84 Each bit in the SABM represents a standard application while each bit 85 in the UDABM represents a user defined application. If a bit in the 86 SABM or UDABM is set, the corresponding application can use the ASLA 87 as an input. If a bit in the SABM or UDABM is not set, the 88 corresponding application cannot use the associated ASLA as an input. 90 According to [RFC8919]: 92 "If link attributes are advertised associated with zero-length 93 Application Identifier Bit Masks for both standard applications and 94 user-defined applications, then any standard application and/or any 95 user-defined application is permitted to use that set of link 96 attributes so long as there is not another set of attributes 97 advertised on that same link that is associated with a non-zero- 98 length Application Identifier Bit Mask with a matching Application 99 Identifier Bit set." 101 This restriction introduces complexity. For example, assume that a 102 network runs many applications. All applications use Attribute 1 as 103 an input. So, it would be convenient to advertise Attribute 1 with a 104 zero-length SABM / UDABM. 106 However, Applications X and Y also use Attribute 2 as an input. 107 Because Applications X and Y required unique values for Attribute 2, 108 Attribute 2 cannot be advertised with a zero-length SABM. Therefore, 109 Attribute 1 cannot be advertised with a zero-length SABM / UDABM 110 either, because Applications X and Y require it. This would result 111 in having to set the application X and application Y bits on 112 attribute 1 in the entire network on each link and is operationally 113 complex. 115 This document reduces operational complexity by introducing a new bit 116 to the Standard Application Identifier Bit Mask. This bit is called 117 the Any Application Bit (i.e., the A-bit). If the A-bit is set, the 118 link attribute can be used by any application. This includes 119 currently defined applications as well as applications to be defined 120 in the future. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. The Any Application Bit 132 A new bit is defined in the Standard Application Identifier Bit Mask. 133 This bit is called the Any Application Bit (i.e., the A-bit). If the 134 A-bit is set, the link attribute can be used by any application. 135 This includes currently defined applications as well as applications 136 to be defined in the future. 138 If a link advertises an ASLA twice, once with the A-bit set and once 139 with a more specific Application Identifier Bit set, the indicated 140 application MUST use the value from the ASLA with the more specific 141 Application Indicator Bit set. 143 3.1. IS-IS 145 IS-IS uses Bit 4 of the SABM to encode the A-bit. 147 3.2. OSPF 149 OSPF uses Bit 4 of the SABM to encode the A-bit. 151 4. Backward Compatibility 153 The solution described in this document is backward compatible with 154 [RFC8919] and [RFC8920]. An implementation that does not recognize 155 the A-bit will process the SABM as specified in [RFC8919] and 156 [RFC8920]. 158 Implementations MAY advertise attributes under both A bit and with 159 SABM and UDABM length set to zero for backward compatibility reasons. 160 When same attributes are received with A bit set as well as in ASLA 161 with SABM and UDABM set to zero, the attributes MUST be used from the 162 ASLA with SABM and UDABM set to zero and procedures described in RFC 163 8919 sec 6.2 MUST be followed. 165 5. Security Considerations 167 The security considerations discussed in [RFC8919] and [RFC8920] are 168 applicable to this document. This document does not introduce any 169 new security risks. 171 6. IANA Considerations 173 This document requests that IANA add the following entry to the 174 registry titled "Link Attribute Application Identifiers" under the 175 "Interior Gateway Protocol (IGP) Parameters" registry: 177 * Bit: 4 179 * Name: Any Application (A-bit) 181 * Reference: This document 183 7. Acknowledgements 185 TBD 187 8. Normative References 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, 191 DOI 10.17487/RFC2119, March 1997, 192 . 194 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 195 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 196 May 2017, . 198 [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 199 J. Drake, "IS-IS Application-Specific Link Attributes", 200 RFC 8919, DOI 10.17487/RFC8919, October 2020, 201 . 203 [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, 204 J., and J. Drake, "OSPF Application-Specific Link 205 Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, 206 . 208 Authors' Addresses 210 Shraddha Hegde 211 Juniper Networks 212 Exora Business Park 213 Bangalore 560103 214 KA 215 India 217 Email: shraddha@juniper.net 219 Ron Bonica 220 Juniper Networks 221 2251 Corporate Park Drive 222 Herndon, Virginia 20171 223 United States of America 225 Email: rbonica@juniper.net 227 Chris Bowers 228 Juniper Networks 230 Email: cbowers@juniper.net 231 Robert Raszuk 232 NTT Network Innovations 234 Email: robert@raszuk.net 236 Zenbin 237 Huawei Technologies 239 Email: lizhenbin@huawei.com 241 Dan Voyer 242 Bell Canada 244 Email: daniel.voyer@bell.ca