Hi Dhruv, First of all, thank you for your comments in such a busy week.
Yes, current usage of redundancy protection is only within SR paradigm and the extension is to SR Policy. To encode the information within the SR policy association group would be the most intuitive way. On the other hand, to define it in RP objects actually generalizes extensions to non-SR networks. I see the confusions might come from here. The authors would surely have some internal discussions and come back with reasonable proposals. Thanks again and enjoy the week! Best regards, Fan From: Dhruv Dhody [mailto:[email protected]] Sent: Saturday, July 23, 2022 2:19 AM To: [email protected] Cc: [email protected] Subject: draft-yang-pce-pcep-redundancy-policy-00 Hi, I have a general query on the extension. If the usage is limited to SR Policy, is it not a good idea to encode this within the SR policy association group? I find the use of RP objects to be limiting as it is not used in the PCRpt, PCUpd, and PCInitiate messages. You are already creating a new TLV called SR Policy Candidate Path Flag TLV at the CP level, you can also create another TLV called SR Policy Redundancy TLV at the SR Policy level and include the fields that you require. Note that the association can be used in PCReq message as well and thus can meet your requirement for just path computation as well. Also I urge you to check out existing mechanism to signal protection before you introduce another TLV for it. Hope this helps! Thanks! Dhruv
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
