Re: [Pce] Multipath / replication segment comment
continued inline , > > [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. > > [TS]: Consider the case of a PCE delegated SR Policy Candidate Path. The > PCC desires an SR path computation from a PCE that is subject to > constraints – The PCC has no a-priori idea **how many** Segment-Lists (SLs) > the PCE path computation will result in-- so it does not know how many (or > whether it should at all) create multiple PLSPs with NO-ERO and report them > so PCE can respond to each. > The PCC can use a PCReq, PCRep, that allows multiple ERO. What is the drawback of delegating the maximum set of Supported Segment List with no ERO, the association may carry an attribute to indicate to the PCE "Minimize the number of LSP with route" (or it can be a METRIC). The PCC knows how many segment-list per candidate path are supported though (whereas the PCE does not a priori) > The PCC creates **one** PLSP and reports to the PCE the LSP down (with > NO-ERO) along with the specified user constraints. The PCE computes and > determines the feasible number of SLs. Now, it would be awkward for the PCE > to instantiate PLSPs – different from the one originally delegated by the > PCC—so to encode each SL in its own PLSP and make use the “association > object” method.. I can also imagine complexities in what each PLSP LSP > would carry in terms of constraints – especially after some configuration > change on the PCC… > s/one/all/ and that works with: - limited extensions - reuse the path protection for protection - Any OAM extension and procedure works (as its per path) - The PCC has the freedom to have policies for per (set of) segment-list constraints - The function desired is more the shared control of the number of path between the PCC and the PCE. Stateless PCE uses the LOAD-BALANCING for that, but stateful has a more restrictive definition. A possibility is to reuse the original multiple ERO defined, What is currently a TE-Path, but adapt it to stateful: - allow LOAD-BALANCING (please refer to RFC5440) in PCRpt - the PCE May use multiple ERO and LOAD-BALANCING to *suggest* some alternative paths to the PCC, in case of a candidate path the PCC should create the other PLSPs - The PCE can update the LOAD-BALANCING and suggested ERO, the PCC should update its set of LSPs It keeps the PCE-Controlled number of paths, it can work for other kind of associations that groups traffic together (RSVP, GMPLS) , you can keep OAM and constraints freedom, scenarios like per-destination or region-chain PCE delegation is still allowed The PCC can have more control and options, or keep one LSP with LOAD-BALANCING + candidate path > > The proposal in draft-koldychev-pce-multipath indeed proposes elegant way > to encode all computed SLs (as multiple SERO lists) into a single PLSP – > the one originally reported by the delegated PLSP. In fact, this method > allows at anytime the PCE to send PCUpd to add/remove/update SL(s) within a > single PLSP freely – which IMO is powerful. > I understand that people like to map their management objects directly, but Its awkward to say that one path is not one path, Anyhow in term of TE and OAM, each segment-list is kind of independent. PCCreate works equally well for a PCE to create/delete paths, the LOAD-BALANCING and suggested EROs offer more flexibility from PCE and PCC. > > > I think the same argument applies to backup paths/SLs too.. The PCC would > not know how many SL(s) can protect a single path, so it would not be able > to a-priori create PLSPs and use association object. > > > 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? > > > > [TS]: please refer to draft-ietf-spring-segment-routing-policy which > defines such terms… > > > The draft does not say why its considered a single path when it has multiple physical paths, nor the use of association with multiple PLSP contradict contradict the unit of signaling (the unit of signaling being the association parameters) . ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Multipath / replication segment comment
Hi all, Some input inline.. From: Pce on behalf of Cyril Margaria Date: Wednesday, February 12, 2020 at 4:19 PM To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: "pce@ietf.org" Subject: Re: [Pce] Multipath / replication segment comment Please see inline On Thu, 19 Dec 2019 at 17:19, Stone, Andrew (Nokia - CA/Ottawa) mailto:andrew.st...@nokia.com>> wrote: Few comments below, Cheers Andrew On 2019-12-19, 6:52 AM, "Dhruv Dhody" mailto:dhruv.i...@gmail.com>> wrote: Hi Andrew, Speaking as a WG contributor... On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) mailto:andrew.st...@nokia.com>> 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. [TS]: Consider the case of a PCE delegated SR Policy Candidate Path. The PCC desires an SR path computation from a PCE that is subject to constraints – The PCC has no a-priori idea **how many** Segment-Lists (SLs) the PCE path computation will result in-- so it does not know how many (or whether it should at all) create multiple PLSPs with NO-ERO and report them so PCE can respond to each. The PCC creates *one* PLSP and reports to the PCE the LSP down (with NO-ERO) along with the specified user constraints. The PCE computes and determines the feasible number of SLs. Now, it would be awkward for the PCE to instantiate PLSPs – different from the one originally delegated by the PCC—so to encode each SL in its own PLSP and make use the “association object” method.. I can also imagine complexities in what each PLSP LSP would carry in terms of constraints – especially after some configuration change on the PCC… The proposal in draft-koldychev-pce-multipath indeed proposes elegant way to encode all computed SLs (as multiple SERO lists) into a single PLSP – the one originally reported by the delegated PLSP. In fact, this method allows at anytime the PCE to send PCUpd to add/remove/update SL(s) within a single PLSP freely – which IMO is powerful. I think the same argument applies to backup paths/SLs too.. The PCC would not know how many SL(s) can protect a single path, so it would not be able to a-priori create PLSPs and use association object. 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? [TS]: please refer to draft-ietf-spring-segment-routing-policy which defines such terms… Regards, Tarek 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
Re: [Pce] Multipath / replication segment comment
Please see inline On Thu, 19 Dec 2019 at 17:19, Stone, Andrew (Nokia - CA/Ottawa) < andrew.st...@nokia.com> wrote: > Few comments below, > > Cheers > Andrew > > On 2019-12-19, 6:52 AM, "Dhruv Dhody" wrote: > > Hi Andrew, > > Speaking as a WG contributor... > > On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) > 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 >
Re: [Pce] Multipath / replication segment comment
Hi Mike, On Sat, Dec 21, 2019 at 3:02 AM Mike Koldychev (mkoldych) wrote: > > Regarding SID lists terminating on the same node This cannot be > mandated/enforced from a protocol point of view. There are use cases, as > Andrew pointed out, where the SID list(s) terminate prior to reaching the > end-point and the packets go the rest of the way unencapsulated. > > It may be that some implementations of SR-TE head-end may choose to validate > the ERO(s) and verify that they actually do reach the end-point node, but > this extra validation is purely optional. > I agree with this. But, during path computation the SR policy endpoint is the "logical" destination for the computed SID list (path) by the PCE. So I would differentiate between validation of the SID list and the original issue - can SR-P2MP multiple SID-list to "different" endpoints, communicated via the multipath ERO solution? I guess this would get clearer when the multipath I-D includes RBNF for all the messages. Well consider the case of PCReq message for P2MP, we need to clearly identify the multiple destinations for PCE to compute the tree. This shows the importance of P2MP ENDPOINT object, similarly ENDPOINT/S2LS object would help in reporting state of part of the tree and group them based on leaf-types which is quite useful. We need to use RFC8306/RFC8623 as a base for SR-P2MP policy work ( provided my current understanding of this work :) )! Happy Holidays! Thanks! Dhruv > Thanks, > Mike. > > -Original Message- > From: Pce On Behalf Of Stone, Andrew (Nokia - > CA/Ottawa) > Sent: Thursday, December 19, 2019 12:19 PM > To: Dhruv Dhody > Cc: pce@ietf.org > Subject: Re: [Pce] Multipath / replication segment comment > > Few comments below, > > Cheers > Andrew > > On 2019-12-19, 6:52 AM, "Dhruv Dhody" wrote: > > Hi Andrew, > > Speaking as a WG contributor... > > On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) > 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. > > 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] Coincidenta
Re: [Pce] Multipath / replication segment comment
Regarding SID lists terminating on the same node This cannot be mandated/enforced from a protocol point of view. There are use cases, as Andrew pointed out, where the SID list(s) terminate prior to reaching the end-point and the packets go the rest of the way unencapsulated. It may be that some implementations of SR-TE head-end may choose to validate the ERO(s) and verify that they actually do reach the end-point node, but this extra validation is purely optional. Thanks, Mike. -Original Message- From: Pce On Behalf Of Stone, Andrew (Nokia - CA/Ottawa) Sent: Thursday, December 19, 2019 12:19 PM To: Dhruv Dhody Cc: pce@ietf.org Subject: Re: [Pce] Multipath / replication segment comment Few comments below, Cheers Andrew On 2019-12-19, 6:52 AM, "Dhruv Dhody" wrote: Hi Andrew, Speaking as a WG contributor... On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) 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. 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 th
Re: [Pce] Multipath / replication segment comment
Few comments below, Cheers Andrew On 2019-12-19, 6:52 AM, "Dhruv Dhody" wrote: Hi Andrew, Speaking as a WG contributor... On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) 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. 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
Re: [Pce] Multipath / replication segment comment
Hi Andrew, Speaking as a WG contributor... On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa) 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 > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Multipath / replication segment comment
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. 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. 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. Cheers Andrew ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
