Martin Vigoureux has entered the following ballot position for draft-ietf-pce-binding-label-sid-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, thank you for this document. I have few points I'd like to discuss. Some might simply arise from my limited knowledge/expertise in pce. Thank you for your understanding. Section 5 is confusing to me. In my understanding, from a PCE perspective, an LSP can be in three different situations: state synched with PCE, delegated to PCE, or initiated by PCE. However, maybe not all the text applies to the three cases. So, I wonder whether organizing this section along the lines of what can be done and not done depending on the situations would help. At least, one key aspect which is not clear to me is whether the binding value is an attribute over which control (change/remove) is given to pce in case of delegation. Also, I have the impression that there are "error" conditions which are not described: * how should PCC react (regardless of whether it already has a binding value) if it receives from PCE an empty TLV with R=1? * how should PCC react if it receives from PCE a TLV with a binding value (different from the one it has) with R=1? * how should PCC react if it receives from PCE a single TLV with a binding value different from the one it has and with R=0? The draft seems silent about how to deal with multiple identical TE-PATH-BINDING TLVs. Use any? Throw an error? The draft allows multiple TE-PATH-BINDING TLVs to be sent but in my view falls short to describe the associated expectations. Ultimately the binding value is something that will end-up programmed in the data-plane (or at least reserved in the control plane) but maybe not all systems have the same capabilities in these domains. Since PCE doesn't know these capabilities, I think, how should be handled the situation where PCE requests N values but the node wants to -or can- only use M (where M < N). Should an error be thrown back, or only M values chosen and reported back? Is the selection of the M values function of a local policy or should they be the M first or last, or any other specific rule? These two paragraphs could be viewed as giving elements of response to these questions but it's not fully clear: If a PCE requires a PCC to allocate a (or several) specific binding value(s), it may do so by sending a PCUpd or PCInitiate message containing a TE-PATH-BINDING TLV(s). If the value(s) can be successfully allocated, the PCC reports the binding value(s) to the PCE. If the PCC considers the binding value specified by the PCE invalid, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID"). If the binding value is valid, but the PCC is unable to allocate the binding value, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD4 ("Unable to allocate the specified binding value"). Note that, in case of an error, the PCC rejects the PCUpd or PCInitiate message in its entirety and can include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To implement the needed changes to PCEP, in this document, we introduce a new OPTIONAL TLV that a PCC can use in order to report the binding label/SID associated with a TE LSP, or a PCE to request a PCC to allocate a specific binding label/SID value. It can also request PCC to allocate a value of its own choosing (with an empty TLV), correct? As another way to use the extension specified in this document, to support the PCE-based central controller [RFC8283] operation where the PCE would take responsibility for managing some part of the MPLS label space for each of the routers that it controls, the PCE could directly make the binding label/SID allocation and inform the PCC. See Section 8 for details. I am a bit sceptical about this and Section 8. This requires a mechanism which is, as the draft says, specified nowhere. If a PCE recognizes the TLV but does not support the TLV, it MUST send a PCErr with Error-Type = 2 (Capability not supported). Could you elaborate on what you mean by "does not support the TLV"? For example the BT value? Also, could the following situation exist: a node with some LSPs which can support a binding value and other which can't. How is PCC supposed to react to a PCE request to allocate a binding value on an LSP from the latter set? Multiple TE-PATH-BINDING TLVs are allowed to be present in the same LSP object. This signifies the presence of multiple binding SIDs for the given LSP. In the case of multiple TE-PATH-BINDING TLVs, the existing instances of TE-PATH-BINDING TLVs MAY be included in the LSP object. Not sure what that last sentence means or adds compared to the previous ones. s/associted/associated/ _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
