A Path Computation Element (PCE)-Based Architecture
RFC 4655
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
05 | (System) | Received changes through RFC Editor sync (changed abstract to 'Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label … Received changes through RFC Editor sync (changed abstract to 'Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.') |
|
2017-05-16
|
05 | (System) | Changed document authors from "Adrian Farrel, Gerald Ash" to "Adrian Farrel, Gerald Ash, JP Vasseur" |
|
2015-10-14
|
05 | (System) | Notify list changed from pce-chairs@ietf.org to (None) |
|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2011-02-21
|
(System) | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to RFC 4655 | |
|
2006-11-08
|
05 | (System) | Request for Early review by SECDIR Completed. Reviewer: Sam Weiler. |
|
2006-08-30
|
05 | Amy Vezza | [Note]: 'RFC 4655' added by Amy Vezza |
|
2006-08-30
|
05 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2006-08-23
|
05 | (System) | RFC published |
|
2006-07-24
|
05 | Bill Fenner | State Change Notice email list have been change to pce-chairs@tools.ietf.org from adrian@olddog.co.uk, jpv@cisco.com |
|
2006-05-02
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2006-05-01
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2006-05-01
|
05 | Amy Vezza | IESG has approved the document |
|
2006-05-01
|
05 | Amy Vezza | Closed "Approve" ballot |
|
2006-04-28
|
05 | Ross Callon | State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Ross Callon |
|
2006-04-28
|
05 | Amy Vezza | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup by Amy Vezza |
|
2006-04-28
|
05 | (System) | Removed from agenda for telechat - 2006-04-27 |
|
2006-04-24
|
05 | Dan Romascanu | [Ballot comment] I cleared my DISCUSS as most of the issues I raised were addressed. There is one editorial issue left that is not worth … [Ballot comment] I cleared my DISCUSS as most of the issues I raised were addressed. There is one editorial issue left that is not worth more than a COMMENT, yet I would be glad to see it fixed or hear an explanation. Section 9 lists Manageability Considerations in sub-sections 9.1 to 9.6, and then includes the follwoing: 9.7. Other Considerations No other management considerations have been identified. Why this? |
|
2006-04-24
|
05 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Undefined by Dan Romascanu |
|
2006-04-24
|
05 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to Undefined from Discuss by Dan Romascanu |
|
2006-04-21
|
05 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2006-04-20
|
05 | Russ Housley | [Ballot discuss] Section 6.10 says: > > This requirement is not a security issue, but relates to Service > Provider policy. Confidentiality, integrity, and authentication … [Ballot discuss] Section 6.10 says: > > This requirement is not a security issue, but relates to Service > Provider policy. Confidentiality, integrity, and authentication of > PCC-PCE and PCE-PCE messages must also be ensured and is described in > Section 10. > This is good. I have no problem with the point that is being made about confidentiality. However, Section 10 does not provide the expected discussion. The closest text in Section 10 is: > > It is expected that PCE solutions will address these issues in detail > using authentication and security techniques. > I would be much happier with a statement like that requires the implementation of mechanisms that will ensure the integrity and authentication of PCC-PCE and PCE-PCE messages. An optional mechanism can also be specified to ensure the confidentiality of these messages. |
|
2006-04-19
|
05 | Ross Callon | Placed on agenda for telechat - 2006-04-27 by Ross Callon |
|
2006-04-19
|
05 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon by Ross Callon |
|
2006-04-14
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2006-04-14
|
05 | (System) | New version available: draft-ietf-pce-architecture-05.txt |
|
2006-04-12
|
05 | Ross Callon | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon |
|
2006-04-12
|
05 | Ross Callon | The author (JP Vasseur) has indicated that a minor editorial update is needed. |
|
2006-03-30
|
05 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer by Amy Vezza |
|
2006-03-30
|
05 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault |
|
2006-03-30
|
05 | Jari Arkko | State Changes to IESG Evaluation - Defer from IESG Evaluation by Jari Arkko |
|
2006-03-29
|
05 | Bill Fenner | Shepherding AD has been changed to Ross Callon from Alex Zinin |
|
2006-03-29
|
05 | Jari Arkko | [Ballot comment] Typo in Section 5.6: s/extening/extending/ |
|
2006-03-29
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko |
|
2006-03-29
|
05 | Dan Romascanu | [Ballot discuss] Several observations concerning manageability aspects, that would deserve a more careful consideration: - Section 5.5 includes the following text: 'The NMS uses a … [Ballot discuss] Several observations concerning manageability aspects, that would deserve a more careful consideration: - Section 5.5 includes the following text: 'The NMS uses a management plane mechanism to send this request such as the TE MIB module [RFC3812].' A MIB module is not a 'management plane mechanism' but a data model. A better text would be: 'The NMS uses a aonfiguration protocol as a management plane mechanism associated with a data model, such as the one defined in SMIv2 for the TE MIB module [RFC3812] - last bullet in section 5.6 includes a list of items for which MIB modules (actually data models) are needed. I would add here PCE monitoring information, so that the last bullet would be: OLD: MIB modules related to communication protocols, routing and signaling extensions and metrics. NEW: MIB modules related to communication protocols, routing and signaling extensions and metrics, and PCE monitoring information - Section 9.2 includes the following: OLD: The new MIB modules should also be used to provide notifications (formerly known as traps) when key thresholds are crossed or when important events occur. Great care must be exercised to ensure that the network is not flooded with SNMP notifications. Thus it might be inappropriate to issue a notification every time that a PCE receives a request to compute a path. In any case, full control must be provided through the MIB modules to allow notifications to be disabled. Two problems here: - saying that notifications are formally known as traps is a well-known buggy expression in the SNMP world. Actually notifications include both traps and informs - if SNMP is being used, there is a standard interface (MIB module) to control notification targets and enabling, which should be mentioned so, I suggest the following: The new MIB modules should also be used to provide notifications when key thresholds are crossed or when important events occur. Great care must be exercised to ensure that the network is not flooded with SNMP notifications. Thus it might be inappropriate to issue a notification every time that a PCE receives a request to compute a path. In any case, full control must be provided to allow notifications to be disabled using for example the mechanisms defined in the SNMP-NOTIFICATION MIB in [RFC3413]. [RFC3413] should be added to the references. - It is not clear to me what is the role of Section 9.7. Looks to me that it can be taken out. - I believe that the security considerations section should mention the fact that a control plane protocol performing configuration operations must be appropriately secured in order to prevent un-desired or even malicious operations that may affect the network operational state, for example by diabling PCE function as described in Section 9.1 |
|
2006-03-29
|
05 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to Discuss from Undefined by Dan Romascanu |
|
2006-03-29
|
05 | Dan Romascanu | [Ballot Position Update] New position, Undefined, has been recorded for Dan Romascanu by Dan Romascanu |
|
2006-03-29
|
05 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert |
|
2006-03-29
|
05 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
|
2006-03-28
|
05 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings |
|
2006-03-26
|
05 | Magnus Westerlund | [Ballot comment] Please spell out all usage of acronyms in their first usage. Some example of this is ASON, NMS and IGP. |
|
2006-03-26
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund |
|
2006-03-16
|
05 | Sam Hartman | State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman |
|
2006-03-16
|
05 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
|
2006-03-16
|
05 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
|
2006-03-16
|
05 | Russ Housley | [Ballot discuss] Section 6.10 covers confidentiality requirements. Authentication and integrity are even more important. Please expand this section to cover all three topics. … [Ballot discuss] Section 6.10 covers confidentiality requirements. Authentication and integrity are even more important. Please expand this section to cover all three topics. The Security Considerations section touches on some of these points, but the document structure leads the reader to the conclusion that confidentiality is more important than authentication and integrity, which is false in this protocol environment. COMMENT Section 1: Please spell out the first use of PCC, TED, and LSR. Section 9.7: Why is this here? Please delete it. |
|
2006-03-16
|
05 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
|
2006-03-16
|
05 | Brian Carpenter | [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Undefined by Brian Carpenter |
|
2006-03-16
|
05 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
|
2006-03-16
|
05 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
|
2006-03-16
|
05 | David Kessens | [Ballot comment] I received the following comments by Pekka Savola from the OPS directorate that you might want to consider: (Note: we don't run MPLS … [Ballot comment] I received the following comments by Pekka Savola from the OPS directorate that you might want to consider: (Note: we don't run MPLS or GMPLS TE networks so review from someone who does woudln't hurt..) I read the draft and thought it was reasonably clear and easy to read. There seemed to be a couple of internal inconsistancies (section x said "foo", section y said "foo and bar") but nothing major. I think the doc could easily be wrapped up in a month with one revision. semi-substantial ---------------- 4.4. Node Outside the Routing Domain An LER might not be part of the routing domain for administrative reasons (for example, a customer-edge (CE) router connected to the provider-edge (PE) router in the context of MPLS VPN [RFC2547] and for which it is desired to provide a CE to CE TE LSP path). This scenario suggests a solution that does not involve doing computation on the ingress (TE LSP head-end) router, and that does not rely on static loose hops configuration in which case optimal shortest paths could not be achieved. A distinct PCE-based solution can help here. Note that the PCE in this case may, itself, provide a path that includes loose hops. ==> I'm not sure how relevant this scenario really is. If you don't rely on external equipment (e.g., CE's, maybe under the customer control or not) to participate in the routing domain for administrative reasons, why could you rely on them doing TE decisions? (which could hurt ISP's own TE decisions..) In any case, such nodes basically just have a default route to the ISP, so I'm not sure why they need to participate in TE at all.. Conversely, stateless PCEs do not have to remember any computed path and each set of request(s) is processed independently of each other. For example, stateless PCEs may compute paths based on current TED information, which could be out of sync with actual network state given other recent PCE-computed paths changes. ==> do you assume that if a PCE computes a path, it will actually automatically get used? The last sentence seems to imply that. (But text further in the draft doesn't seem to assume that.) The router could just also very well discard it. The path computations made to PCC's seem irrelevant, as the PCEs should use solely TED to get info about path changes. (This might imply that you might need to wait until TED has been updated between each PCE computation to know if it was activated or not...) editorial --------- 4.8 Path Selection Policy ===> it might have been useful to briefly also mention the policy synchronization here, because if you have multiple PCE's, that's pretty important; whether that needs to be done out-of-band or using e.g., PCE-PCE protocols remains to be seen. 5.3. Multiple PCE Path Computation Figure 3 illustrates how multiple PCE path computations may be performed along the path of a signaled service. As in the previous example, the head-end PCC makes a request to an external PCE, but the path that is returned is such that the next network element finds it necessary to perform further computation. This may be the case when the path returned is a partial path that does not reach the intended destination or when the computed path is loose. [...] ==> in section 5 or 6, you don't describe the scenario at all where PCC sends in a request to a PCE, which fails to provide a reply or replies in such a manner (e.g., the first hop is loose) that the PCC needs to contact another PCE for better path information. On the other hand, the second bullet in Section 7 seems to imply this is also possible. Is this an intentional omission or should that scenario also be mentioned here? (AFAICS, your the two cases addressed here are: 1) contact PCE, get enough information to forward packets to the next hop, let that contact the same or some other PCE, and 2) contact PCE, and assume inter-PCE communication to sort it out.) 6.6. PCC-PCE & PCE-PCE Communication ==> you don't include any requirements on how the communication needs to be 1) secured (well, later in section 6.10 you have some but PCE-PCE or PCC-PCE IMHO belong here; note that you'll probably want more than just confidentiality, e.g., integrity), or 2) what kind of requirements there are for communication (e.g., how fast should you notice if the communication doesn't form? or dies in the middle?) [I note that some of this is under 6.5] 9.7. Other Considerations No other management considerations arise. ==> hmm.. shouldn't you rather say, "No other management considerations have been identified." ? :-) |
|
2006-03-16
|
05 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
|
2006-03-15
|
05 | Brian Carpenter | [Ballot comment] I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. … [Ballot comment] I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. Similarly, the assumption that QoS enters into path computation seems very casual given the history of QoS-based routing. |
|
2006-03-15
|
05 | Brian Carpenter | [Ballot comment] I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. … [Ballot comment] I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. Similarly, the assumption that QoS enters into path computation seems very casual given the history of QoS-based routing. |
|
2006-03-15
|
05 | Brian Carpenter | [Ballot comment] I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. … [Ballot comment] I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. Similarly, the assumption the QoS enters into path computation seems very casual given the history of QoS-based routing. |
|
2006-03-15
|
05 | Brian Carpenter | [Ballot Position Update] New position, Undefined, has been recorded for Brian Carpenter by Brian Carpenter |
|
2006-03-15
|
05 | Michelle Cotton | IANA Comments: As described in the IANA Consideration section, we understand this document to have NO IANA Actions. |
|
2006-03-13
|
05 | Alex Zinin | [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin |
|
2006-03-13
|
05 | Alex Zinin | Ballot has been issued by Alex Zinin |
|
2006-03-13
|
05 | Alex Zinin | Created "Approve" ballot |
|
2006-03-13
|
05 | (System) | Ballot writeup text was added |
|
2006-03-13
|
05 | (System) | Last call text was added |
|
2006-03-13
|
05 | (System) | Ballot approval text was added |
|
2006-02-26
|
05 | Alex Zinin | Placed on agenda for telechat - 2006-03-16 by Alex Zinin |
|
2006-02-26
|
05 | Alex Zinin | State Changes to IESG Evaluation from AD Evaluation by Alex Zinin |
|
2006-01-19
|
05 | Alex Zinin | State Changes to AD Evaluation from Publication Requested by Alex Zinin |
|
2006-01-19
|
05 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2006-01-17
|
04 | (System) | New version available: draft-ietf-pce-architecture-04.txt |
|
2005-12-09
|
03 | (System) | New version available: draft-ietf-pce-architecture-03.txt |
|
2005-09-21
|
02 | (System) | New version available: draft-ietf-pce-architecture-02.txt |
|
2005-07-19
|
01 | (System) | New version available: draft-ietf-pce-architecture-01.txt |
|
2005-03-21
|
00 | (System) | New version available: draft-ietf-pce-architecture-00.txt |