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 PROTECTED]
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
