Extensions to OSPF for Advertising Optional Router Capabilities
draft-ietf-ospf-rfc4970bis-07

[Ballot comment]
I just have a nit:  The text immediately under the Section 2 header is only related to OSPFv2 — that would fit better under 2.1. (OSPFv2 Router Information (RI) Opaque LSA).  Leave the general header for general information.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ospf-rfc4970bis-04. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested by this document. (Please see Action 5.)

IANA understands that upon approval, this document requires five sets of registry actions.

ACTION 1:

The following Opaque Link-State Advertisements (LSA) Option Type registration (http://www.iana.org/assignments/ospf-opaque-types) will be updated to be refer to this document rather than RFC 4970:             

4 Router Information (RI) [this document]

ACTION 2:

IANA will make the following changes in the OSPFv3 LSA Function Code registry (http://www.iana.org/assignments/ospfv3-parameters):

- update the following registrations and the registry itself to refer to this document rather than RFC 4970:

0 Reserved [this document]
12 OSPFv3 Router Information (RI) LSA [this document]

- change the column headings to "Value," "LSA Function Code Name," and "Reference"

NOTE: IANA would prefer to use the name "Reference" rather than "Document Reference" in order to maintain uniformity across registries. Because this registry requires IETF Review, only RFCs will be listed in this column.

- change the registration procedure for the non-reserved range (1-255) from Standards Action to IETF Review

- remove value 8191 from the "Vendor Private Use" range and list it as "Reserved"

- list this document as a reference for the "Reserved," "Experimental," and "Vendor Private Use" entries that don't currently list references

ACTION 3:

IANA will make the following changes in the OSPF Router Information (RI) TLVs registry (http://www.iana.org/assignments/ospfv2-parameters):

- update the following registrations and the registry itself to refer to this document rather than RFC 4970:

0 Reserved [this document]
1 RI Informational Capabilities [this document]
32768-32777 Experimentation [this document]
32778-65535 Reserved [this document]

- change the column headings to "Value," "TLV Name," and "Reference"

- change the registration procedure for the non-reserved range (1-32767) from Standards Action to IETF Review

- register the following:

TBD (value 2 suggested) Router Functional Capabilities TLV [this document]

ACTION 4:

IANA will make the following changes in the OSPF Router Informational Capability Bits registry (http://www.iana.org/assignments/ospfv2-parameters):

- update the registry itself to refer to this document rather than RFC 4970

- change the column headings to "Bit Number," "Capability Name," and "Reference"

- change the registration procedure from Standards Action to IETF Review

- in accordance with Section 2.4, update the following assignment to refer to RFC 6987 rather than RFC 3137:

2 OSPF Stub Router support

- in accordance with Section 2.4, update the following assignment to refer to RFC 5309 rather than "N. Shen, A. Zinin, 'Point-to-point operation over LAN in link-state routing protocols', Work in Progress, April 2006":

4 OSPF point-to-point over LAN

ACTION 5:

IANA will create the following registry, initially empty, at http://www.iana.org/assignments/ospfv2-parameters:

Registry Name: OSPF RI Functional Capability Bits
Registration Procedure: IETF Review
Reference: [this document]

The required fields will be "Bit Number," "Capability Name," and "Reference."

QUESTION: What is the range of available values for this registry? If 0 isn't available, should it be marked "Reserved"?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extensions to OSPF for Advertising Optional Router Capabilities) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'Extensions to OSPF for Advertising Optional Router Capabilities'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
  know the capabilities of their neighbors and other routers in the
  routing domain.  This document proposes extensions to OSPFv2 and
  OSPFv3 for advertising optional router capabilities.  The Router
  Information (RI) Link State Advertisement (LSA) is defined for this
  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 function code.  In both protocols, the RI LSA can be
  advertised at any of the defined flooding scopes (link, area, or
  autonomous system (AS)).  This document obsoletes RFC 4970 by
  providing a revised specification including support for advertisement
  of multiple instances of the RI LSA and a TLV for functional
  capabilities.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc4970bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc4970bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Did AD review - various nits and a number of minor issues around the IANA considerations.

In addition, two major concerns:

First, from a process concern, I do not see any active discussion on the OSPF mailing list - even to simply say "yes - go forward".  I don't see anything about this draft or discussion in minutes for IETF 92 or IETF 93.  I'd prefer some indication besides silence and lack of opposition.  I do realize that there are some process or protocol-tidying drafts where there isn't
much interest.  However, I am particularly concerned because this is changing RFC4970 is a way that should be backwards compatible but might trigger issues.  I would encourage WG participants to PLEASE RESPOND!

Second, I can see the intent that by creating an Opaque ID and creating a special meaning for 0, the draft is making efforts to preserve backwards compatibility.  Please add a paragraph or subsection that articulates how and why backwards compatibility isn't an issue.  For extra credit, what happens if the same TLV information is advertised in multiple RI LSAs (as part of moving it from one RI LSA to another)?

Are there any implementations of this draft?  Has backwards compatibility been verified at all?