Subject: [Pce] I-D Action:draft-ietf-pce-vendor-constraints-02.txt

From: [email-masked]
Date: Thu, 16 Sep 2010 14:45:03 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element Working Group of the IETF.

	Title           : Conveying Vendor-Specific Constraints in the Path Computation Element Protocol
	Author(s)       : A. Farrel, G. Bernstein
	Filename        : draft-ietf-pce-vendor-constraints-02.txt
	Pages           : 9
	Date            : 2010-09-16

The Path Computation Element Protocol (PCEP) is used to convey path
computation requests and responses between Path Computation Clients
(PCCs) and Path Computation Elements (PCEs), and also between
cooperating PCEs. In PCEP the path computation requests carry details
of the constraints and objective functions that the PCC wishes the
PCE to apply in its computation.

The mechanisms defined for indicating objective functions include
the capability to convey vendor-specific objective functions. This
document defines a facility to carry vendor-specific constraints in
PCEP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-vendor-constraints-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 17 Sep 2010 09:22:52 +0200

> 	Title           : Conveying Vendor-Specific Constraints in the Path Computation Element Protocol

All,

A minor question regarding the I.-D. and proposed EBNF grammar. As you 
know, when serializing a PCEP  message, a given implementation would 
follow a "recommended" order (mandatory in RFC5886, according to section 
3).
In view of having a single unified implementation of several WG RFC and 
I-D, we are hesitating regarding which "order" to follow.

According to RF 5441: (OF)
-----------------------------------

<svec-list> ::= <SVEC>[<OF>][<metric-list>]
<request> ::= <RP><END-POINTS>
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<OF>]

Key aspects are:
* allows different OF for each single SVEC
* For some reason OF, metric_list are "swapped" in the svec "tuple" and 
individual request

draft-vendor_constraints
---------------------------------

<PCReq Message>::= <Common Header>
                          [ [<OF>] [<metric-list>]
                            [<vendor-constraint-list>] <SVEC-list> ]
<request-list>

<svec-list>::= <SVEC> <svec-list>
<request>::= <RP> END-POINTS> [<LSPA>] [<BANDWIDTH>] [<OF>] 
[<metric-list>] [<vendor-constraint-list>]

* The same OF has to be applied to all SVEC (OF appears at "message 
level" rather than "svec tuple" level).
* Changes the order OF, metric list w.r.t. RFC5441

RFC5886
------------------------------
only mentions OF in the svec tuple, without mentioning metric list, and 
only mentions metric_list in request without mentioning OF (:?) so we 
cannot conclude anything

Since vendor_constraints is still in I.D, at least for the specific case 
of <OF> and <metric_list>, would you consider changing the draft 
grammar? we are not sure,  RFC5441 already changes order for svec tuples 
and for individual requests in the same document.

A pragmatic solution, IMHO, would be that metric_list and OF could be 
swapped at the request level to align with RFC5441 and OF, and svec list 
could be changed.

Something in the lines of ('m adding the rule svec_tuple for clarity):

PCReq ::=<Common Header>
               [svec_tuple_list]
<request_list>

svec_tuple_list ::= <svec_tuple> [<svec_tuple_list>]

svec_tuple ::= [<OF>] [<GC>] [<XRO>] [metric_list][vendor_costraint_list]

<request>::= <RP> <END-POINTS> [<LSPA>] [<BANDWIDTH>]  
[<metric-list>][<OF>] [<vendor-constraint-list>]

- The order "of, metric_list, vendor_constraint_list" would be kept at 
the SVEC (to be aligned with RFC5441)
- Different OF, Vendor constraint list, etc. could be applied for each 
individual SVEC (concerning different groups of requests)
- The order "metric_list, of, vendor_constraint_list" would be kept at 
the request level (basically, to be aligned with RFC5441)

Thoughts and comments welcome

Thanks for reading

R.

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Sep 2010 11:04:18 +0100

Hi Ramon,

Good question.

s/EBNF/RBNF/  :-)

I think that vendor-constraints should definitively conform to the prior 
work, so will need to change.

Give me a short time to parse the BNF, and I'll issue an update.

Cheers,
Adrian

----- Original Message ----- 
From: "Ramon Casellas" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 17, 2010 8:22 AM
Subject: Re: [Pce] I-D Action:draft-ietf-pce-vendor-constraints-02.txt

All,

Key aspects are:

draft-vendor_constraints

RFC5886

PCReq ::=<Common Header>
               [svec_tuple_list]
<request_list>

Thanks for reading

R.

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Sep 2010 17:08:08 +0100

Hi again Ramon,

I've been trying to unpick this RBNF.

> According to RFC 5441: (OF)

OK. You mean 5541 (5441 is BRPC - easy mistake :-)

> * allows different OF for each single SVEC

Right

> * For some reason OF, metric_list are "swapped" in the svec "tuple" and 

Yes. "For some reason"  :-)

> draft-vendor_constraints
> -------------------------
>

Right. the vendor-constraints I-D should not change the SVEC list contruct.

> * Changes the order OF, metric list w.r.t. RFC5441

Yes. We should not change the RFC 5541 definition.

> RFC5886
> ------------------------
> only mentions OF in the svec tuple, without mentioning metric list,
> and only mentions metric_list in request without mentioning OF so we 
> cannot conclude anything

OK

> grammar? we are not sure,  RFC5441 already changes order for
> svec tuples and for individual requests in the same document.

Absolutely.

> swapped at the request level to align with RFC5441 and OF, and svec list 

Ah, I think you are also calling on RFC 5557 (which is good)

> Something in the lines of (I'm adding the rule svec_tuple for clarity):
>
> PCReq ::=<Common Header>
>               [svec_tuple_list]
>               <request_list>
>

Missing the <SVEC> :-)

>                      [<metric-list>][<OF>] [<vendor-constraint-list>]

OK. I think I can find a few more optional objects :-)

> - The order "of, metric_list, vendor_constraint_list" would be kept
> at the SVEC (to be aligned with RFC5441)
>

Intention looks good.

I am updating as...

     <PCReq Message> ::= <Common Header>
                         [svec_list]
                         <request-list>

     where

         <svec-list> ::= <SVEC>
                         [<OF>]
                         [<GC>]
                         [<XRO>]
                         [<metric-list>]
                         [<vendor-constraint-list>]
                         [<svec-list>]
       
         <metric-list> ::= <METRIC>
                           [<metric-list>]

         <vendor-constraint-list> ::= <VENDOR-CONSTRAINT>
                                      [<vendor-constraint-list>]

         <request-list>::= <request>
                           [<request-list>]

         <request>::= <RP>
                      <END-POINTS>
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<OF>]
                      [<vendor-constraint-list>]
                      [<RRO>]
                      [<IRO>]
                      [<LOAD-BALANCING>]

Regards,
Adrian