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

[Thomas Mangin <[e-mail]>]

Bonjour Stephane,

I am not at the meeting, so could only work from your draft ... Your proposal seems sensitive and useful to me and I believe it would be a useful addition to the protocol.

IMHO, adding some extra message processing would take some CPU time, taking this CPU from the propagation of UPDATE, so the format should be as simple as possible and require as little parsing as possible. It is not clear to me that a speaker can ignore the validity of the data before appending its TS. Forcing the TS to be validated at every hop would seems to be self-defeating. The format is as well quite complex to parse and I would be in favour of a much more simple one with less flags and/or options.

Regarding format proposed :

Type 1 and Type 2 and later in peer : 16 bits ASN can be coded using 32 bits - why make a distinction - we do not need to know if the speaker considered itself or was configured as a ASN4 speaker. Why not include ASN and IPs ( prepended with AFI/SAFI so it is possible to include other Family later )
Why not always include all possible information ASN, IP, IPv6 ( knowing that only some may be present ). At debugging time, it is not clear what would be most useful therefore having both the AS and IP should be better.

Receiving timestamp from January 1900, I am under the impression that most system have built-in Epoch function from 1970 and with 64 bits would not suffer from any issue with 2038, I wonder why you picked 1990 (which I realise is another option).

Regarding the Peer Flags,I would rather see all the information being included (ASN and IP). Debugging information should try to provide as much information as possible.

4.2, I assume this apply for prefixes which match the selection in 4.1

4.4, I would rather see TS being transmitted by default on IBGP sessions and explicit on EBGP ( easier to configure )

4.5.2 does not say how the new TS should be set. It is not clear if the summary option must be implemented or can be left out ( IMHO, this should be left out the draft and be left to be done by the external tool displaying the information )

4.6 does not indicate what must be done if two TS entries are in the both synchronised but inconsistent, like a time sequence of 1, 3, 2, 5 where a router found a way to go back in time :-) .... Should it be ignored or should this TS sequence be seen as invalid and discarded ( assuming each router is performing some validation of the attribute ).

Only skimmed over 5+ 

Thomas

On 22 Jul 2014, at 23:00, <[e-mail]> <[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.
> 
> Hope it clarifies.
> 
> Stephane
> 
> 
> -----Original Message-----
> From: Jon Mitchell [mailto:[e-mail]] 
> Sent: Tuesday, July 22, 2014 17:28
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: Robert Raszuk; Jeffrey Haas; idr wg
> Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp
> 
> On 22/07/14 19:19 +0000, [e-mail] wrote:
>> [Renamed topic]
>> 
>> Hi Robert,
>> 
>>> Your results may actually in the above case casue more problems then gains unfortunately.
>> 
>> I don’t really understand why … even if RR are not in the dataplane (which would be the case for VPN environment), RR behavior is really important to track.
>> 
>> Consider a MPLS VPN scenario, some PEs connected to RR clusters and meshing between clusters.
>> Consider that one of the RR is getting stuck because of Route-refresh processing of 2M of routes or just busy to do something else due to bad scheduling in the implemention … if a PE lose a customer connection, and customer has a backup connection and backup PE has to send a new BGP update to propagate the new path. The time for RR to propagate the BGP update is critical to track because this will condition convergence time for the customer …
>> 
>> Thoughts ?
> 
> Stephane -
> 
> I'm supportive of your goal, however after the presentation I'm still a bit unclear on the need for the BGP extension to propogate the timestamp information.  As was brought up by Saikat today in the WG meeting, if update packing is different for this prefix due to the timestamp attribute then it loses some of it's value for providing an accurate view of your end to end BGP propogation time.  Someone suggested BMP, it appears it already supports this option in paragraph 3 of Section 5 of that draft.  The justification given that instrumenting sessions (BMP/BGP/or other export mechanism for the data) to all routers versus getting the information from egress PE only does not seem to be a large concern if monitoring this route propogation is of importance to the operator.  After all presumably there are a much larger number of PE's in most networks than RR's so instrumenting monitoring all devices is not much more work than just the PE's. Specifying or identifying which prefixes are monitored (the timestamp is collected and exported for) seems also like something that can be handled by the local implementation based on a community or other attributes.
> 
> 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.
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr