Hi all,
Sorry for being late, I fully support the adoption too.
Some small comments for the better understanding:
1) Section 4.1 Association parameters
1.1) Association ID which should be set to 1, will it never be used and should be kept as '1" ?
1.2) This sentence sounds confusing, IMO:
"If the PCC receives a PCInit message with the Association Source set not to the headend IP but to some globally unique IP address that the headend owns, then the PCC SHOULD accept the PCInit message and create the SRPA with the Association Source that was sent in the PCInit message."
Why do we need such dualism here? I mean this other IP-address which should be delivered to PCE in advance etc. Complicates an implementation IMO.
1.3) Also not exactly clear how these parameters can help to escape "a race condition when multiple PCEP speakers want to create the same SR Policy at the same time." Can you please clarify?
2) Can you please add into section 7 (Implementation status) some info/plans about the Invalidation TLV. It is very important mechanism in practice.
Thank you.
SY,
Boris
08.01.2024, 13:29, "Dhruv Dhody" <d...@dhruvdhody.com>:
,Hi WG,
This email starts a 2-weeks working group last call for draft-ietf-pce-segment-routing-policy-cp-12.https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/
Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome.
The WG LC will end on Monday 22nd January 2024.
A general reminder to the WG to be more vocal during the last-call/adoption.
Thanks,
Dhruv & Julien
_______________________________________________
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
