idnits 2.17.00 (12 Aug 2021) /tmp/idnits15069/draft-acee-ospf-prefix-link-attr-impl-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 2015) is 2572 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 information found for draft-ietf-ospf-prefix-link - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PREFIX-LINK-ATTR' == Outdated reference: draft-ietf-bier-ospf-bier-extensions has been published as RFC 8444 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: A later version (-02) exists of draft-francois-spring-segment-routing-ti-lfa-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track May 6, 2015 5 Expires: November 7, 2015 7 OSPF Prefix/Link Attributes Extension Implementation Report 8 draft-acee-ospf-prefix-link-attr-impl-01.txt 10 Abstract 12 This document reports the results of the OSPFv2 Prefix/Link 13 Attributes implementation survey. The survey has seven questions 14 related to the implementer's support of OSPFv2 Prefix/Link 15 Attributes. After a brief summary of the results, each response is 16 listed. This document contains responses from six implementers who 17 completed the survey. No external means were used to verify the 18 accuracy of the information submitted by the respondents. The 19 respondents are considered experts on the products they reported on. 20 Additionally, responses were omitted from implementers who indicated 21 that they have not implemented the function yet. 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 http://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 November 7, 2015. 40 Copyright Notice 42 Copyright (c) 2015 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 (http://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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 71 2. Summary Results of Survey . . . . . . . . . . . . . . . . . . 3 72 3. Implementation Survey Results . . . . . . . . . . . . . . . . 3 73 3.1. Alcatel-Lucent . . . . . . . . . . . . . . . . . . . . . 3 74 3.2. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.3. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 80 6.2. Informative References . . . . . . . . . . . . . . . . . 6 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 84 1. Introduction 86 This document reports the results of the OSPFv2 Prefix/Link 87 Attributes [PREFIX-LINK-ATTR] implementation survey. The survey has 88 seven questions related to the implementer's support of OSPFv2 89 Prefix/Link Attributes. The OSPFv2 Prefix/Link Attributes are 90 extensions to the base OSPFv2 protocol [OSPFV2] to allow additional 91 information to be associated with an OSPFv2 link or attribute. After 92 a brief summary of the results, each response is listed. This 93 document contains responses from three implementers who completed the 94 survey. No external means were used to verify the accuracy of the 95 information submitted by the respondents. The respondents are 96 considered experts on the products they reported on. Additionally, 97 responses were omitted from implementers who indicated that they have 98 not implemented the function yet. 100 1.1. Requirements notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC-KEYWORDS]. 106 2. Summary Results of Survey 108 Three vendors replied to the survey. These include Alcatel-Lucent, 109 Cisco, and Huawei. Cisco and Alcatel-Lucent also did 110 interoperability testing. The Cisco and Alcatel-Lucent 111 implementations are in released software versions and the Huawei 112 implementation release is pending. For prefix attributes, the recent 113 change incorporating the A-Flag is pending implementation by Alcatel- 114 Lucent and Huawei. Implementation of the N-flag is pending Huawei 115 implementation. Otherwise, the vendors have full implementations of 116 [PREFIX-LINK-ATTR]. For all three vendors, segment routing 117 [SEGMENT-ROUTING] was an application making use of the extensions. 118 Additionally, Cisco has implemented Topology-Independent Loop-Free 119 Alternatives (TI-LFA) [TI-LFA] and Bit Indexed Egress Replication 120 (BIER) advertisement [BIER]. 122 3. Implementation Survey Results 124 3.1. Alcatel-Lucent 126 The Alcatel-Lucent responses to the survey questions are as follows: 128 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 129 Yes 131 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 132 OSPFv2 Extended Prefix TLV? Yes 134 3. If yes for #3, have you implemented the A and N flags which have 135 been moved from the segment routing extensions? Yes for N-flag, 136 A-flag not yet. 138 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 139 OSPFv2 Extended Link TLV? Yes 141 5. In your implementation, what applications utilize the OSPFv2 142 Extended Prefix/Link attributes (e.g., segment routing)? Segment 143 Routing 145 6. Is the function in a generally available software release? Yes - 146 Product Name: SR OS, Release: 13.0.R4 148 7. Have you tested interoperability with any other vendors? If yes, 149 with whom? Yes. With Cisco. 151 8. Would you be amenable to your data being included in an 152 implementation survey document (complete with vendor 153 identification)? Yes 155 3.2. Cisco 157 The Cisco responses to the survey questions are as follows: 159 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 160 Yes 162 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 163 OSPFv2 Extended Prefix TLV? Yes 165 3. If yes for #3, have you implemented the A and N flags which have 166 been moved from the segment routing extensions? Yes 168 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 169 OSPFv2 Extended Link TLV? Yes 171 5. In your implementation, what applications utilize the OSPFv2 172 Extended Prefix/Link attributes (e.g., segment routing)? Segment 173 Routing, Topology-Independent Loop-Free-Alternatives (TI-LFA), 174 and OSPF Bit Index Egress Replication (BIER) extensions 176 6. Is the function in a generally available software release? 177 Segment Routing and TI-LFA are available in IOS-SR 5.3.2. OSPF 178 BIER Extensions are not available yet. 180 7. Have you tested interoperability with any other vendors? If yes, 181 with whom? Yes. With Alcatel-Lucent. 183 8. Would you be amenable to your data being included in an 184 implementation survey document (complete with vendor 185 identification)? Yes 187 3.3. Huawei 189 The Huawei responses to the survey questions are as follows: 191 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 192 Yes 194 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 195 OSPFv2 Extended Prefix TLV? Yes 197 3. If yes for #3, have you implemented the A and N flags which have 198 been moved from the segment routing extensions? Not yet. 200 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 201 OSPFv2 Extended Link TLV? Yes 203 5. In your implementation, what applications utilize the OSPFv2 204 Extended Prefix/Link attributes (e.g., segment routing)? Segment 205 Routing 207 6. Is the function in a generally available software release? Not 208 yet. It will be in Huawei Versatile Routing Platform (VRP) 210 7. Have you tested interoperability with any other vendors? No 212 8. Would you be amenable to your data being included in an 213 implementation survey document (complete with vendor 214 identification)? Yes 216 4. Security Considerations 218 This document reports the results of an OSPFv2 Prefix/Link Attributes 219 implementation survey. As such, it does not introduce any security 220 risks. 222 5. IANA Considerations 224 No IANA actions are required. 226 6. References 228 6.1. Normative References 230 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 232 [PREFIX-LINK-ATTR] 233 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 234 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 235 Advertisement", draft-ietf-ospf-prefix-link-04.txt (work 236 in progress), April 2015. 238 [RFC-KEYWORDS] 239 Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", RFC 2119, March 1997. 242 6.2. Informative References 244 [BIER] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 245 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 246 for BIER", draft-ietf-bier-ospf-bier-extensions-00.txt 247 (work in progress), April 2015. 249 [SEGMENT-ROUTING] 250 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 251 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 252 Extensions for Segment Routing", draft-ietf-ospf-segment- 253 routing-extensions-04.txt (work in progress), February 254 2015. 256 [TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., 257 and S. Litkowski, "Topology Independent Fast Reroute using 258 Segment Routing", draft-francois-spring-segment-routing- 259 ti-lfa-01.txt (work in progress), October 2014. 261 Appendix A. Acknowledgments 263 The RFC text was produced using Marshall Rose's xml2rfc tool. 265 Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, and Eric Wu for 266 their responses to the survey. 268 Author's Address 270 Acee Lindem 271 Cisco Systems 272 301 Midenhall Way 273 Cary, NC 27513 274 USA 276 Email: acee@cisco.com