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
<[email protected]> 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" <[email protected]>:
>
>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
