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 - 

https://tools.ietf.org/html/draft-ietf-ospf-rfc4970bis-06





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 


document?




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

Section 3.0: Backwards Compatibility

regards,

Victor K