Subject: [Pce] WG feed-backs on PCEP

From: JP Vasseur <[email-masked]>
Date: Thu, 26 May 2005 11:42:05 -0400

Dear WG,

A new ID has recently been posted 
(http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) 
proposing a new PCE communication protocol. There are several aspects 
for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to 
get your feed-backs (see section 6). Comments are also very welcome on 
the other parts of the ID of course.

Thanks.

JP.

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

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 26 May 2005 15:23:36 -0400

Hi,

I think that the draft is certainly a very good starting point.

I have several comments.

1.                    Section 8.7

L (Link diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following
REQUEST-ID objects MUST not have any link in common.                N (Node
diverse) bit: when set, this indicates that the computed        paths
corresponding to the requests specified by the following        REQUEST-ID
objects MUST not have any node in common.                S (SRLG diverse)
bit: when set, this indicates that the computed        paths corresponding
to the requests specified by the following        REQUEST-ID objects MUST
not share any SRLG (Shared Risk Link Group).       I think a good idea would
be to add one more flag:

      B (Best diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following
REQUEST-ID objects MUST be best disjoint (have minimal number of SRLGs,
nodes and links in common) .

2.                    Section 10.1

R bit: when the R bit of the REQUEST-ID object is set in a PCReq
message, this indicates that the path computation request relates to
the reoptimization of an existing TE LSP. In this case, the PCC MUST
provide the complete or partial path by including an ERO object in
the PCReq message so as to avoid double bandwidth counting. The ERO
must be formed of strict hops only.

It is possible that a PCC requires a path computation for MB4B modification
of e2e or segment protected service. In order to avoid double bandwidth
counting this would require specifying not one but several EROs
(representing current working and all recovery LSPs), because newly computed
paths can share resources with each of the existing paths. I think a good
idea is to specify for such "sharables" a single special ERO that includes
an unordered list of links that new path(s) is/are allowed to share
resources with (similar to XRO)

On more general note:

3.                    It looks like that the protocol is designed only for
Shortest Path First computations. What if a PCC does not want a shortest
path, rather, say, minimal delay path with a constraint on the path cost?
How a PCC can specify different (possibly many) optimization criteria(s)?

4.                    How the protocol is expendable for incorporating new
constraints? For instance, in some near future we will introduce Interface
Adaptation Capabilities Descriptor TE link sub-TLV (necessary for
multi-layer path computations). How path computation could be constrained to
honor this information? I think it would a good idea to bind a constraint
type with TE link sub-TLV type in an abstracted way, so that at least link
level constraints could be easily added to the protocol

5.                    How a PCC can request computation of paths for several
LSPs so that they could share backup resources?

6.                    How a PCC can request computation of paths for one or
more services to be diverse (link-, node-, SRLG-, best-) from paths taken by
existing LSPs (note that the latter may be explicitly provisioned rather
than computed)?

7.                    Why the authors think that reusing of RSVP objects is
a good idea? For instance, RSVP SESSION_ATTRIBUTES object has a field
"Session Name". Do we really need it in the path computation request? Why
not to introduce instead, say, a PATH_ATTRIBUTES object that will include
only parameters (e.g. priorities) and flags (e.g. colors) that are needed
for path computation?

That's it for now,

Igor

----- Original Message ----- 

From: "JP Vasseur" <[email-masked]>

To: <[email-masked]>

Sent: Thursday, May 26, 2005 11:42 AM

Subject: [Pce] WG feed-backs on PCEP

---

From: JP Vasseur <[email-masked]>
Date: Thu, 26 May 2005 16:40:18 -0400

Hi Igor,

> I think that the draft is certainly a very good starting point.

thanks for these useful comments, see below

> nodes and links in common) .

We can support this by mentioning some interest for less-constrained 
path (and let the PCE uses any relevant algo) but adding such bit would 
add more flexibility indeed. We could in fact have even more 
granularity:
	- minimize the number of network elements with fate sharing
	- minimize the number of elements in common across all the network 
elements with fate sharing

> resources with (similar to XRO)

Good point, thanks. Could easily be done with extension to the CVEC 
object.

> How a PCC can specify different (possibly many) optimization 

This is planned for the next revision: ability to specify the objective 
function - thanks.

> level constraints could be easily added to the protocol

Good comment, thanks.

> LSPs so that they could share backup resources?

We could easily add a flag to the CVEC object to support 1:N 
protection. Let see if the WG thinks that this is a requirement ? May 
be listed as a requirement in the context of future 
application-specific ID.

> existing LSPs (note that the latter may be explicitly provisioned 

Same as above.

> only parameters (e.g. priorities) and flags (e.g. colors) that are 

Ah I was expecting this comment ;-) Well, PCEP is in that respect 
really flexible. Just allow to reuse *some* RSVP objects when 
appropriate. In that particular context we could w/o any problem 
specify a new object minus this field but it really does not hurt to 
carry it, thus we just reuse this object. Conversely, in some other 
contexts, for instance the source and destination addresses, it is 
really more optimal to define a new object (END-POINTS) with two fields 
rather than using the SENDER-TEMPLATE and SESSION objects of course.

Thanks for your comments.

Any comment on the section 6 ?

Cheers.

JP.

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 27 May 2005 09:09:07 -0400

JP,

> Any comment on the section 6 ?

 6. PCEP Finite State Machine (FSM)

       PCE Working Group feed-backs will be requested on the following
       items:
       - Is there a need for "open" and "close" messages? IB>> Have no
strong opinion;
       - Is there a requirement for PCEP hello message that could be used
         for faster PCC/PCE liveness detection? (If yes, the hello
         frequency could be negotiated upon PCEP connection setup (via
         open messages)IB>> Have no strong opinion;
       - Is there a requirement for detailed capability discovery upon PCEP
         connection set up? IB>> Detailed capability discovery is necessary,
however, IMHO it should be a part of separate (PCE discovery) protocolrather
than PCEP.I believe that a PCE should advertise its presence and basic
capability bits, and it should be a responsibility of PCC to establish a
capability discovery session with the PCE and obtain (as well as subscribe
to notifications on changes in future)all necessary detail information about
PCE capabilities, resources, etcHave a great weekend,Igor

---

From: JP Vasseur <[email-masked]>
Date: Sat, 28 May 2005 22:35:20 -0400

Hi Igor,

Thanks for your feed-backs. Opinions form others ?

JP.

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 31 May 2005 15:53:33 +0800

Hi, JP
  Sorry for the late reply.

 What is used to identify the PCEs, IP address? it should be
better to give each PCE a sole ID, should a PCE have more than
one interfaces connected to the network.

In section 8.1, why OS, PR are defined to be two bits, according
the usage, one bit is enough, are there some other thoughts on these definition?

 Section 9 only mentions the correlated request from the same LSR, but 
the request from different LSR may also be considered correlated, for example,
the same source may be allocated by different PCEs at the same time
to different PCCs.

About section 6:
hello message:  this can be optional and can be decided by PCC when
PCC requesting a computation, for example, an object can be defined that 
inclueds the interval and timeout value and inserted into the PCReq message,
thus the hello message can be relative to PCReq message, if so, the hello message
will have more meaning, for example, it can tell PCC how long the request will be
served, this is especially useful when the PCReq is sent to multiple PCE. 
I think it is worst that PCE send the hello messages to all PCCs.

detailed capability discovery:
Before this is decided, all possible capabilities of PCE should be estimated,
maybe this will be clear after this estimation.However, I have had some
comments on this issue: PCEs learn of each other's detailed capabilitis if 
the discovery protocol can be used in PCE-PCE discovery, PCCs learn
of generic capabilitis, this will facilitate PCCs to discovery PCEs. When the
PCC's first request fails due to the bad selection of PCE based on the generic 
capability, the PCE determines the right PCE according to the request and the
acknowledge of  other PCEs' capabilities, and also can communicate the detailed
capabilities of the right PCE though PCEP to the PCC.

Regard,
Zhang