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

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

On Oct 15, 2015, at 5:01 AM, Ben Campbell <[email-masked]> wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Stephen's and Kathleen's discuss positions concerning the lack
> of MTI security. I'm balloting no-objection (for now) so that those
> conversations can happen on their respective threads.
> 
> 3.2: 
> The says no message is ever sent by the monitoring station, but the last
> paragraph in the section mentions a monitoring station sending a
> termination message.

Fixed now, thanks.

> Also, does the strategy for retrying failed
> connection attempts apply to reconnects after the fail or an existing
> connection?

Sorry, I don't understand this question.

> The 3rd paragraph from the end talks about redundant connections
> happening when both parties are configured as active. But previous
> paragraphs suggested that only passive endpoints will listen for a
> connection. How could this result in redundant connections?

To quote the draft,

   as might occur if both parties are configured
   to be active

I'm a little bit embarrassed to admit to having (pretty much) recapitulated the BGP-3 and BGP-4 connection collision strategies, except...

> Is there
> logic to make sure the endpoints do not terminate both redundant
> connections?

... the document punts on providing a specific algorithm. I'm comfortable with this given the likely use cases and lack of grave consequences for redundant connections.

> IANA Considerations:
> 
> Several of the tables reserve an experimental range of 65531 through
> 65534. Is it really the intent to have experimental ranges with only 4
> code-points each?

Yes. I tend to think of experimental ranges as a necessary evil whose only non-evil use is to allow implementers to compile something while they're waiting to get their proper, registered code point. Accordingly, I didn't specify big ranges. I'm open to changing the ranges to something larger, but still small, like 16 or something like that. Otherwise, we may have to have a longer discussion.

--John