Subject: Re: [Gen-art] Review: draft-ietf-bmwg-bgp-basic-convergence-04.txt

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Nov 2014 20:59:22 -0500

Joel: 

Answers below to your questions: 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, October 30, 2014 6:28 PM
To: A. Jean Mahoney; [email-masked];
[email-masked]
Cc: IETF discussion list; [email-masked]
Subject: [Gen-art] Review: draft-ietf-bmwg-bgp-basic-convergence-04.txt

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?
[Sue]: The keepalives are on "on-wire" feature that indicates the adjacency
is formed rather than believing the cli/snmp/netconf
Opinion.  Early testing found that these features may anticipate the event
of adjacency establishment. 

    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)

[Sue: Restart the data flow.  We will correct this text] 

 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?
[Sue: The basic BGP only allows one 

     I believe 5.3 step J has a cut-and-paste where it should have a
subtraction?
[Sue: Did you mean step "G" for 5.3? ]

    G.  Measure the Convergence Time for the event to be detected and
          traffic to be forwarded to Next-Best Egress Interface.  This
          time is Tr-rr2 also called TR2-traffic-on

             Convergence = TR2-traffic-on - BGPpeer-down]

     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?
[Sue: One of the parameters can be how long of traffic absence determines
"no traffic".  Would this work for you? 
On the second question, this goes through a different datapath in some
routers so we advised the "no traffic" implemented by the 
IXIA and other testers.   Do you have a preference for the previous?  We
could define both.] 

Nits/editorial comments:

     Step F of 5.2.1 should note that the time of the shutdown will be named
Shutdown time.
[Sue: Will fix in next draft] 

     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?
[Sue: Yes - to both, will fix in next draft.] 

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

[Sue: Because we want clear instructions on the restart for different
attributes. Otherwise people misunderstood how to implement.]  
     J.  Stop the offered load and wait for the queues to drain and
          Restart.

      K.  Repeat the test for various attributes.