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
