Skip to main content

Last Call Review of draft-ietf-bmwg-bgp-basic-convergence-04
review-ietf-bmwg-bgp-basic-convergence-04-genart-lc-halpern-2014-10-30-00

Request Review of draft-ietf-bmwg-bgp-basic-convergence
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-11-10
Requested 2014-10-30
Authors Rajiv Papneja , Bhavani Parise , Susan Hares , Dean Lee , Ilya Varlashkin
Draft last updated 2014-10-30
Completed reviews Genart Last Call review of -04 by Joel M. Halpern (diff)
Secdir Last Call review of -04 by Chris M. Lonvick (diff)
Opsdir Last Call review of -04 by Scott O. Bradner (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Review review-ietf-bmwg-bgp-basic-convergence-04-genart-lc-halpern-2014-10-30
Reviewed revision 04 (document currently at 05)
Result Almost Ready
Completed 2014-10-30
review-ietf-bmwg-bgp-basic-convergence-04-genart-lc-halpern-2014-10-30-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-bmwg-bgp-basic-convergence-04.txt
    Basic BGP Convergence Benchmarking Methodology for Data Plane
                             Convergence
Reviewer: Joel M. Halpern
Review Date: 30-October-2014
IETF LC End Date: 10-November-2014
IESG Telechat date: N/A



Summary: This document is almost ready for publication as an 


informational RFC.




Major issues: None.

Minor issues:



    The four subtraction in step of section 5.1.2 appear to be 


backwards, as they subtract a later event time from an earlier event time.






    Should the test procedures recommend using CLI / SNMP / NetConf to 


verify adjacency establishment, rather than just observing / waiting for 


KeepAlives?






   What is meant by "Restart" in step H for 5.2.1.  Or conversely, why 


bother draining the queue, since you will just refill it in an 


uncontrolled fashion?  The step first waits for queues to drain.  But 


there needs to be traffic flowing before step I.  It is unclear why one 


would drain the queue, and the refill the queue an unspecified amount. 


(This also appears in step H of 5.3)






    Given normal BGP behavior which requires that only one route be 


selected, shouldn't 5.2.3 be more specific about what sort of ECMP can 


be tested?






    I believe 5.3 step J has a cut-and-paste where it should have a 


subtraction?






    Isn't it a bit tricky to record the time of a non-event?  (5.6 step 


10, Record the time when no traffic is observed.)  Deciding when an 


expected packet was not received seems to have more uncertainty than 


recording when a packet is received.  Could the withdrawl test been done 


by having a less preferred route and observing traffic arriving on that 


less-preferred route?




Nits/editorial comments:



    Step F of 5.2.1 should note that the time of the shutdown will be 


named Shutdown time.






    In section 5.4.1 the relevant steps are missing the "This time is 


called" text.  Also should there be a step between G and H to actually 


observe the restarted traffic?






    Why does 5.7 J exist.  The test is complete by then, isn't it.  If 


J is prep for "Repeat the test"< then it should not have "Restart."