Hi, Ramon, I think you raise a very good point. IMHO, the two lines drawn (using the figure Ramon provided below) between the box above (named as NMS) and NEs will not co-exist although it serves the purpose of including all modes currently under discussion.
1) For provisioning, as detailed in http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00, it does not expect any computation request/reply message exchange (if I understand correctly) since LSPs are assumed to be delegated all the time. So, although I do expect other PCEP messages other than PCInitiate sent through, but definitely not request and reply communication exchanged. 2) For computation request/reply, assume what we meant here is the basic stateless (or maximum the active stateful PCE) function, then the left line is definitely not needed. A couple of more points I would like to raise for discussion: First: PCEP is used between a PCE and a PCC, but from figure below it seems PCEP can also be used between a LSP coordinator and a NE, or say a NMS and a NE. Second: Currently in Section 5.5 of RFC4655, it discuss how NMS can take advantage of a PCE, but again there NMS and PCE are different boxes and the NMS is acting as a PCC and presumably using its own protocol (but not PCEP) for service request. So, it seems that we need to either broaden PCE function or broaden the entity catalogue using PCEP, isn’t it? (To answer Dhruv’s question sent to the list) Personally, I do not have an issue saying phrases such as “PCE-initiated LSP” since we are extending the PCEP to do provisioning and the acting entity has to be PCE in current std definition, unless I am mistaken. If preserving current function of PCE (aka, path computation) is preferred, what we can emphasize is the PCE itself is not acting as a provisioning entity but rather it acts as a proxy for the entity (say a network controller) to send the provisioning request. So, instead of controller->PCE->controller-> NE message flow, it is simplified as controller->PCE->NEs path. Regards, Xian From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas Sent: 2014年3月19日 15:13 To: 'Adrian Farrel' (adr...@olddog.co.uk); pce >> "pce@ietf.org" Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt) Adrian, all A somehow orthogonal comment/question unrelated to whether a PCE should be kept a simple element for path computation (as in abno) or its scope augmented with NMS-like capabilities. I am wondering about the role of your "PCEP Protocol Engine" box, as simply opposed to have two parallel vertical lines that use PCEP. Maybe a away of narrowing my question would be as follows: "Can it be that the whole NMS box in your drawing is a single IP host?" If the answer is, as I would expect "usually not", since the LSP coordinator and PCE are different functional entities that can be located in different IP hosts, then I guess my subsequent comment would be that "the PCEP protocol engine box" is not really needed, the same way we don't add "X protocol engine" to all the interfaces / lines. However, in my humble opinion, it does make sense if, for example, the NMS is just an IP host, and to highlight the role of PCE as a functional component within that box. In this case, I am wondering about the issue with RFC5440 disallowing parallel PCEP sessions [1] (this is something that I find unfortunate in RFC5440, and that was left out of the errata when we changed the mandatory client port) In other words, If the head end node has a single, unique, persistent PCEP/TCP connection to the "NMS" box, represented by a given IP address, and which is used for path computation requests and responses, can this persistent PCEP session be *also* used to receive provisioning requests? (i.e. multiplexed in a single PCEP instance). By RFC5440 the answer seems to be "yes". Then your question reduces to "shall the working group call PCE to the NMS box, of just to the inner box", but noting that the only thing that is added to a PCE is the "LSP coordinator function" Alternatively, I guess that the head end node would need to listen for incoming TCP/PCEP connections as provisioning interface or establish a PCEP connection with the "LSP coordinator" (thus assuming configuring the head end node with both addresses), in addition to acting as PCC client. (I am postponing the issue of having to replicate PCRpts to both the initiating LSP coordinator as well as PCE, and keeping both in sync for a later discussion :o) sorry for the long, I guess somehow confusing mail. R. ----------------------------------- | ------ ----- | | NMS |LSP-DB| | TED |<-+-----------> | / ------ ----- | TED synchronization | -------------/ | | | mechanism (for example, | | LSP | | | | routing protocol) | | Coordinator | v v | | | | -------------- | | | |-| PCE | | | ------------- -------------- | | | | | | --------------------------- | | | PCEP Protocol Engine | | | --------------------------- | | | A | | | | | -------+-----+--------------------- Provisioning | |Computation Request | |Request/Response V V ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<------------->| Node | ---------- ---------- [1] RFC5440 Only one PCEP session can exist between a pair of PCEP peers at any one time. Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time.
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
