Hi, I support the feature, I have the following comment regarding the draft: - There is not mandated capability negotiation, this generally makes interworking more cumbersome. This could be resolved by mandating the presence of OP-CONF-ASSOC-RANGE, and using reserved value 0,0 for Start-Assoc-ID, Range to indicate that there is no
Operator-configured Association Range. Section 4.1 : what happens if the dynamic allocation ranges do not match between the two peer ? is it allowed or should the session be bounced? A special case can be made when one peer advertise (0,0) section 5.2.1: - the PCC can remove an association by setting the R flag to 1, if the PCC does not include any association, should the association be kept on the LSP? - I think the following should be added : PCRpt: all associations MUST be reported during state synchronization - Value 0 was previously used to ask a peer to allocate an association ID. Is it deemed not necessary anymore. Section 5.3: - the "association information" is not defined. The whole section can be clarified by detailing what the association information is.: is it (association type, association source, association-id), from the association group definitions, the triplet defines a group, so it should be possible to have several association id for th same type, source Does the the "association information previously received about the same association from a peer" relates to the association group (should there be an unique association id per lsp for a given type,source) or does it refers to the optional TLVs. " On receiving association information that does not match with the association information previously received about the same association from a peer, it MUST return a PCErr message with Error-Type TBD "Association Error" and Error-Value 6 "Association information mismatch"" This could be clarified, IMHO generally speaking the draft should allow several association id per (type, source), this kind of restriction may be defined in the documents defining the association types. Thanks, Cyril On 1 February 2018 at 10:38, <stephane.litkow...@orange.com> wrote: > Support > > -----Original Message----- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric > Sent: Thursday, February 01, 2018 15:10 > To: pce@ietf.org > Subject: [Pce] WG LC of draft-ietf-pce-association-group > > Hi all, > > This message initiates a 2-week WG last call for > draft-ietf-pce-association-group-04. Please review and share your > feedback on the PCE mailing list. This LC will end on Thursday February, 15. > > Regards, > > Jon & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > ____________________________________________________________ > _____________________________________________________________ > > 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 > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
