Hi WG, We have posted an update to the association group draft that handle the final pending issue regarding capability advertisement. See the update - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-06
Hope the document can be sent to IESG soon! Thanks! Dhruv On Thu, Apr 26, 2018 at 4:33 PM Dhruv Dhody <[email protected]> wrote: > Hi Cyril, > > > > Thanks for engaging, please see inline *[[Dhruv Dhody2]]* > > > > Working Copy: > > Diff: > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-05.txt&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-06.txt > > Txt: > https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-association-group-06.txt > > > > > > Dhruv Dhody > > Lead Architect > > Network Business Line > > Huawei Technologies India Pvt. Ltd. > > Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield > > Bengaluru, Karnataka - 560066 > > Tel: + 91-80-49160700 Ext 71583 II Email: [email protected] > > [image: Huawei-small] > > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > > > *From:* Cyril Margaria [mailto:[email protected]] > *Sent:* 26 April 2018 00:13 > *To:* Dhruv Dhody <[email protected]> > *Cc:* LITKOWSKI Stephane DTF/DERX <[email protected]>; Dhruv > Dhody <[email protected]>; [email protected] > *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group > > > > 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 <[email protected]> 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:[email protected]] *On Behalf Of *Cyril Margaria > *Sent:* 02 February 2018 04:54 > *To:* LITKOWSKI Stephane DTF/DERX <[email protected]> > *Cc:* [email protected] > *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) > > > > *[[Dhruv Dhody2]] I can’t think of way to introduce this in a backward > compatible way that would work with existing association implementations. > Let me talk to the chairs on the resolving this! * > > > > > > 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, > > -- > > > > > > *[[Dhruv Dhody2]] Ack, updated! * > > > > > > 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? > > > > *[[Dhruv Dhody2]] Yes, I guess that would be aligned to RSVP-TE RFC 6780 > as well! At least I think it does! * > > > > > 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) > > > > *[[Dhruv Dhody2]] Our intention was to say that you could not completely > change the meaning of the association as a whole, as included in > association-information. You can definitely change the state of the LSP as > a part of an association. I will try to reword this. * > > *Also the I-D where the association types are defined they could clarify > this behavior as per each association-type use and encodings. See updated > text. * > > > > > > > > > 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. > > > > *[[Dhruv Dhody2]] Use of a path computation request message to create a > new association state is not correct for a message that supposed to be for > stateless PCE model. Ofcourse if PCE is aware of the association group > already carrying this information as a part of PCReq is fine! * > > *A PCReq message on the other hand can notify PCE of a new association, > and PCE would store the association state as part of LSP-DB. Does that make > sense? * > > > > *Regards,* > > *Dhruv* > > > > > > *Thanks for your patience. * > > > > *Regards,* > > *Dhruv* > > > > Thanks, Cyril > > > > On 1 February 2018 at 10:38, <[email protected]> wrote: > > Support > > -----Original Message----- > From: Pce [mailto:[email protected]] On Behalf Of Julien Meuric > Sent: Thursday, February 01, 2018 15:10 > To: [email protected] > 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 > [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce > > > > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
