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

draft-pouyllau-pce-enhanced-errors-01 2 | PCEP extensions for enhanced errors and notifications |IETF 77 th Outline Motivation and problem statement PCEP behaviors Proposed Extensions

draft-pouyllau-pce-enhanced-errors-01 3 | PCEP extensions for enhanced errors and notifications |IETF 77 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. Crossing various domains (e.g. routing domains, ASes), the probability of having heterogeneous PCE systems is high  Hence, the risk of divergent and unstable situations is high  Extending error and notification codes is a major challenge considering PCE applicability in multi-domain contexts Other motivation  particular 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  e.g. BRPC error-type=4, error-value=4 (Unsupported parameter) could be propagated to the PCC so that the request can be modified  Notifications could be used for new features (PCE policing, discovery, etc.)

draft-pouyllau-pce-enhanced-errors-01 4 | PCEP extensions for enhanced errors and notifications |IETF 77 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-01 5 | PCEP extensions for enhanced errors and notifications |IETF 77 th Outline Motivation and problem statement PCEP behaviors Proposed Extensions

draft-pouyllau-pce-enhanced-errors-01 6 | PCEP extensions for enhanced errors and notifications |IETF 77 th PCEP behaviors On the basis of RFC-5440 and RFC-5441, but also to enhance PCEP applicability, we identify different possible behaviors In case of error:  “Propagation”: the received message requires to be propagated forwardly or backwardly;  “Status quo”: the received message does not affect the PCEP connection but the path computation request is cancelled;  “Unrecoverable”: the received message is an unrecoverable failure leading to cancel the path computation and close the TCP connection and release the PCEP resources;

draft-pouyllau-pce-enhanced-errors-01 7 | PCEP extensions for enhanced errors and notifications |IETF 77 th PCEP behaviors In case of notification:  “Status quo”: the notification is or is not request-specific but does not imply any forward or backward propagation of the message;  “Request-specific Propagation”: the received message requires to be propagated forwardly or backwardly (depending on which peer has sent the message) to the PCEP peers;  “Non request-specific Propagation”: the received message must be propagated to any known peers (e.g. if PCE discovery is activated) or to a list of identified peers.

draft-pouyllau-pce-enhanced-errors-01 8 | PCEP extensions for enhanced errors and notifications |IETF 77 th Outline Motivation and problem statement PCEP behaviors Proposed Extensions

draft-pouyllau-pce-enhanced-errors-01 9 | PCEP extensions for enhanced errors and notifications |IETF 77 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 | PCEP extensions for enhanced errors and notifications |IETF 77 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 | PCEP extensions for enhanced errors and notifications |IETF 77 th Conclusion Goals of the draft  Extending PCEP to generalize error and notification behaviors  Limit the risks of divergence and instability in heterogeneous situations  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 Step: Get a PCE WG feedback on the proposal