Subject: [Pce] Comments on draft-vasseur-pce-pcep-02.txt

From: "Darek Skalecki" <[email-masked]>
Date: Tue, 1 Nov 2005 10:24:25 -0500

Good day,

I have gone over the draft and have the following comments for
consideration by the authors and others on the mailing list:

*	In section 6.7 - In the BNF for PCErr, why is there an <Open>
object>?. Looks like a typo :)
*	In section 6.4 - In the BNF for PCReq, would it be possible to
reverse the order of [<SVEC-list>] and <request-list> such that
<request-list> is first and then followed by [<SVEC-list>], and such
order being recommended. The reasoning is related to potential
efficiency in decoding. I realize it may be implementation specific but
if most implementations find it easier to decode the request-list before
the SVEC-list then this is the order that should be adopted. Comments
from other implementers???.
*	In section 7.2 - There is a keepalive frequency in the OPEN
object but do we need some sort of dead-interval or
number-of-keepalives-that-can-be-lost-before-we-declare-session-DOWN.
For example, keepalive frequency is 30 seconds and dead-interval is 3 or
90 seconds meaning that if PCC/PCE doesn't receive a keepalive from its
peer in 90 seconds then the session to its peer will be deemed DOWN.
*	In section 7.6 - Bandwidth in bytes per second may not be
sufficient for all applications of PCE. For example, in SONET networks,
to compute a route through a BLSR ring where time-slot interchange is
not possible, one needs to compute a route consisting of the same
time-slot from an ingress to egress of that ring. Same may hold for
photonic networks where a route consisting of the same lambda may need
to be computed.
*	In section 7.8 and 7.9 - I am getting confused as to whether the
route to reoptimize is specified in ERO or RRO. 7.8 seems to suggest the
route of current LSP to reoptimize is carried in ERO in PCReq, while 7.9
suggests RRO in PCReq is used for the same purpose.
*	In section 7.10 - PCReq is used instead of PCRep in the first
paragraph where "...(in this case, the PCReq message also comprises a
NO-PATH object ...".
*	In section 7.10 - Why is Setup Prio and Holding Prio 8-bits in
length. Shouldn't 3 bits be sufficient. Also, at first I was scratching
my head why Holding Prio is specified for path computation where it
really doesn't play any role unlike Setup Prio, but I now presume it is
used by PCEs that are stateful, i.e. the ones that keep track of the
routes and need their Holding Prio in order to compute routes that
bump/pre-empt. Is this correct?.
*	In section 7.12 - There are some inefficiencies in the SVEC
object. When SVEC object is used in PCReq (section 6.4) then it doesn't
need not contain a set of RP objects and could simply contain a set of
Request-ID-numbers from the RP objects. If the SVEC object is used in
PCRep (section 6.5) then I see the need for the entire RP object albeit
also Request-ID-number and Pri fields of RP are really only used. I
wonder if we can come up with a better definition, unless carrying the
redundant info in RP is OK. 
Also in section 7.12, why is Pri value of 0 used to denote "no priority"
or "lowest priority". It seems to be contrary to definitions of Setup
and Holding Priorities where 0 implies the highest priority and 7 the
lowest priority.
*	In section 6.6 - Why is the entire RP object used instead of
just the Request-ID-number of RP. It seems the combination of
Request-ID-number and PCC's source IP address are the unique keys used
to identify a particular path computation request. The other 32 bits of
info in RP doesn't add any value and I doubt it would be used by the
recipient of PCNtf for anything. Am I missing something???.
*	In section 6.7 - Same comment as just above.
*	In section 7.12 - About the diversity specifications. We have
come up with requests from our customers to provide maximum diversity in
addition to absolute diversity, i.e. if you cannot find absolutely
diverse set of routes then find a set of routes with as fewer
nodes/links/SRLGs in common as possible. Has such concept of maximum
diversity been discussed among the authors and are there any parties on
the PCE mailing list interested in it also. 

Regards,

Darek

Darek Skalecki
Optical Networks
Nortel
[email-masked]

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

---

From: JP Vasseur <[email-masked]>
Date: Tue, 1 Nov 2005 11:00:06 -0500

