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

From: Julien Meuric <[email-masked]>
Date: Wed, 12 Jun 2013 10:08:49 +0200

Hi PCE'rs.

This message ignites a 2-week-long WG last call for 
draft-ietf-pce-vendor-constraints-10. Please send your comments on the 
I-D to the PCE mailing list by Wednesday June 26.

Best regards,

JP & Julien

---

From: Julien Meuric <[email-masked]>
Date: Mon, 24 Jun 2013 18:31:59 +0200

Hi all.

The I-D is not particularly long and is certainly well-known by many of 
you: a few reviews would be much appreciated.

Thanks,

JP & Julien

Le 12/06/2013 10:08, Julien Meuric a écrit :
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Jun 2013 18:21:31 +0100

Thanks Julien,
I appreciate that.
Since I had been told that a number of people have applications of this
mechanism, it would be good if they could speak up.

As an author, I guess I can't offer a review :-)

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien
> Meuric
> Sent: 24 June 2013 17:32
> To: [email-masked]
> Subject: Re: [Pce] WG Last Call of draft-ietf-pce-vendor-constraints-10
> 
> Hi all.
>

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Wed, 26 Jun 2013 07:40:58 +0000

Support.

I have a few remarks : 
 1) The <svec-list> definition does include the definitions from RFC5541 and RFC5557, the RFC5557 did not include the [<metric-list>] element, should this fixed by RFC5557 errata to match the pce-vendor-constraints definition?

 2) This document include the XRO in the svec-list, but not in the <request>, where should it go in the <request>?

 3) the Path key expansion requests, nor monitoring are considered, is it OK? Basically should a new document take into account all the existing RFCs grammar element or should it cherry pick (and based on which criteria) 

 4) RFC5440/RFC6006/pce-vendor-constraints compatibility:
     RFC5440 indicates that the object order MUST be followed,  RFC6006 did change the object order defined in RFC5440:
        - RRO list and RRO bandwidth should follow the <ENDPOINTS>, not the <metric-list>, 
        - 3 BANDWITH objects are allowed
        - [<OF>] is before the [<LSPA>]  in RFC6006 but after the [<metric-list>] in RFC5541	
    pce-vendor-constraints does  use the [<OF>] definition of RFC5541 (after [<metric-list>]), add the [<RRO>] (without [<BANDWIDTH>])  before the [<IRO>]( in contrary to RFC6006, which put the RROs after the endpoints)   

The object order are not consistent, which is not very good for implementation (need to support the different  variation) 

 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.

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Julien Meuric
> Sent: Monday, June 24, 2013 6:32 PM
> To: [email-masked]

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 26 Jun 2013 11:54:42 +0200

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

Below a minor review. The draft is quite clear and self-explanatory (all 
my comments are minor) .

OLD
   The object can be present in two places within the PCReq message to
   enable it to apply to a single path computation request or to a set
   of synchronized requests

Sorry to be picky, but I count three :-) within a SVEC, within an 
individual request both as a direct constraint and within the endpoint 
rro pair-list. Maybe just

NEW
    The object can be present to enable it to apply to a single path
    computation request or to a set of synchronized requests.

* I would, if not too much effort, separate the case where a PCE does 
not parse/understand the VENDOR-INFORMATION object from the case it does 
not support a given Enterprise number. In other words, the draft could 
specify the procedures when a PCE finds a VERDOR-INFORMATION object with 
an Enterprise number it does not understand (as done for TLV, Section 
2.1 deals with the case of "unknown object".) Maybe something in the 
lines of "If the Enterprise Number is unknown to the PCE, the PCE 
(...)".  I think it could be useful to have a dedicated error code for 
that. Alternatively Just add the text "If the Enterprise Number is 
unknown to the PCE, it MUST treat that object as Unknown" but I like 
this less. The curent text "if the P flag is set, the object will be 
treated as mandatory and the request will either be processed using the 
contents of the object" somehow covers it implicitly, thuogh but I would 
like to see it explicitly written.

OLD

- The PCE determines how to interpret the information in the Vendor
   Information object by examining the Enterprise Number it contains.

NEW

