Last Call Review of draft-ietf-ospf-rfc4970bis-05

Request Review of draft-ietf-ospf-rfc4970bis
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-10-13
Requested 2015-09-28
Draft last updated 2015-10-19
Completed reviews Genart Last Call review of -05 by Dan Romascanu (diff)
Genart Last Call review of -05 by Dan Romascanu (diff)
Opsdir Last Call review of -05 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Review review-ietf-ospf-rfc4970bis-05-opsdir-lc-kuarsingh-2015-10-19
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Review completed: 2015-10-19


Dear Authors,

I have reviewed this document as part of the Operational directorate's 

ongoing effort to review all IETF documents being processed by the 

IESG.  These comments were written with the intent of improving the 

operational aspects of the IETF drafts. Comments that are not addressed 

in last call may be included in AD reviews during the IESG review.  

Document editors and WG chairs should treat these comments just like any 

other last call comments.

Document Reviewed - draft-ietf-ospf-rfc4970bis-06
Link to Document -

This document updates RFC4970 which originally defined extensions to 

OSPF optionally advertise router capabilities to neighbor OSPF speakers 

/ routers.  This BIS document is focused  on making two key changes 

which include a new TLV for advertising functional capabilities and 

defines the ability to advertise multiple instances of the OSPF Router 

Information LSA.  Other terminology was changed (“IETF Review”) per 

RFC5226 and references were updated.

Much of the text was present in RFC4970, and well at the original 

extensions defined.  The updated document is also well written and is 

clear. The new functionality introduced we clearly defined (Section 2.6: 

Router Functional Capabilities TLV) and the authors did add specific 

text (in Section 3) for backwards compatibility. One comment (shown 

below in review) was made here from an operational perspective, but is 

not seen as blocking (regarding some definition around configured state 

vs. potentially conflicting advertised state).

Outside of that, the document is well done.

Draft Review - OSPF RFC4970BIS

Extensions to OSPF for Advertising Optional Router Capabilities

1.0: Introduction
- ok

1.1: Requirements Notation
- ok

1.2 Summary of Changes from RFC 4970
- ok
- Good clear explanation of changes in BIS document.

Section 2.0: OSPF Router Information (RI) LSA

- Confirm in Paragraph 1, last sentence, that the word “subsequence” was 

to be used.

Section 2.1: OSPFv2 Router Information (RI) Opaque LSA
- ok

Section 2.2: OSPFv3 Router Information (RI) Opaque LSA
- ok

Section 2.3: OSPF Router Information LSA TLV Format

- Section paragraph.  The author uses both the terms “octet” and 

“xx-bit” within the paragraph to describe the same basic padding 

concept.  Although it’s technically correct, perhaps consistency may be 

valid here?.

- Example “Nest TLVs are also 4-octet aligned”.

Section 2.4: OSPF Router Informational Capabilities TLV
- ok

Section 2.5: Assigned OSPF Router Informational Capability Bits
- ok

Section 2.6: OSPF Router Functional Capabilities TLV

- This section describes the additions to the OSPF RI LSAs.  The new 

functional capabilities TLV is described, however it’s not 100% clear on 

how a device would behave if configured differently then the advertised 

capabilities may indicate from a neighboring router. Would it also be 

advisable (potentially) to note that configured router state supersedes 

advertised state?  or would you consider that out of scope for this 


Section 2.7: Flooding Scope o the Router Information LSA
- ok

Section 3.0: Backwards Compatibility


Victor K