Review: draft-ietf-bmwg-bgp-basic-convergence-04.txt

"Joel M. Halpern" <[email protected]>
Newsgroups gmane.ietf.gen-art,gmane.ietf.general,gmane.ietf.bmwg
Message-ID <[email protected]>
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."
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.