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

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






On 4/4/14, 2:34 PM, "Fernando Calabria (fcalabri)" <[email protected]>
wrote:

>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 
>
>
>
>
>On 4/4/14, 5:29 PM, "Dean Lee" <[email protected]> wrote:
>
>>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