Thanks Martin! Respect, Cheng
-----Original Message----- From: Martin Vigoureux [mailto:[email protected]] Sent: Tuesday, March 15, 2022 5:32 PM To: Chengli (Cheng Li) <[email protected]>; Dhruv Dhody <[email protected]> Cc: The IESG <[email protected]>; [email protected]; pce-chairs <[email protected]>; [email protected]; Julien Meuric <[email protected]> Subject: Re: 答复: Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT) Cheng, Druv, sorry for the belated response. I have reviewed the changes and I'm fine with them. I'll clear my DISCUSS. -m Le 2022-02-10 à 14:44, Chengli (Cheng Li) a écrit : > 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
