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

[Jon Mitchell <[e-mail]>]

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