[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

[Cheng Li <[e-mail]>]

Hi Dhruv,



-----Original Message-----
From: Dhruv Dhody <[e-mail]> 
Sent: Wednesday, September 11, 2024 5:26 PM
To: [e-mail]
Cc: Cheng Li <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

Hi Quan, Cheng

For this text ->

The ASSOCIATION object should also be carried in PCInitiate message to indicate the SR policy association parameters as per [I-D.ietf-pce-segment-routing-policy-cp], if this path segment identifies an SR policy.

Note that currently we do not have a way to signal if the path segment identifies a CP or a SR-Policy.
(1) Is it required to be explicitly signalled?
(2) Or should you simply state that the SR policy association needs to be included if the SR path belongs to an SR Policy?
(3) Consider using normative keywords here MUST(?)

[Cheng]I think they are independent. A Path Segment is used for identifying an LSP/Path. Then a Path may be associated with others in a Candidate path or a SR policy in the end, I think they are independent, if I am understanding correct. So it should be option 2.

==

Consider adding this text in the Introduction ->

Although [RFC9050] defines the PCE as the central controller (PCECC) model, where the PCE can instruct each hop (including the egress) on the end-to-end path, PCE (as per [RFC5040], [RFC8231], and [RFC8281]) typically only communicates with the ingress node. However, since the path segment identifies the SR path on the egress node, the PCE must also communicate with the egress node. This document outlines a mechanism to use the existing stateful message exchange with the egress node to signal both the SR path and the path segment.

[Cheng]I am ok with this proposal.
==

Thanks!
Dhruv (as a WG participant)


On Wed, Sep 11, 2024 at 12:17 PM <[e-mail]> wrote:

>
> Hi Cheng and Co-authors,
>
>
> I have updated the draft as discussed and the diff file is attached.
>
> Please review and comment and I will submit it before this weekend! Thanks!
>
>
> Best Regards,
>
> Quan
>
>
> Original
> *From: *ChengLi <[e-mail]>
> *To: *熊泉00091065;[e-mail] <[e-mail]>;
> *Cc: *[e-mail] 
> <[e-mail]>;[e-mail]
> <[e-mail]>;
> *Date: *2024年09月09日 17:42
> *Subject: **RE: [Pce] Re: I-D Action:
> draft-ietf-pce-sr-path-segment-10.txt*
>
> Hi Quan,
>
>
>
> Do you mind to lead this update? If yes, please update the xml(You can 
> download it from the datatracker) and share the diff file for authors 
> to review.
>
>
>
> I am crazy busy on updating 10+ drafts recently. If you can help on 
> this, I will be very appreciated!
>
>
>
> Thanks,
>
> Cheng
>
>
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Monday, September 9, 2024 11:23 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]
> *Subject:* Re: [Pce] Re: I-D Action: 
> draft-ietf-pce-sr-path-segment-10.txt
>
>
>
>
>
> Hi Dhruv and Joel,
>
>
>
> Thanks for your suggestion!
>
>
>
> The adding texts in my last email mainly clarify the path segment 
> related parameters (e.g association) within an SR policy.  I think the 
> PCE communicates with the tail instead of a notification, for example, 
> as figure 3 shown, it send PCInitiate message to the egress PCC for 
> PCE tail notification, for example, as figure 3 shown.
>
>
>
> I agree that the path segment is the first function that requires 
> communication with both tail and head end cause the the path segment 
> should be inserted at the ingress PCC and should be recognized at the egress PCC