Skip to main content

Last Call Review of draft-ietf-bmwg-bgp-basic-convergence-04

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
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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
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 


   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 


    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."