Hi Darek,

Just wanted to thank you for these useful comments ... we'll  
certainly address them right after Vancouver

Thanks.

JP.

On Nov 1, 2005, at 10:24 AM, Darek Skalecki wrote:

> In section 6.7 - In the BNF for PCErr, why is there an <Open>  
> In section 6.4 - In the BNF for PCReq, would it be possible to  
> <request-list> is first and then followed by [<SVEC-list>], and  
> such order being recommended. The reasoning is related to potential  
> efficiency in decoding. I realize it may be implementation specific  
> but if most implementations find it easier to decode the request- 
> list before the SVEC-list then this is the order that should be  
> adopted. Comments from other implementers???.
> In section 7.2 - There is a keepalive frequency in the OPEN object  
> but do we need some sort of dead-interval or number-of-keepalives- 
> that-can-be-lost-before-we-declare-session-DOWN. For example,  
> keepalive frequency is 30 seconds and dead-interval is 3 or 90  
> seconds meaning that if PCC/PCE doesn't receive a keepalive from  
> its peer in 90 seconds then the session to its peer will be deemed  
> DOWN.
> In section 7.6 - Bandwidth in bytes per second may not be  
> sufficient for all applications of PCE. For example, in SONET  
> networks, to compute a route through a BLSR ring where time-slot  
> interchange is not possible, one needs to compute a route  
> consisting of the same time-slot from an ingress to egress of that  
> ring. Same may hold for photonic networks where a route consisting  
> of the same lambda may need to be computed.
> In section 7.8 and 7.9 - I am getting confused as to whether the  
> route to reoptimize is specified in ERO or RRO. 7.8 seems to  
> suggest the route of current LSP to reoptimize is carried in ERO in  
> PCReq, while 7.9 suggests RRO in PCReq is used for the same purpose.
> In section 7.10 - PCReq is used instead of PCRep in the first  
> paragraph where "…(in this case, the PCReq message also comprises a  
> NO-PATH object …".
> In section 7.10 - Why is Setup Prio and Holding Prio 8-bits in  
> length. Shouldn't 3 bits be sufficient. Also, at first I was  
> scratching my head why Holding Prio is specified for path  
> computation where it really doesn't play any role unlike Setup  
> Prio, but I now presume it is used by PCEs that are stateful, i.e.  
> the ones that keep track of the routes and need their Holding Prio  
> in order to compute routes that bump/pre-empt. Is this correct?.
> In section 7.12 - There are some inefficiencies in the SVEC object.  
> When SVEC object is used in PCReq (section 6.4) then it doesn't  
> need not contain a set of RP objects and could simply contain a set  
> of Request-ID-numbers from the RP objects. If the SVEC object is  
> used in PCRep (section 6.5) then I see the need for the entire RP  
> object albeit also Request-ID-number and Pri fields of RP are  
> really only used. I wonder if we can come up with a better  
> definition, unless carrying the redundant info in RP is OK.
> Also in section 7.12, why is Pri value of 0 used to denote "no  
> priority" or "lowest priority". It seems to be contrary to  
> definitions of Setup and Holding Priorities where 0 implies the  
> highest priority and 7 the lowest priority.
> In section 6.6 - Why is the entire RP object used instead of just  
> the Request-ID-number of RP. It seems the combination of Request-ID- 
> number and PCC's source IP address are the unique keys used to  
> identify a particular path computation request. The other 32 bits  
> of info in RP doesn't add any value and I doubt it would be used by  
> the recipient of PCNtf for anything. Am I missing something???.
> In section 6.7 - Same comment as just above.
> In section 7.12 - About the diversity specifications. We have come  
> up with requests from our customers to provide maximum diversity in  
> diverse set of routes then find a set of routes with as fewer nodes/ 
> links/SRLGs in common as possible. Has such concept of maximum  
> diversity been discussed among the authors and are there any  
> parties on the PCE mailing list interested in it also.
>
> Regards,
>
> Darek
>
> Darek Skalecki
> Optical Networks
> Nortel
> [email-masked]
>
>