Skip to main content

Extensions to OSPF for Advertising Optional Router Capabilities
RFC 4970

Revision differences

Document history

Date Rev. By Action
2017-05-16
11 (System) Changed document authors from "Rahul Aggarwal, Naiming Shen, Acee Lindem, Scott Shaffer" to "Rahul Aggarwal, Naiming Shen, Acee Lindem, Scott Shaffer, JP Vasseur"
2015-10-14
11 (System) Notify list changed from ospf-chairs@ietf.org to (None)
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Mark Townsley
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for David Kessens
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2007-07-31
11 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-07-31
11 Amy Vezza [Note]: 'RFC 4970' added by Amy Vezza
2007-07-31
11 (System) RFC published
2007-05-14
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-05-14
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-05-11
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-05-11
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-05-11
11 (System) IANA Action state changed to In Progress from Waiting on ADs
2007-05-11
11 (System) IANA Action state changed to Waiting on ADs from Waiting on Authors
2007-05-10
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-05-10
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-05-08
11 (System) New version available: draft-ietf-ospf-cap-11.txt
2007-05-08
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-03-19
11 (System) IANA Action state changed to In Progress
2007-03-16
11 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-03-15
11 Amy Vezza IESG state changed to Approved-announcement sent
2007-03-15
11 Amy Vezza IESG has approved the document
2007-03-15
11 Amy Vezza Closed "Approve" ballot
2007-03-08
11 Bill Fenner State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bill Fenner
2007-03-01
11 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Mark Townsley
2007-03-01
11 David Kessens [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens
2007-02-13
11 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-02-13
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-02-13
10 (System) New version available: draft-ietf-ospf-cap-10.txt
2007-02-09
11 (System) Removed from agenda for telechat - 2007-02-08
2007-02-08
11 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-02-08
11 (System) [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by IESG Secretary
2007-02-08
11 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-02-08
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2007-02-08
11 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-02-08
11 David Kessens
[Ballot discuss]
In section '4. Interoperability with routers not supporting the

capability TLV.':

  If leaking of the CAP TLV is required, the entire CAP …
[Ballot discuss]
In section '4. Interoperability with routers not supporting the

capability TLV.':

  If leaking of the CAP TLV is required, the entire CAP TLV MUST be
  leaked into another level even though it may contain some of the
  unsupported sub-TLVs.

How does one know that leaking is required if one doesn't support the
the 'Router CAPABILITY TLV' ?
2007-02-08
11 David Kessens [Ballot Position Update] New position, Discuss, has been recorded by David Kessens
2007-02-07
11 Sam Hartman
[Ballot comment]
I agree with Mark.  I'd be OK with designated expert with clear
guidelines (probably assisted by a mailing list) although ietf
consensus might …
[Ballot comment]
I agree with Mark.  I'd be OK with designated expert with clear
guidelines (probably assisted by a mailing list) although ietf
consensus might be easier.
2007-02-07
11 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman
2007-02-07
11 Mark Townsley
[Ballot discuss]
6-31      Future assignments

  discretion
  and sound engineering judgment MUST be adhered to when deciding
  whether newly proposed TLV(s) …
[Ballot discuss]
6-31      Future assignments

  discretion
  and sound engineering judgment MUST be adhered to when deciding
  whether newly proposed TLV(s) in support of a new application are
  advertised in the RI LSA or warrant the creation of an application
  specific LSA.

  2.  Registry for OSPF Router Informational Capability Bits - The
      values defined in Section 2.3.  All Router Informational
      Capability TLV additions are subject to review by an expert
      designated by the IESG.

Given that this is a fixed bitfield, and the advice of discretion in assignment, shouldn't the policy be a bit more strict than designated expert?
2007-02-07
11 Mark Townsley [Ballot Position Update] New position, Discuss, has been recorded by Mark Townsley
2007-02-07
11 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-02-07
11 Dan Romascanu [Ballot comment]
It would be useful to expand LSA at the first occurence in the Abstract section.
2007-02-06
11 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2007-02-05
11 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-02-05
11 Russ Housley
[Ballot discuss]
To resolve SecDir Review comments from Kurt Zeilenga the author agreed
  to change the security considerations.  The changes have not happened
  …
[Ballot discuss]
To resolve SecDir Review comments from Kurt Zeilenga the author agreed
  to change the security considerations.  The changes have not happened
  yet.  The expected text is:
  >
  > This document describes both a generic mechanism for advertising
  > router capabilities and a TLV for advertising informational capability
  > bits.  The latter TLV is less critical than the topology information
  > currently advertised by the base OSPF protocol.  The security
  > considerations for the generic mechanism are dependent on the future
  > application and, as such, should be described as additional
  > capabilities are proposed for advertisement.  Security considerations
  > for the base OSPF protocol are covered in [OSPF] and [OSPFV3].
2007-02-05
11 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-02-04
11 Brian Carpenter
[Ballot discuss]
Need the -10 version:

On 2006-11-28 21:41, Acee Lindem wrote:
> Hi David,
> Thanks for the review. All your comments will be …
[Ballot discuss]
Need the -10 version:

On 2006-11-28 21:41, Acee Lindem wrote:
> Hi David,
> Thanks for the review. All your comments will be in the -10 version of the
> document. Here is my new text for the "Security Considerations" section:
>
> 4.  Security Considerations
>
>  This document describes both a generic mechanism for advertising
>  router capabilites and a TLV for advertising informational capability
>  bits.  The latter TLV is less critical than the topology information
>  currently advertised by the base OSPF protocol.  The security
>  considerations for the generic mechanism are dependent on the future
>  application and, as such, should be described as additional
>  capabilities are proposed for advertisement.  Security considerations
>  for the base OSPF protocol are covered in [OSPF] and [OSPFV3].
2007-02-04
11 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded by Brian Carpenter
2007-02-02
11 Bill Fenner
From: Acee Lindem <acee@redback.com>
Subject: IANA Actions for draft-ietf-ospf-cap
Date: Fri, Feb 2 06:26:50
To: iana-drafts@iana.org
Cc: JP Vasseur <jvasseur@cisco.com>, Rahul …
From: Acee Lindem <acee@redback.com>
Subject: IANA Actions for draft-ietf-ospf-cap
Date: Fri, Feb 2 06:26:50
To: iana-drafts@iana.org
Cc: JP Vasseur <jvasseur@cisco.com>, Rahul Aggarwal <rahul@juniper.net>, Naiming Shen <naiming@cisco.com>, Scott Shaffer
    <sshaffer1@bridgeport-networks.com>, Bill Fenner <fenner@research.att.com>

Hi IANA Staff,

Here are my comments on the IANA actions for draft-ietf-ospf-cap-09.txt.

On Feb 1, 2007, at 2:59 PM, Acee Lindem wrote:

> Date and Time:        2006-11-28, 20:35:53
> Version:      09
> Commented by: Yoshiko Chong
> State before Comment: Waiting for Writeup
> State after Comment:  Waiting for Writeup
> Comment:      IANA Last Call Comments:
>
> Editors and WG chairs please read this carefully as the
> document was NOT clear on where to make the assignements,
> this is IANA's best guess on which registries you wanted
> assignments in!
>
>
> First action:
> Upon approval of this document, the IANA will make the
> following assignments in the "OSPF Opaque LSA Option"
> registry located
>
> http://www.iana.org/assignments/ospf-opaque-types
>
> Value Opaque Type Reference
> ------ ----------- ---------
> 4 Router Information [RFC-ospf-cap-09]

This is correct.

>
>
> Second Action:
> Upon approval of this document, the IANA will make the
> following assignments in the  "Open Shortest Path First
> (OSPF) Traffic Engineering TLVs per [RFC3630]" registry
> located at
>
> http://www.iana.org/assignments/ospf-traffic-eng-tlvs
> Sub-registry "Types for sub-TLVs in a TE Link TLV"
>
> Value sub-TLV Reference
> ---------- -------------------- ---------
> 18 Router Information (RI) Opaque LSA [RFC-ospf-cap-09]

This is incorrect. This action is unnecessary. Other than having the 
same structure RI TLVs are unrelated to TE TLVs.

However the action for the OSPFv3 function code addition is missing. 
The OSPFv3 LSA function code registry referenced in section draft-
kompella-ospf-iana-01.txt. Here is the text - this draft should have 
made it through the process by now but there is a hold up with the 
author.

2.5  OSPFv3 LSA Function Code

    (Defined in section A.4.2.1 of [5])

                    +-----------+--------------------+
                    | Range    | Assignment Policy  |
                    +-----------+--------------------+
                    | 0        | Not to be assigned |
                    |          |                    |
                    | 1-9      | Already assigned  |
                    |          |                    |
                    | 10-255    | Standards Action  |
                    |          |                    |
                    | 255-8175  | Reserved          |
                    |          |                    |
                    | 8175-8183 | Experimentation    |
                    |          |                    |
                    | 8184-8191 | Vendor Private Use |
                    +-----------+--------------------+

    In an OSPFv3 LSA with LSA Function Code in the Vendor Private Use
    range, the first four octets following the 20 octets of LSA header
    MUST be the Vendor enterprise code.

    If a new LSA Function Code is documented, the documentation MUST
    include the valid combinations of the U, S2 and S1 bits for the LSA.

    It SHOULD also say how the Link State ID is to be filled in.


>
>
>
> Action #3:
> Upon approval of this document, the IANA will in the following
> registry "Open Shortest Path First (OSPF) Traffic Engineering
> TLVs per [RFC3630]" located at
>
> http://www.iana.org/assignments/ospf-traffic-eng-tlvs
> create a new sub-registry " OSPF Router Informational TLVs"
>
> Initial contents of this sub-registry will be:
> 0 Available for assignment
> 1 OSPF Router Informational Capabilities TLV [RFC-ospf-cap-09]
> 2 - 65535 Available for assignment

This is incorrect. This should be a new registry for OSPF Capability 
TLVs which is not a sub-registry of any other registry.


>
>
>
>
> Allocation policy: Expert review, IESG needs to appoint expert.
>
>
>
> Action #4:
> Upon approval of this document, the IANA will in the following
> registry "Open Shortest Path First (OSPF) Traffic Engineering TLVs per
> [RFC3630]" located at

Incorrect. This should be a sub-registry of the registry created in 
action 3.

> http://www.iana.org/assignments/ospf-traffic-eng-tlvs
> create a new sub-registry "OSPF Router Informational Capability Bits"
> initial contents:
>
> value NAME Referene:
> 0 OSPF graceful restart capable [RFC3623]
> 1 OSPF graceful restart helper [RFC3623]
> 2 OSPF Stub Router support [RFC3137]
> 3 OSPF Traffic Engineering support [RFC3630]
> 4 OSPF point-to-point over LAN [RFC-isis-igp-p2p-over-lan-05]
> 5 OSPF Experimental TE [RFC-srisuresh-ospf-te-07]
> 6-31 Available for assignment




>
>
> Allocation policy: Expert review, IESG needs to appoint expert.
>
> References:
> [RFC-isis-igp-p2p-over-lan-05] Shen, N. and A. Zinin,
> "Point-to-point operation over LAN in link-state routing
> protocols", draft-ietf-isis-igp-p2p-over-lan-05.txt
> (work in progress) [RFC-srisuresh-ospf-te-07] Srisuresh,
> P. and P. Joseph,  "OSPF OSPF-TE: An experimental extension
> to OSPF for Traffic Engineering",
> draft-srisuresh-ospf-te-07.txt (work in progress).
>
>
> We understand the above to be the only IANA Actions for
> this document.
>

Feel free to contact me if you have any further questions.

Thanks,
Acee
2007-02-02
11 Magnus Westerlund
[Ballot comment]
The security consideration section seems thin. Isn't it recommended that one actually describe which parts of an referenced document that is applicable to …
[Ballot comment]
The security consideration section seems thin. Isn't it recommended that one actually describe which parts of an referenced document that is applicable to this doc.
2007-02-02
11 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-01-29
11 Bill Fenner State Changes to IESG Evaluation from Waiting for Writeup by Bill Fenner
2007-01-29
11 Bill Fenner Placed on agenda for telechat - 2007-02-08 by Bill Fenner
2007-01-29
11 Bill Fenner [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner
2007-01-29
11 Bill Fenner Ballot has been issued by Bill Fenner
2007-01-29
11 Bill Fenner Created "Approve" ballot
2006-11-28
11 Yoshiko Fong
IANA Last Call Comments:

Editors and WG chairs please read this carefully as the
document was NOT clear on where to make the assignements,
this …
IANA Last Call Comments:

Editors and WG chairs please read this carefully as the
document was NOT clear on where to make the assignements,
this is IANA's best guess on which registries you wanted
assignments in!


First action:
Upon approval of this document, the IANA will make the
following assignments in the "OSPF Opaque LSA Option"
registry located

http://www.iana.org/assignments/ospf-opaque-types

Value Opaque Type Reference
------ ----------- ---------
4 Router Information [RFC-ospf-cap-09]


Second Action:
Upon approval of this document, the IANA will make the
following assignments in the  "Open Shortest Path First
(OSPF) Traffic Engineering TLVs per [RFC3630]" registry
located at

http://www.iana.org/assignments/ospf-traffic-eng-tlvs
Sub-registry "Types for sub-TLVs in a TE Link TLV"

Value sub-TLV Reference
---------- -------------------- ---------
18 Router Information (RI) Opaque LSA [RFC-ospf-cap-09]



Action #3:
Upon approval of this document, the IANA will in the following
registry "Open Shortest Path First (OSPF) Traffic Engineering
TLVs per [RFC3630]" located at

http://www.iana.org/assignments/ospf-traffic-eng-tlvs
create a new sub-registry " OSPF Router Informational TLVs"

Initial contents of this sub-registry will be:
0 Available for assignment
1 OSPF Router Informational Capabilities TLV [RFC-ospf-cap-09]
2 - 65535 Available for assignment

Allocation policy: Expert review, IESG needs to appoint expert.



Action #4:
Upon approval of this document, the IANA will in the following
registry "Open Shortest Path First (OSPF) Traffic Engineering TLVs per
[RFC3630]" located at
http://www.iana.org/assignments/ospf-traffic-eng-tlvs
create a new sub-registry "OSPF Router Informational Capability Bits"
initial contents:

value NAME Referene:
0 OSPF graceful restart capable [RFC3623]
1 OSPF graceful restart helper [RFC3623]
2 OSPF Stub Router support [RFC3137]
3 OSPF Traffic Engineering support [RFC3630]
4 OSPF point-to-point over LAN [RFC-isis-igp-p2p-over-lan-05]
5 OSPF Experimental TE [RFC-srisuresh-ospf-te-07]
6-31 Available for assignment


Allocation policy: Expert review, IESG needs to appoint expert.

References:
[RFC-isis-igp-p2p-over-lan-05] Shen, N. and A. Zinin,
"Point-to-point operation over LAN in link-state routing
protocols", draft-ietf-isis-igp-p2p-over-lan-05.txt
(work in progress) [RFC-srisuresh-ospf-te-07] Srisuresh,
P. and P. Joseph,  "OSPF OSPF-TE: An experimental extension
to OSPF for Traffic Engineering",
draft-srisuresh-ospf-te-07.txt (work in progress).


We understand the above to be the only IANA Actions for
this document.
2006-11-08
11 (System) Request for Early review by SECDIR Completed. Reviewer: Kurt Zeilenga.
2006-11-06
11 (System) State has been changed to Waiting for Writeup from In Last Call by system
2006-10-23
11 Amy Vezza Last call sent
2006-10-23
11 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-10-23
11 Bill Fenner Last Call was requested by Bill Fenner
2006-10-23
11 Bill Fenner State Changes to Last Call Requested from AD Evaluation::AD Followup by Bill Fenner
2006-10-23
11 (System) Ballot writeup text was added
2006-10-23
11 (System) Last call text was added
2006-10-23
11 (System) Ballot approval text was added
2006-10-22
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-10-22
09 (System) New version available: draft-ietf-ospf-cap-09.txt
2006-10-19
11 Bill Fenner State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Bill Fenner
2006-07-24
11 Bill Fenner [Note]: 'The PROTO shepherd is Rohit Dube <dube.rohit@gmail.com>' added by Bill Fenner
2006-07-24
11 Bill Fenner State Change Notice email list have been change to ospf-chairs@tools.ietf.org from acee@cisco.com, dube.rohit@gmail.com
2006-07-24
11 Bill Fenner [Note]: 'The PROTO shepherd is Rohit Dube &lt;dube.rohit@gmail.com&gt;' added by Bill Fenner
2006-01-23
11 Bill Fenner State Changes to AD Evaluation from Publication Requested by Bill Fenner
2006-01-23
11 Bill Fenner [Note]: 'The PROTO shepherd is Rohit Dube <dube.rohit@gmail.com>' added by Bill Fenner
2006-01-23
11 Bill Fenner State Change Notice email list have been change to acee@cisco.com, dube.rohit@gmail.com from acee@cisco.com, rohit@utstar.com
2005-12-02
08 (System) New version available: draft-ietf-ospf-cap-08.txt
2005-07-18
11 Bill Fenner
Proto writeup:

1. Have the chairs personally reviewed this version of the
  Internet Draft (ID), and in particular, do they believe
  this ID …
Proto writeup:

1. Have the chairs personally reviewed this version of the
  Internet Draft (ID), and in particular, do they believe
  this ID is ready to forward to the IESG for publication?

  Yes. Acee is the editor of the draft and Rohit has reviewed
  earliar versions.
 

2. Has the document had adequate review from both key WG
  members and key non-WG members? Do you have any concerns
  about the depth or breadth of the reviews that have been performed?

  Again - non-WG members don't typically review OSPF WG drafts.
  We've received comments from serveral WG members and those have
  been incorporated into the draft. We've also received comments
  from Adrian Farrell and incorporated his comments (people who
  comment on drafts are automatically WG members :^).


3. Do you have concerns that the document needs more review from
  a particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

  No. 

4. Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or have concerns whether there really is a need for it. In any
  event, if your issues have been discussed in the WG and the WG
  has indicated it that it still wishes to advance the document,
  detail those concerns in the write-up.

  No - I have no concerns.

  There have been some concerns over the life of the draft:

    A. That the capabilities LSA will become a catch-all TLV
        container. Section 3.0 was added to the draft to address this
        concern.

    B. That router capabilities are advertised solely for
        informational purposes. This was the orginal purpose of the
        LSA as expressed by a draft author. I don't feel that this
        incringes on OM&A and agree that it is useful to provide
        this information via the LSA. Note that the informational
        and functional bits will be carried in separate TLVs.
     
    C. That a given router can advertise different capabilities
        LSAs at different flooding scopes.  This is covered in
        section 2.5 of the draft. 

5. How solid is the WG consensus behind this document? Does it
  represent the strong concurrence of a few individuals, with
  others being silent, or does the WG as a whole understand
  and agree with it?

  I'd beleive is closer to the former. However, there have been
  comments from a number of WG members and a number of proposals
  that have been based on the capabilities LSA.

6. Has anyone threatened an appeal or otherwise indicated extreme
  discontent? If so, please summarise the areas of conflict in
  separate email to the Responsible Area Director.

  No.

7. Have the chairs verified that the document adheres to all of
  the ID Checklist items ?

  The document was created using xml2rfc so it should satisfy the
  nits.

8. Is the document split into normative and informative references?
  Are there normative references to IDs, where the IDs are not also
  ready for advancement or are otherwise in an unclear state? (note
  here that the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs
  are also ready for publication as RFCs.)

  No drafts as normative references.

9. What is the intended status of the document? (e.g., Proposed Standard,
  Informational?)

  Proposed Standard
2005-07-01
11 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-05-23
07 (System) New version available: draft-ietf-ospf-cap-07.txt
2005-02-15
06 (System) New version available: draft-ietf-ospf-cap-06.txt
2005-01-07
05 (System) New version available: draft-ietf-ospf-cap-05.txt
2004-12-02
04 (System) New version available: draft-ietf-ospf-cap-04.txt
2004-07-08
03 (System) New version available: draft-ietf-ospf-cap-03.txt
2004-06-01
02 (System) New version available: draft-ietf-ospf-cap-02.txt
2003-10-24
01 (System) New version available: draft-ietf-ospf-cap-01.txt
2003-07-25
00 (System) New version available: draft-ietf-ospf-cap-00.txt