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

[Jeffrey Haas <[e-mail]>]

Jon,

On Tue, Jul 22, 2014 at 05:27:35PM -0400, Jon Mitchell wrote:
> 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.

This is definitely true.  However, this would also be true of any other
in-bgp mechanism.  This then asks the question of why not use an outside of
BGP mechanism.

> 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. 

And yet, it's a large amount of data.  The requests we've had in terms of
tuning what BMP supplies has been mostly with respect to limiting the amount
of data that is available in the stream.  Being able to watch for the probe
prefix only at the end station accomplishes the main goal.

Certainly, an alternative could be to have a specific BMP session only for
the purposes of watching for the probe routes but this still would involve
catching the routes at each collector along the path.  

Another observation that had been made during the discussion of the initial
draft version was simply the amount of transient noise at the intermediate
nodes in your reflector mesh.  The "ping pong" of convergence adds noise
that you have to ignore.  And honestly, we don't care about the multiple
hits we'd get at a given device - it's not helpful data unless you were
trying to measure reflector convergence artifacts.

> 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.

With exactly the same property you note above about breaking the route
packing. :-)

-- Jeff