Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C19C169436; Wed, 11 Sep 2024 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPFhYu7JDjWV; Wed, 11 Sep 2024 08:26:08 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE7EC151707; Wed, 11 Sep 2024 08:26:08 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id ada2fe7eead31-49bc7387371so2182228137.2; Wed, 11 Sep 2024 08:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726068367; x=1726673167; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gj7JfMir4vFZ2/RZpePzQcVu8ULuM6y2NTAr6Rs961w=; b=C5xiKfdUl01Ga9mDdTC5i6gS6wC3kpHymt0eLtWN8RLSDrVrFYxJqjD/oTcEkbepHn mqXKTf+79GIlWX+ueVQRZJ6p+ZCqprqGt5/pljv8rGeD9SkkbxCH/tQjNhF946q4E8jM 6POLy8RatL3EVQKabTKsO8+MS867wS5hBu0QjfzXWxU6rYeqpvHFw1iZQ+gl1ghSYziE h1Fz/ZIUJ6RvUmw9z123KDE/nefPqBAb6Mlzzl+K1NHNvxnoXAHmTdv7hz73ZlpCZDAA cS9TwX+QqCkbyIJAm4sPBythKsujCEtcq4nY21lzmOr5EpIz3pWXk/mNcbWh0shJojGj Oq1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726068367; x=1726673167; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Gj7JfMir4vFZ2/RZpePzQcVu8ULuM6y2NTAr6Rs961w=; b=LM4c1gmmwa2axP86F8Y7K6+ZVACIWMwmaquN40NRocut2nTs8t5JtIqZlHU6rHODKk 8tibJLY0bsWSAu2EmfDgIhAw2Mmyi3LnXpMzsG1xRT92FKmGa7f7ob6DXy4TOKw6dHP0 dK3yh+UaSs/Vx9Dt1Zwgq2BdNUf3f0dSUeWDT5I9zQ0NQTr+7GzbRQ+Vg/0a2pgfn6C1 dak5DtPJM0ZE2o+LOSpuhMzkCG8walLEKEKDQICKQvTeRYNhHyzpINZdTc8epoPwHWCW YCZqK+qpcaGFoYgoSKyw7AdsHFExnjY4JpPxLgEUBQ9aVWJ3ewgO8CjPizM/UFvQ0F4R BQdw== X-Forwarded-Encrypted: i=1; AJvYcCUG4C9OcqcTKwCKlGbD12PcfiGXBGS5/rWli7IN/yZfd1QxhR/orpQMh0+i7SNgHdtTIdQO6FrWn7S2vCM4vMyMHa9IaCgrg2UHMkXlIO8=@ietf.org, AJvYcCXcot0BXlob8XobiCvYTDH7XG5qgqET0f0/EQiJnHHYoiWOb32ATTqrNx5fAvM3nFALM4/E@ietf.org X-Gm-Message-State: AOJu0YwEPnNWjgnTge/toy6EcAuTNgGkssp8ABMpAgjYq7oGgSNn2/TA Ek9SPSzi5uYTDVENH/saXg7m3u7lOsInwQv0CXO/Wbr6JzClUgoqHMz8EYf736Mi5IePz5vBNi7 4i++9FRp5K6dcSwzsaX+a+ip5U30= X-Google-Smtp-Source: AGHT+IF9JNvrPywEgGntlaCHb1YJb4kWSYj4pZSAuESGwAP7lvX5NXaJsBqrENfayEWJyPpqmpreXvYydO0xG0gr3io= X-Received: by 2002:a05:6102:c0f:b0:49b:e3fd:b6d0 with SMTP id ada2fe7eead31-49bedb7464cmr12425957137.5.1726068367243; Wed, 11 Sep 2024 08:26:07 -0700 (PDT) MIME-Version: 1.0 References: <633e09a0f80546deba21a1afd91bf0d7@huawei.com> <20240911144652862CYyh71ya73mRlw9qXoiOR@zte.com.cn> In-Reply-To: <20240911144652862CYyh71ya73mRlw9qXoiOR@zte.com.cn> From: Dhruv Dhody Date: Wed, 11 Sep 2024 20:55:30 +0530 Message-ID: To: xiong.quan@zte.com.cn Content-Type: multipart/alternative; boundary="000000000000e340ef0621d99b8b" Message-ID-Hash: GAFLLSXFPM2EHTO245KRRGB4J7VO2NO6 X-Message-ID-Hash: GAFLLSXFPM2EHTO245KRRGB4J7VO2NO6 X-MailFrom: dhruv.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-ietf-pce-sr-path-segment@ietf.org, pce@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BPce=5D_Re=3A_I-D_Action=3A_draft-ietf-pce-sr-path-segment-10=2E?= =?utf-8?q?txt?= List-Id: Path Computation Element Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e340ef0621d99b8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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(?) =3D=3D 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. =3D=3D Thanks! Dhruv (as a WG participant) On Wed, Sep 11, 2024 at 12:17=E2=80=AFPM 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! Thank= s! > > > Best Regards, > > Quan > > > Original > *From: *ChengLi > *To: *=E7=86=8A=E6=B3=8900091065;dd@dhruvdhody.com ; > *Cc: *pce@ietf.org ;draft-ietf-pce-sr-path-segment@ietf.org > ; > *Date: *2024=E5=B9=B409=E6=9C=8809=E6=97=A5 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:* xiong.quan@zte.com.cn > *Sent:* Monday, September 9, 2024 11:23 AM > *To:* dd@dhruvdhody.com > *Cc:* jmh.direct@joelhalpern.com; gregimirsky@gmail.com; pce@ietf.org; > draft-ietf-pce-sr-path-segment@ietf.org > *Subject:* Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.tx= t > > > > > > 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 shou= ld > be inserted at the ingress PCC and should be recognized at the egress PCC= . > > From my understanding, the section 3 has described the operations, as per > https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#na= me-overview-of-path-segment-ex, the path > segment can be allocated by egress PCC or PCE. > > A, If it is allocated by the egress PCC as per section 5.1, the PCE (or > ingress PCC first sends requests to the PCE) should request a path segmen= t > from egress PCC and notify the ingress PCC. > > B, If it is allocated by the PCE as per section 5.2, the PCE should > allocate a path segment and notify both ingress and egress PCC. > > > > Would it be better to clarify it clearly in section 3 like following show= n? > > "There are various modes of operations, such as > > =C2=B7 The Path Segment can be allocated by Egress PCC. The PCE s= hould > request the Path Segment from egress PCC by PCInitiate messge and notify > the ingress PCC bu PCUpd messge as per section 5.1.2. > > =C2=B7 The PCE (or the ingress PCC requests the path segment to > PCE) can allocate a Path Segment on its own accord and inform the > ingress/egress PCC by PCInitiate or PCUpd messge as per section 5.2.2. > > =C2=B7 Ingress PCC can also request PCE to allocate the Path Segm= ent, > in this case, the PCE would either allocate and inform the assigned Path > Segment to the ingress/egress PCC using PCInitiate or PCUpd message, or > first request egress PCC for Path Segment and then inform it to the ingre= ss > PCC as per 5.1.1. > > " > > What is your thoughts? > > > > Best, > > Quan > > > > Original > > *From: *DhruvDhody > > *To: *Joel Halpern ; > > *Cc: *=E7=86=8A=E6=B3=8900091065;gregimirsky@gmail.com ; > pce@ietf.org ;draft-ietf-pce-sr-path-segment@ietf.org < > draft-ietf-pce-sr-path-segment@ietf.org>; > > *Date: *2024=E5=B9=B409=E6=9C=8809=E6=97=A5 12:43 > > *Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt= * > > Hi Joel, > > On Fri, Sep 6, 2024 at 7:22=E2=80=AFPM Joel Halpern > wrote: > > > These references appear useful. There is however one aspect that I am > > missing. It may well be my own mistake, rather than a problem in the > > draft. The usage of the sr path segment relies on the tail of the path > > > being able to recognize the path segment label. I am not familiar with= any > > > usage of PCE that communicates path information to the LSP tail end, ra= ther > > > than the head end. Looking at the drat you point to in these changes, = I do > > not see any addition of tail notification. Is there already a PCE tail > > notification that I have forgotten about? > > > > There is a PCECC model RFC 9050 that communicates with all nodes (includi= ng > the tail) along the path, so there is some precedence. > > But the path segment draft is the first one that requires communication > with the tail end ( > > https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#fi= gure-3 > ) > outside of the PCECC model. > > Authors, I suggest that your draft should highlight this explicitly rathe= r > than it being buried in a subsection. > > Thanks! > Dhruv > > > > > Thank you, > > > > Joel > > On 9/6/2024 5:20 AM, xiong.quan@zte.com.cn wrote: > > > > > > Hi Greg, Joel and all, > > > > > > Thanks for your discussion on the MPLS mailing list as following link > > shown~ > > > > https://mailarchive.ietf.org/arch/msg/mpls/e3CI8xeDN1OTu5FgAIB6tI_yRaY/ > > > > > > Allow me to take the discussion to PCE. As per RFC9545 and > > > draft-ietf-spring-srv6-path-segment, a path segment can identify a SR p= ath, > > a SR policy, a candidate-path or a SID-List in a SR policy. But this > > > document did not mention the path segment processing within SR policy P= CEP > > > instantiation. It may cause some misunderstandings about PCEP processes= and > > parameters for path segment within a SR policy. So I suggest to add > > some texts for next version of this draft. Please see inline with > > . > > > > > > 1 Introduction > > > > [RFC8664] specifies extensions to the Path Computation Element > > Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE = to > > > compute and initiate SR-TE paths, as well as a PCC to request, report= or > > > delegate SR paths. ** *"[ietf-pce-segment-routing-polic= y-cp] > > specifies the PCEP extension to signal candidate paths of the SR Poli= cy > > > > > _______________________________________________ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-leave@ietf.org > --000000000000e340ef0621d99b8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Quan, Cheng

