Hi Samuel, Thank you for your reply, I hope this update to the list triggers further discussion here and in the WG session.
Thanks! Dhruv On Tue, Jul 26, 2022 at 3:31 PM Samuel Sidor (ssidor) <ssidor= [email protected]> wrote: > Hi Dhruv, > > > > Thanks a lot for your feedback. > > > > For comments received during IETF113 – I checked notes: > > https://notes.ietf.org/notes-ietf-113-pce?both > > > > And it seems to me that those should be covered already in latest version > (v02), which will be presented. To be more specific: > > > > - Comment from Tarek about reducing number of flags to block specific > trigger for re-optimization – TLV was renamed and we dropped original flags > for triggering re-optimization (new flag was introduced to address comment > from Andrew, but that is described bellow). Tarek also joined draft as > co-author. > - Comments from Andrew – he joined draft as co-author and provided > more comments – including those provided during last IETF presentation. > Those comments should be addressed. > - Comment from Cheng Li – I responded to that comment during > presentation. > - Comment from Fan Yang – It was about draft [0] and not about [1] > (used references from your mail) > > > > So only remaining comment I can see is from you about using policy > association vs introducing new TLV for blocking re-computation – I > discussed it with you before this draft was introduced and you know my > opinion, so I’ll keep others from PCE WG to express their view. For now, > feedback received from co-authors for introducing those TLVs is positive. > We still have a plan to add capability (or other mechanism to handle > backward compatibility) to check whether blocking re-computation is > supported. Something like that would be harder (if possible) to do with > associations. > > > > For your new comments – please see inline. > > > > Regards, > > Samuel > > > > *From:* Dhruv Dhody <[email protected]> > *Sent:* Friday, July 22, 2022 8:17 PM > *To:* [email protected] > *Cc:* [email protected] > *Subject:* draft-sidor-pce-circuit-style-pcep-extensions-02 > > > > Hi, > > I am glad the companion document [0] is on the SPRING agenda. It is not > clear if the plan is to move it to SPRING WG with a change in draft name > and make it fully protocol agnostic by removing any details specific to PCE. > > Please go over the minutes of 113 [1] and provide an update on the list. > That would help in moving the discussion forward. > > Few comments - > > - I suggest removing figure 1 and do not assign bit positions (leave that > for the IANA). This is no longer aligned as a new document ahead in the > publication queue can request flags (in this case the recent update of > stateful GMPLS I-D did just that) > > <S> Makes sense. I’ll do that. > - Since PATH-RECOMPUTATION TLV is useful only for delegated LSP, encoding > it in an LSP object might be a better option than LSPA (which is allowed > for PCReq as well). It is also easier to check the delegate flag in the LSP > object and add text to ignore the TLV if it is not set. > <S> TLV was moved to LSPA mostly based on discussion that logically it > belongs more to LSPA as it represents LSP attributes/behavior, but I don’t > think that there was any strong opinion against. I can see also some > potential improvement in size of PCEP message as LSP object is always > included (with TLV being included in LSP object), but LSPA is optional, so > sometimes we would have to include LSPA object only because of this TLV. I > would say that PCReq is not strong argument against (we can easily block > usage of that TLV in this draft for stateless messages). > > > Hope this helps! > > Thanks! > Dhruv > > [0] https://datatracker.ietf.org/doc/draft-schmutzer-pce-cs-sr-policy/ > [1] https://datatracker.ietf.org/doc/minutes-113-pce/ > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
