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 <dube.rohit@gmail.com>' 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 |