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 protected]> On Behalf Of Dhruv Dhody Sent: Thursday, March 18, 2021 8:01 AM To: [email protected] Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action. 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/ _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
