< draft-ietf-ospf-rfc4970bis-03.txt   draft-ietf-ospf-rfc4970bis-04.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 26, 2016 R. Aggarwal Expires: March 27, 2016 R. Aggarwal
Arktan Arktan
S. Shaffer S. Shaffer
Akamai Akamai
September 23, 2015 September 24, 2015
Extensions to OSPF for Advertising Optional Router Capabilities Extensions to OSPF for Advertising Optional Router Capabilities
draft-ietf-ospf-rfc4970bis-03.txt draft-ietf-ospf-rfc4970bis-04.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 26, 2016. This Internet-Draft will expire on March 27, 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 38 skipping to change at page 2, line 38
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
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 . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 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
applicable to both OSPFv2 and OSPFv3. Similarly, OSPFv2 or OSPFv3 applicable to both OSPFv2 and OSPFv3. Similarly, OSPFv2 or OSPFv3
skipping to change at page 3, line 36 skipping to change at page 3, line 36
1. The main change is that an OSPF router will be able to advertise 1. The main change is that an OSPF router will be able to advertise
multiple instances of the OSPF Router Information LSA. This multiple instances of the OSPF Router Information LSA. This
change permeates through much of the document change permeates through much of the document
2. Additionally, Section 2.5 includes an additional TLV for 2. Additionally, Section 2.5 includes an additional TLV for
functional capabilities. This is in contrast to the existing TLV functional capabilities. This is in contrast to the existing TLV
which is used to advertise capabilities for informational which is used to advertise capabilities for informational
purposes only. purposes only.
3. Finally, references have been updated for drafts that have become 3. The IANA allocation policy for the OSPFv3 LSA Function Code
registry and all the OSPF Router Information IANA registeries has
been changed from "Standards Action" to "IETF Review"
[IANA-GUIDE].
4. Finally, references have been updated for drafts that have become
RFCs and RFCs that have been obsoleted since the publication of RFCs and RFCs that have been obsoleted since the publication of
RFC 4970. RFC 4970.
2. OSPF Router Information (RI) LSA 2. OSPF Router Information (RI) LSA
OSPFv2 routers will advertise a link scoped, area-scoped, or AS- OSPFv2 routers will advertise a link scoped, area-scoped, or AS-
scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information (RI) LSA scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information (RI) LSA
has an Opaque type of 4 and the Opaque ID is the RI LSA instance ID. has an Opaque type of 4 and the Opaque ID is the RI LSA instance ID.
The first Opaque ID, i.e., 0, SHOULD always contain the Router The first Opaque ID, i.e., 0, SHOULD always contain the Router
Informational Capabilities TLV and, if advertised, the Router Informational Capabilities TLV and, if advertised, the Router
skipping to change at page 4, line 18 skipping to change at page 4, line 20
scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information LSA has an scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information LSA has an
Opaque type of 4 and Opaque ID specifies the LSA instance ID with the Opaque type of 4 and Opaque ID specifies the LSA instance ID with the
first instance always having an Instance ID of 0. first instance always having an Instance ID of 0.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10, or 11 | | LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Opaque ID (Instance ID) | | 4 | Opaque ID (Instance ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+d-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
skipping to change at page 11, line 22 skipping to change at page 11, line 22
| 12 | OSPFv3 RI LSA (Assigned herein) | | 12 | OSPFv3 RI LSA (Assigned herein) |
| | | | | |
| 13-15 | Already assigned | | 13-15 | Already assigned |
| | | | | |
| 16-255 | Unassigned (IETF Review) | | 16-255 | Unassigned (IETF Review) |
| | | | | |
| 256-8175 | Reserved (No assignments) | | 256-8175 | Reserved (No assignments) |
| | | | | |
| 8176-8183 | Experimentation (No assignments) | | 8176-8183 | Experimentation (No assignments) |
| | | | | |
| 8184-8191 | Vendor Private Use (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 * OSPFv3 LSA function codes in the range 16-255 are not be
assigned subject to IETF Review. New values are assigned only assigned subject to IETF Review. New values are assigned only
through RFCs that have been shepherded through the IESG as AD- through RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [IANA-GUIDE]. Sponsored or IETF WG Documents [IANA-GUIDE].
* OSPFv3 LSA function codes in the range 8176-8181 are for * 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 NOT be mentioned by RFCs. MUST NOT be mentioned by RFCs.
* OSPFv3 LSAs with an LSA Function Code in the Vendor Private * OSPFv3 LSAs with an LSA Function Code in the Vendor Private
Use range 8184-8191 MUST include the Vendor Enterprise Code as Use range 8184-8190 MUST include the Vendor Enterprise Code as
the first 4 octets following the 20 octets of LSA header. the first 4 octets following the 20 octets of LSA header.
* If a new LSA Function Code is documented, the documentation * If a new LSA Function Code is documented, the documentation
MUST include the valid combinations of the U, S2, and S1 bits MUST include the valid combinations of the U, S2, and S1 bits
for the LSA. It SHOULD also describe how the Link State ID is for the LSA. It SHOULD also describe how the Link State ID is
to be assigned. to be assigned.
Changes to the OSPFv3 LSA Function Code registry from RFC 4970
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 2. Registry for OSPF RI TLVs - This top-level registry will be
comprised of the fields Value, TLV Name, and Document Reference. comprised of the fields Value, TLV Name, and Document Reference.
The value of 1 for the informational capabilities TLV is defined The value of 1 for the informational capabilities TLV is defined
herein. The value IANA TBD (suggested value 2) for the Router herein. The value IANA TBD (suggested value 2) for the Router
Functional Capabilities TLV is also defined herein. Functional Capabilities TLV is also defined herein.
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| Range | Assignment Policy | | Range | Assignment Policy |
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| 0 | Reserved (not to be assigned) | | 0 | Reserved (not to be assigned) |
skipping to change at page 12, line 37 skipping to change at page 12, line 43
* Types in the range 2, 10-32767 are to be assigned subject to * Types in the range 2, 10-32767 are to be assigned subject to
IETF Review. New values are assigned only through RFCs that IETF Review. New values are assigned only through RFCs that
have been shepherded through the IESG as AD-Sponsored or IETF have been shepherded through the IESG as AD-Sponsored or IETF
WG Documents [IANA-GUIDE]. WG Documents [IANA-GUIDE].
* Types in the range 32778-65535 are reserved and are not to be * 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 range, there MUST be a Standards Track RFC that specifies this range, there MUST be a Standards Track RFC that specifies
IANA Considerations that covers the range being assigned. IANA Considerations that covers the range being assigned.
The only change to OSPF RI TLV registry from RFC 4970 is a change
to the allocation policy for the range 10-32767 from "Standard
Action" to "IETF Review".
3. Registry for OSPF Router Informational Capability Bits - This 3. Registry for OSPF Router Informational Capability Bits - This
sub-registry of the OSPF RI TLV registry will be comprised of the sub-registry of the OSPF RI TLV registry will be comprised of the
fields Bit Number, Capability Name, and Document Reference. The fields Bit Number, Capability Name, and Document Reference. The
values are defined in Section 2.4. All Router Informational values are defined in Section 2.4. All Router Informational
Capability TLV additions are to be assigned through IETF Review. Capability TLV additions are to be assigned through IETF Review.
This is changed from RFC 4970 where the allocation policy was
Standards Action.
4. Registry for OSPF Router Functional Capability Bits - This sub- 4. Registry for OSPF Router Functional Capability Bits - This sub-
registry of the OSPF RI TLV registry will be comprised of the registry of the OSPF RI TLV registry will be comprised of the
fields Bit Number, Capability Name, and Document Reference. fields Bit Number, Capability Name, and Document Reference.
Initially, the sub-registry will be empty but will be available Initially, the sub-registry will be empty but will be available
for future capabilities. All Router Functional Capability TLV for future capabilities. All Router Functional Capability TLV
additions are to be assigned through IETF Review. additions are to be assigned through IETF Review. This is
registery is added since RFC 4970 and will be added to the "OSPF
Shortest Path First v2 (OSPFv2) Parameters" group.
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 10 skipping to change at page 14, line 22
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.
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 Chris Bowers, Shraddha Hegde, and Alia Atlas for review of Thanks to Yingzhen Qu for acting as document shepherd.
the BIS version of this document.
Thanks to Chris Bowers, Alia Atlas, Shraddha Hegde, and Tom Petch for
review of 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
 End of changes. 14 change blocks. 
12 lines changed or deleted 35 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/