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) <[email protected]> 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 <[email protected]> > Sent: Tuesday, March 2, 2021 12:31 AM > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]> > Cc: Dhruv Dhody <[email protected]>; [email protected]; [email protected] > 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) > <[email protected]> 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 protected]> > > Sent: Thursday, February 11, 2021 9:00 PM > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]> > > Cc: [email protected]; [email protected] > > 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 protected]> 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 protected]> > > Sent: Thursday, February 11, 2021 5:01 AM > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]> > > Cc: [email protected]; [email protected] > > 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 protected]> wrote: > > > > > > Hi Dhruv > > > > > > Much appreciate your reply, Inline > > > > > > Thanks > > > Hooman > > > > > > > > > -----Original Message----- > > > From: Dhruv Dhody <[email protected]> > > > Sent: Tuesday, February 9, 2021 5:28 AM > > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]> > > > Cc: [email protected]; [email protected] > > > 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 protected]> 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 protected] > > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
