Last Call Review of draft-ietf-ospf-two-part-metric-05

Request Review of draft-ietf-ospf-two-part-metric
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-10-11
Requested 2016-08-08
Authors Zhaohui Zhang, Lili Wang, Acee Lindem
Draft last updated 2016-09-21
Completed reviews Genart Last Call review of -05 by Brian Carpenter (diff)
Genart Telechat review of -09 by Brian Carpenter (diff)
Opsdir Last Call review of -05 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Review review-ietf-ospf-two-part-metric-05-opsdir-lc-kuarsingh-2016-09-21
Reviewed rev. 05 (document currently at 10)
Review result Has Nits
Review completed: 2016-09-21


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 - OSPF Two-part Metric

Link to Document -


This document specifies an option extension to the OSPF protocol metric 

which allows calculations of said metric to consider the 

network-to-router and router-to-network components.  The document would 

update both RFC2328 (OSPF Version 2) and RFC5340 (OSPF for IPv6)

The document presents use cases in which such dual metric calculations 

can help such as with a satellite radio network.

General Comments and Feedback:

The document is well written and provides the needed details to describe 

the new functionality, and rationale for it based on real world 

scenarios. No specific feedback is provided on how to change the 

protocol and/or on updates to the document's text.  Only one 

operationally focused question for the authors is included in this 

review to help provide clarity on potentially impacting events and it's 

effect on the routers operating in this new mode.

(1). Potential Excessive recalculations [Minor] ?

In Section 3.7 it notes that all routers capable of running in this new 

mode shall do so and advertise the RI LSA.  If a new router in that area 

were to be connected and deemed to not be able to run in this new state, 

the local routers " MUST recalculate routers without considering the 

network-to-router costs".

My question is that if a router which does not support this new mode of 

operation (or is specifically configured not to do so) on a network with 

questionable connectivity (i.e. flapping) where to join and then be 

timed out within the area, could this cause excessive recalculations on 

the remaining routers? (it's not 100% understood if the router then 

leaves the area again, whether the remaining routers would then 

recalculate again to reconsider the network-to-router costs).

Should some type of dampening be used to prevent such conditions form 

running up the CPU and/or processing time of the routers?

Textual Review, questions and feedback:

None recommended.