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

["Fernando Calabria (fcalabri)" <[e-mail]>]

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" <[e-mail]> wrote:

>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)" <[e-mail]>
>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" <[e-mail]> 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)"
>>><[e-mail]>
>>>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
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/bmwg
>>>
>>
>