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

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