Subject: [GROW] Proposed change to BMP registry policies

From: "John G. Scudder" <[email-masked]>
Date: Wed, 29 Mar 2017 14:47:36 -0500

Tl;dr: I propose changing almost all the BMP registries to FCFS.

Hi GROW/BMP Fans,

With the pair of draft-evens BMP drafts, we now have some allocation requests from our freshly-minted BMP registries. (https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#initiation-message-tlvs)

I took a look at the registries and TBH I'm not sure why we established them with the policies given. Most of the code points are 16-bit fields, which means they're not a scarce resource, but nevertheless they have restrictive allocation policies -- they're all split 50/50 between Standards Action and Specification Required. Maybe when I was proposing the policies I was thinking Spec Req'd was more permissive than it actually is? But it ain't, not really, it's pretty close to Standards Action in practice.

I have in recent times become a fan of the First Come, First Served allocation policy, as a way to virtually eliminate the need to squat on code points. Administrative overhead is very low, you can generally get a code point in a couple business days with about 10 minutes of paperwork. The downside of FCFS is that if you have something that actually does need to be locked down either because it's a scarce resource or for some other reason, you can't. Furthermore I've become less enamored of splitting policies -- it now seems to me to be needless, and unhelpful, structure since a rational and experienced person will always select a code point from the most permissive range, FCFS. OTOH inexperienced people can be confused by having too many choices. The goal of protecting resources from being exhausted by a run on the FCFS "bank" can be satisfied by marking a good-sized range Reserved or by choosing a sufficiently large field size that code points are too cheap to meter.

All the BMP registries other than BMP Peer Flags have their policies split 50/50 between Standards Action and Specification Required, modulo four Experimental and one Reserved at the top of each range. I'd like to suggest to the WG that we fix this by changing all the two-byte fields' 50/50 splits to 100% FCFS (keeping the Experimental and Reserved at the top unchanged). In the case of the one-byte fields "BMP Message Types" and "BMP Peer Types" I suggest changing the Standards Action portion (0-127) to FCFS and making the Specification Required portion (128-250) Reserved instead. I propose leaving Peer Flags the way they are, Standards Action. There are only five unallocated flags, it seems reasonable to have a higher bar to allocating one.

Registration policies have to be changed by an RFC, so if this proposal sounds good to the WG I volunteer to write a short Internet Draft to make it so. Before going to the effort i wanted to solicit feedback though.

Thanks,

--John

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Mar 2017 23:27:04 +0100

John G. Scudder wrote:
> Registration policies have to be changed by an RFC, so if this
> proposal sounds good to the WG I volunteer to write a short Internet
> Draft to make it so. Before going to the effort i wanted to solicit
> feedback though.

this looks sensible. The justification is sound and unless someone gets
a rush of blood to the head, it seems unlikely that there will be a
stampede to register all the available codepoints.  I'd say go for it.

Nick

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 30 Mar 2017 21:48:43 +0000

On 3/29/17, 12:47 PM, "GROW on behalf of John G. Scudder" <[email-masked] on behalf of [email-masked]> wrote:

>    I propose leaving Peer Flags the way they are, Standards Action. There are only five unallocated flags, it seems reasonable to have a higher bar to allocating one.
    
Can we assign per-peer header flags based on peer type?   Some of the flags are irrelevant based on peer type, such as local-rib type.  If FIB is added, that will likely result in a need for changed/additional flags.  The local-rib draft proposes flags based on type, with the removal of ones that are not applicable and addition of the F flag to indicate filtered.  

Thanks,
Tim