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

[Robert Raszuk <[e-mail]>]

> even if the implementation is compatible with said specification

Well I think this is completely different problem regardless on how the
types/codepoints will be allocated.

> 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

That was not what I have tried to express ... I suggested to assign all
detected points to the drafts they belong as early allocation rather then
to deprecate them. Result is the same - geo will not be allocated code
point which is already used.

So is 32 final code point for Large or early allocated one. If what LC got
is final one why geo would need to ask for early allocation vs final one :)
?

Best,
R.


On Tue, Nov 1, 2016 at 4:01 PM, Job Snijders <[e-mail]> wrote:

> 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
>