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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

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

From: Dhruv Dhody <[e-mail]>
Sent: Thursday, March 4, 2021 11:05 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>
Cc: Dhruv Dhody <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

On Wed, Mar 3, 2021 at 6:32 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>> 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.

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 <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 3, 2021 4:54 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Cc: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.

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

On Tue, Mar 2, 2021 at 6:48 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>> wrote:
>
> 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 <[e-mail]<mailto:[e-mail]>>
> Sent: Tuesday, March 2, 2021 12:31 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
> Cc: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> 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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
> > Sent: Thursday, February 11, 2021 9:00 PM
> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > 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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
> > Sent: Thursday, February 11, 2021 5:01 AM
> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > 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) <[e-mail]<mailto:[e-mail]>> wrote:
> > >
> > > Hi Dhruv
> > >
> > > Much appreciate your reply, Inline
> > >
> > > Thanks
> > > Hooman
> > >
> > >
> > > -----Original Message-----
> > > From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
> > > Sent: Tuesday, February 9, 2021 5:28 AM
> > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
> > > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > > 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) <[e-mail]<mailto:[e-mail]>> 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<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.
> > > >
> > > >
> > > >
> > > > 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
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/pce