Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Aijun Wang <> Tue, 23 March 2021 07:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 320073A157C for <>; Tue, 23 Mar 2021 00:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JgniKzyfc1Y5 for <>; Tue, 23 Mar 2021 00:00:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 951C03A0A31 for <>; Tue, 23 Mar 2021 00:00:49 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown []) by (Hmail) with ESMTPA id B27E91C030F; Tue, 23 Mar 2021 15:00:44 +0800 (CST)
From: "Aijun Wang" <>
To: "'Dhruv Dhody'" <>, "'Bidgoli, Hooman \(Nokia - CA/Ottawa\)'" <>
Cc: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <1806 2086-5dc2-5fee> <> <> <>
In-Reply-To: <>
Date: Tue, 23 Mar 2021 15:00:43 +0800
Message-ID: <00cb01d71fb2$3e5274f0$baf75ed0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01D71FF5.4C769F50"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ1x4XQ5etMHGlRzEkhtsERQhrRsQKvevgaAhVJVEABh3s95wEhIfatAcV/LykCcPFnYQJtB7ClAIC5i5ECV/RwDAC9PTbzAdZFUSQA9qf/MQFvw5CJAfRkBR8B994oZAJLTTdLqHL5koA=
Content-Language: zh-cn
X-HM-Tid: 0a785de2c0a2d993kuwsb27e91c030f
Archived-At: <>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Mar 2021 07:00:57 -0000



My consideration is that if the solution depends on the distribution protocol among the underlay nodes to accomplish the task, then PCE should follow the procedures described in RFC8231, RFC8281 etc. That is to say, in such situation, the instruction from the PCE needs only to be sent to the headend of the path.


And, if the solution depends solely on the computation of the PCE, and PCE should interact not only the headend node, but also the transit node, tail-end node, follow the PCECC approach is more clear.

Mixed of these two solutions should be avoided.



Best Regards


Aijun Wang

China Telecom


From: <> On Behalf Of Dhruv Dhody
Sent: Monday, March 22, 2021 12:48 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.


Hi Hooman,


On Thu, Mar 18, 2021 at 10:06 PM Bidgoli, Hooman (Nokia - CA/Ottawa) < <> > wrote:

Hi Dhruv

I am very confused by your messaging. 

Originally it was pointed out that the draft should follow PCECC/CCI.
The authors explained why they feel that is not a good fit.

Now you are mentioning get in part with RFC 8231, 8281 etc... which is a new input. Thank you.


I apologize if I was not clear. As I said in the mail, I still feel PCECC is the way to go. What I want to highlight is that if you consider it as an LSP operation instead, then it should be built on RFC 8623 (P2MP) instead. 


The 'recap' was to show how the extensions in PCEP have been done for SR and P2MP in the past in a consistent way. 



The authors/co-authors have  tried to keep the draft in par with all the RFCs that you mentioned as much as possible. As it is mentioned in the draft clearly. That said this is new concept and there is a need for a new PCE concept and deviation, hence the draft ūüėä and the purpose of IETF.

RSVP-TE P2MP is built via S2Ls.
Replication segment is nothing like S2L, replication segment can be connected via unicast SR.


If you claim that the replication segment can not use RFC 8623, that gives it more of a reason to not consider it as an LSP operation in the first place.  


Again we are open for any constructive feedback on how this draft can be improved, in the boundary of


Just to clarify, my feedback is on your choice of PCEP procedure and encoding for the replication segment taking existing PCEP extensions/procedures in mind.  Hope the discussion was useful, it was for me...



Dhruv (as a WG member)



-----Original Message-----
From: Pce < <> > On Behalf Of Dhruv Dhody
Sent: Thursday, March 18, 2021 8:01 AM
To: <> 
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.


Speaking as a WG member...

Let's continue the discussion on considering the replication segment as an LSP v/s PCECC operation.

I just wanted to quickly recap -

- We have stateful operations for RSVP-TE: RFC 8231, RFC 8281
- We then introduced SR with a minimal extension of new PST and a new SR-ERO subobject: RFC 8664
- We supported P2MP stateful operations for RSVP-TE with RBNF change in PCEP messages: RFC 8623

We have always tried our best to maintain consistency between RSVP-TE and SR in PCEP.

Now, if one considers the Replication segment as an LSP operation, IMHO it needs to be built on RFC 8623 P2MP LSP operations. The current approach does not build on RFC 8623 instead uses the multi-path technique (related to ECMP in P2P [1]). This would deviate from RFC
8623 significantly.

On the other hand, considering the replication segment as a PCECC/CCI operation gives you more leeway to choose an encoding with a new CCI Object type for the replication segment and it could be independent of RFC 8623.

I *still* feel PCECC makes more sense at the higher level too (because of the additional instruction to the leaves and coordination required). Even if one disagrees with that and considers it an LSP operation, it then needs to build on RFC 8623. The current "mashup"
approach (i.e. it is an LSP operation but does not follow P2MP LSP
encoding) does not work well in maintaining consistency within our extensions.

Dhruv (as a WG member)

Pce mailing list <>
Pce mailing list <>