On 20/11/2008, at 8:06 AM, John G. Scudder wrote:
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?
Yes, that is 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.
of course, and I appreciate that caveat.
Thanks for your efforts in this work - I for one am very interested in
this. From a very selfish perspective I have high expectations of its
utility in my work on BGP dynamics.
Geoff
--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
