Re: [Idr] draft-litkowski-idr-bgp-timestamp

[<[e-mail]>]

Sure we can update the text.

Thanks,

Stephane


-----Original Message-----
From: Jon Mitchell [mailto:[e-mail]] 
Sent: Tuesday, July 22, 2014 18:23
To: LITKOWSKI Stephane SCE/IBNF
Cc: Robert Raszuk; Jeffrey Haas; idr wg
Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp

On 22/07/14 22:00 +0000, [e-mail] wrote:
> Hi Jon,
> 
> Thanks for your comment.
> Regarding packing, depending of the address family you are trying to monitor, current packing may be low or high. In case where existing packing is low, it does not change anything. In case packing is high, yes I agree that the processing of the update is a bit changed and my beacon would be sent may be faster. Packing is introducing slight delay but I don't think delay introduced by packing is a major component expect if an implementation get stucks in packing (it may happen but I never seen it). IMHO, I don't think this is a critical point but I'm open to other opinions.
> 
> Now for BMP, we are not targeting to monitor our beacons on all PEs, just a subset of representative.
> Moreover it's not only a question about number of sessions, it's a question of ordering the information retrieved. If you consider using BMP , the tool will peer with selected PEs, but also "transit BGP Speakers" (ASBRs, RRs ...). When the tool will receive the timestamp information (if implementation of BMP supports timestamp), it requires to sort and reorganize the received information based on the knowledge of the topology : you cannot just sort by timestamp, you have to find relationship between BGP Speakers (information from BMP and topology) and combine them to recreate our timestamp vector. BGP transport permits to create automatically this timestamp vector without having to implement a complex machinery in the tool. But BMP can be used at the selected PE to the tool to retrieve timestamp vectors.
> 

Stephane - yes, I think this second point is the real object of the draft (correct me if I'm wrong).  Offline correlation engines are complicated to implement and/or expensive, although commercially available.  Getting the timestamp data seems not to be the real issue here at all (via BMP or other mechanisms a local implementation can provide).  Maybe this point should be more clear in the intro and text.

Jon

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.