idnits 2.17.00 (12 Aug 2021) /tmp/idnits15611/draft-acee-ospf-prefix-link-attr-impl-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 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 7, 2015) is 2571 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 7, 2015 5 Expires: November 8, 2015 7 OSPF Prefix/Link Attributes Extension Implementation Report 8 draft-acee-ospf-prefix-link-attr-impl-02.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 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 for N-flag, 167 A-flag not yet. 169 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 170 OSPFv2 Extended Link TLV? Yes 172 5. In your implementation, what applications utilize the OSPFv2 173 Extended Prefix/Link attributes (e.g., segment routing)? Segment 174 Routing, Topology-Independent Loop-Free-Alternatives (TI-LFA), 175 and OSPF Bit Index Egress Replication (BIER) extensions 177 6. Is the function in a generally available software release? 178 Segment Routing and TI-LFA are available in IOS-SR 5.3.2. OSPF 179 BIER Extensions are not available yet. 181 7. Have you tested interoperability with any other vendors? If yes, 182 with whom? Yes. With Alcatel-Lucent. 184 8. Would you be amenable to your data being included in an 185 implementation survey document (complete with vendor 186 identification)? Yes 188 3.3. Huawei 190 The Huawei responses to the survey questions are as follows: 192 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 193 Yes 195 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 196 OSPFv2 Extended Prefix TLV? Yes 198 3. If yes for #3, have you implemented the A and N flags which have 199 been moved from the segment routing extensions? Not yet. 201 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 202 OSPFv2 Extended Link TLV? Yes 204 5. In your implementation, what applications utilize the OSPFv2 205 Extended Prefix/Link attributes (e.g., segment routing)? Segment 206 Routing 208 6. Is the function in a generally available software release? Not 209 yet. It will be in Huawei Versatile Routing Platform (VRP) 211 7. Have you tested interoperability with any other vendors? No 213 8. Would you be amenable to your data being included in an 214 implementation survey document (complete with vendor 215 identification)? Yes 217 4. Security Considerations 219 This document reports the results of an OSPFv2 Prefix/Link Attributes 220 implementation survey. As such, it does not introduce any security 221 risks. 223 5. IANA Considerations 225 No IANA actions are required. 227 6. References 229 6.1. Normative References 231 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 233 [PREFIX-LINK-ATTR] 234 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 235 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 236 Advertisement", draft-ietf-ospf-prefix-link-04.txt (work 237 in progress), April 2015. 239 [RFC-KEYWORDS] 240 Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", RFC 2119, March 1997. 243 6.2. Informative References 245 [BIER] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 246 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 247 for BIER", draft-ietf-bier-ospf-bier-extensions-00.txt 248 (work in progress), April 2015. 250 [SEGMENT-ROUTING] 251 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 252 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 253 Extensions for Segment Routing", draft-ietf-ospf-segment- 254 routing-extensions-04.txt (work in progress), February 255 2015. 257 [TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., 258 and S. Litkowski, "Topology Independent Fast Reroute using 259 Segment Routing", draft-francois-spring-segment-routing- 260 ti-lfa-01.txt (work in progress), October 2014. 262 Appendix A. Acknowledgments 264 The RFC text was produced using Marshall Rose's xml2rfc tool. 266 Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, and Eric Wu for 267 their responses to the survey. 269 Author's Address 271 Acee Lindem 272 Cisco Systems 273 301 Midenhall Way 274 Cary, NC 27513 275 USA 277 Email: acee@cisco.com