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

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 protected]>
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 protected]
>https://www.ietf.org/mailman/listinfo/bmwg

_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg