Re: [Pce] WG Last Call of draft-ietf-pce-vendor-constraints-10

[Robert Varga <[e-mail]>]

On 06/26/2013 05:51 PM, Oscar González de Dios wrote:
> Dear PCErs,

Oscar,

>     First of all, I must say that standardizing a way to de-standardize a
> protocol is weird. The document draft-ietf-pce-vendor-constraints-10
> defines a new object and a new TLV to carry proprietary information. Thus,
> two implementations will never interwork properly if they use this I-D. Of
> course, the object can be ignored, but also, the information of the object
> is lost. And if the intention is to be used only internally by vendors,
> why standardize it? You can add to your implementation whatever new object
> or TLV you have in mind, you are not going to interop with anybody
> anywayŠ.
>
>     As nothing can be done about that (the ID was adopted by the WG long
> time ago), let's focus on what can be done now to foster interoperabilityŠ

I think it is better to keep the non-standard extensions contained than 
to have vendors randomly pick reserved numbers without letting anyone 
know about it.

>     Ramon, Cyril and Robert raised very good issues about grammars and
> having several documents that do not cover all the objects in them. Given
> that the ordering is STRICT, it is highly important to have a clear
> grammar, with ZERO interpretation margin.
>
>     My suggestion is that now, when most of the extensions to PCEP are
> quite mature, we could have an ID covering the grammar of RFC 5440 +
> mature stateless PCE extensions. This is something I had in mind long time
> ago, as it would be the best way to facilitate the interoperability.

We touched on this briefly during IETF85, I think. My recollection is 
that you wanted to create an informational I-D, which would provide 
guidance on how to combine the currently-defined drafts up to and 
including GPMLS. Is that accurate?

If so, I agree this is a good idea, but I would like us to do more to 
prevent this situation from occurring in future. I think Ramon's 
proposal goes a long way towards that goal. If we were to also relax the 
strict ordering requirement for attribute objects, it would make 
defining new attributes/constraints more straightforward.

On a related note: would the WG consider relaxing the allocation rules 
on a portion of the PCEP codepoint space? I think having an option to 
use first-come first-serve allocation for objects and TLVs could make 
implementers more open about their extensions.

Thanks,
Robert