Re: [Pce] Multipath / replication segment comment

[Cyril Margaria <[e-mail]>]

Please see inline

On Thu, 19 Dec 2019 at 17:19, Stone, Andrew (Nokia - CA/Ottawa) <
[e-mail]> wrote:

> Few comments below,
>
> Cheers
> Andrew
>
> On 2019-12-19, 6:52 AM, "Dhruv Dhody" <[e-mail]> wrote:
>
>     Hi Andrew,
>
>     Speaking as a WG contributor...
>
>     On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa)
>     <[e-mail]> 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.
>
> [Andrew] True, the original intent of multiple paths within the same
> tunnel in a single report/update, but that could still be leveraged in the
> replication case, i.e I want a single report/update to modify the state of
> a replication segment. I think it becomes a gray area in interpretation of
> whether or not a replication segment creates a P2MP tunnel or if it's
> actually just creating multiple P2P tunnels from a single ingress label. If
> the interpretation is it's a P2MP tunnel, then using multiple EROs to
> define the forwarding of a P2MP. Tunnel requires those EROs to terminate on
> different nods.
>
> [Cyril] There is a related work that ties one tunnel to multiple path,
list of hops :  RFC8697, and draft-ietf-pce-stateful-path-protection-11.
Given the mechanism used (and flexibility in term of the individual legs),
would it make sense to reuse the path protection mechanisms to tie those
multiple EROs together? In addition it addresses the backup path already.

Where is the requirement of updating all the segment-list of an
SR-Candidate together coming from?

On an unrelated note, why is it called Candidate-path and not
candidate-multipath, if there are multiple path?


>     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.
>
>
> [Andrew] Coincidentally this was just mentioned in SPRING mailing list,
> whether in SR Policy endpoint is the tunnel termination vs a prefix/route
> to reach (which I kind of have to agree with), which seemed to have been
> raised because there's the concept of null/0.0.0.0 (and some wording on
> whether or not this is a valid "endpoint"). Anyways, in an EPE case I don't
> need to specify a path to reach the absolute endpoint, I just need to
> specify a path to steer to an egress peer, and with last label in the stack
> being an EPE Peer link or node, and that egress peer can take over the
> packet (likely not MPLS encaped anymore) and steer, forward or tunnel
> however it chooses. In this regard the SID list specified on the headend SR
> Policy "stops early" before the "real endpoint". From this perspective
> whether my ECMP SID lists stop on different routers or not is not really
> relevant for reaching the "real endpoint". Section 4.7 in
> draft-ietf-spring-segment-routing-central-epe-10 briefly comments on this,
> in the sense that to reach an internet route a SID list comprised of only
> SID(s) to reach the border node, and a SID to specify the peering router is
> sufficient. In this regard the path terminates on the peering router,
> despite the fact that my endpoint is much further in the network / perhaps
> across the internet.
>
>
>     > 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 :)
>
> [Andrew] ACK, something I guess that will need to be discussed further in
> the shaping of PCEP replication segment draft. Configuring stitched
> replication segments (and each replication segment does not perform any
> network signalling), one could leverage independent RSVP LSP(s) in between
> replication segments along their unicast path, but it's not clear to me if
> there could/would/should be RSVP signalling for the replication segment
> itself, so I'm not sure how directly mapped to an RSVP use case it is, as
> the current focus is SR-MPLS/SRv6-like functionality. Keeping data models
> and message encoding the same as much as possible, I do agree with, and the
> replication segment draft has attempted to do that by re-using the model
> encoding from all the previous IETF work. Side note, the separation of the
> P2MP Policy vs Replication Segment in PCEP is also key to keeping the
> solution manageable in PCEP to handle cases of mbb, redundancy and
> transport re-usability - it's not clear to me how that split looks like if
> one were to completely build on the RFC 8623.
>
>
>     Thanks!
>     Dhruv
>
>     >
>     > Cheers
>     >
>     > Andrew
>     >
>     >
>     >
>     > _______________________________________________
>     > Pce mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/pce
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>