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
