Hi Martin and Dhruv, Sorry for my delay due to the Lunar tiger new year, and many thanks to Dhruv for your help!
I have updated the draft according to the recent discussion in the mailing list. Hope it can address your comments: Respect, Cheng There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13 -----邮件原件----- 发件人: Dhruv Dhody [mailto:[email protected]] 发送时间: 2022年2月1日 21:09 收件人: Martin Vigoureux <[email protected]> 抄送: The IESG <[email protected]>; [email protected]; pce-chairs <[email protected]>; [email protected]; Julien Meuric <[email protected]> 主题: Re: Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT) 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
