Geoff,
If I've got it straight now, you're saying that you really wish you
could have the bit-for-bit (or at least update-for-update) property of
the -00 version of the draft, because you're interested in the fine-
grained dynamics of the BGP update stream. But if you can't have that
(and you can't :-), you'd at least like some hints in that direction.
Correct?
This seems like a reasonable desire and one can imagine providing a SR
message with information about the update stream as received from the
peer (for example). My caveat is the same as I told Ruediger this
morning -- that implementability and minimal intrusiveness is of
paramount importance.
--John
On Nov 19, 2008, at 1:54 PM, Geoff Huston wrote:
but form the client's perspective it still looks the same as a
discarded message - i.e. there is a gap in the data stream
i.e. the client sees a withdraw and then a little later see another
withdraw with no intervening announcement, for example
with sequencing of messages from the source the gap in the
information flow is then a little more obvious
geoff
(who could well be a card carrying member of the Bad Idea
Department in this case - I dunno! ;-) )
On 20/11/2008, at 6:48 AM, John G. Scudder wrote:
In -01 there's no such thing as discarded messages -- if the
monitoring station backpressures the BGP speaker, the BGP speaker
simply stops generating messages until the monitoring station is
ready to consume more messages. This was the most important change
between -00 and -01.
--John
On Nov 19, 2008, at 1:37 PM, Geoff Huston wrote:
While we are on the topic of suggestions from the great unwashed
masses about this draft, you might also want to consider the
suggestion that the BGP speaker should sequentially number the BMP
messages to the BMP client so that if the sender was forced to
discard msgs because of a broken or stalled TCP connection that
caused local backlog overflow of to-be-sent messages, then the
receiver could at least be aware that these was an interruption in
the feed of msgs by a jump in the sequence number space.
Geoff
On 20/11/2008, at 3:28 AM, Erik Romijn wrote:
Hi all,
John G. Scudder wrote:
Fast forward to present, there's been significant renewed
interest so
we've dusted off the draft and modified the mechanism to make it
more implementor-friendly. I'm hoping that the WG would still,
after the long hiatus, like to adopt the draft.
Having been thinking myself about a similar custom system from
time to time, this looks very useful to me.
Briefly reading through the draft, I do notice that there is no
way to detect the existence of a peer if it sends no prefixes
(except when the session goes down).
This should probably not be a common case, but we do see it from
time to time. It would be useful for us to be able to have this
data.
cheers,
Erik Romijn
RIPE NCC RIS
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
