Hi, This update addresses my comments, including the recommended capability advertisement.
Thanks, Cyril On 6 September 2018 at 01:39, Julien Meuric <julien.meu...@orange.com> wrote: > Hi all, > > I have not seen any feedback on the update below. We will thus consider > that everyone is fine with the optional advertisement which has been added. > > Cyril, you raised the issue: could you please confirm this update > addresses your comment? > > Thanks, > > Julien > > > Jun. 19, 2018 - Dhruv Dhody: > > 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 <dhruv.dh...@huawei.com> > 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 >> <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: dhruv.dh...@huawei.com >> >> [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:cyril.marga...@gmail..com >> <cyril.marga...@gmail.com>] >> *Sent:* 26 April 2018 00:13 >> *To:* Dhruv Dhody <dhruv.dh...@huawei.com> >> *Cc:* LITKOWSKI Stephane DTF/DERX <stephane.litkow...@orange.com>; Dhruv >> Dhody <dhruv.i...@gmail.com>; pce@ietf.org >> *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 <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 >> <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) >> >> >> >> *[[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, <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 listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > 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
