Murray Kucherawy has entered the following ballot position for draft-ietf-pce-binding-label-sid-12: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 1: This document specifies an extension to PCEP to manage of binding label/SID for both SR and non-SR paths. I can't parse this sentence. The SHOULD in Section 8 seems strange; it offers the implementer a choice of not allocating the binding label/SID when the PCC has met the stated conditions. Why the choice? If the SHOULD is meant to cover the "unable to allocate" case, I would argue that the SHOULD is not necessary because there's no interoperability choice being exercised, and would instead suggest: * To request that the PCE allocate the binding label/SID, a PCC MUST set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt message. The PCE will attempt to allocate it and respond to the PCC with PCUpd message including the allocated binding label/SID in the TE- PATH-BINDING TLV and P=1, D=1 in the LSP object. If the PCE is unable to allocate, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable to allocate a new binding label/SID"). Thank you for including Section 9. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
