Subject: Re: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt

From: Dean Lee <[email-masked]>
Date: Fri, 4 Apr 2014 20:29:17 +0000

Hi Fernando,

Thanks for your feedback.

We didn’t specify clearly how to capture the arrival time (Tup(DUT,Rt-A))
of advertised routes at DUT because there are multiple options to achieve
the same result. We like to leave it to readers and implementers to choose
the suitable test tools. To my best knowledge, there are few options to
capture the arrival time (Tup(DUT,Rt-A)):

* DUT’s log file - as you indicated in the feedback, this option doesn’t
offer the best timing resolution and the emulator needs to be synchronized
with the time base of DUT. This option is not scalable to deal with large
amount of routes.

* External analyzer - this option requires an external analyzer to capture
NLRI packets between the emulator and DUT. The packets capturing can be
done with a TAP device or span port of DUT if applicable. The time base of
analyzer and emulator needs to be synchronized.

* Hybrid emulator and analyzer - some modern test tools have the
capability to capture and timestamp every NLRI packets leaving and
arriving at the emulator ports. The timestamps of these NLRI packets will
be almost identical to (Tup(DUT,Rt-A)) if the cable distance between the
emulator and DUT is relatively short.

Dean

On 3/14/14, 11:15 AM, "Fernando Calabria (fcalabri)" <[email-masked]>
wrote:

>Hi there,  I hope everyone is doing ok and you had a good productive  time
>@ London Š
>
>After reading the doc, I find the methodology as well as the overall  Test
>Coverage very well laid out.
>
>I personally see some room for further improvement / expansion in some of
>the specific procedures,  for example:
>
>5.1.1 RIB-IN Convergence..  Step ³F²
>
>Record the time when the route A from Peer-x is received at
>          the DUT.
>
>
>The authors may want to expand here and described how Œexactly¹ the tester
> can  measure this specific time.
>
>I would expect that it is not by  relying in any sort of Œdebugs¹ / logs ,
>nor for a single  prefix and even worst for the case of multiple ones.
>
>A  suggestion would be to  have a ³TAP² or a Sniffer and make note of the
>exact time the UPDATE carrying the corresponding  NLRI makes it to the
>³wire² 
>
>This comment also applies  to 5.1.2 point ³I² and to  other Test Cases as
>well.
>
>
>Rgds 
>
>Fernando
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>bmwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bmwg

---

From: "Fernando Calabria (fcalabri)" <[email-masked]>
Date: Fri, 4 Apr 2014 21:34:27 +0000

This is great, don’t you think that the document may benefit with a
paragraph describing these options  and the possible trade-off of each
approach / technique ?

Rgds 

Fernando

---

From: Dean Lee <[email-masked]>
Date: Sat, 5 Apr 2014 16:28:58 +0000

Hi  Fernando,

We initially don’t want to make the benchmark draft tied with specific set
of test tools or test capabilities. Our intention was to make it generic
for the test methodology and allow the readers to choose the tool sets to
best fit their test environments. I thought this has been the guidance
from BMWG. I will discuss with other authors to see if they agree to add
paragraph to describe the possible test tool setup.

Dean

---

From: "Fernando Calabria (fcalabri)" <[email-masked]>
Date: Sat, 5 Apr 2014 20:04:31 +0000

Hi there , 

I personally don’t  think u need to discuss the test tool x say, just
recommend some generic methodologies and point out the pros and cons of
each, like you described in your original reply

Rgds 

Fernando 

On 4/5/14, 1:28 PM, "Dean Lee" <[email-masked]> wrote:

>>>>I would expect that it is not by  relying in any sort of Œdebugs¹ /
>>>>logs
>>>>,