Hi, Thanks for the prompt reply, sorry for the not-so-prompt handling of that. Please see inline
On 23 February 2018 at 08:51, Dhruv Dhody <dhruv.dh...@huawei.com> wrote: > Hi Cyril, > > > > Thanks for your review and suggestions. I could not get to this earlier, > apologies for that! Please see inline... > > > > Diff: https://tools.ietf.org/rfcdiff?url1=https://tools. > ietf.org/id/draft-ietf-pce-association-group-04.txt&url2= > https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/ > master/draft-ietf-pce-association-group-05.txt > > Txt: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft- > ietf-pce-association-group-05.txt > > > > *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria > *Sent:* 02 February 2018 04:54 > *To:* LITKOWSKI Stephane DTF/DERX <stephane.litkow...@orange.com> > *Cc:* pce@ietf.org > *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group > > > > 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. > > > > *[[Dhruv Dhody]] The presence of ASSOCIATION object in PCEP message is a good > indicator for this feature. Not sure if there is a need to exchange > capabilities in OPEN, we have followed the similar approach in RFC5455, 5520, > 5521 etc. * > > [MC] Peer capability discovery is supported in RFC5541, RFC8281, RFC6006. The ability to know which type of association (bidirectional LSP, path protection,..etc) is supported affect the Path Computation, and in addition the reception of an unknown object will close the session, which is less than ideal at scale. If the OP-CONF-ASSOC-RANGE is not meaningful, then a TLV for discovery is needed (list of association source and reserved flags for draft use would be ideal) 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) > > > > *[[Dhruv Dhody]] I have added an appendix with an example to make this > clearer, please let me know if I need to make any change for this! * > > > > The example helps, maybe the following change in version 5, section 3.4 would clarify further: OLD: A range of association identifier for each association-type are kept for the operator-configured associations. Dynamic associations MUST NOT use the association identifier from this range. This range as set at the PCEP speaker (as an association source) needs to be communicated to a PCEP peer in the Open Message. A new TLV is defined in this specification for this purpose (Section 4 <https://tools.ietf.org/html/draft-ietf-pce-association-group-05#section-4>). See Appendix A <https://tools.ietf.org/html/draft-ietf-pce-association-group-05#appendix-A> for an example. NEW: A range of association identifier for each association-type,association-source are kept for the operator-configured associations. Dynamic associations MUST NOT use the association identifier from this range. This range as set at the PCEP speaker (PCC or PCE) and needs to be communicated to a PCEP peer in the Open Message. A new TLV is defined in this specification for this purpose (Section 4 <https://tools.ietf.org/html/draft-ietf-pce-association-group-05#section-4>). See Appendix A <https://tools.ietf.org/html/draft-ietf-pce-association-group-05#appendix-A> for an example. Association identifier range for sources other than the PCEP peer (an NMS system for example) is outside the scope of this document, -- > 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? > > *[[Dhruv Dhody]] The R flag is set in association, if association id is zero, > that is invalid; if association id is 0xffff, then it is all association > within the scope of association type/source; otherwise it looks for > association, if not found it is considered as unknown association. * > > So > - I think the following should be added : PCRpt: all associations MUST be > reported during state synchronization > > *[[Dhruv Dhody]] Ack. * > > - Value 0 was previously used to ask a peer to allocate an association ID. > Is it deemed not necessary anymore. > > *[[Dhruv Dhody]] Yes* > > > > > > 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 > > *[[Dhruv Dhody]] I have added a new section on it, also clarified > “association information” and “association parameters” in section 5.3* > > That is clarified, but as the global id and extended id are optional, I understand that (association type, association source, association-id) and (association type, association source, association-id, extended-id) for example (10,10,10) and (10,10,10,0) are two different associations, correct? > > 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"" > > *[[Dhruv Dhody]] it is latter, I have updated! * > > So that means that the association information is immutable, a peer has to delete the association (id is association-parameters), then re-create it with same id, new association information. I find this quite restrictive and might cause churn. For instance the path protection and diversity group have such information, and not being able to update them seems too restrictive (changing a secondary to standby for instance) > > 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. > > > > *[[Dhruv Dhody]] Please check the diff and let me know if there is scope of > any other improvement. * > > The processing rules were expanded greatly, some new comments: If a PCEP speaker receives ASSOCIATION in PCReq message, and the association is not known (association is not configured, or created dynamically, or learned from a PCEP peer), it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 4 "Association unknown". I am confused, that forbids PCReq on LSP with unknown association. If the P bit is set, maybe, bit its likely association-dependent. > > *Thanks for your patience. * > > > > *Regards,* > > *Dhruv* > > > > 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
