Dear authors, I would raised come comments on your draft following its presentation during the last IETF meeting.
First, regarding section 2, using PcRpt to request a path to PCE is not a good idea, IMHO, for many reasons: - You claim that it will simplify the protocol and reduce the number of messages. But, in case of PcReq usage, there is 3 messages (PcReq from PCC to PCE, PcRep from PCE to PCC and PcRpt from PCC to PCE) which is the same with an empty PcRpt: 3 messages take place (PcRpt from PCC to PCE, PcUpdate from PCE to PCC and PcRpt from PCC to PCE), - It is clearly mention that a PCE MAY send a PcUpdate message when a PCC sends a PcRpt with an LSP mark as down (with or without an empty ERO) in RFC8231. Thus, in your proposal, there is no guarantee that a PCC receives a path from the PCE while, with a PcReq, a PCE MUST answer even with a NO-PATH Object as per RFC5440 definition, - Changing above behavior for PCE, i.e. PCE MUST reply to a PcRpt with an empty ERO with a PcUpdate will violate the base principle of IETF where only one message is allowed per protocol for a given action. Here, your proposal will introduce the possibility to request a Path with two different messages within the same protocol, - Doing that, as two consequences: - there is no possiblity for the PCE with an PcUpdate message to advertise the PCC that there is no path with all indications allowed by the NO-PATH Object, - Using PcRpt to request a path is also restrictive compared to a PcReq. In particular, the PcRpt could not contains an IRO/XRO or SVEC Objects which are mandatory constraints for operator, in particular in the scope of geopolitical / tactical path computation, path diversity, path protection ... However, I agree that when a PCC would request a new path, the number of messages is increase as it MUST first send a PcRpt to stop delegation, then sends a PcReq message, wait for the PcRep and finaly sends another PcRpt to re-delegate the LSP. But, if the goal is to simplify the protocol, I would suggest to take the problem in another way: Why not enhance the PcReq and as consequence PcRep messages to stateful? I mean: LSP is already part of PcReq and PcRep messages. Thus, there is no modification in the protocol. We just need to authorize the Delegation within the PcReq and PcRep messages. Operations will be as follow: - A PCC sends a PcReq message with Delegate=1 to both request and delegate a path to PCE, - PCE MUST reply to PcReq with a PcRep message with Delegate=1 or Delegate=0 depending if it accepts or not the delegation as usual, - PCC install the path and sends a PcRpt message with Delegate=1 as usual, - In case of NO-PATH, the PCE could accept the delegation by setting Delegate=1. PCC sends a PcRpt with state down. PCE could then update later the path when resource or constraint become available by sending a PcUpdate message. PCC could also sends a new PcReq message already with Delegate=1 after relaxing some constraints accoring to the NO-PATH Object it received previously. - During path life, PCC could sends new PcReq message already with Delegate=1 to request a new path. This time, we save exchanges between PCC and PCE. Another benefit of this solution will be the possibility for a PCC to request a new path in the case of a PCE Initiated path. Today, PCC has no possiblity to advertise or request a new path to the PCE in the case of an initiated tunnel. Only a PcRpt message could be send with a Down or Goes-to-Down bit set. But, there is again no guarantee that the PCE will update the path. Now, regarding section 3, I agree that both ERO and RRO with SR or SRv6 path is useless. However, I think, IMHO, that it would be better to keep or render mandatory RRO Object instead of ERO. Indeed, the purpose of PcRpt is to synchronise the LSP-DB between PCC and PCE but also report to PCE the state of the LSP. Thus, in this scope, RRO, which represent the actual path, has more meaning compared to ERO which represents the intend path. Best Regards Olivier ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
