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
