Subject: Re: [GROW] Spencer Dawkins' No Objection on draft-ietf-grow-bmp-15: (with COMMENT)

From: "John G. Scudder" <[email-masked]>
Date: Wed, 4 Nov 2015 14:43:41 +0900

On Oct 15, 2015, at 1:03 AM, Spencer Dawkins <[email-masked]> wrote:
> I found myself wondering when you can start route mirroring,

I think the answer is "pretty much any time" following the Initiation and Peer Up. It's true this isn't written down anywhere. I propose adding this to the end of S 4.7:

   A Route Mirroring message may be sent any time it would be legal to
   send a Route Monitoring message.

> and whether
> there was any guidance about what to do when a BGP speaker runs out of
> buffers so that route mirroring is no longer complete.

Yes, there is. You send one of these:

   o  Type = 1: Information.  A two-byte code that provides information
      about the mirrored message or message stream.  Defined codes are:
...
      *  Code = 1: Messages Lost.  One or more messages may have been
         lost.  This could occur, for example, if an implementation runs
         out of available buffer space to queue mirroring messages.

Thanks,

--John

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 5 Nov 2015 23:08:13 +0900

Hi, John,

On Wed, Nov 4, 2015 at 2:43 PM, John G. Scudder <[email-masked]> wrote:

> I think the answer is "pretty much any time" following the Initiation and
> Peer Up. It's true this isn't written down anywhere. I propose adding this
> to the end of S 4.7:
>

That's helpful. Thanks!

>          out of available buffer space to queue mirroring messages.

Got it. I'm sorry for not being clearer. I meant "what to do AFTER a BGP
speakers runs out of buffers so that route mirroring is no longer
complete". So, Code = 1: Messages Lost.

Do you wait before trying to resynchronize, for instance? Or is retrying
immediately OK? Stuff like that.

Spencer

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 6 Nov 2015 07:48:02 +0900

On Nov 5, 2015, at 11:08 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> I meant "what to do AFTER a BGP speakers runs out of buffers so that route mirroring is no longer complete". So, Code = 1: Messages Lost.
> 
> Do you wait before trying to resynchronize, for instance? Or is retrying immediately OK? Stuff like that.

Oh, I see. Sorry about that. No, there is no specific guidance. I think it would be very difficult to provide general guidance because the correct strategy is going to depend on what the application is. For example, if the monitor is doing the main expected use case of gathering a routing table, once messages are lost it really has to give up and retry from the beginning. However it's easy to imagine other applications, such as watching for the advertisement or withdrawal of a beacon route which is being done periodically. Such an application might simply say "oh well" and wait for the next beacon. So, I think putting in general guidance would be misleading rather than helpful.

Thanks for bringing this up,

--John

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 6 Nov 2015 07:51:58 +0900

Hi, John,

On Nov 6, 2015 7:48 AM, "John G. Scudder" <[email-masked]> wrote:
>> I meant "what to do AFTER a BGP speakers runs out of buffers so that
route mirroring is no longer complete". So, Code = 1: Messages Lost.
>
>
> Oh, I see. Sorry about that. No, there is no specific guidance. I think
it would be very difficult to provide general guidance because the correct
strategy is going to depend on what the application is. For example, if the
monitor is doing the main expected use case of gathering a routing table,
once messages are lost it really has to give up and retry from the
beginning. However it's easy to imagine other applications, such as
watching for the advertisement or withdrawal of a beacon route which is
being done periodically. Such an application might simply say "oh well" and
wait for the next beacon. So, I think putting in general guidance would be
misleading rather than helpful.
> Thanks for bringing this up,

Thank you for helping me understand!

Spencer