Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Boris,

Sorry for the late reply...

1.1) Yes, it's basically always going to be set to 1. There isn't expected to be any other values there in the future, this field is basically unused.

1.2) I've removed that sentence in version 15. I think the intent was that the PCC can have multiple loopbacks, but this text just adds confusion and isn't necessary.

1.3) Normally, when the PCE creates a new LSP in a new Association, it can choose the Association ID however it wants. So if the ID is some 16-bit number, then the PCE can choose a random number for example. But in the SR Policy use-case this can lead to a (very rare) race condition when two PCEs both decide to create the same SR Policy at exactly the same time. Each PCE would choose some random number as the Association ID and each PCE sends its random Association ID in its PCInitiate message. Now the PCC would receive two PCInitiate messages asking to create the same SR Policy (same color and endpoint), but these two messages have different Association IDs. To avoid this mess, it's just cleaner to make Association ID == Color + Endpoint, so that the two PCEs don't have to pick a "random number" for the Association ID. They always send a deterministic value. Hopefully that clears it up?

Thanks,
Mike.

On Tuesday, January 23rd, 2024 at 5:17 AM, Boris Khasanov <bhassanov@yandex-team.ru> wrote:

> 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" <dd@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