Hi Julien, My bad! I did some digging and we added this based on Adrian's comment [1] back in Feb last year (and my memory failed me).
How about - The Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE TLV in the case of a non-contiguous Operator-configured Association Range. The PCEP speaker originating this TLV MUST NOT carry overlapping ranges for an association type. If a PCEP peer receives overlapping ranges for an association type, it MUST consider the Open message malformed and MUST reject the PCEP session with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message). Thanks! Dhruv [1] https://mailarchive.ietf.org/arch/msg/pce/QSobS2pul-lIlMLXV4KcBhwgBM0 On Thu, Mar 7, 2019 at 6:45 PM <[email protected]> wrote: > Hi Dhruv, > > Congratulation from the prompt update. I'm fine with the <a, b> notation > for ranges. > > The only open issue is the text you add below: > - Is there a reason to prohibit, for a given Association type, split > operator-configured ranges? I don't think this is what the original > version suggested. > - Assuming we proceed with this new rule, then why so much text about > overlapping ranges? To have this happen, the TLV would already break > that "present only once" rule: why would an implementation care about > checking if ranges overlap if the TLV is already wrong? > > Thanks, > > Julien > > > On 07/03/2019 09:28, Dhruv Dhody wrote: > >> ------ > >> 5.1. Procedure > >> --- > >> - The current text only indirectly tackles the case where a given Assoc- > >> type is advertised multiple times, when forbidding overlapping ranges. A > >> complementary sentence explicitly mentioning non-overlapping ranges > would > >> be welcome. > > [[Dhruv Dhody]] Added - > > > > An Assoc-Type MUST be present only once in the OP-CONF-ASSOC-RANGE > > TLV, if the same Assoc-Type is present more than once, the PCEP > > session MUST be rejected with error type 1 and error value 1 (PCEP > > session establishment failure / Reception of an invalid Open > > message). > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