For this text= ->=C2=A0

The ASSOCIATION object should also be ca= rried in PCInitiate
message to indicate the SR policy association parame= ters as per
[I-D.ietf-pce-segment-routing-policy-cp], if this path segme= nt
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.=C2=A0
(1) Is it required to be explicitly=C2=A0signalled= ?=C2=A0
(2) Or should you simply state t= hat the SR policy association needs to be included if the SR path belongs t= o an SR Policy?=C2=A0
<= font color=3D"#073763" face=3D"trebuchet ms, sans-serif">(3) Consider using= normative keywords here MUST(?)

=3D=3D

<= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif;font-size:small;color:rgb(7,55,99)">Consider adding this text in = the Introduction ->=C2=A0
<= font face=3D"monospace" style=3D"" color=3D"#444444">

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 [RFC50= 40], [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 ou= tlines a mechanism to use the existing stateful message exchange with the e= gress node to signal both the SR path and the path segment.=C2=A0


=3D=3D

Thanks!=C2=A0
Dhruv = (as a WG participant)
<= br>

On Wed, Sep 11, 2024 at 12:17=E2=80=AFPM <xiong.quan@zte.com.cn> wrote:


Hi Cheng and Co-authors,


I have u= pdated the draft as discussed and the diff file is attached.

Please review and comment and I will submit it befor= e this weekend! Thanks!


Best Regards,

Quan


<= div style=3D"display:block">
Original
From:=C2=A0ChengLi <c.l@huawei.com>
To:=C2= =A0=E7=86=8A=E6=B3=8900091065;dd@dhruvdhody.com <dd@dhruvdhody.com>;
Date:=C2=A02024=E5=B9=B409=E6=9C=8809=E6=97=A5 17:42
Subje= ct:=C2=A0RE: [Pce] Re: I-D Action: draft-ietf-pce-sr= -path-segment-10.txt

Hi Quan,

=C2= =A0

Do you mind to lead this update? I= f yes, please update the xml(You can download it from the datatracker) and = share the diff file for authors to review.

=C2=A0

I am crazy busy on updatin= g 10+ drafts recently. If you can help on this, I will be very appreciated!=

=C2=A0

Thanks,

Cheng

=C2=A0

=C2=A0

From: xiong.quan@zte.com.cn &l= t;xiong.quan@zte= .com.cn>
Sent: Monday, September 9, 2024 11:23= AM
To: dd@dhruvdhody.com
Cc: jmh.direct@joelhalpern.com= ; gregimirsky@gm= ail.com; pce@ietf.org= ; draft-ietf-pce-sr-path-segment@ietf.org
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

=C2=A0

= =C2=A0

Hi Dhruv and Joel,

=C2=A0

Thanks for your sugg= estion!

=C2=A0

= The adding texts in my last email mainly = clarify the path segment related parameters (e.g association) within an SR = policy.=C2=A0 I think the PCE communicates with the=C2=A0tail instead of a = notification,=C2=A0for example, as figure 3 shown,=C2=A0it send PCInitiate= message to the egress PCC for PCE=C2=A0tail notification, for example, as = figure 3 shown.

=C2=A0

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 shoul= d be=C2=A0recognized at the egress PCC.=C2=A0

From my understanding, the section 3 has described the op= erations, as per https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#n= ame-overview-of-path-segment-ex,=C2=A0the=C2=A0path segment can be allo= cated by egress PCC or PCE.=C2=A0

A, If it is allocated by the egress PCC as per section 5.1, the PCE (o= r ingress PCC first sends requests to the PCE) should request a path segmen= t from egress PCC and notify the ingress PCC.

B, If it is=C2=A0allocated by the PCE as per section 5.2,= the PCE should allocate a path segment and notify both ingress and egress = PCC.

=C2=A0

Would it be better to clarify it clearly in = section 3 like following shown?

"There are various modes of ope= rations, such as

=

=C2= =B7=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Path Segment can be allocated by Egress PCC. The PCE shoul= d request the Path Segment from egress PCC by PCInitiate messge and notify = the ingress PCC bu PCUpd=C2=A0messge as p= er section 5.1.2.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The PCE (= or the ingress PCC requests the path segment to PCE)=C2=A0can allocate a Pa= th Segment on its own accord and inform the ingress/egress PCC by PCInitiate or PCUpd=C2=A0messge=C2=A0as per = section=C2=A05.2.2.

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ingress PCC can also request PCE to allocate the P= ath Segment, in this case, the PCE would either allocate and inform the ass= igned Path Segment to the ingress/egress PCC using PCInitiate or=C2=A0PCUpd=C2=A0=C2=A0message, or first requ= est egress PCC for Path Segment and then inform it to the ingress PCC as pe= r 5.1.1.

"

What is you= r thoughts?

=C2=A0

=

Best,

Quan

=C2=A0

Original

From:=C2=A0DhruvDhody <= ;dd@dhruvdhody.com>

Date:=C2=A02024=E5=B9=B409= =E6=9C=8809=E6=97=A5 12:43=

Subject:=C2=A0Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-1= 0.txt

Hi=C2=A0Joel,

On=C2=A0Fri,= =C2=A0Sep=C2=A06,=C2=A02024=C2=A0at=C2=A07:22=E2=80=AFPM=C2=A0Joel=C2=A0Halpern=C2=A0<jmh.direct@joelhalpern..com>= ;
wrote:

>=C2=A0These=C2=A0references=C2=A0appear=C2=A0use= ful.=C2=A0=C2=A0There=C2=A0is=C2=A0however=C2=A0one=C2=A0aspect=C2=A0that= =C2=A0I=C2=A0am
>=C2=A0missing.=C2=A0=C2=A0It=C2=A0may=C2=A0well=C2= =A0be=C2=A0my=C2=A0own=C2=A0mistake,=C2=A0rather=C2=A0than=C2=A0a=C2=A0prob= lem=C2=A0in=C2=A0the
>=C2=A0draft.=C2=A0=C2=A0The=C2=A0usage=C2=A0of= =C2=A0the=C2=A0sr=C2=A0path=C2=A0segment=C2=A0relies=C2=A0on=C2=A0the=C2=A0= tail=C2=A0of=C2=A0the=C2=A0path
>=C2=A0being=C2=A0able=C2=A0to=C2=A0= recognize=C2=A0the=C2=A0path=C2=A0segment=C2=A0label.=C2=A0=C2=A0I=C2=A0am= =C2=A0not=C2=A0familiar=C2=A0with=C2=A0any
>=C2=A0usage=C2=A0of=C2= =A0PCE=C2=A0that=C2=A0communicates=C2=A0path=C2=A0information=C2=A0to=C2=A0= the=C2=A0LSP=C2=A0tail=C2=A0end,=C2=A0rather
>=C2=A0than=C2=A0the=C2= =A0head=C2=A0end.=C2=A0=C2=A0Looking=C2=A0at=C2=A0the=C2=A0drat=C2=A0you=C2= =A0point=C2=A0to=C2=A0in=C2=A0these=C2=A0changes,=C2=A0I=C2=A0do
>= =C2=A0not=C2=A0see=C2=A0any=C2=A0addition=C2=A0of=C2=A0tail=C2=A0notificati= on.=C2=A0=C2=A0Is=C2=A0there=C2=A0already=C2=A0a=C2=A0PCE=C2=A0tail
>= ;=C2=A0notification=C2=A0that=C2=A0I=C2=A0have=C2=A0forgotten=C2=A0about? >

There=C2=A0is=C2=A0a=C2=A0PCECC=C2=A0model=C2=A0RFC=C2=A0= 9050=C2=A0that=C2=A0communicates=C2=A0with=C2=A0all=C2=A0nodes=C2=A0(includ= ing
the=C2=A0tail)=C2=A0along=C2=A0the=C2=A0path,=C2=A0so=C2=A0there=C2= =A0is=C2=A0some=C2=A0precedence.

But=C2=A0the=C2=A0path=C2=A0segme= nt=C2=A0draft=C2=A0is=C2=A0the=C2=A0first=C2=A0one=C2=A0that=C2=A0requires= =C2=A0communication
with=C2=A0the=C2=A0tail=C2=A0end=C2=A0(
https://www.ietf.org/archive/id/draft-ietf-pce-= sr-path-segment-10.html#figure-3)
outside=C2=A0of=C2=A0the=C2=A0PCE= CC=C2=A0model.

Authors,=C2=A0I=C2=A0suggest=C2=A0that=C2=A0your=C2= =A0draft=C2=A0should=C2=A0highlight=C2=A0this=C2=A0explicitly=C2=A0rather than=C2=A0it=C2=A0being=C2=A0buried=C2=A0in=C2=A0a=C2=A0subsection.
=
Thanks!
Dhruv



>=C2=A0Thank=C2=A0you,
>= ;
>=C2=A0Joel
>=C2=A0On=C2=A09/6/2024=C2=A05:20=C2=A0AM,=C2= =A0xiong.quan@zt= e.com.cn=C2=A0wrote:
>
>
>=C2=A0Hi=C2=A0Greg,=C2= =A0Joel=C2=A0and=C2=A0all,
>
>
>=C2=A0Thanks=C2=A0fo= r=C2=A0your=C2=A0discussion=C2=A0on=C2=A0the=C2=A0MPLS=C2=A0mailing=C2=A0li= st=C2=A0as=C2=A0following=C2=A0link
>=C2=A0shown~
>
>= =C2=A0https://mailarchive.ietf.org/arch/msg/mpls= /e3CI8xeDN1OTu5FgAIB6tI_yRaY/
>
>
>=C2=A0Allow= =C2=A0me=C2=A0to=C2=A0take=C2=A0the=C2=A0discussion=C2=A0to=C2=A0PCE.=C2=A0= As=C2=A0per=C2=A0RFC9545=C2=A0and
>=C2=A0draft-ietf-spring-srv6-path= -segment,=C2=A0a=C2=A0path=C2=A0segment=C2=A0can=C2=A0identify=C2=A0a=C2=A0= SR=C2=A0path,
>=C2=A0a=C2=A0SR=C2=A0policy,=C2=A0=C2=A0a=C2=A0candid= ate-path=C2=A0or=C2=A0a=C2=A0SID-List=C2=A0in=C2=A0a=C2=A0SR=C2=A0policy.= =C2=A0But=C2=A0this
>=C2=A0document=C2=A0did=C2=A0not=C2=A0mention= =C2=A0the=C2=A0path=C2=A0segment=C2=A0processing=C2=A0within=C2=A0SR=C2=A0p= olicy=C2=A0PCEP
>=C2=A0instantiation.=C2=A0It=C2=A0may=C2=A0cause=C2= =A0some=C2=A0misunderstandings=C2=A0about=C2=A0PCEP=C2=A0processes=C2=A0and=
>=C2=A0parameters=C2=A0for=C2=A0path=C2=A0segment=C2=A0within=C2=A0= a=C2=A0SR=C2=A0policy.=C2=A0=C2=A0So=C2=A0I=C2=A0suggest=C2=A0to=C2=A0add >=C2=A0some=C2=A0texts=C2=A0for=C2=A0next=C2=A0version=C2=A0of=C2=A0t= his=C2=A0draft.=C2=A0=C2=A0Please=C2=A0see=C2=A0inline=C2=A0with
>= =C2=A0<suggested=C2=A0text>.
>
>
>=C2=A0=C2=A0= 1=C2=A0Introduction
>
>=C2=A0=C2=A0=C2=A0[RFC8664]=C2=A0spec= ifies=C2=A0extensions=C2=A0to=C2=A0the=C2=A0Path=C2=A0Computation=C2=A0Elem= ent
>=C2=A0Protocol=C2=A0(PCEP)=C2=A0[RFC5440]=C2=A0for=C2=A0SR=C2= =A0networks,=C2=A0that=C2=A0allow=C2=A0a=C2=A0stateful=C2=A0PCE=C2=A0=C2=A0= =C2=A0to
>=C2=A0compute=C2=A0and=C2=A0initiate=C2=A0SR-TE=C2=A0paths= ,=C2=A0as=C2=A0well=C2=A0as=C2=A0a=C2=A0PCC=C2=A0to=C2=A0request,=C2=A0=C2= =A0=C2=A0report=C2=A0or
>=C2=A0delegate=C2=A0SR=C2=A0paths.=C2=A0*&l= t;suggested=C2=A0text>*=C2=A0*"[ietf-pce-segment-routing-policy-cp]=
>=C2=A0=C2=A0=C2=A0specifies=C2=A0the=C2=A0PCEP=C2=A0extension=C2= =A0to=C2=A0signal=C2=A0candidate=C2=A0paths=C2=A0of=C2=A0the=C2=A0SR=C2=A0P= olicy

=C2=A0


________________= _______________________________
Pce mailing list -- pce@i= etf.org
To unsubscribe send an email to pce-leave@ietf.org
--000000000000e340ef0621d99b8b--