Hi Andrew, Speaking as a WG contributor...
On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) <[email protected]> wrote: > > Hi all, > > > > In Singapore I made a remark about draft-koldychev-pce-multipath that it’s a > helpful draft and is also applicable to the replication segment. > > > > I received a follow up question emailed directly, asking about whether “EROs > need to share same source and destination” and how/if this could be related > to RFC 8623. > > > > For openness, sending my thoughts/comments here to the WG: > > > > There is no requirement listed in draft-koldychev-pce-multipath that I can > see which requires EROs to terminate on the same source/destination, I > haven’t seen that expectation anywhere, and in my opinion there should not be. [Dhruv] You are right, this is not explicit in the I-D. But based on the scope of past discussion IMHO it was always about multiple paths (ERO) for a single tunnel and thus finding a way to encode them within a single report/update in a PCEP message. The new ERO-ATTRIB object in the I-D is just a separator between several ERO objects in a existing PCEP message which reports/update a particular LSP (identified by PLSP-ID in the LSP object). > For example, one of the use cases of draft-koldychev-pce-multipath is for SR > Policy to support multiple SID lists, combine that with use case such as > SR-EPE, you could have multiple SID lists and have weighted ECMP traffic out > different egress nodes intentionally to load balance across different peer > nodes. [Dhruv] As per the SR policy as it is currently defined - End point is the property of the SR Policy. Each segment-list inside a candidate path would be a specific source-routed path from the headend to the endpoint of the corresponding SR policy. That said, in this use case perhaps you would use an anycast address but still the same endpoint from the SR policy point of view. > Another example, with ingress replication, is the multipath ERO can also be > re-used to describe the egress downstream paths which will be going to > different receiver(s), for either further replication or consumption. > > > > My comment regarding multipath to be used for ingress replication is because > there is a need in replication segment to be able to program backup paths for > each egress ERO. There were comments on this in the earlier sr-replication > draft in spring wg, but appears the wording has been redone / drafts are > still in a state of change. None the less, the multipath backup TLV via the > ERO attributes object in draft-koldychev-pce-multipath permits the relation > between the normal ERO and the backup (PCE computed) ERO, something that the > current RFC 8623 does not. There’s a desire to build this into replication > segment and draft-hsd-pce-sr-p2mp-policy-01 is leveraging this construct > (probably need further remarks on this in the drafts to describe this > intention). Comparing to RFC 8623, considering all of the nuances of > replication segment (p2mp-lsp-identifier-tlv, replication-sid/binding-label, > backup eros) it seems reasonable to me that draft-hsd-pce-sr-p2mp-policy > defines the replication segment (draft-hsd-pce-sr-p2mp-policy-01 section 3.3) > while leveraging existing/other common constructs, and defining it’s > behaviour, rather than trying to just use all of RFC8623 and attempt to > update and squeeze in (or out) other elements of the RFC. > > [Dhruv]: For the SR-P2MP usecase you have two building blocks in PCEP (1) PCEP-SR for P2P (2) PCEP-RSVP-TE for P2MP. I would suggest you to build on both of these. The (1) offers you SR-ERO, SR-Policy association etc. The (2) offers you P2MP END-POINT object with multiple destination, S2LS object to report status to each leaf etc. Regarding backup, Protection Association could be used even for P2MP as well. I would not look only at a feature like 'backup' to make this fundamental judgment on how to encode SR-P2MP in PCEP. I like the fact that as far as PCEP message encoding is concerned, there is a minimal difference between SR and RSVP-TE. I would like to see if we can continue to keep that true for SR-P2MP as well :) Thanks! Dhruv > > Cheers > > Andrew > > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
