Last Call Review of draft-ietf-ospf-two-part-metric-05
review-ietf-ospf-two-part-metric-05-opsdir-lc-kuarsingh-2016-09-21-00

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 - 


https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-08








Summary:



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.