Hi Martin, Considering Cheng would be busy celebrating the Lunar new year (and the year of the tiger), let me take a stab at your comments.
On Tue, Feb 1, 2022 at 4:06 PM Martin Vigoureux via Datatracker <[email protected]> wrote: > > 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. > Dhruv: Regarding the formating of section 5, it is common practice in PCE documents to list text based on PCEP messages. The use of messages is dependent on the "situation" i.e. PCRpt for passive; PCRpt & PCUpd for active; PCRpt, PCUpd, & PCInitiate for PCE-initiated. Since the same message can be used for all, it makes sense to list the operations in terms of messages. Regarding delegation - Yes, if the LSP is delegated to PCE, PCE can change/remove the binding using the PCUpd message. Note that as described in RFC 8231, PCUpd is still a request from PCE to update and the PCC can always reject it. The same holds true for binding value. > 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? > Dhruv: Thanks for noticing these, I suggest adding - If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where the R flag is set to 1, but either the binding value is missing (empty TE-PATH-BINDING TLV) or the binding value is incorrect, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD6 ("Unable to remove the binding value"). > * 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? > Dhruv: The existing binding values which remain unchanged are optional to be included. The text uses MAY for them. So in this case, the PCC would try to allocate an additional binding value. > The draft seems silent about how to deal with multiple identical > TE-PATH-BINDING TLVs. Use any? Throw an error? > Dhruv: I guess use any. Do you suggest adding text for this? I am not sure if I have seen such text in similar cases. > 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? Dhruv: In case the PCE sends N TE-PATH-BINDING TLVs in the message and the PCC cannot allocate them all, the whole message is rejected with an error message. > 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. > > Dhruv: Since the whole message is rejected, we don't need to select the 'M' values. Is some text required here? > ---------------------------------------------------------------------- > 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? > Dhruv: Yes! s/a specific binding/any or a specific binding/ > 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. > Dhruv: RFC 9050 says this - For the purpose of this document, it is assumed that the exclusive label range to be used by a PCE is known and set on both PCEP peers. A future extension could add the capability to advertise this range via a possible PCEP extension as well (see [PCE-ID]). Maybe authors could repeat this in section 8. > 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? > Dhruv: Yes BT value can play a role. In general, in PCEP there is a distinction made between unknown and (known but not supported). The reason for not being supported could be many (including the feature is not enabled). Regarding the situation you mention, PCC would send the error saying unable to allocate using the existing error codes. > 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. > Dhruv: The second sentence focus on the existing instances of TE-PATH-BINDING which remains unchanged. Thanks for a comprehensive review! Much appreciated. Regards, Dhruv > s/associted/associated/ > > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