- The PCE determines how to interpret the information in the Vendor
   Information object by examining the Enterprise Number it contains.
   If the Enterprise Number is unknown to the PCE, it MUST treat that
   object as an Unknown object.

Note that the TLV text currently states

- The PCE determines how to interpret the Vendor Information TLV by
   examining the Enterprise Number it contains.  If the Enterprise
   Number is unknown to the PCE, it MUST treat the Vendor Information
   TLV as an unknown TLV

* <request> ::= lacks a [<XRO>] after [<IRO>] since XRO is mentioned

* <request> ::= I would suggest moving the vendor-info-list after 
endpoints (for both p2p and p2mp) My personal preference would be after 
metric list and objective function. endpoint-rro-pair-list at least 
includes one mandatory ENDPOINTS object, making the mandatory RP and 
ENDPOINTS objects appear first.

* The draft states "Thus, the PCReq message based on [RFC6006] is 
encoded as follows". Much like RFC6006, the draft is ignoring the BNC 
object in the grammar. Also it is not clear where in the PCReq it should 
appear. RFC6006 also says that "The object can only be carried in a 
PCReq message.  A Path Request may carry at most one Branch Node 
Object". But I am not sure how to specify a branch node list and a 
non-branch node list.

* The draft just says "The Vendor Information object can be included in 
a PCRep message in exactly the same way as any other object as defined 
in [RFC5440]" I would suggest to provide a suggested grammar/ordering 
which includes not only the vendor-information-list but also othe 
RFC6006 extensions notably regarding end-point-path-pair-list and 
ERO/SERO. As a bare minimum the draft should refer to RFC6006 regarding 
to PCRep message instead of RFC5440.

* As RFC6006, the draft is ignoring the UNREACH-DESTINATION object and 
is not present in the PCRep grammar

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.

Finally, as a a personal comment which I echoed when the draft was 
polled, and althgouh I support this draft, I still hope that the objects 
and TLVs defined in this document are not overused and that objective 
functions, related metrics, and constraints in general are defined 
following open processes.

Thanks
R.

---

From: Robert Varga <[email-masked]>
Date: Wed, 26 Jun 2013 14:26:28 +0200

Hi,

aside from a typo ("SHUOLD" instead of "SHOULD" in first sentence of 
section 6.1) I don't have any objections.

Thanks,
Robert

On 06/24/2013 06:31 PM, Julien Meuric wrote:
> Hi all.
>
> The I-D is not particularly long and is certainly well-known by many 
> of you: a few reviews would be much appreciated.
>
> Thanks,
>
> JP & Julien
>
>
>> draft-ietf-pce-vendor-constraints-10. Please send your comments on 
>> the I-D to the PCE mailing list by Wednesday June 26.
>>
>> Best regards,
>>
>> JP & Julien
>>

---

From: Robert Varga <[email-masked]>
Date: Wed, 26 Jun 2013 15:26:57 +0200

On 06/26/2013 11:54 AM, Ramon Casellas wrote:
>> [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).
> 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]
>
>
> 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)
>

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

---

From: Oscar González de Dios <[email-masked]>
Date: Wed, 26 Jun 2013 15:51:41 +0000

Dear PCErs,

   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Š

   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.

   Best Regards,

        Oscar

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Robert Varga <[email-masked]>
Date: Wed, 26 Jun 2013 20:57:13 +0200

> Dear PCErs,

Oscar,

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

> 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

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 27 Jun 2013 02:07:56 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Varga
Sent: Thursday, June 27, 2013 2:57 AM
To: [email-masked]
Subject: Re: [Pce] WG Last Call of draft-ietf-pce-vendor-constraints-10

Oscar,

Thanks,
Robert

---

From: Julien Meuric <[email-masked]>
Date: Thu, 27 Jun 2013 11:13:25 +0200

Hi all.

This last call has ended. Thanks for the feedback. The chairs' review 
will follow. Authors, before we send the I-D to the IESG, you will be 
expected to address the comments, at least by responding.

The side output of the discussion looks interesting. Several WG 
contributors seem to volunteer to edit an I-D summarizing PCEP 
(stateless) extensions: that could be valuable.

Regards,

Julien