Extension to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications draft-pouyllau-pce-enhanced-errors-02 H. Pouyllau R. Theillaud J. Meuric

draft-pouyllau-pce-enhanced-errors-02 2 | PCEP extensions for enhanced errors and notifications |IETF 78 th Outline Motivation and problem statement Proposed Extensions Conclusion

draft-pouyllau-pce-enhanced-errors-02 3 | PCEP extensions for enhanced errors and notifications |IETF 78 th Motivation PCErr and PCNtf  Some error and notification types/values are standardized  A large range of types and values is not used. The goal is not to modify the existing ones. Extending error and notification codes and specify associated behaviors is a a need for:  Enhancing PCE functionalities  Notifications can be used for particular functions (PCE policing, discovery, etc.)  Improving the coordination among PCE systems  Anticipating future evolutions of the standard Examples  Path computation methods (e.g. Hierarchical PCE End-to-End) might require the propagation of errors or notifications to PCEs involved in a path computation

draft-pouyllau-pce-enhanced-errors-02 4 | PCEP extensions for enhanced errors and notifications |IETF 78 th Outline Motivation and problem statement Proposed Extensions Conclusion

draft-pouyllau-pce-enhanced-errors-02 5 | PCEP extensions for enhanced errors and notifications |IETF 78 th Proposed Extensions Error types corresponding to the identified behaviors:  Error-type=16, “status quo”,  Error-type=17, “propagation” and “status quo”,  Error-type=18, “unrecoverable”,  Error-type=19, “propagation” and “unrecoverable”, Notification types corresponding to the identified behaviors:  Notification-type=3, “status quo”,  Notification-type=4, “Request-specific Propagation”,  Notification-type=5, “Non request-specific Propagation”.

draft-pouyllau-pce-enhanced-errors-02 6 | PCEP extensions for enhanced errors and notifications |IETF 78 th Propagation Restrictions A Time-To-Live object: to limit the number of PCEP peers that will recursively receive the message; A Diffusion List Object (DLO): to indicate the PCEP peer addresses or domains of PCEP peers the message must be propagate to and to exclude some domains or PCEs; History mechanisms: if a PCEP peer keeps track of the messages it has relayed, it could avoid propagating several times the same error/notification to the same peers.

draft-pouyllau-pce-enhanced-errors-02 7 | PCEP extensions for enhanced errors and notifications |IETF 78 th Examples provided in -02 – Error-type 17 A parameter is not supported by one of the PCE (e.g. a METRIC object of type 4). The path computation request can thus be treated but the parameter will be ignored. Hence, this error is not critical but the source PCC should be informed of this fact. So, an error of type 17 is raised and propagated backwardly to the source PCC. (17, x)

draft-pouyllau-pce-enhanced-errors-02 8 | PCEP extensions for enhanced errors and notifications |IETF 78 th Examples provided in -02 – Notification-type 03 A PCE sends a request-specific notification indicating that, due to multiple sendings (or for other reason), further requests from this PCC will be ignored. Hence, a notification of type 3 is sent to the PCC. (3, x)

draft-pouyllau-pce-enhanced-errors-02 9 | PCEP extensions for enhanced errors and notifications |IETF 78 th Conclusion Goals of the draft  Extending PCEP to generalize error and notification behaviors  Give a common error/notification framework for existing and future path computation methods Will to restrict the propagation of errors/notifications while ensuring flexibility Next Steps:  Get a PCE WG feedback on the proposal

draft-pouyllau-pce-enhanced-errors | PCEP extensions for enhanced errors and notifications |IETF 78 th Points raised on the mailing-list 1) Error type is more related to a family of errors, in the draft it indicates a king of processing indication. Use means of TLVs rather than types for each possible option (propagation, shutdown, etc.)  Inline with the draft, no strong argument against this proposal  To be discussed 2) Warning is an error or a notification  Do errors always induce to shutdown the connection ? 3)DLO  Example: a PCE want to advertize to all the PCEs of the AS it belongs to that it is congested. The DLO object (in the manner of the IRO) can be used for that

Back-up

draft-pouyllau-pce-enhanced-errors | PCEP extensions for enhanced errors and notifications |IETF 78 th Notification Use-Case PCE(i-1)PCE(i)PCE(i+1) PCReq (ID=1) In this use case, PCE(i-1) and PCE(i+1) shares the same semantic of error messages (e.g. they are provided by the same vendor) but not PCE(i). PCE(i-1) is the PCC of the request. PCE(i+1) is overloaded. PCNtf(2,1, RP(ID=1)) PCRep (NO_PATH,ID=1) PCReq (ID=1) Domain(i-1)Domain(i) Domain(i+1) PCE(i+1) is overloaded and can not honored request 1. PCE(i-1) ignores the congestion on PCE(i+1) and sends a request to PCE(i+1).

draft-pouyllau-pce-enhanced-errors | PCEP extensions for enhanced errors and notifications |IETF 78 th Examples provided in -02 – Error-type 16 A PCE receiving a request does not understand a parameter value. For instance, the request could have a METRIC object of type 3 (hop count) with a bound value equal to -1. It raises an error to the PCC with error-type 16. This error is not critical, (the parameter will be ignored), the session is still active and a response can still be expected. (16, x)

draft-pouyllau-pce-enhanced-errors | PCEP extensions for enhanced errors and notifications |IETF 78 th Examples provided in -02 – Error-type 18 A PCC sends a request that contains an IRO which can not be satisfied by the next PCE. This problem is critical but not due to a malformation in the request of the source PCC. An error of type 18 is raised. The PCECP session is closed and PCE resources released. (18, x)

draft-pouyllau-pce-enhanced-errors | PCEP extensions for enhanced errors and notifications |IETF 78 th Examples provided in -02 – Error-type 19 The next PCE in the path computation chain is no more active (congested or deleted). The path can not be computed and the source PCC should be informed - for further path computation requests - that one of the PCE is not reachable any more. An error of type 19 is raised and propagated backwardly to the source PCC. PCECP sessions are closed and PCE resources released. (19, x)

draft-pouyllau-pce-enhanced-errors | PCEP extensions for enhanced errors and notifications |IETF 78 th Examples provided in -02 – Notification-type 04 A PCE receives a request but it is temporarily congested. However, it can treat the request after few minutes which might cause some time-out in the predecessor PCEs. A notification of type 4 is send to the PCC and forward backwardly in the PCE sequence. Such a notification could include an OVERLOAD object as described in RFC5886. (4, x)

draft-pouyllau-pce-enhanced-errors | PCEP extensions for enhanced errors and notifications |IETF 78 th Examples provided in -02 – Notification-type 05 The notification-type 5 could be used to disclose to external domains' PCEs (here PCEj and PCEj') that the parent PCE of a domain (here PCEi) has changed. In this case, the notification-type 5 is used as a complement of a discovery feature. (5, x, DLO(PCEj, PCEj’))