Hi Hooman, On Wed, Mar 3, 2021 at 6:32 PM Bidgoli, Hooman (Nokia - CA/Ottawa) < [email protected]> 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 <[email protected]> > Sent: Wednesday, March 3, 2021 4:54 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 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
