Re: [Idr] draft-decraene-idr-reserved-extended-communities-00

[<[e-mail]>]

Eric,

> John> although draft-decraene-idr-reserved-extended-communities-00
makes its
> John> request from the Standards Action portion of the two registries,
it
> John> need not -- the authors could have requested an FCFS code point
> John> instead in which case this discussion would have been moot.
They
> John> could still do this.
> 
> The discussion about the allocation of the codepoint would be moot,
but I
> don't think there's a FCFS procedure for the creation of IANA
registries.
> So I don't really think this draft could go forward without WG
discussion
> even if FCFS codepoints were requested.
> 
> I think it's a valid question to ask why this new registry is actually
> needed.  The draft offers two justifications:
> 
>    "one needing to reserve a single non-transitive extended community
>    would need to reserve an extended subtype which represents 2^48
>    communities.  This would both waste the resources"
> 
> I don't really see what the resource is that's being wasted.  Are we
worried
> about running out of extended type codepoints?

Reserving 2^48 = 2.8 10^14 = two hundreds thousand billions communities
while a single is required, I call this wasting resources.

The number of code points is limited. If we use it, what ever the rate
of use, one day there won't be any. We ran out of class B, AS number, IP
addresses, optional parameter length... How can you be certain that we
will never run out extended types?


>    "and disable the ability to define global policies on reserved
>    communities, such as to filter them out."
> 
> The proposal is to have a big chunk of FCFS space in the new registry.
This
> means that anyone can use it for anything.  That makes it hard to see
how
> there could be a useful global policy to filter them all out.

For example, if _you_ believe these are evil, you will be able to remove
or not interpret them.
On the contrary, one could this type to allow them on PE-CE eBGP session
(within a VRF) while filtering out RT or others extended community
types.

 
> I'm having trouble seeing what value is provided by this new registry.

The value is the ability to get and use non-transitive reserved/well
known/std action extended community.

As for myself, I'm having trouble understanding your concern with this. 
A registry for reserved/well known/std action community do exist. Do you
have a concern with it? If not, don't you think that non transitive ones
would be as useful as the transitive ones?
 
> Bruno> if people can't get a community, they will get a full type
> Bruno> instead. This seems much more suboptimal to me.
> 
> I'm not sure what "much more suboptimal" means in this context.

It's suboptimal to waste 2.8 10^14 when allocating a single value.
That's a 3.10E-13 % efficiency.
 
> I also think it's confusing to call these extended communities
"reserved",
> as RFC 5226 ("Guidelines for Writing IANA Considerations") defines the
term
> "reserved" as meaning "not to be assigned".

We can use a different name. Would you have any proposition?