idnits 2.17.1 draft-acee-ospf-prefix-link-attr-impl-03.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 8, 2015) is 3273 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: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-00 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-04 == 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 8, 2015 5 Expires: November 9, 2015 7 OSPF Prefix/Link Attributes Extension Implementation Report 8 draft-acee-ospf-prefix-link-attr-impl-03.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 9, 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 3.4. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 81 6.2. Informative References . . . . . . . . . . . . . . . . . 6 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 85 1. Introduction 87 This document reports the results of the OSPFv2 Prefix/Link 88 Attributes [PREFIX-LINK-ATTR] implementation survey. The survey has 89 seven questions related to the implementer's support of OSPFv2 90 Prefix/Link Attributes. The OSPFv2 Prefix/Link Attributes are 91 extensions to the base OSPFv2 protocol [OSPFV2] to allow additional 92 information to be associated with an OSPFv2 link or attribute. After 93 a brief summary of the results, each response is listed. This 94 document contains responses from four implementers who completed the 95 survey. No external means were used to verify the accuracy of the 96 information submitted by the respondents. The respondents are 97 considered experts on the products they reported on. Additionally, 98 responses were omitted from implementers who indicated that they have 99 not implemented the function yet. 101 1.1. Requirements notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC-KEYWORDS]. 107 2. Summary Results of Survey 109 Four vendors replied to the survey. These include Alcatel-Lucent, 110 Cisco, Huawei, Juniper. Cisco and Alcatel-Lucent also did 111 interoperability testing. The Cisco and Alcatel-Lucent 112 implementations are in released software versions. The Huawei and 113 Junipers implementation releases are pending. For prefix attributes, 114 the recent change incorporating the A-Flag is pending implementation 115 for all four vendors. Implementation of the N-flag is pending for 116 the Huawei and Juniper implementations. Otherwise, the vendors have 117 full implementations of [PREFIX-LINK-ATTR]. For all four vendors, 118 segment routing [SEGMENT-ROUTING] was an application making use of 119 the extensions. Additionally, Cisco has implemented Topology- 120 Independent Loop-Free Alternatives (TI-LFA) [TI-LFA] and Bit Indexed 121 Egress Replication (BIER) advertisement [BIER]. 123 3. Implementation Survey Results 125 3.1. Alcatel-Lucent 127 The Alcatel-Lucent responses to the survey questions are as follows: 129 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 130 Yes 132 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 133 OSPFv2 Extended Prefix TLV? Yes 135 3. If yes for #3, have you implemented the A and N flags which have 136 been moved from the segment routing extensions? Yes for N-flag, 137 A-flag not yet. 139 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 140 OSPFv2 Extended Link TLV? Yes 142 5. In your implementation, what applications utilize the OSPFv2 143 Extended Prefix/Link attributes (e.g., segment routing)? Segment 144 Routing 146 6. Is the function in a generally available software release? Yes - 147 Product Name: SR OS, Release: 13.0.R4 149 7. Have you tested interoperability with any other vendors? If yes, 150 with whom? Yes. With Cisco. 152 8. Would you be amenable to your data being included in an 153 implementation survey document (complete with vendor 154 identification)? Yes 156 3.2. Cisco 158 The Cisco responses to the survey questions are as follows: 160 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 161 Yes 163 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 164 OSPFv2 Extended Prefix TLV? Yes 166 3. If yes for #3, have you implemented the A and N flags which have 167 been moved from the segment routing extensions? Yes for N-flag, 168 A-flag not yet. 170 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 171 OSPFv2 Extended Link TLV? Yes 173 5. In your implementation, what applications utilize the OSPFv2 174 Extended Prefix/Link attributes (e.g., segment routing)? Segment 175 Routing, Topology-Independent Loop-Free-Alternatives (TI-LFA), 176 and OSPF Bit Index Egress Replication (BIER) extensions 178 6. Is the function in a generally available software release? 179 Segment Routing and TI-LFA are available in IOS-XR 5.3.2. OSPF 180 BIER Extensions are not available yet. 182 7. Have you tested interoperability with any other vendors? If yes, 183 with whom? Yes. With Alcatel-Lucent. 185 8. Would you be amenable to your data being included in an 186 implementation survey document (complete with vendor 187 identification)? Yes 189 3.3. Huawei 191 The Huawei responses to the survey questions are as follows: 193 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 194 Yes 196 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 197 OSPFv2 Extended Prefix TLV? Yes 199 3. If yes for #3, have you implemented the A and N flags which have 200 been moved from the segment routing extensions? Not yet. 202 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 203 OSPFv2 Extended Link TLV? Yes 205 5. In your implementation, what applications utilize the OSPFv2 206 Extended Prefix/Link attributes (e.g., segment routing)? Segment 207 Routing 209 6. Is the function in a generally available software release? Not 210 yet. It will be in Huawei Versatile Routing Platform (VRP) 212 7. Have you tested interoperability with any other vendors? No 214 8. Would you be amenable to your data being included in an 215 implementation survey document (complete with vendor 216 identification)? Yes 218 3.4. Juniper 220 The Juniper responses to the survey questions are as follows: 222 1. Have you implemented the OSPFv2 Prefix/Link Attributes Draft? 223 Yes 225 2. Have you implemented the OSPFv2 Extended Prefix opaque LSA and 226 OSPFv2 Extended Prefix TLV? Yes 228 3. If yes for #3, have you implemented the A and N flags which have 229 been moved from the segment routing extensions? Not yet. 231 4. Have you implemented the OSPFv2 Extended Link opaque LSA and 232 OSPFv2 Extended Link TLV? Yes 234 5. In your implementation, what applications utilize the OSPFv2 235 Extended Prefix/Link attributes (e.g., segment routing)? Segment 236 Routing 238 6. Is the function in a generally available software release? Not 239 yet. It will be in JUniper Network Operating System (JUNOS). 241 7. Have you tested interoperability with any other vendors? No 243 8. Would you be amenable to your data being included in an 244 implementation survey document (complete with vendor 245 identification)? Yes 247 4. Security Considerations 249 This document reports the results of an OSPFv2 Prefix/Link Attributes 250 implementation survey. As such, it does not introduce any security 251 risks. 253 5. IANA Considerations 255 No IANA actions are required. 257 6. References 259 6.1. Normative References 261 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 263 [PREFIX-LINK-ATTR] 264 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 265 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 266 Advertisement", draft-ietf-ospf-prefix-link-04.txt (work 267 in progress), April 2015. 269 [RFC-KEYWORDS] 270 Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", RFC 2119, March 1997. 273 6.2. Informative References 275 [BIER] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 276 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 277 for BIER", draft-ietf-bier-ospf-bier-extensions-00.txt 278 (work in progress), April 2015. 280 [SEGMENT-ROUTING] 281 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 282 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 283 Extensions for Segment Routing", draft-ietf-ospf-segment- 284 routing-extensions-04.txt (work in progress), February 285 2015. 287 [TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., 288 and S. Litkowski, "Topology Independent Fast Reroute using 289 Segment Routing", draft-francois-spring-segment-routing- 290 ti-lfa-01.txt (work in progress), October 2014. 292 Appendix A. Acknowledgments 294 The RFC text was produced using Marshall Rose's xml2rfc tool. 296 Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, Eric Wu, and 297 Shraddha Hegde for their responses to the survey. 299 Author's Address 301 Acee Lindem 302 Cisco Systems 303 301 Midenhall Way 304 Cary, NC 27513 305 USA 307 Email: acee@cisco.com