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

Stephane: 

Try looking into time-stamp when BGP packet gets put on the transmit queue.
The purpose is that you avoid the costly inbound policy and outbound policy
cycles.  Let me know if it is just as complex. 

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of
stephane.litkowski@orange.com
Sent: Friday, July 25, 2014 12:48 PM
To: Susan Hares; 'Jon Mitchell'
Cc: 'Jeffrey Haas'; 'idr wg'; 'Robert Raszuk'
Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp

Susan,

Thanks for pointing this. We will investigate the possibility to do it from
an implementation point of view. Putting timestamp at receive side is easy,
at transmit side it may be more complex and really implementation dependant
as we would need to try to have a consensus at which part of the sending
process, we would need to put the timestamp (Update formatting, Route
Queueing for the peer group ...)

Best Regards,

Stephane

-----Original Message-----
From: Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, July 24, 2014 14:50
To: 'Jon Mitchell'; LITKOWSKI Stephane SCE/IBNF
Cc: 'Jeffrey Haas'; 'idr wg'; 'Robert Raszuk'
Subject: RE: [Idr] draft-litkowski-idr-bgp-timestamp

Jon and Stephan: 

Based on work with vendor boxes for the BMWG BGP work - I would recommend
you timestamp the BGP trace NLRI as you leave the BGP Peer and as you
receive it. Otherwise, you run into the data flow patterns the trace NLRI is
included in causing variation in your flows.

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell
Sent: Tuesday, July 22, 2014 6:23 PM
To: stephane.litkowski@orange.com
Cc: Jeffrey Haas; idr wg; Robert Raszuk
Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp

On 22/07/14 22:00 +0000, stephane.litkowski@orange.com 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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

____________________________________________________________________________
_____________________________________________

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.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr