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 <dhruv.i...@gmail.com> Sent: Friday, July 22, 2022 8:17 PM To: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Cc: pce@ietf.org 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
