Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

[Job Snijders <[e-mail]>]

On Tue, Nov 01, 2016 at 03:41:12PM +0100, Robert Raszuk wrote:
> > Am I to understand that you consider deployment problems not to be
> > technical problems?
> 
> You stated clearly that Large is not subject to suffer from deployment
> problems. So what other deployment problems you envision if those types
> would be moved to early allocation by IANA?

You might misunderstand what I intended to convey, my apologies for not
being able to articulate myself better.

Large BGP Communities was assigned BGP Path attribute, by IANA according
to the Early Allocation rules (value 30 - 2016.09.26). Turns out that an
implementor had already used that codepoint. This proved to cause issues
during an experimental deployment of Large BGP Communities. Large BGP
Communities had to back to the WG, the chairs and then IANA assigned a
new codepoint (value 32 - 2016.10.26). So, today, Large BGP Communities
does not suffer from the squatted '30' codepoint, because a renumbering
effort was undertaken. The above is a description of a deployment
problem and its resolution. 

In short: any new (early) allocations should not come from tainted
codepoints. To ensure this, IANA needs instruction not to do so (that is
the draft at hand).

Maybe a pragmatic example will help clarify the situation: If IANA
assigns Path Attribute 30 as early allocation of
draft-chen-idr-geo-coordinates-03, I suspect the
draft-chen-idr-geo-coordinates effort will encounter considerable
deployment problems. This would be a waste of time for the authors and
implementors of draft-chen-idr-geo-coordinates.

> > BGP Path attribute codepoints are a global, shared resources. As
> > Internet community we have vested IANA with the authority to assign
> > resources from this pool. The social contract is that we abide by the
> > rules related to IETF and IANA. The same rules we write ourselves.
> 
> Few days back You and others complained that Wide was not implemented
> by anyone for so many years. Now when we see it actually was
> implemented at least by few BGP code basis it is again bad.

You might not view it this way, but I am actually looking out for Wide's
chances of deployment. At this point it is not known which version of
the wide draft was implemented, or even if the implementation is
compatible with said specification. It really is in -wide-'s best
interest to _not_ use attribute 129.

> So to me the problem we need to solve is how to allow early
> implementations for any proposal on the table especially now when we
> have no two but at least 8 production BGP implementations (and
> growing). Forbidding it does not seems to me like a solution to the
> main problem.

But isnt the solution simple? I think early implementors should just
request an Early IANA Allocation and follow that process!

Kind regards,

Job