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

Hi Oscar,

I would like to focus on your first comment. 

I concur with Robert on this point besides some additional points blow. 

There MUST be some non-standard constraints or metrics because of vendor specific stuff in the real networks, for example, WSON impairment, especially in case of multi domains with different vendor equipments . BUT, it does not mean that this non-standard constraints cannot be conveyed in a STANDARD way (as this draft defines), ie., it is still useful and valuable to define a STANDARD way to convey this kind of vendor specific information. This vendor specific information can be understood by the corresponding PCC and PCE (see the definition of "Enterprise-Specific Information"), so the PCE can compute the viable path for the path request. 

In addition, I have the feeling that it is a little similar to the *Path Kay* for the usage of the vendor specific information. We put the "secret or proprietary" information in the <Path Key>, but how to convey the secret can be standardized. Otherwise, it is impossible for interoperability. 

Best Regards

Fatai

-----Original Message-----
From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Robert Varga
Sent: Thursday, June 27, 2013 2:57 AM
To: pce@ietf.org
Subject: Re: [Pce] WG Last Call of draft-ietf-pce-vendor-constraints-10

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

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce