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

From: Dhruv Dhody <[email-masked]>
Date: Tue, 2 Mar 2021 11:01:08 +0530

Hi Homman,

Thank you for your email and further discussion. Speaking as a WG member....

On Mon, Mar 1, 2021 at 3:54 AM Bidgoli, Hooman (Nokia - CA/Ottawa)
<[email-masked]> wrote:
>
> Hi Dhruv
>
>
>
> As per draft-ietf-spring-sr-replication-segment, a replication segment allows a node (henceforth called as Replication Node) to replicate packets to a set of other nodes(called Downstream Nodes) or hosts in a Segment Routing Domain.
>
>
>
> A Replication segment can replicate a packet to directly connected nodes/hosts or to downstream nodes (without need for state on the transit routers). In some use cases replication segments can be stitch directly “Tree” or via a unicast segment routing domain “spraying”. In other use cases the replication segment can be a stand alone resource and act as a root and the leaf on the same node. In short a replication segment is a logical construct and behaves as a standalone resource, as an example it can be thought of as a binding SID on that particular node encoded via draft-ietf-pce-binding-label-sid
>
>
>
> This is why the authors on this draft feel a replication segment does not fit the PCE-CC Architecture Design, as each replication segment is really a head-end resource or a root that does a form of replication regardless if it plays the role classified as a root, bud or leaf to deliver a multicast service. As well, the authors view is that encoding the data in a CCI object does not add enhancements, however introduces further complexity with new identifiers to be used in message exchange, new object codepoint and capability allocations, when the existing proposal based on simply ERO encoding using already defined objects achieves the intended goals consistently regardless if one would consider the role a node plays in an overall tree.
>
>

If I understand correctly, the proposal is that each Replication
segment is packaged as an "LSP" at headend from the point of view of
PCEP. At the leaves, from the PCEP's view, a leaf node of a
replication segment could be considered as a headend of an LSP with
itself in the replication state.
This reminds me of the PCECC discussion for static LSP :); at that it
was said that the per-hop instruction along the path can be considered
as a 1-hop LSP. But instead of considering it an 1-hop LSP in PCEP
encodings, we created a new CCI Object. This was done because we had
PCECC-SR and other use cases in mind where the SR/SRv6 SID
allocation/distribution instruction were bit diffcult to be viewed as
an "LSP". The idea was that each PCECC usecase to create a new CCI
object-type when needed and maintain some consistency in the protocol.
This approach also helps to distinguish between the existing stateful
LSP operation with the headend and the PCECC operations.

I do not agree with the assertion that the Replication segment does
not fit with PCECC architecture. Looking at the figure
https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-02#section-4,
this looks like a typical PCECC operation, irrespective of the choice
of PCEP message encoding.

So IMHO, we should get more inputs from the WG and try to get an agreement on -
- Is the act of downloading the replication segment to the nodes
(including leaves), a PCECC operation or not?
- If yes, is it fine to take a different PCEP approach for this one
use-case deviating from the rest of the PCE WG output?

>
> In addition the concept of CCI object will create further complexity for the protection paths of the replication segment. The replication segment outgoing interfaces can be protected via a single protection ERO. The ERO object combined with draft-koldychev-pce-multipath will create the perfect solution for this.
>
>

Let's focus on the above discussion first. To me, the
procedure/information encoded is similar, only the object is
different. I fail to see how CCI+multipathERO cannot handle this use
case.

Hope the above discussion helps to make progress.

Thanks!
Dhruv

>
> In conclusion to repeats the original point since a replication segment is stand alone resource on each node (as an example a shared replication segment as per draft-ietf-pim-sr-p2mp-policy) with the function of providing a replication instruction on that node it really does not break the PCE-CC Architecture.
>
>
>
> I hope above clarifies the questions about PCE-CC decision.
>
>
>
> Thanks
>
>
>
> Hooman
>
>
>
>
>
>
>
> From: Dhruv Dhody <[email-masked]>
> Sent: Thursday, February 11, 2021 9:00 PM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
>
>
>
>
> Hi Hooman,
>
>
>
> On Fri, Feb 12, 2021 at 5:36 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]> wrote:
>
> [Dhruv]: I feel there is some misunderstanding here. The PCECC extensions defined a new object called CCI, with different object-types to be defined for various use-cases. There is common handling for all such instructions and it is defined once and can be reused across multiple use cases. I understand that you want to use the ERO object with multi-path, and that *is* fine, you could in fact easily define the RBNF in such a way that both CCI and ERO are included for the new CCI object type for SR-P2MP.
>
> Hi Dhruv
>
> I am not sure if I understand are you suggesting we include both CCI and ERO as an option and vendor chooses? What benefit does this have? How would this improve the interop?
>
> No, I did not say "or", it is not a choice!
>
>
> In PCEP when we communicate with the head-end we use Candidate Path as the unit of signaling (with Policy as an association). For programming instructions (and not paths) we use CCI Object. New CCI Object-type for each use case can be defined.
>
> I think your proposal to program the replication and leaf nodes as (section 3.4.2) -
>
>    <Common Header>
>    [<SRP>]
>    <LSP>
>    [<replication-sid>]
>    as described in [draft-sivabalan-pce-binding-label-sid]
>    [<ERO-Attributes Object>]
>    as per [draft-koldychev-pce-multipath]
>
> * RBNF is not correct, but I get the idea! I.e. you are signaling this as a path on the branches and leaves :(
>
> =
>
>
> What I suggested is that for programming the branch and leaf node, we should use CCI as a unit of signaling and you can include the ERO and PATH-ATTRIB along with the CCI. Note this is a new CCI Object-type and RBNF can be updated for it -
>
>    <Common Header>
>    <SRP>
>    [<LSP>] <- not included for shared case
>    <CCI> <- you can carry the replication-sid as TE-binding as a TLV here
>    [(<PATH-ATTRIB><ERO>)...] <- this is a list
>
> To Recap
> - you needed ERO and PATH-ATTRIB and you get that here!
> - the unit of signaling is a programming instruction and not a Path for the above case!
> - aligns with other use cases in PCEP
>
> Hope I am able to explain myself clearly and this helps!
>
> Thanks!
> Dhruv
>
>
>
>
>
> Thanks
> Hooman
>
> -----Original Message-----
> From: Dhruv Dhody <[email-masked]>
> Sent: Thursday, February 11, 2021 5:01 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi Hooman,
>
> Please see inline...
>
> On Tue, Feb 9, 2021 at 8:36 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]> wrote:
> >
> > Hi Dhruv
> >
> > Much appreciate your reply, Inline
> >
> > Thanks
> > Hooman
> >
> >
> > -----Original Message-----
> > From: Dhruv Dhody <[email-masked]>
> > Sent: Tuesday, February 9, 2021 5:28 AM
> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
> >
> > Hi Hooman,
> >
> > Apologies! Missed replying to this email...
> >
> > On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]> wrote:
> > >
> > > Dear Chairs
> > >
> > >
> > >
> > > Looking at the wiki page there was a comment on the sr-p2mp-policy draft.
> > >
> > >
> > >
> > > draft-hsd-pce-sr-p2mp-policy
> > >
> > > 109; More work is needed - align to PCECC, text needs to aligned to
> > > the PCE WG style
> > >
> > >
> > >
> > > The authors took an action to setup a meeting and discuss the alignment with PCECC farther. The final outcome of this meeting was unanimous agreement, by all the authors/vendors on the draft, to go forward with ERO object.
> > >
> > >
> >
> > As an individual I-D, it is up to the co-authors to decide the content of the I-D.
> >
> > The comment (and earlier discussions) was to make sure we maintain consistency across all our documents that we produce. RFC 8283 describes the PCECC architecture, where the PCE needs to interact with not only the head-end routers (the usual stateful/stateless PCE case) but also with the egress and the internal P routers. The WG has just sent the first PCECC extension for MPLS label allocation along the path to the IESG. For other use cases such as SR/SRv6 SID allocation as well as for the branch node in the P2MP LSP and Native-IP, all are under the PCECC umbrella. So far all use cases where the PCE needs to interact with other nodes beyond the ingress and provide instructions to them are using PCECC architecture.
> >
> > So when the PCE is interacting with the head end for SR P2MP Policy, it can use the usual stateful PCE extensions but when the PCE is interacting with the branch nodes and leaf nodes for replication segment, we strongly feel it should be described under the PCECC architecture. So you could use the ERO object for encoding the full P2MP path (and SR P2MP Policy) when interacting with the root node.
> > But when interacting with other nodes, use the PCECC technique i.e. a new CCI object type (which could be used with the ERO if needed). This would help you to not reinvent things as well as maintain consistency.
> > To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5 only and not the whole document. If you still disagree please list the technical reason why so that the WG can evaluate them.
> >
> > HB> As I am sure you do appreciate there are many ways to skin the cat. TreeSID can be connected via unicast SR path and not every node needs to be programmed. In addition as explained the PCECC did not provide the with flexibility to configure backup/fast reroute paths and the current methods does provide that capability.
> > Again as mentioned we looked at PCECC very hard and tried to implement treeSID via this method but there were major short comings for backup and FRR paths.
> > There are multiple implementation in the field that is using the ERO object for treeSID with success.
> > Are the chairs suggesting that the working group is only dictating PCECC and is not open to any other option but PCECC for the purpose of programming the PCC and multicast?
> > We have been asking for adaptation since 3 IETF ago and we keep getting pushback because our implementation does not follow the PCECC, why is PCECC the only choice on the table? Why isn't the working group open to other options to solve the multicast requirements? Given the fact that the ERO has been implemented and is in the field and in multiple providers labs being tested with successful outcome, I think the WG should have a open view to this implantation. Especially when multiple vendors and providers (Cisco, Juniper, Nokia, Ciena, Bell Canada) to name a few have agreed to this implementation.
> >
> >
>
> [Dhruv]: I feel there is some misunderstanding here. The PCECC extensions defined a new object called CCI, with different object-types to be defined for various use-cases. There is common handling for all such instructions and it is defined once and can be reused across multiple use cases. I understand that you want to use the ERO object with multi-path, and that *is* fine, you could in fact easily define the RBNF in such a way that both CCI and ERO are included for the new CCI object type for SR-P2MP.
>
> Thanks!
> Dhruv
>
> > >
> > > The authors feel ERO object in addition to draft-koldychev-pce-multipath-04 - PCEP Extensions for Signaling Multipath Information (ietf.org) for backup paths is the easiest and the most efficient way to address the programming of a replication segment on PCC from to the PCE.
> > >
> > >
> > >
> > > The authors would like to move forward with the adaptation call please. In addition the authors are open to discuss the ERO preference in an interim open session with the chairs.
> > >
> > >
> >
> > The document has not been updated after 109, last we discussed this, we found that the document needed more work because it does not follow the way the PCEP extensions are usually defined. It follows a very unusual format (e.g. section 5) at places. It is good to provide examples but suggest it be done in a way that is more readable. Please follow the RBNF notations when specifying PCEP message changes (in a backward-compatible way). Some of your co-authors have vast experience in writing documents in this WG, I suggest taking their help. Hopefully, a more readable version will help you get more reviews.
> >
> > HB> sure this is cosmetics and we will follow the WG suggestion, that said this should not stop the adaptation call. The sooner we have adaptation call the sooner we can have input.
> >
> > HB> to close, as you mentioned some of the co-authors have vast experience in PCE WG and the same co-authors have agreed and recommended ERO implementation. As such I ask the chairs for adaptation call again ASAP. We will fix the cosmetics to be inline with WG recommendations asap.
> >
> >
> >
> > Hope this helps, and again accept our apologies for missing replying to this email earlier.
> >
> > Thanks!
> > Dhruv & Julien
> >
> > >
> > > Regards
> > >
> > > Hooman
> > >
> > >
> > >
> > >
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 2 Mar 2021 13:18:10 +0000

Hi Dhruv

I do not agree with the assertion that the Replication segment does not fit with PCECC architecture. Looking at the figure https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-02#section-4,
this looks like a typical PCECC operation, irrespective of the choice of PCEP message encoding.

HB> you keep looking at a single use case of replication policy which is "TREE" and most of your argument is using the tree to justify a replication segment fits the PCECC. Where the replication segment has many other use cases as explained below. Spray, stand-alone replication segment etc... In fact even a "Tree" can be setup via a replication segment at needed nodes and unicast SR policy stitching those replication segments many hops away.
Quoting from the PCE-CC draft "Thus, the LSP can be calculate/set up/initiated". Obviously the PCE-CC is for a continues LSP.
Replication segment doesn't need any computation, it has an incoming interface and a set of outgoing interface. It can be shared by multiple services. It can be setup at a strategic replication node to replicate a unicast flow "LSP" to a set of out going unicast flow. It is a resource. No where in the PCE-CC draft I can read that PCE-CC should be used for single resource or SID in the network. 
Quoting again from the PCE-CC draft " where LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path."  Replication segment concept is not end-to-end as the authors keep pointing out. Even in the case of the "TREE" the replication segment is not end-to-end. It is only used were the replication is needed. As an example through out the unicast path. 

HB> To give you a bit of history that might help you, at beginning the segment was the "TREE" it self. The SID represented the entire "TREE". End-to-end "TREE". We deviated from this simply because we understood the benefits of being able to program a single replication resource on a strategic node, that can replicate any arriving packet to a set of outgoing interface. As long as the resource is identified and the traffic is steered into this resource, it does its job and replicates.  How this resource is used is up to the service/application. As an example BGP could only program this resource on strategic nodes on a unicast path. As such this resource is not end-to-end.

So IMHO, we should get more inputs from the WG and try to get an agreement on -
- Is the act of downloading the replication segment to the nodes (including leaves), a PCECC operation or not?
- If yes, is it fine to take a different PCEP approach for this one use-case deviating from the rest of the PCE WG output?

HB> For sure the authors are open for discussion, keeping the facts above in mind. We are not trying to deviate as mentioned, we just don't see the replication SID breaking the PCE-CC architecture as it doesn't fit into that end-to-end architecture. 

Regards

Hooman 

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Tuesday, March 2, 2021 12:31 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Homman,

On Mon, Mar 1, 2021 at 3:54 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]> wrote:
> A Replication segment can replicate a packet to directly connected 
> nodes/hosts or to downstream nodes (without need for state on the 
> transit routers). In some use cases replication segments can be stitch 
> directly “Tree” or via a unicast segment routing domain “spraying”. In 
> other use cases the replication segment can be a stand alone resource 
> and act as a root and the leaf on the same node. In short a 
> replication segment is a logical construct and behaves as a standalone 
> resource, as an example it can be thought of as a binding SID on that 
> particular node encoded via draft-ietf-pce-binding-label-sid
>
>
>

If I understand correctly, the proposal is that each Replication segment is packaged as an "LSP" at headend from the point of view of PCEP. At the leaves, from the PCEP's view, a leaf node of a replication segment could be considered as a headend of an LSP with itself in the replication state.
This reminds me of the PCECC discussion for static LSP :); at that it was said that the per-hop instruction along the path can be considered as a 1-hop LSP. But instead of considering it an 1-hop LSP in PCEP encodings, we created a new CCI Object. This was done because we had PCECC-SR and other use cases in mind where the SR/SRv6 SID allocation/distribution instruction were bit diffcult to be viewed as an "LSP". The idea was that each PCECC usecase to create a new CCI object-type when needed and maintain some consistency in the protocol.
This approach also helps to distinguish between the existing stateful LSP operation with the headend and the PCECC operations.

I do not agree with the assertion that the Replication segment does not fit with PCECC architecture. Looking at the figure https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-02#section-4,
this looks like a typical PCECC operation, irrespective of the choice of PCEP message encoding.

So IMHO, we should get more inputs from the WG and try to get an agreement on -
- Is the act of downloading the replication segment to the nodes (including leaves), a PCECC operation or not?
- If yes, is it fine to take a different PCEP approach for this one use-case deviating from the rest of the PCE WG output?

> In addition the concept of CCI object will create further complexity for the protection paths of the replication segment. The replication segment outgoing interfaces can be protected via a single p…

Let's focus on the above discussion first. To me, the procedure/information encoded is similar, only the object is different. I fail to see how CCI+multipathERO cannot handle this use case.

Thanks!
Dhruv

> What I suggested is that for programming the branch and leaf node, we 
> should use CCI as a unit of signaling and you can include the ERO and 
> PATH-ATTRIB along with the CCI. Note this is a new CCI Object-type and 
> RBNF can be updated for it -
>
>    <Common Header>
>    <SRP>
> > > 109; More work is needed - align to PCECC, text needs to aligned 
> > > to the PCE WG style
> > >
> > >
> > >

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 3 Mar 2021 15:24:00 +0530

Hi Hooman,

Based on quotes, I think you might be looking at
draft-ietf-pce-pcep-extension-for-pce-controller [1] ONLY which is
about provisioning labels along the path of a static LSP.

There are actually some other work in the WG in this space -
1) SR and SRv6 SID allocation and distribution [2][3]
2) Native IP [4]
3) Static P2MP LSP [5]
4) BIER [6]

And the related usecases discussion in RFC 8283 [7].

Thus the statement "Obviously the PCE-CC is for a continues LSP", "No
where in the PCE-CC draft I can read that PCE-CC should be used for
single resource or SID in the network." are not true. See [2] and [3].

I agree with your description of the replication segment. But we
arrive at a different conclusion on the applicability of PCECC :). The
difference in view could be because we are looking at the scope of
PCECC differently (beyond [1]) as well as where we draw the line
between a stateful and a PCECC operation.

This is a good discussion. I hope this helps us (as a WG) to make an
informed decision on the questions in the previous post!

Thanks!
Dhruv (as a WG participant)

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
[2] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-pce-controller-sr/
[3] https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/
[4] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
[5] https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-p2mp/
[6] https://datatracker.ietf.org/doc/draft-chen-pce-pcep-extension-pce-controller-bier/
[7] https://www.rfc-editor.org/rfc/rfc8283.html

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 3 Mar 2021 13:01:59 +0000

Hi Dhruv

I don't think we are arguing against the usefulness of PCECC 😊 I am sure all of these other draft have leveraged "TECHNICALLY" from PCECC 

We are asking what is the advantage of wrapping an ERO object in CCI object? Technically we find managing the CCI objects and IDs cumbersome for replication segment and not necessary. 
And until now we have "NOT" heard a "SINGLE" technical argument what the advantage is. As per our call with yourself (thank you for taking time), you mentioned that the only point is the need for us to be in PCECC architecture, because of working group mandate/decision that was made while back, even if it doesn't bring any technical advantages to the solution. 

In addition we are blocked from an adaptation call 😉 

So far we have heard from yourself only and I think we hear clearly were you stand 😊 We have not heard from any other member of WG that why we should use CCI object.

If the working group consensus is that the PCECC (CCI Object) is a must, even if there is no technical reasons behind it, then it is what it is. 

How do we proceed? Do we want to do a adaptation call maybe that will make other members more vocal? 

Regards
Hooman

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Wednesday, March 3, 2021 4:54 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Based on quotes, I think you might be looking at draft-ietf-pce-pcep-extension-for-pce-controller [1] ONLY which is about provisioning labels along the path of a static LSP.

Thus the statement "Obviously the PCE-CC is for a continues LSP", "No where in the PCE-CC draft I can read that PCE-CC should be used for single resource or SID in the network." are not true. See [2] and [3].

I agree with your description of the replication segment. But we arrive at a different conclusion on the applicability of PCECC :). The difference in view could be because we are looking at the scope of PCECC differently (beyond [1]) as well as where we draw the line between a stateful and a PCECC operation.

This is a good discussion. I hope this helps us (as a WG) to make an informed decision on the questions in the previous post!

Thanks!

On Tue, Mar 2, 2021 at 6:48 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]> wrote:
> https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-02
> #section-4, this looks like a typical PCECC operation, irrespective of 
> the choice of PCEP message encoding.
>
> > transit routers). In some use cases replication segments can be 
> > stitch directly “Tree” or via a unicast segment routing domain 
> > “spraying”. In other use cases the replication segment can be a 
> > stand alone resource and act as a root and the leaf on the same 
> > node. In short a replication segment is a logical construct and 
> > behaves as a standalone resource, as an example it can be thought of 
> > as a binding SID on that particular node encoded via 
> > draft-ietf-pce-binding-label-sid
> >
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-02
> #section-4, this looks like a typical PCECC operation, irrespective of 
> the choice of PCEP message encoding.
>
> > * RBNF is not correct, but I get the idea! I.e. you are signaling 
> > this as a path on the branches and leaves :(
> >
> > =
> >
> >
> > What I suggested is that for programming the branch and leaf node, 
> > we should use CCI as a unit of signaling and you can include the ERO 
> > and PATH-ATTRIB along with the CCI. Note this is a new CCI 
> > Object-type and RBNF can be updated for it -
> >
> >    <Common Header>
> >    <SRP>

---

From: Tarek Saad <[email-masked]>
Date: Wed, 3 Mar 2021 21:55:05 +0000

Hi Dhuruv/WG,

From the RBNFs below (extracted from the bottom of this email), the difference I see between the 2 proposals is that the PCE-CC approach requires a new P2MP CCI object just to carry the resplication-sid  (which can already be carried today w/mechanisms in [draft-ietf-pce-binding-label-sid without the CCI].
Yes, both proposals I presume would work to signal the replication-segment. However, IMO, we need not mandate an approach (especially that the difference below is minimal and most vendors already have support for the “current” proposal). Let me know, and apologies if I misunderstood the proposals below.

Current:
   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>] as described in [draft-sivabalan-pce-binding-label-sid]
 [(<PATH-ATTRIB><ERO>)...]

CCI-Object:
   <Common Header>
   <SRP>

To Recap
<<

Regards,
Tarek

On 2/28/21, 5:24 PM, "Pce on behalf of Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Dhruv

Thanks

Hooman

Hi Hooman,

On Fri, Feb 12, 2021 at 5:36 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
[Dhruv]: I feel there is some misunderstanding here. The PCECC extensions defined a new object called CCI, with different object-types to be defined for various use-cases. There is common handling for all such instructions and it is defined once and can be reused across multiple use cases. I understand that you want to use the ERO object with multi-path, and that *is* fine, you could in fact easily define the RBNF in such a way that both CCI and ERO are included for the new CCI object type for SR-P2MP.

Hi Dhruv

   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>]

   <Common Header>
   <SRP>

To Recap

Thanks!
Dhruv

Thanks
Hooman

-----Original Message-----
From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 11, 2021 5:01 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Please see inline...

On Tue, Feb 9, 2021 at 8:36 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Dear Chairs
> >
> >
> >

Thanks!
Dhruv

> >
> > The authors feel ERO object in addition to draft-koldychev-pce-multipath-04 - PCEP Extensions for Signaling Multipath Information (ietf.org<http://ietf.org>) for backup paths is the easiest and the most efficient way to address the programming of a replication segment on PCC from to the PCE.
> >
> >
> >

Juniper Business Use Only

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 5 Mar 2021 09:34:50 +0530

Hi Hooman,

On Wed, Mar 3, 2021 at 6:32 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi Dhruv
>
> I don't think we are arguing against the usefulness of PCECC 😊 I am sure
> all of these other draft have leveraged "TECHNICALLY" from PCECC
>
> We are asking what is the advantage of wrapping an ERO object in CCI
> object? Technically we find managing the CCI objects and IDs cumbersome for
> replication segment and not necessary.
> And until now we have "NOT" heard a "SINGLE" technical argument what the
> advantage is. As per our call with yourself (thank you for taking time),
> you mentioned that the only point is the need for us to be in PCECC
> architecture, because of working group mandate/decision that was made while
> back, even if it doesn't bring any technical advantages to the solution.
>
>
I wanted to focus on the question - "Is the act of downloading a
replication segment to the replication node AND the leaves, a PCECC
operation or a stateful operation?". We can discuss encoding once we have
this settled.

I disagree with the above characterization. But let's leave it at
that.  Let's continue the discussion on the key question.

> In addition we are blocked from an adaptation call 😉
See Julien's response -
https://mailarchive.ietf.org/arch/msg/pce/Vimr_-zn3DjpW2uY8A-hFpZXJg4/

> So far we have heard from yourself only and I think we hear clearly were
> you stand 😊 We have not heard from any other member of WG that why we
> should use CCI object.
>
>
I agree, lets give time for others to chime in, a week before IETF is a
busy time :)

Thanks!
Dhruv

> If the working group consensus is that the PCECC (CCI Object) is a must,
> even if there is no technical reasons behind it, then it is what it is.
>
> draft-ietf-pce-pcep-extension-for-pce-controller [1] ONLY which is about
> provisioning labels along the path of a static LSP.
>
> where in the PCE-CC draft I can read that PCE-CC should be used for single
> resource or SID in the network." are not true. See [2] and [3].
>
> I agree with your description of the replication segment. But we arrive at
> a different conclusion on the applicability of PCECC :). The difference in
> view could be because we are looking at the scope of PCECC differently
> (beyond [1]) as well as where we draw the line between a stateful and a
> PCECC operation.
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
> [2]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-pce-controller-sr/
> [3]
> https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/
> [4]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
> [5]
> https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-p2mp/
> [6]
> https://datatracker.ietf.org/doc/draft-chen-pce-pcep-extension-pce-controller-bier/
> > HB> you keep looking at a single use case of replication policy which is
> "TREE" and most of your argument is using the tree to justify a replication
> segment fits the PCECC. Where the replication segment has many other use
> cases as explained below. Spray, stand-alone replication segment etc... In
> fact even a "Tree" can be setup via a replication segment at needed nodes
> and unicast SR policy stitching those replication segments many hops away.
> > Quoting from the PCE-CC draft "Thus, the LSP can be calculate/set
> up/initiated". Obviously the PCE-CC is for a continues LSP.
> > Replication segment doesn't need any computation, it has an incoming
> interface and a set of outgoing interface. It can be shared by multiple
> services. It can be setup at a strategic replication node to replicate a
> unicast flow "LSP" to a set of out going unicast flow. It is a resource. No
> where in the PCE-CC draft I can read that PCE-CC should be used for single
> resource or SID in the network.
> > Quoting again from the PCE-CC draft " where LSPs can be provisioned as
> explicit label instructions at each hop on the end-to-end path."
> Replication segment concept is not end-to-end as the authors keep pointing
> out. Even in the case of the "TREE" the replication segment is not
> end-to-end. It is only used were the replication is needed. As an example
> through out the unicast path.
> >
> > HB> To give you a bit of history that might help you, at beginning the
> segment was the "TREE" it self. The SID represented the entire "TREE".
> End-to-end "TREE". We deviated from this simply because we understood the
> benefits of being able to program a single replication resource on a
> strategic node, that can replicate any arriving packet to a set of outgoing
> interface. As long as the resource is identified and the traffic is steered
> into this resource, it does its job and replicates.  How this resource is
> used is up to the service/application. As an example BGP could only program
> this resource on strategic nodes on a unicast path. As such this resource
> is not end-to-end.
> >
> > HB> For sure the authors are open for discussion, keeping the facts
> above in mind. We are not trying to deviate as mentioned, we just don't see
> the replication SID breaking the PCE-CC architecture as it doesn't fit into
> that end-to-end architecture.
> >
> > Regards
> >
> > Hooman
> >
> > > As per draft-ietf-spring-sr-replication-segment, a replication segment
> allows a node (henceforth called as Replication Node) to replicate packets
> to a set of other nodes(called Downstream Nodes) or hosts in a Segment
> Routing Domain.
> > >
> > >
> > >
> > > This is why the authors on this draft feel a replication segment does
> not fit the PCE-CC Architecture Design, as each replication segment is
> really a head-end resource or a root that does a form of replication
> regardless if it plays the role classified as a root, bud or leaf to
> deliver a multicast service. As well, the authors view is that encoding the
> data in a CCI object does not add enhancements, however introduces further
> complexity with new identifiers to be used in message exchange, new object
> codepoint and capability allocations, when the existing proposal based on
> simply ERO encoding using already defined objects achieves the intended
> goals consistently regardless if one would consider the role a node plays
> in an overall tree.
> > >
> > >
> >
> > If I understand correctly, the proposal is that each Replication segment
> is packaged as an "LSP" at headend from the point of view of PCEP. At the
> leaves, from the PCEP's view, a leaf node of a replication segment could be
> considered as a headend of an LSP with itself in the replication state.
> was said that the per-hop instruction along the path can be considered as a
> 1-hop LSP. But instead of considering it an 1-hop LSP in PCEP encodings, we
> created a new CCI Object. This was done because we had PCECC-SR and other
> use cases in mind where the SR/SRv6 SID allocation/distribution instruction
> were bit diffcult to be viewed as an "LSP". The idea was that each PCECC
> usecase to create a new CCI object-type when needed and maintain some
> consistency in the protocol.
> > > In addition the concept of CCI object will create further complexity
> for the protection paths of the replication segment. The replication
> segment outgoing interfaces can be protected via a single protection ERO.
> The ERO object combined with draft-koldychev-pce-multipath will create the
> perfect solution for this.
> > >
> > >
> >
> procedure/information encoded is similar, only the object is different. I
> fail to see how CCI+multipathERO cannot handle this use case.
> >
> > > In conclusion to repeats the original point since a replication
> segment is stand alone resource on each node (as an example a shared
> replication segment as per draft-ietf-pim-sr-p2mp-policy) with the function
> of providing a replication instruction on that node it really does not
> break the PCE-CC Architecture.
> > >
> > >
> > >
> > > [Dhruv]: I feel there is some misunderstanding here. The PCECC
> extensions defined a new object called CCI, with different object-types to
> be defined for various use-cases. There is common handling for all such
> instructions and it is defined once and can be reused across multiple use
> cases. I understand that you want to use the ERO object with multi-path,
> and that *is* fine, you could in fact easily define the RBNF in such a way
> that both CCI and ERO are included for the new CCI object type for SR-P2MP.
> > >
> > > Hi Dhruv
> > >
> > > I am not sure if I understand are you suggesting we include both CCI
> and ERO as an option and vendor chooses? What benefit does this have? How
> would this improve the interop?
> > >
> > > In PCEP when we communicate with the head-end we use Candidate Path as
> the unit of signaling (with Policy as an association). For programming
> instructions (and not paths) we use CCI Object. New CCI Object-type for
> each use case can be defined.
> > >
> > > > > The authors took an action to setup a meeting and discuss the
> alignment with PCECC farther. The final outcome of this meeting was
> unanimous agreement, by all the authors/vendors on the draft, to go forward
> with ERO object.
> > > > >
> > > > >
> > > >
> > > > The comment (and earlier discussions) was to make sure we maintain
> consistency across all our documents that we produce. RFC 8283 describes
> the PCECC architecture, where the PCE needs to interact with not only the
> head-end routers (the usual stateful/stateless PCE case) but also with the
> egress and the internal P routers. The WG has just sent the first PCECC
> extension for MPLS label allocation along the path to the IESG. For other
> use cases such as SR/SRv6 SID allocation as well as for the branch node in
> the P2MP LSP and Native-IP, all are under the PCECC umbrella. So far all
> use cases where the PCE needs to interact with other nodes beyond the
> ingress and provide instructions to them are using PCECC architecture.
> > > >
> > > > So when the PCE is interacting with the head end for SR P2MP Policy,
> it can use the usual stateful PCE extensions but when the PCE is
> interacting with the branch nodes and leaf nodes for replication segment,
> we strongly feel it should be described under the PCECC architecture. So
> you could use the ERO object for encoding the full P2MP path (and SR P2MP
> Policy) when interacting with the root node.
> > > > But when interacting with other nodes, use the PCECC technique i.e.
> a new CCI object type (which could be used with the ERO if needed). This
> would help you to not reinvent things as well as maintain consistency.
> > > > To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5
> only and not the whole document. If you still disagree please list the
> technical reason why so that the WG can evaluate them.
> > > >
> > > > HB> As I am sure you do appreciate there are many ways to skin the
> cat. TreeSID can be connected via unicast SR path and not every node needs
> to be programmed. In addition as explained the PCECC did not provide the
> with flexibility to configure backup/fast reroute paths and the current
> methods does provide that capability.
> > > > Again as mentioned we looked at PCECC very hard and tried to
> implement treeSID via this method but there were major short comings for
> backup and FRR paths.
> > > > Are the chairs suggesting that the working group is only dictating
> PCECC and is not open to any other option but PCECC for the purpose of
> programming the PCC and multicast?
> > > > We have been asking for adaptation since 3 IETF ago and we keep
> getting pushback because our implementation does not follow the PCECC, why
> is PCECC the only choice on the table? Why isn't the working group open to
> other options to solve the multicast requirements? Given the fact that the
> ERO has been implemented and is in the field and in multiple providers labs
> being tested with successful outcome, I think the WG should have a open
> view to this implantation. Especially when multiple vendors and providers
> (Cisco, Juniper, Nokia, Ciena, Bell Canada) to name a few have agreed to
> this implementation.
> > > >
> > > >
> > >
> > > [Dhruv]: I feel there is some misunderstanding here. The PCECC
> extensions defined a new object called CCI, with different object-types to
> be defined for various use-cases. There is common handling for all such
> instructions and it is defined once and can be reused across multiple use
> cases. I understand that you want to use the ERO object with multi-path,
> and that *is* fine, you could in fact easily define the RBNF in such a way
> that both CCI and ERO are included for the new CCI object type for SR-P2MP.
> > >
> > > Thanks!
> > > Dhruv
> > >
> > > > >
> > > > > The authors feel ERO object in addition to
> draft-koldychev-pce-multipath-04 - PCEP Extensions for Signaling Multipath
> Information (ietf.org) for backup paths is the easiest and the most
> efficient way to address the programming of a replication segment on PCC
> from to the PCE.
> > > > >
> > > > >
> > > > >
> > > > > The authors would like to move forward with the adaptation call
> please. In addition the authors are open to discuss the ERO preference in
> an interim open session with the chairs.
> > > > >
> > > > >
> > > >
> > > > The document has not been updated after 109, last we discussed this,
> we found that the document needed more work because it does not follow the
> way the PCEP extensions are usually defined. It follows a very unusual
> format (e.g. section 5) at places. It is good to provide examples but
> suggest it be done in a way that is more readable. Please follow the RBNF
> notations when specifying PCEP message changes (in a backward-compatible
> way). Some of your co-authors have vast experience in writing documents in
> this WG, I suggest taking their help. Hopefully, a more readable version
> will help you get more reviews.
> > > >
> > > > HB> sure this is cosmetics and we will follow the WG suggestion,
> that said this should not stop the adaptation call. The sooner we have
> adaptation call the sooner we can have input.
> > > >
> > > > HB> to close, as you mentioned some of the co-authors have vast
> experience in PCE WG and the same co-authors have agreed and recommended
> ERO implementation. As such I ask the chairs for adaptation call again
> ASAP. We will fix the cosmetics to be inline with WG recommendations asap.
> > > >
> > > >
> > > >

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 5 Mar 2021 09:36:57 +0530

Hi Tarek,

Thanks for your message.

As I said to Hooman, the key is for WG to figure out if the act of
downloading the replication segment is considered a PCECC operation or a
regular stateful operation.

Since the replication segment state needs to be programmed on the leaves
and the replication node; plus coordination is needed for SID/labels
across these instructions. I lean towards PCECC.

And the argument for using CCI for PCECC operations is consistency and the
ability to reuse concepts already defined. When an implementation supports
multiple of these PCECC use cases, there will be consistency in
implementation. But this is not written in stone and if the WG decides
otherwise then that's that!

Thanks!
Dhruv

On Thu, Mar 4, 2021 at 3:25 AM Tarek Saad <tsaad=
[email-masked]> wrote:

> Hi Dhuruv/WG,
>
>
>
> From the RBNFs below (extracted from the bottom of this email), the
> difference I see between the 2 proposals is that the PCE-CC approach
> requires a new P2MP CCI object just to carry the resplication-sid  (which
> can already be carried today w/mechanisms in
> [draft-ietf-pce-binding-label-sid without the CCI].
>
> Yes, both proposals I presume would work to signal the
> replication-segment. However, IMO, we need not mandate an approach
> (especially that the difference below is minimal and most vendors already
> have support for the “current” proposal). Let me know, and apologies if I
> misunderstood the proposals below.
>
>
>
> >>
>
> *Current:*
>
>    <Common Header>
>    [<SRP>]
>    <LSP>
> *CCI-Object:*
> On 2/28/21, 5:24 PM, "Pce on behalf of Bidgoli, Hooman (Nokia -
> CA/Ottawa)" <[email-masked] on behalf of [email-masked]>
> wrote:
>
>
>
> Hi Dhruv
>
>
>
> *As per draft-ietf-spring-sr-replication-segment, a replication segment
> Routing Domain. *
> *A Replication segment can replicate a packet to directly connected
> nodes/hosts or to downstream nodes (without need for state on the transit
> routers). In some use cases replication segments can be stitch directly
> “Tree” or via a unicast segment routing domain “spraying”. In other use
> cases the replication segment can be a stand alone resource and act as a
> root and the leaf on the same node. In short a replication segment is a
> logical construct and behaves as a standalone resource, as an example it
> can be thought of as a binding SID on that particular node encoded via
> draft-ietf-pce-binding-label-sid*
>
>
>
> *This is why the authors on this draft feel a replication segment does not
> fit the PCE-CC Architecture Design, as each replication segment is really a
> head-end resource or a root that does a form of replication regardless if
> it plays the role classified as a root, bud or leaf to deliver a multicast
> service. As well, the authors view is that encoding the data in a CCI
> object does not add enhancements, however introduces further complexity
> with new identifiers to be used in message exchange, new object codepoint
> and capability allocations, when the existing proposal based on simply ERO
> encoding using already defined objects achieves the intended goals
> consistently regardless if one would consider the role a node plays in an
> overall tree. *
>
>
>
> *In addition the concept of CCI object will create further complexity for
> the protection paths of the replication segment. The replication segment
> outgoing interfaces can be protected via a single protection ERO. The ERO
> object combined with draft-koldychev-pce-multipath will create the perfect
> solution for this. *
>
>
>
> *In conclusion to repeats the original point since a replication segment
> is stand alone resource on each node (as an example a shared replication
> segment as per draft-ietf-pim-sr-p2mp-policy) with the function of
> providing a replication instruction on that node it really does not break
> the PCE-CC Architecture.*
>
>
>
> *I hope above clarifies the questions about PCE-CC decision.*
>
>
>
> *Thanks*
>
>
>
> *Hooman*
>
>
>
>
>
>
>
> *From:* Dhruv Dhody <[email-masked]>
> *Sent:* Thursday, February 11, 2021 9:00 PM
> *To:* Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
>
>
>
>
> Hi Hooman,
>
>
>
> [Dhruv]: I feel there is some misunderstanding here. The PCECC extensions
> defined a new object called CCI, with different object-types to be defined
> for various use-cases. There is common handling for all such instructions
> and it is defined once and can be reused across multiple use cases. I
> understand that you want to use the ERO object with multi-path, and that
> *is* fine, you could in fact easily define the RBNF in such a way that both
> CCI and ERO are included for the new CCI object type for SR-P2MP.
>
> Hi Dhruv
>
> I am not sure if I understand are you suggesting we include both CCI and
> ERO as an option and vendor chooses? What benefit does this have? How would
> this improve the interop?
>
> In PCEP when we communicate with the head-end we use Candidate Path as the unit
> of signaling (with Policy as an association). For programming
> PATH-ATTRIB along with the CCI. Note this is a new CCI Object-type and RBNF
> can be updated for it -
>
>    <Common Header>
>    <SRP>
> > So when the PCE is interacting with the head end for SR P2MP Policy, it
> can use the usual stateful PCE extensions but when the PCE is interacting
> with the branch nodes and leaf nodes for replication segment, we strongly
> feel it should be described under the PCECC architecture. So you could use
> the ERO object for encoding the full P2MP path (and SR P2MP Policy) when
> interacting with the root node.
> > But when interacting with other nodes, use the PCECC technique i.e. a
> new CCI object type (which could be used with the ERO if needed). This
> > To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5 only
> and not the whole document. If you still disagree please list the technical
> reason why so that the WG can evaluate them.
> >
> > HB> As I am sure you do appreciate there are many ways to skin the cat.
> TreeSID can be connected via unicast SR path and not every node needs to be
> programmed. In addition as explained the PCECC did not provide the with
> flexibility to configure backup/fast reroute paths and the current methods
> does provide that capability.
> > Again as mentioned we looked at PCECC very hard and tried to implement
> treeSID via this method but there were major short comings for backup and
> FRR paths.
> > Are the chairs suggesting that the working group is only dictating PCECC
> and is not open to any other option but PCECC for the purpose of
> > We have been asking for adaptation since 3 IETF ago and we keep getting
> pushback because our implementation does not follow the PCECC, why is PCECC
> the only choice on the table? Why isn't the working group open to other
> options to solve the multicast requirements? Given the fact that the ERO
> has been implemented and is in the field and in multiple providers labs
> [Dhruv]: I feel there is some misunderstanding here. The PCECC extensions
> defined a new object called CCI, with different object-types to be defined
> for various use-cases. There is common handling for all such instructions
> and it is defined once and can be reused across multiple use cases. I
> understand that you want to use the ERO object with multi-path, and that
> *is* fine, you could in fact easily define the RBNF in such a way that both
> CCI and ERO are included for the new CCI object type for SR-P2MP.
>
> Thanks!
> Dhruv
>
> > >
> > The document has not been updated after 109, last we discussed this, we
> found that the document needed more work because it does not follow the way
> the PCEP extensions are usually defined. It follows a very unusual format
> (e.g. section 5) at places. It is good to provide examples but suggest it
> be done in a way that is more readable. Please follow the RBNF notations
> when specifying PCEP message changes (in a backward-compatible way). Some
> of your co-authors have vast experience in writing documents in this WG, I
> suggest taking their help. Hopefully, a more readable version will help you
> get more reviews.
> >
> > HB> sure this is cosmetics and we will follow the WG suggestion, that
> said this should not stop the adaptation call. The sooner we have

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 5 Mar 2021 17:30:13 +0000

Hi Dhruv,

"figure out if the act of downloading the replication segment is considered a PCECC operation or a regular stateful operation"

Could you expand on how you see the fundamental difference of PCECC operation vs regular stateful? Or correct the following statements if incorrect or missing something (?):

        PCECC : Explicit incoming/outgoing instructions on each hop end to end for a LSP that is sourced at a headend

       Regular Stateful: Explicit outgoing instruction(s) on a headend where binding label could be used to help steer into that head end

The view I have of replication segment is it has a “family relation” to the unicast SR Policy, and specifically it’s usage of binding label and egress label stack. Key difference of course that replicating packets vs weighted ecmp egress forwarding. PCE can deploy a unicast SR Policy with the intention of using it on that targeted headend or even as a transit for an upstream headend to achieve label stack reduction. A replication segment has the same philosophy with the exception that a replication segment can be encoded to indicate if it's shared or tied to a specific tree. Important encodings (binding label, multi-path ero) are being leveraged from objects being delivered in the unicast use case. I do consider leveraging these same encodings and mechanisms consistent between unicast and replication segment, and also consistent whether it’s a root, bud or leaf - without having to define new and reusing the concepts defined in those related docs. Yes, PCECC defines similar concepts and objects but appears to me like we’d have to define more-new things to leverage it and have replication segment deviate from its unicast relative and in return it would be picking only a very small part of what PCECC is accomplishing.

Thanks
Andrew

From: Pce <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Date: Thursday, March 4, 2021 at 11:08 PM
To: Tarek Saad <tsaad=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Tarek,

Thanks for your message.

As I said to Hooman, the key is for WG to figure out if the act of downloading the replication segment is considered a PCECC operation or a regular stateful operation.

Since the replication segment state needs to be programmed on the leaves and the replication node; plus coordination is needed for SID/labels across these instructions. I lean towards PCECC.

And the argument for using CCI for PCECC operations is consistency and the ability to reuse concepts already defined. When an implementation supports multiple of these PCECC use cases, there will be consistency in implementation. But this is not written in stone and if the WG decides otherwise then that's that!

Thanks!
Dhruv

On Thu, Mar 4, 2021 at 3:25 AM Tarek Saad <tsaad=[email-masked]<mailto:[email-masked]>> wrote:
Hi Dhuruv/WG,

Current:
   <Common Header>
   [<SRP>]
   <LSP>

To Recap

Regards,
Tarek

Hi Dhruv

Thanks

Hooman

Hi Hooman,

Hi Dhruv

   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>]

   <Common Header>
   <SRP>

To Recap

Thanks!
Dhruv

Thanks
Hooman

-----Original Message-----
From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 11, 2021 5:01 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Please see inline...

Thanks!
Dhruv

Juniper Business Use Only
_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 10 Mar 2021 08:39:02 +0530

Hi Andrew,

Thanks for your email.

On Fri, Mar 5, 2021 at 11:00 PM Stone, Andrew (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi Dhruv,
>
>
>
> *"figure out if the act of downloading the replication segment is
> considered a PCECC operation or a regular stateful operation"*
>
>
>
> Could you expand on how you see the fundamental difference of PCECC
> operation vs regular stateful? Or correct the following statements if
> incorrect or missing something (?):
>
>
>
>         PCECC : Explicit incoming/outgoing instructions on each hop end to
> end for a LSP that is sourced at a headend
>
>
>

I would say this is the first use-case. RFC 8283 also highlighted SR use
cases which are all about programming and coordinating across nodes (not
necessarily directly connected). IMHO the same is true for the SFC use
case.

>        Regular Stateful: Explicit outgoing instruction(s) on a headend
> where binding label could be used to help steer into that head end
>
>
>
>
>

And this has always seen as an LSP operation/state.

> The view I have of replication segment is it has a “family relation” to
> the unicast SR Policy, and specifically it’s usage of binding label and
> egress label stack. Key difference of course that replicating packets vs
> weighted ecmp egress forwarding. PCE can deploy a unicast SR Policy with
> the intention of using it on that targeted headend or even as a transit for
> an upstream headend to achieve label stack reduction. A replication segment
> has the same philosophy with the exception that a replication segment can
> be encoded to indicate if it's shared or tied to a specific tree. Important
> encodings (binding label, multi-path ero) are being leveraged from objects
> being delivered in the unicast use case. I do consider leveraging these
> same encodings and mechanisms consistent between unicast and replication
> segment, and also consistent whether it’s a root, bud or leaf - without
> having to define new and reusing the concepts defined in those related
> docs. Yes, PCECC defines similar concepts and objects but appears to me
> like we’d have to define more-new things to leverage it and have
> replication segment deviate from its unicast relative and in return it
> would be picking only a very small part of what PCECC is accomplishing.
>
>
>

I can understand your point of view when I look at the headend operation on
the replication node. It is the operation on the leaf nodes and
coordination of SIDs required that gives me a pause. I also understand the
wish to keep the PCEP message the same on the root, bud, and leaves.

But, the Replication segment is described as forwarding instructions. See
-

https://datatracker.ietf.org/doc/html/draft-hsd-pce-sr-p2mp-policy-02#section-3
   A replication segment is set of forwarding instructions on a specific
   node.  As an example the push information on the Root node or swap
   and outgoing interface information on the transit nodes or pop
   information on the bud and leaves nodes.

Also, in all stateful operations, the unit of signaling is an LSP (RFC
8281, RFC 8664, SR Policy Candidate Path, Multipath ERO). I guess you see
the replication segment as an LSP operation (and so do the instructions
sent to the leaves).  I see them as central controller instructions that
require coordination across multiple nodes. This is a good discussion and I
am glad we are having it :)

Thanks!
Dhruv (as a WG member)

> Thanks
>
> Andrew
>
>
>
> *From: *Pce <[email-masked]> on behalf of Dhruv Dhody <
> [email-masked]>
> *Date: *Thursday, March 4, 2021 at 11:08 PM
> *To: *Tarek Saad <tsaad=[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and
> action.
>
>
>
> Hi Tarek,
>
>
>
> Thanks for your message.
>
>
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 10 Mar 2021 03:39:06 +0000

Hi Dhruv

“wanted to focus on the question - "Is the act of downloading a replication segment to the replication node AND the leaves, a PCECC operation or a stateful operation?". We can discuss encoding once we have this settled. “

HB> let me provide you the long answer so it is review for the WG as well:

1.       the tree is discovered via the manual configuration of the leaves via PCE or discovery of the LEAVES via NG-MVPN procedures. There could be other methods as well.
2.       In case of NG-MVPN the PCC will use PCE northbound to report the root and the leaves to the PCE.
3.       in case of NG-MVPN PCE can calculate the tree and program the replication points with forwarding instructions.
          a.       each Replication forwarding instruction is like a binding SID, in short the tree is not a single segment as such each replication segment can be programmed individually at only the replication nodes.
4.       the replication points can be stitch together via unicast segment routing by using a node or adjacency SID as nexthop.
5.       while on the unicast Segment Routing domain the PCE has “NO” part on programing the unicast paths stitching the Replication SIDs together.
6.       As such on a SR domain that there is many nodes (10s or 100s) the PCE Could only play a role for Root and the LEAVES (i.e. where the root is the only replication point) and it is stitched to the leaves via Unicast SR and appropriate node/adjacency SIDs.

“See Julien's response - https://mailarchive.ietf.org/arch/msg/pce/Vimr_-zn3DjpW2uY8A-hFpZXJg4/”

HB> Dear chairs I am not sure if I understand the criteria of how drafts move from “Individual documents that authors consider ready for WG adoption” to “WG Adoptoin call queue”. I am guessing it is chairs consent that moves the draft between the 2 queues, not the adaptation request?

Regards
Hooman

Sent: Thursday, March 4, 2021 11:05 PM

Hi Hooman,

On Wed, Mar 3, 2021 at 6:32 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dhruv

I wanted to focus on the question - "Is the act of downloading a replication segment to the replication node AND the leaves, a PCECC operation or a stateful operation?". We can discuss encoding once we have this settled.

I disagree with the above characterization. But let's leave it at that.  Let's continue the discussion on the key question.

See Julien's response - https://mailarchive.ietf.org/arch/msg/pce/Vimr_-zn3DjpW2uY8A-hFpZXJg4/

I agree, lets give time for others to chime in, a week before IETF is a busy time :)

Thanks!
Dhruv

Regards
Hooman

-----Original Message-----
From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 3, 2021 4:54 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Thanks!

On Tue, Mar 2, 2021 at 6:48 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
> Cc: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On Mon, Mar 1, 2021 at 3:54 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Dhruv
> >
> >
> >

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 11 Mar 2021 15:56:27 +0000

Hi Dhruv,

>“I guess you see the replication segment as an LSP operation (and so do the instructions sent to the leaves).  I see them as central controller instructions that require coordination across multiple nodes”

Yes, agreed that’s a good way to summarize it. From my perspective, I still have some difficulty seeing the benefits gained by adding items/encoding to the p2mp replication SID that currently would essentially go unused, since without those new additions the solution is still achieved. My though process here is “less is more”

Thanks!
Andrew

From: Dhruv Dhody <[email-masked]>
Date: Tuesday, March 9, 2021 at 10:09 PM
To: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Cc: Tarek Saad <tsaad=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Andrew,

Thanks for your email.

On Fri, Mar 5, 2021 at 11:00 PM Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dhruv,

I would say this is the first use-case. RFC 8283 also highlighted SR use cases which are all about programming and coordinating across nodes (not necessarily directly connected). IMHO the same is true for the SFC use case.

I can understand your point of view when I look at the headend operation on the replication node. It is the operation on the leaf nodes and coordination of SIDs required that gives me a pause. I also understand the wish to keep the PCEP message the same on the root, bud, and leaves.

But, the Replication segment is described as forwarding instructions. See  -

Also, in all stateful operations, the unit of signaling is an LSP (RFC 8281, RFC 8664, SR Policy Candidate Path, Multipath ERO). I guess you see the replication segment as an LSP operation (and so do the instructions sent to the leaves).  I see them as central controller instructions that require coordination across multiple nodes. This is a good discussion and I am glad we are having it :)

Thanks!
Dhruv (as a WG member)

Thanks
Andrew

From: Pce <[email-masked]<mailto:[email-masked]>> on behalf of Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 4, 2021 at 11:08 PM
To: Tarek Saad <tsaad=[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Tarek,

Thanks for your message.

Thanks!
Dhruv

Current:
   <Common Header>
   [<SRP>]
   <LSP>

To Recap

Regards,
Tarek

Hi Dhruv

Thanks

Hooman

Hi Hooman,

Hi Dhruv

   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>]

   <Common Header>
   <SRP>

To Recap

Thanks!
Dhruv

Thanks
Hooman

-----Original Message-----
From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 11, 2021 5:01 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Please see inline...

Thanks!
Dhruv

---

From: Tarek Saad <[email-masked]>
Date: Thu, 11 Mar 2021 17:17:30 +0000

Hi Dhruv/all,

Thanks, meant to send this earlier too.

>> "figure out if the act of downloading the replication segment is considered a PCECC operation or a regular stateful operation"
[TS]: Indeed, IMO it can be a regular stateful operation and many of the machinery already defined (e.g. rfc8231, rfc8281) can be reused.

>> Also, in all stateful operations, the unit of signaling is an LSP (RFC 8281, RFC 8664, SR Policy Candidate Path, Multipath ERO). I guess you see the replication segment as an LSP operation (and so…
[TS]: Yes, I think when sharing of replication SIDs (section 3.1.1), this also allows a single replication SID to be treated independently. Thanks.

Regards,
Tarek

On 3/9/21, 10:09 PM, "Dhruv Dhody" <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

Hi Andrew,

Thanks for your email.

https://datatracker.ietf.org/doc/html/draft-hsd-pce-sr-p2mp-policy-02#section-3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hsd-pce-sr-p2mp-policy-02*section-3__;Iw!!NEt6yMaO-gk!WYXbT0WXt-LI_aq9HpXAvSL9U7NWznbT3vL3sdy7v6dR4a-7X0-oQv24IWfouA$>

Thanks!
Dhruv (as a WG member)

Thanks
Andrew

Hi Tarek,

Thanks for your message.

Thanks!
Dhruv

Current:
   <Common Header>
   [<SRP>]
   <LSP>

To Recap

Regards,
Tarek

Hi Dhruv

Thanks

Hooman

Hi Hooman,

Hi Dhruv

   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>]

   <Common Header>
   <SRP>

To Recap

Thanks!
Dhruv

Thanks
Hooman

-----Original Message-----
From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 11, 2021 5:01 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Please see inline...

Thanks!
Dhruv

> >
> > The authors feel ERO object in addition to draft-koldychev-pce-multipath-04 - PCEP Extensions for Signaling Multipath Information (ietf.org<https://urldefense.com/v3/__http:/ietf.org__;!!NEt6yMaO-gk!WYXbT0WXt-LI_aq9HpXAvSL9U7NWznbT3vL3sdy7v6dR4a-7X0-oQv1oayAjlg$>) for backup paths is the easiest and the most efficient way to address the programming of a replication segment on PCC from to the PCE.
> >
> >
> >

Juniper Business Use Only
_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pce__;!!NEt6yMaO-gk!WYXbT0WXt-LI_aq9HpXAvSL9U7NWznbT3vL3sdy7v6dR4a-7X0-oQv1Ut8b5-A$>

---

From: <[email-masked]>
Date: Thu, 18 Mar 2021 12:16:14 +0100

Hi Hooman,

To respond to your comment, we usually follow the list below:
1- Gauge interest on the mailing list about an I-D,
2- Gauge interest when the I-D is presented to the WG,
3- If enough of 1 and 2, do a 1st poll in the room during WG meetings,
4- If enough of 3, add the I-D to the adoption queue.

Without face-to-face meeting, we sometimes skip 3. Considering its
depth, we often revise the order in the adoption queue with respect to
consensus and document maturity (consider thanking Dhruv for that). As a
result, your effort should focus on progressing technical discussions
rather than process requests: I believe the discussion in progress will
end up in improving your I-D, which will be valuable whatever the
further steps.
Contrary to what I've read, please note PCE-CC isn't a prerequisite and
there's no such statement like "the working group is only dictating
PCECC and is not open to any other option but PCECC for the purpose of
programming the PCC and multicast".

Thanks,

Julien

On 10/03/2021 04:39, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:
> HB> Dear chairs I am not sure if I understand the criteria of how
> drafts move from “Individual documents that authors consider ready for
> WG adoption” to “WG Adoptoin call queue”. I am guessing it is chairs
> consent that moves the draft between the 2 queues, not the adaptation
> request?

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 18 Mar 2021 17:31:15 +0530

Hi,

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.

Thanks!
Dhruv (as a WG member)
[1] https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 18 Mar 2021 16:36:27 +0000

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.

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.

Again we are open for any constructive feedback on how this draft can be improved, in the boundary of 
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/

Regards
Hooman

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

Hi,

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

- 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.

Thanks!
Dhruv (as a WG member)

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 22 Mar 2021 10:18:05 +0530

Hi Hooman,

> Now you are mentioning get in part with RFC 8231, 8281 etc... which is a
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.
>
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.

> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/
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...

Thanks!
Dhruv (as a WG member)

> 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.
>
> 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"

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 23 Mar 2021 15:00:43 +0800

Hi, 

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: [email-masked] <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Monday, March 22, 2021 12:48 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Cc: [email-masked]
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) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Dhruv

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. 

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.  

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...

Thanks! 

Dhruv (as a WG member)

Regards
Hooman

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

Hi,

Thanks!
Dhruv (as a WG member)

_______________________________________________
Pce mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/pce

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 24 Mar 2021 03:19:04 +0000

Hi Aijun

Thanks you for your comments.

Inline

Regards
Hooman

From: Aijun Wang <[email-masked]>
Sent: Tuesday, March 23, 2021 3:01 AM
To: 'Dhruv Dhody' <[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Cc: [email-masked]
Subject: RE: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi,

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.
HB> no underlay distribution for replication SID, as it is not a P2MP LSP. Replication SID is an individual resource, that can be programmed at strategical node for sole purpose of replication. It can be stitched together via unicast SR. Traffic can be steered out of each OIF via unicast Node/Adjacency SID.
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.
HB> Agreed that the 2 concept can’t be mixed. A bit of history, my apologies for repetition here:
1.            We did look at PCECC and our first implementation and first draft was based on PCECC and CCI object. We found CCI object for replication SID to be cumbersome, it made the solution much more complicated then what it needed to be. The perfect examples are: the FRR protection path, with CCI the protection path had to be downloaded with every single OIF making the message much larger. In addition for an incoming label and set of outgoing OIF, the CCI solution forced the download of the incoming label and the outgoing OIFs/Labels in order with in a message, making the ordering of the labels and the OIFs very complicated. In short we tried to use the CCI object and it did not fit nicely. Hence why we looked at the ERO object with multipath backup TLV for protection. In addition the replication segment is in “NO WAY” part of an LSP or a P2MP LSP or a static P2MP LSP, it is an individual segment (like a binding SID) programed at a strategic node for sole purpose of replication.
2.            I think above point is driven home. The next suggestion was why not wrap the ERO in CCI object. This is where the authors/co-authors didn’t understand what additional improvement this method would bring into the solution. When the question was posed the answer was consistency “only”. Consistency is great as long as the solution and the implementation does not get complicated and there are obvious benefits to it. The solution is achievable without CCI object, the CCI object and encoding will be there wrapping ERO for no purpose at all.

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv Dhody
Sent: Monday, March 22, 2021 12:48 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dhruv

Thanks!
Dhruv (as a WG member)

Regards
Hooman

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

Hi,

Thanks!
Dhruv (as a WG member)

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 26 Mar 2021 13:02:48 +0530

Hi Hooman,

With my chair hat off and speaking as a WG participant. Thanks for
explaining your point of view and the history.

The PCEP stateful messages are currently being used for -

- LSP operations (LSP instruction/reports to/from head end i.e. stateful
PCE)
- PCECC operations (generic instructions/reports to/from any node)

You say-

In addition the replication segment is in “NO WAY” part of an LSP or a P2MP
> LSP or a static P2MP LSP, it is an individual segment (like a binding SID)
> programed at a strategic node for sole purpose of replication.

You agree that it is not an LSP operation but you don't consider it PCECC
either! You would like to use the encoding that matches with the P2P LSP
operations for the replication segment. Since you mentioned binding SID, in
PCEP, it is a property of the LSP. It is encoded in a TLV inside the LSP
Object. Even when the binding segment is used on a strategic internal node
it is for an LSP with the strategic node as the head-end from PCEP's point
of view.

Regarding the question of why CCI Object, as I mentioned earlier, we could
have instantiated a static PCECC LSP as a one-hop LSP along the path
without a new object. The approach that the WG took was to define a new CCI
Object instead, as the scope of PCECC was bigger and we wanted to have the
freedom to encode various types of instructions (which can be unrelated to
LSP operations). For example SR/SRv6 SID programming, Native-IP, etc. This
has been helpful IMHO. And replication segment fits here well.

You say -

Consistency is great as long as the solution and the implementation does
> not get complicated and there are obvious benefits to it. The solution is
> achievable without CCI object, the CCI object and encoding will be there
> wrapping ERO for no purpose at all.

I agree that your solution is achievable without using a CCI object but
disagree that adding a CCI object Type would make it complicated. Moreover
to me, it is a PCECC operation (but I-D does not refer to it in any way and
that is confusing).

Coming back to the question to the WG -- Is the act of programming
replication segment to a replication node and the leaves, a PCECC operation
(we seem to agree that it is not an LSP operation)? And should we use a new
CCI Object type to encode it or not?

Thanks!
Dhruv (as a WG participant/still chair hat off)

On Wed, Mar 24, 2021 at 8:49 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> *From:* Aijun Wang <[email-masked]>
> *Sent:* Tuesday, March 23, 2021 3:01 AM
> *To:* 'Dhruv Dhody' <[email-masked]>; Bidgoli, Hooman (Nokia -
> CA/Ottawa) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and
> action.
>
>
>
> Hi,
>
>
>
> 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.
>
> HB> no underlay distribution for replication SID, as it is not a P2MP LSP.
> Replication SID is an individual resource, that can be programmed at
> strategical node for sole purpose of replication. It can be stitched
> together via unicast SR. Traffic can be steered out of each OIF via unicast
> Node/Adjacency SID.
>
> 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.
>
> 1.            We did look at PCECC and our first implementation and first
> draft was based on PCECC and CCI object. We found CCI object for
> replication SID to be cumbersome, it made the solution much more
> complicated then what it needed to be. The perfect examples are: the FRR
> protection path, with CCI the protection path had to be downloaded with
> every single OIF making the message much larger. In addition for an
> incoming label and set of outgoing OIF, the CCI solution forced the
> download of the incoming label and the outgoing OIFs/Labels in order with
> in a message, making the ordering of the labels and the OIFs very
> complicated. In short we tried to use the CCI object and it did not fit
> nicely. Hence why we looked at the ERO object with multipath backup TLV for
> protection. In addition the replication segment is in “NO WAY” part of an
> LSP or a P2MP LSP or a static P2MP LSP, it is an individual segment (like a
> binding SID) programed at a strategic node for sole purpose of replication.
>
> 2.            I think above point is driven home. The next suggestion was
> why not wrap the ERO in CCI object. This is where the authors/co-authors
> didn’t understand what additional improvement this method would bring into
> the solution. When the question was posed the answer was consistency
> “only”. Consistency is great as long as the solution and the implementation
> does not get complicated and there are obvious benefits to it. The solution
> is achievable without CCI object, the CCI object and encoding will be there
> wrapping ERO for no purpose at all.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Dhruv
> Dhody
> *Sent:* Monday, March 22, 2021 12:48 PM
> *Cc:* [email-masked]
> *Subject:* Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and
> action.
>
>
>
> Hi Hooman,
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Mar 2021 15:16:08 -0400

Authors / WG

I will try to help summarize to facilitate  the discussion.  Please let me
know if I am off on the points to help come to consensus.

SR Replication SID for SR P2MP tree is analogous concept to IR Ingress
Replication unicast replication.

SR replication SID uses the same RFC 6513 6514 MVPN instantiation
procedures for X-PMSI PTA p-tree identical to IR RFC 7988 unicast
replication where the parent root unicast the copies to the Chile leaves
with Unicast LSPs.

Similarly with SR Replication SID the root and leaf nodes are known to the
PCE and the root node can replicate the segments, however the intermediate
 nodes that require stitching of the hop by hop replication segments of the
intermediate nodes unicast stitching of the replication segments to
instantiate the P2MP tree.

With PCE CC stateful LSP style the head end has control of the label space
and can instantiate the end to end P2MP LSP.

In the case of SR P2MP policy using replication SID the replication SIDs
are unicast routing hop by hop stitched push/next using RFC 8664 PCE SR
extension SR-ERO object.

https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-04

https://tools.ietf.org/html/draft-ietf-spring-sr-replication-segment-04

3 <https://tools.ietf.org/html/draft-ietf-spring-sr-replication-segment-04#section-3>.
Use Cases

   In the simplest use case, a single Replication segment includes the
   root node of a multi-point service and the egress/leaf nodes of the
   service as all the Downstream Nodes.  This achieves Ingress
   Replication [RFC7988 <https://tools.ietf.org/html/rfc7988>] that
has been    widely used for MVPN [RFC6513
<https://tools.ietf.org/html/rfc6513>]
   and EVPN [RFC7432 <https://tools.ietf.org/html/rfc7432>] BUM
(Broadcast, nknown and Multicast) traffic.

   Replication segments can also be used as building blocks for
   replication trees when Replication segments on the root, intermediate
   Replication Nodes and leaf nodes are stitched together to achieve
   efficient replication.  That is specified in
   [I-D.ietf-pim-sr-p2mp-policy
<https://tools.ietf.org/html/draft-ietf-spring-sr-replication-segment-04#ref-I-D.ietf-pim-sr-p2mp-policy>].

This draft defines the SR-TE P2MP policy of inserting the candidate path
Replication SID list into the forwarding plane and discusses in detail how
to use PCE CC CCI object instantiation or SR replication SID stitched P2MP
tree.

CCI object

https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-14#section-5.5.3.1

SR TE P2MP policy using replication SID

https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/02/

A lot of what is defined in the draft being discussed PCE extension for SR
P2MP is also discussed in the above draft using PCE CC CCI object.

Hope this helps facilitate the discussion to try to get to root of the
technical issue as to why CCI cannot be used for SR P2MP.

It does appear that we should be able to use PCE CC CCI object for the SR
P2MP tunnel however we need dig into the technical issues we are seeing.
>From the thread it seems the issue maybe related to the unicast routing
stitching hop by hop of the replication SIDs to build the P2MP tree,
however that should be able to be accomplished with SR-ERO object with CCI.

Kind Regards

Gyan

On Fri, Mar 26, 2021 at 3:33 AM Dhruv Dhody <[email-masked]> wrote:

> In addition the replication segment is in “NO WAY” part of an LSP or a
>> P2MP LSP or a static P2MP LSP, it is an individual segment (like a binding
>> SID) programed at a strategic node for sole purpose of replication.
>
>
>> HB> no underlay distribution for replication SID, as it is not a P2MP
>> LSP. Replication SID is an individual resource, that can be programmed at
>> 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,
>> 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.
>>
>>
>>
>> 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
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*