| < draft-ietf-ospf-rfc4970bis-04.txt | draft-ietf-ospf-rfc4970bis-05.txt > | |||
|---|---|---|---|---|
| Network Working Group A. Lindem, Ed. | Network Working Group A. Lindem, Ed. | |||
| Internet-Draft N. Shen | Internet-Draft N. Shen | |||
| Obsoletes: 4970 (if approved) J. Vasseur | Obsoletes: 4970 (if approved) J. Vasseur | |||
| Intended status: Standards Track Cisco Systems | Intended status: Standards Track Cisco Systems | |||
| Expires: March 27, 2016 R. Aggarwal | Expires: March 28, 2016 R. Aggarwal | |||
| Arktan | Arktan | |||
| S. Shaffer | S. Shaffer | |||
| Akamai | Akamai | |||
| September 24, 2015 | September 25, 2015 | |||
| Extensions to OSPF for Advertising Optional Router Capabilities | Extensions to OSPF for Advertising Optional Router Capabilities | |||
| draft-ietf-ospf-rfc4970bis-04.txt | draft-ietf-ospf-rfc4970bis-05.txt | |||
| Abstract | Abstract | |||
| It is useful for routers in an OSPFv2 or OSPFv3 routing domain to | It is useful for routers in an OSPFv2 or OSPFv3 routing domain to | |||
| know the capabilities of their neighbors and other routers in the | know the capabilities of their neighbors and other routers in the | |||
| routing domain. This document proposes extensions to OSPFv2 and | routing domain. This document proposes extensions to OSPFv2 and | |||
| OSPFv3 for advertising optional router capabilities. The Router | OSPFv3 for advertising optional router capabilities. The Router | |||
| Information (RI) Link State Advertisement (LSA) is defined for this | Information (RI) Link State Advertisement (LSA) is defined for this | |||
| purpose. In OSPFv2, the RI LSA will be implemented with an opaque | purpose. In OSPFv2, the RI LSA will be implemented with an opaque | |||
| LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique | LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique | |||
| skipping to change at page 1, line 47 ¶ | skipping to change at page 1, line 47 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 27, 2016. | This Internet-Draft will expire on March 28, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 | |||
| 1.2. Summary of Changes from RFC 4970 . . . . . . . . . . . . 3 | 1.2. Summary of Changes from RFC 4970 . . . . . . . . . . . . 3 | |||
| 2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . 3 | 2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . 4 | |||
| 2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4 | 2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4 | |||
| 2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 6 | 2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 6 | |||
| 2.3. OSPF Router Informational Capabilities TLV . . . . . . . 6 | 2.3. OSPF Router Informational Capabilities TLV . . . . . . . 6 | |||
| 2.4. Assigned OSPF Router Informational Capability Bits . . . 7 | 2.4. Assigned OSPF Router Informational Capability Bits . . . 7 | |||
| 2.5. OSPF Router Functional Capabilities TLV . . . . . . . . . 8 | 2.5. OSPF Router Functional Capabilities TLV . . . . . . . . . 8 | |||
| 2.6. Flooding Scope of the Router Information LSA . . . . . . 9 | 2.6. Flooding Scope of the Router Information LSA . . . . . . 9 | |||
| 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 | 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 5.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 10 | ||||
| 5.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 10 | ||||
| 5.3. OSPF RI LSA TLV Type Assignment . . . . . . . . . . . . . 12 | ||||
| 5.4. Registry for OSPF RI Informational Capability Bits . . . 13 | ||||
| 5.5. Registry for OSPF RI Functional Capability Bits . . . . . 13 | ||||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 13 | 6.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 1. Introduction | 1. Introduction | |||
| It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFV3] | It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFV3] | |||
| routing domain to know the capabilities of their neighbors and other | routing domain to know the capabilities of their neighbors and other | |||
| routers in the routing domain. This can be useful for both the | routers in the routing domain. This can be useful for both the | |||
| advertisement and discovery of OSPFv2 and OSPFv3 capabilities. | advertisement and discovery of OSPFv2 and OSPFv3 capabilities. | |||
| Throughout this document, OSPF will be used when the specification is | Throughout this document, OSPF will be used when the specification is | |||
| skipping to change at page 10, line 37 ¶ | skipping to change at page 10, line 37 ¶ | |||
| functional capability bits. The capability TLVs are less critical | functional capability bits. The capability TLVs are less critical | |||
| than the topology information currently advertised by the base OSPF | than the topology information currently advertised by the base OSPF | |||
| protocol. The security considerations for the generic mechanism are | protocol. The security considerations for the generic mechanism are | |||
| dependent on the future application and, as such, should be described | dependent on the future application and, as such, should be described | |||
| as additional capabilities are proposed for advertisement. Security | as additional capabilities are proposed for advertisement. Security | |||
| considerations for the base OSPF protocol are covered in [OSPF] and | considerations for the base OSPF protocol are covered in [OSPF] and | |||
| [OSPFV3]. | [OSPFV3]. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| The following IANA assignment was made from an existing registry: | 5.1. OSPFv2 Opaque LSA Type Assignment | |||
| The OSPFv2 opaque LSA type 4 has been reserved for the OSPFv2 RI | [RFC4970] defined the Router Information opaque LSA as type 4 in the | |||
| opaque LSA. | Opaque Link-State Advertisements (LSA) Option Types Registry. IANA | |||
| is asked to update the reference for that entry to point to this RFC. | ||||
| The following registries have been defined for the following | 5.2. OSPFv3 LSA Function Code Assignment | |||
| purposes: | ||||
| 1. Registry for OSPFv3 LSA Function Codes - This top-level registry | [RFC4970] created the registry for OSPFv3 LSA Function Codes. IANA | |||
| will be comprised of the fields Value, LSA function code name, | is requested to update the reference for that registry to point to | |||
| and Document Reference. The OSPFv3 LSA function code is defined | this RFC. References within that registry to [RFC4970] should be | |||
| in section A.4.2.1 of [OSPFV3]. The OSPFv3 LSA function code 12 | updated to point to this RFC; references to other RFCs are unchanged. | |||
| has been reserved for the OSPFv3 Router Information (RI) LSA. | The definition and assignment policy has been updated as follows. | |||
| +-----------+-------------------------------------+ | This registry is now comprised of the fields Value, LSA function code | |||
| | Range | Assignment Policy | | name, and Document Reference. The OSPFv3 LSA function code is | |||
| +-----------+-------------------------------------+ | defined in section A.4.2.1 of [OSPFV3]. The OSPFv3 LSA function code | |||
| | 0 | Reserved (not to be assigned) | | 12 has been reserved for the OSPFv3 Router Information (RI) LSA. The | |||
| | | | | assignment policy has been updated for the range 16-255. | |||
| | 1-11 | Already assigned | | ||||
| | | | | +-----------+-------------------------------------+ | |||
| | 12 | OSPFv3 RI LSA (Assigned herein) | | | Range | Assignment Policy | | |||
| | | | | +-----------+-------------------------------------+ | |||
| | 13-15 | Already assigned | | | 0 | Reserved (not to be assigned) | | |||
| | | | | | | | | |||
| | 16-255 | Unassigned (IETF Review) | | | 1-11 | Already assigned | | |||
| | | | | | | | | |||
| | 256-8175 | Reserved (No assignments) | | | 12 | OSPFv3 RI LSA (Assigned herein) | | |||
| | | | | | | | | |||
| | 8176-8183 | Experimentation (No assignments) | | | 13-15 | Already assigned | | |||
| | | | | | | | | |||
| | 8184-8190 | Vendor Private Use (No assignments) | | | 16-255 | Unassigned (IETF Review) | | |||
| | | | | | | | | |||
| | 8191 | Reserved (not to be assigned) | | | 256-8175 | Reserved (No assignments) | | |||
| +-----------+-------------------------------------+ | | | | | |||
| | 8176-8183 | Experimentation (No assignments) | | ||||
| | | | | ||||
| | 8184-8190 | Vendor Private Use (No assignments) | | ||||
| | | | | ||||
| | 8191 | Reserved (not to be assigned) | | ||||
| +-----------+-------------------------------------+ | ||||
| OSPFv3 LSA Function Codes | OSPFv3 LSA Function Codes | |||
| * OSPFv3 LSA function codes in the range 16-255 are not be | o OSPFv3 LSA function codes in the range 16-255 are to be assigned | |||
| assigned subject to IETF Review. New values are assigned only | subject to IETF Review. New values are assigned only through RFCs | |||
| through RFCs that have been shepherded through the IESG as AD- | that have been shepherded through the IESG as AD- Sponsored or | |||
| Sponsored or IETF WG Documents [IANA-GUIDE]. | IETF WG Documents [IANA-GUIDE]. | |||
| * OSPFv3 LSA function codes in the range 8176-8181 are for | o OSPFv3 LSA function codes in the range 8176-8181 are for | |||
| experimental use; these will not be registered with IANA and | experimental use; these will not be registered with IANA and MUST | |||
| MUST NOT be mentioned by RFCs. | NOT be mentioned by RFCs. | |||
| * OSPFv3 LSAs with an LSA Function Code in the Vendor Private | o OSPFv3 LSAs with an LSA Function Code in the Vendor Private Use | |||
| Use range 8184-8190 MUST include the Vendor Enterprise Code as | range 8184-8191 MUST include the Vendor Enterprise Code as the | |||
| the first 4 octets following the 20 octets of LSA header. | first 4 octets following the 20 octets of LSA header. | |||
| * If a new LSA Function Code is documented, the documentation | o If a new LSA Function Code is documented, the documentation MUST | |||
| MUST include the valid combinations of the U, S2, and S1 bits | include the valid combinations of the U, S2, and S1 bits for the | |||
| for the LSA. It SHOULD also describe how the Link State ID is | LSA. It SHOULD also describe how the Link State ID is to be | |||
| to be assigned. | assigned. | |||
| Changes to the OSPFv3 LSA Function Code registry from RFC 4970 | 5.3. OSPF RI LSA TLV Type Assignment | |||
| include changing the allocation policy for the range 16-255 from | ||||
| "Standard Action" to "IETF Review" and reservation of the | ||||
| maxiumum value (8191). | ||||
| 2. Registry for OSPF RI TLVs - This top-level registry will be | [RFC4970] created the registry for OSPF Router Information (RI) TLVs. | |||
| comprised of the fields Value, TLV Name, and Document Reference. | IANA is requested to update the reference for this registry to point | |||
| The value of 1 for the informational capabilities TLV is defined | to this RFC. The definition and assignment policy has been updated | |||
| herein. The value IANA TBD (suggested value 2) for the Router | as follows. References within that registry to [RFC4970] should be | |||
| Functional Capabilities TLV is also defined herein. | updated to point to this RFC; references to other RFCs are unchanged. | |||
| The definition and assignment policy has been updated as follows. | ||||
| +-------------+-----------------------------------+ | The registry is now comprised of the fields Value, TLV Name, and | |||
| | Range | Assignment Policy | | Document Reference. The value of 1 for the informational | |||
| +-------------+-----------------------------------+ | capabilities TLV is defined herein. The value IANA TBD (suggested | |||
| | 0 | Reserved (not to be assigned) | | value 2) for the Router Functional Capabilities TLV is also defined | |||
| | | | | herein. | |||
| | 1 | Informational Capabilities | | ||||
| | | | | +-------------+-----------------------------------+ | |||
| | 2 | Unassigned (IETF Review) | | | Range | Assignment Policy | | |||
| | | | | +-------------+-----------------------------------+ | |||
| | TBD | Functional Capabilities | | | 0 | Reserved (not to be assigned) | | |||
| | | | | | | | | |||
| | 3-9 | Already Assigned | | | 1 | Informational Capabilities | | |||
| | | | | | | | | |||
| | 10-32767 | Unassigned (IETF Review) | | | 2 | Unassigned (IETF Review) | | |||
| | | | | | | | | |||
| | 32768-32777 | Experimentation (No assignments) | | | TBD | Functional Capabilities | | |||
| | | | | | | | | |||
| | 32778-65535 | Reserved (Not to be assigned) | | | 3-9 | Already Assigned | | |||
| +-----------+-------------------------------------+ | | | | | |||
| | 10-32767 | Unassigned (IETF Review) | | ||||
| | | | | ||||
| | 32768-32777 | Experimentation (No assignments) | | ||||
| | | | | ||||
| | 32778-65535 | Reserved (Not to be assigned) | | ||||
| +-------------+-----------------------------------+ | ||||
| OSPF RI TLVs | OSPF RI TLVs | |||
| * Types in the range 2, 10-32767 are to be assigned subject to | o Types in the range 2, 10-32767 are to be assigned subject to IETF | |||
| IETF Review. New values are assigned only through RFCs that | Review. New values are assigned only through RFCs that have been | |||
| have been shepherded through the IESG as AD-Sponsored or IETF | shepherded through the IESG as AD-Sponsored or IETF WG Documents | |||
| WG Documents [IANA-GUIDE]. | [IANA-GUIDE]. | |||
| * Types in the range 32778-65535 are reserved and are not to be | o Types in the range 32778-65535 are reserved and are not to be | |||
| assigned at this time. Before any assignments can be made in | assigned at this time. Before any assignments can be made in this | |||
| this range, there MUST be a Standards Track RFC that specifies | range, there MUST be a Standards Track RFC that specifies IANA | |||
| IANA Considerations that covers the range being assigned. | Considerations that covers the range being assigned. | |||
| The only change to OSPF RI TLV registry from RFC 4970 is a change | 5.4. Registry for OSPF RI Informational Capability Bits | |||
| to the allocation policy for the range 10-32767 from "Standard | ||||
| Action" to "IETF Review". | ||||
| 3. Registry for OSPF Router Informational Capability Bits - This | [RFC4970] created the registry for OSPF Router Informational | |||
| sub-registry of the OSPF RI TLV registry will be comprised of the | Capability Bits. IANA is requested to update the reference for this | |||
| fields Bit Number, Capability Name, and Document Reference. The | registry to point to this RFC. The definition and assignment policy | |||
| values are defined in Section 2.4. All Router Informational | has been updated as follows. | |||
| Capability TLV additions are to be assigned through IETF Review. | ||||
| This is changed from RFC 4970 where the allocation policy was | o This registry is now comprised of the fields Bit Number, | |||
| Standards Action. | Capability Name, and Document Reference. | |||
| 4. Registry for OSPF Router Functional Capability Bits - This sub- | o The values are defined in Section 2.4. All Router Informational | |||
| registry of the OSPF RI TLV registry will be comprised of the | Capability TLV additions are to be assigned through IETF Review | |||
| fields Bit Number, Capability Name, and Document Reference. | [IANA-GUIDE]. | |||
| Initially, the sub-registry will be empty but will be available | ||||
| for future capabilities. All Router Functional Capability TLV | 5.5. Registry for OSPF RI Functional Capability Bits | |||
| additions are to be assigned through IETF Review. This is | ||||
| registery is added since RFC 4970 and will be added to the "OSPF | IANA ia asked to create a registry for OSPF Router Functional | |||
| Shortest Path First v2 (OSPFv2) Parameters" group. | Capability Bits within the Open Shortest Path First v2 (OSPFv2) | |||
| Parameters Group. This registry will be comprised of the fields Bit | ||||
| Number, Capability Name, and Document Reference. Initially, the sub- | ||||
| registry will be empty but will be available for future capabilities. | ||||
| All Router Functional Capability TLV additions are to be assigned | ||||
| through IETF Review [IANA-GUIDE]. | ||||
| 6. References | 6. References | |||
| 6.1. Normative References | 6.1. Normative References | |||
| [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The | [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The | |||
| OSPF Opaque LSA Option", RFC 5250, July 2008. | OSPF Opaque LSA Option", RFC 5250, July 2008. | |||
| [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | |||
| skipping to change at page 14, line 19 ¶ | skipping to change at page 14, line 32 ¶ | |||
| McPherson, "OSPF Stub Router Advertisement", RFC 6987, | McPherson, "OSPF Stub Router Advertisement", RFC 6987, | |||
| September 2013. | September 2013. | |||
| Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
| The idea for this work grew out of a conversation with Andrew Partan | The idea for this work grew out of a conversation with Andrew Partan | |||
| and we would like to thank him for his contribution. The authors | and we would like to thank him for his contribution. The authors | |||
| would like to thanks Peter Psenak for his review and helpful comments | would like to thanks Peter Psenak for his review and helpful comments | |||
| on early versions of the document. | on early versions of the document. | |||
| Special thanks to Tom Petch for providing the updated IANA text in | ||||
| the BIS version of the document. | ||||
| Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian | Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian | |||
| Farrel have been incorporated into later versions. | Farrel have been incorporated into later versions. | |||
| Thanks to Yingzhen Qu for acting as document shepherd. | Thanks to Yingzhen Qu for acting as document shepherd. | |||
| Thanks to Chris Bowers, Alia Atlas, Shraddha Hegde, and Tom Petch for | Thanks to Chris Bowers, Alia Atlas, and Shraddha Hegde for review of | |||
| review of the BIS version of this document. | the BIS version of this document. | |||
| The RFC text was produced using Marshall Rose's xml2rfc tool. | The RFC text was produced using Marshall Rose's xml2rfc tool. | |||
| Authors' Addresses | Authors' Addresses | |||
| Acee Lindem (editor) | Acee Lindem (editor) | |||
| Cisco Systems | Cisco Systems | |||
| 301 Midenhall Way | 301 Midenhall Way | |||
| Cary, NC 27513 | Cary, NC 27513 | |||
| USA | USA | |||
| Email: acee@cisco.com | Email: acee@cisco.com | |||
| Naiming Shen | Naiming Shen | |||
| Cisco Systems | Cisco Systems | |||
| End of changes. 28 change blocks. | ||||
| 108 lines changed or deleted | 127 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||