idnits 2.17.1 draft-chen-lsr-anycast-flag-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC9085], [RFC8362], [RFC7684]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC8362, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7684, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 September 2021) is 956 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR R. Chen 3 Internet-Draft D. Zhao 4 Intended status: Standards Track ZTE Corporation 5 Expires: 14 March 2022 P. Psenak 6 Cisco Systems 7 10 September 2021 9 Updates to Anycast Property advertisement for OSPF 10 draft-chen-lsr-anycast-flag-00 12 Abstract 14 Both SR-MPLS prefixes-SID and IPv4/IPv6 prefix may be configured as 15 anycast and as such the same value can be advertised by multiple 16 routers. It is useful for other routers to know that the 17 advertisement is for an anycast identifier. 19 This document updates [RFC7684] and [RFC8362], by defining a new flag 20 in OSPFv2 Extended Prefix Opaque LSA [RFC7684] and Prefix Options 21 [RFC8362] to advertise the anycast property, and also updates the 22 corresponding interpretation of the Flags field of the Prefix 23 Attribute Flags TLV in [RFC9085]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 14 March 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Updates to Anycast Property advertisement for OSPFv3 . . . . 3 61 3. Updates to Anycast Property advertisement for OSPFv2 . . . . 4 62 4. Updates to Anycast Property advertisement for BGP-LS . . . . 4 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 6.1. OSPFv3 Prefix Options . . . . . . . . . . . . . . . . . . 5 66 6.2. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . 5 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 Both SR-MPLS prefixes-SID and IPv4/IPv6 prefix may be configured as 75 anycast and as such the same value can be advertised by multiple 76 routers. It is useful for other routers to know that the 77 advertisement is for an anycast identifier. 79 [RFC7684] defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) 80 tuples that can be used to associate additional attributes with 81 prefixes or links. The OSPFv2 Extended Prefix TLV that is contained 82 in the OSPFv2 Extended Prefix Opaque LSA is used to advertise 83 additional attributes associated with the prefix, but the definition 84 of anycast flag to identify the prefix as anycast has not yet been 85 defined. 87 [RFC8362] extends the LSA format by encoding the existing OSPFv3 LSA 88 information in Type-Length-Value (TLV) tuples and allowing 89 advertisement of additional information with additional TLVs. Each 90 prefix is advertised along with an 8-bit field of capabilities,by 91 using the Prefix Options, but the definition of anycast capability 92 bit to identify the prefix as anycast has not yet been defined. 94 [RFC9085] defines the Prefix Attribute Flags TLV carries IPv4/IPv6 95 prefix attribute flags information, and the Flags field of this TLV 96 is interpreted according to OSPFv2 [RFC7684] and OSPFv3 [RFC8362], 97 but the anycast flag isnot included. 99 This document updates [RFC7684] and [RFC8362], by defining a new flag 100 in OSPFv2 Extended Prefix Opaque LSA [RFC7684] and Prefix Options 101 [RFC8362] to advertise the anycast property, and also updates the 102 corresponding interpretation of the Flags field of the Prefix 103 Attribute Flags TLV in [RFC9085]. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Updates to Anycast Property advertisement for OSPFv3 113 The prefix may be configured as anycast and it is useful for other 114 routers to know that the advertisement is for an anycast identifier. 116 A new flag in Prefix Options [RFC8362] is defined to advertise the 117 anycast property, The figure below shows the position of the A-bit in 118 the prefix options. 120 0 1 2 3 4 5 6 7 121 +--+--+--+--+--+--+--+--+ 122 | | A| N|DN| P| x|LA|NU| 123 +--+--+--+--+--+--+--+--+ 125 Figure 1 127 When the prefix is configured as anycast, the A-flag SHOULD be set. 128 Otherwise, this flag MUST be clear.If both N-flag and A-flag are set, 129 the receiving routers MUST ignore the N-flag. 131 A-flag MUST be preserved when the prefix is propagated between areas. 133 The same prefix can be advertised by multiple routers, and that if at 134 least one of them sets the A-Flag in its advertisement, the prefix 135 SHOULD be considered as anycast. 137 3. Updates to Anycast Property advertisement for OSPFv2 139 [RFC7684] defines one-octet field contains flags applicable to the 140 prefix, and it only defines two flag (A-Flag (Attach Flag) and N-Flag 141 (Node Flag). This section extends a new flag: An(Anycast Flag). 143 An-flag: A new flag in OSPFv2 Extended Prefix Opaque LSA [RFC7684] is 144 defined to advertise the anycast property. When the prefix is 145 configured as anycast, the An-flag SHOULD be set. Otherwise, this 146 flag MUST be clear.If both N-flag and An-flag are set, the receiving 147 routers MUST ignore the N-flag. 149 An-flag MUST be preserved when the prefix is propagated between 150 areas. 152 The same prefix can be advertised by multiple routers, and that if at 153 least one of them sets the An-Flag in its advertisement, the prefix 154 SHOULD be considered as anycast. 156 4. Updates to Anycast Property advertisement for BGP-LS 158 [RFC9085] defines the Prefix Attribute Flags TLV carries IPv4/IPv6 159 prefix attribute flags information, and the Flags field of this TLV 160 is interpreted according to OSPFv2 [RFC7684]and OSPFv3 [RFC8362].This 161 section extends the interpretation of the Flags field of the Prefix 162 Attribute Flags TLV. 164 Flags: 166 * IS-IS flags refer to Section 2.3.2 of [RFC9085] . 168 * OSPFv2 flags correspond to the Flags field of the OSPFv2 Extended 169 Prefix TLV defined in Section 2.1 of [RFC7684] and extended in 170 Section 3 of this draft. 172 * OSPFv3 flags map to the Prefix Options field defined in 173 Appendix A.4.1.1 of [RFC5340] and extended in Section 3.1 of 174 [RFC8362] and Section 4 of this draft. 176 5. Acknowledgements 178 TBD. 180 6. IANA Considerations 182 This document requests allocation for the following bits registry. 184 6.1. OSPFv3 Prefix Options 186 This document adds a new bit in the "OSPFv3 Prefix Options" registry: 188 A-flag (Anycast Flag). 190 6.2. OSPFv2 Extended Prefix TLV 192 This document adds a new bit in the "OSPFv2 Extended Prefix TLV" 193 registry: 195 An-flag (Anycast Flag). 197 7. Security Considerations 199 Procedures and protocol extensions defined in this document do not 200 affect the OSPFv2 , OSPFv3 and BGP-LS security model. See the 201 "Security Considerations"section of [RFC7684] for a discussion of 202 OSPFv2 security, the "Security Considerations"section of [RFC8362] 203 for a discussion of OSPFv3 security and the "Security 204 Considerations"section of [RFC9085] for a discussion of SR BGP-LS 205 security. 207 8. References 209 8.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, 213 DOI 10.17487/RFC2119, March 1997, 214 . 216 [RFC5340] Coltun, R., "OSPF for IPv6", RFC 5340, 217 DOI 10.17487/RFC5340, July 2008, 218 . 220 [RFC7684] Psenak, P., "Key words for use in RFCs to Indicate 221 Requirement Levels", RFC 7684, DOI 10.17487/RFC7684, 222 November 2015, . 224 [RFC8362] Lindem, A., "OSPFv3 Link State Advertisement (LSA) 225 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 226 2018, . 228 [RFC9085] Previdi, S., "Border Gateway Protocol - Link State (BGP- 229 LS) Extensions for Segment Routing", RFC 9085, 230 DOI 10.17487/RFC9085, August 2021, 231 . 233 Authors' Addresses 235 Ran Chen 236 ZTE Corporation 237 Nanjing 238 China 240 Email: chen.ran@zte.com.cn 242 Detao Zhao 243 ZTE Corporation 244 Nanjing 245 China 247 Email: zhao.detao@zte.com.cn 249 Peter Psenak 250 Cisco Systems 251 Slovakia 253 Email: ppsenak@cisco.com