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

[Robert Varga <[e-mail]>]

On 06/26/2013 11:54 AM, Ramon Casellas wrote:
> El 26/06/2013 9:40, Margaria, Cyril (Coriant - DE/Munich) escribió:
>> [trimmed]
>>
>>   I understand the need for a different grammar in RFC6006, my 
>> preference would be to define one p2p grammar and one p2mp grammar 
>> (as this is in the RP this is not perfect, but OK from implementation 
>> point of view) (as in gmpls-pcep-extensions).
>> For the other points  think this could  be covered by erratas in the 
>> original documents.
>
> Dear all,
>
> I share Cyril's comments. In my humble opinion, we are more and more 
> having a set of documents with grammars selecting only some objects 
> from existing documents and not covering them all and, once integrated 
> in a single implementation, it becomes harder to make sense of all 
> them (e.g. "bandwidths" made worse later with also 
> GENERALIZED-BANDWIDTHs). Ordering constraints are also a problem that 
> would need to be addressed.
>
> [trimmed]
>
>
> Other "philosophical" comments
> =============================
>
> Although I understand it is inherited from RFC6006,  it is unfortunate 
> that that we keep the name of endpoint-rro-pair-list, since it is more 
> and and more losing its meaning of a (endpoint, rro) pair list. 
> Dreaming on, I also believe it could useful to split into a P2P 
> grammar and a P2MP grammar, roughly as follows (as Cyril mentioned 
> this was also suggested for GMPLS extensions and clarifies RFC6006. In 
> any case, an implementation needs to parse the RP object to know if it 
> is a p2p or p2mp)
>
> <request> ::= <expansion> | <p2p_computation> | <p2mp_computation>
>
> <expansion> ::= <RP> <PATH-KEY>
>
> <p2p_computation> ::= <RP><ENDPOINTS> [<attributes>]
>
> <attributes> ::= CLASSTYPE LSPA BANDWIDTH metric-list 
> objective-functions vendor-info-list rro-bw-pair IRO BNC XRO 
> LOADBALANDING ... (all optional and parsed in any order for interworking)
>
> <p2mp_computation> ::= <RP><tree-list>[<attributes>]
>
> <tree-list> ::= <tree> [<tree-list>]
>
> <tree> ::= <ENDPOINTS> <rro_bw_pair> etc.
>

Cyril, Ramon, all,

Wearing my implementer hat, I have to say that the combination of:

- strict ordering,
- no negotiation of use at session setup,
- lack of explicit differentiation between 'structural' and 'attribute' 
objects,
- the usual omissions and mistakes in specification

has made it very difficult to combine the various extensions, with the 
job becoming increasingly difficult as more of them pile up. Given 
independent implementations of a PCE and a PCC, both supporting the sum 
of all current RFCs and active extensions, I do not dare to quantify the 
chances of them being fully plug'n'play interoperable.

I will certainly support any effort which would result in my 
implementation being able to have independent syntactic and semantic 
validators.

Bye,
Robert