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
