Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Cyril Margaria]

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set
of EROs/Label switch paths using RFC6007, including multi-domain and
multi-PCEs scenarios. This can be used for computing a set of EROs for SR
candidate paths, one case that can apply to the candidate path and
explicitly mentioned by the RFC is "Two or more end-to-end diverse paths".
This does not cover the stateful PCE case directly, but there are similar
situations to what RFC6007 in the form of path protection
(primary/secondary/standby) for statefull PCE, which use the association
mechanism. Those two existing mechanism exists to coordinate several paths
and could be used to indicate how multiple paths are related and on how to
signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated
LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to
be an advantage as its less restrictive. Having the same restriction on a
set of paths is easy, relaxing a restriction on the ERO #5 is more
complicated (in term of encoding).
  - There is a set of options to achieve the "signal the set of paths
together":
 a)  set of LSPs can be reported in the same message, it can be
enforced by the document defining that specific association type.
 b) SVEC/SVEC List can be extended to statefull PCEP,

That solution would work in case of multi-domain PCEs, and also be helpful
for OAM and auto-bw mechanism.
As a segment list is one path in the network, that maps nicely to one LSP.


Solution 2:
  - This limit the set of constraints to be applied, policies like "10% of
the traffic does not need to be protected" cannot be expressed (it can be
with solution 1, clear L bit of LSPA on one TE-LSP out of 10)
  - 2.a when the LSP is reported down : which ERO is down?, the same is
applicable for auto-bw and any form of OAM data.
  - Solution 2.b allows for Optimized branch encoding, that should be
disabled for that solution


Slide "Comparison of Solutions":
   - There are solutions to most of the points raised for solution 1
   - The database problem seems specific to one implementation, other
implementation will have the problem for solution 2
   -  multi-PCE and multi-domain are not evaluated. Solutions and
consideration are available for solution 1, not for solution 2.
(experimental Inter-domain P2MP tree solutions exists).

Best Regards,
Cyril

On Fri, 12 Jul 2019 at 22:02, Mike Koldychev (mkoldych) 
wrote:

> Hi WG,
>
> As per SPRING WG, SR Policy may contain multiple Candidate Paths and each
> Candidate Path may contain multiple Segment Lists. Existing SR standards in
> PCEP allow only a single ERO (one Segment List) for the SR Path in a
> stateful PCEP message. There is a need to signal multiple Segment Lists in
> PCEP for this as well as other load balancing use cases.
>
> See the link that describes this, as well as list possible ways to achieve
> this. Please provide your feedback on the list or during the WG session.
>
> https://github.com/dhruvdhody-huawei/105/blob/master/multiple_ERO_jl03a.pdf
>
> Thanks,
> Mike.
>
> ___
> 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

Re: [Pce] Quick Review of SR Inter-domain and association

[Dhruv Dhody]

Hi Quan,

First of all thanks for your reply to the list...

On Wed, Jul 17, 2019 at 8:43 AM  wrote:

>
> Hi Dhruv,
>
>
> Thanks for your review and suggestions! It is very appreciated!
>
> My clarification is as follows tagged with Quan>>.
>
>
> Best Regards,
>
> Quan
>
>
> <
> < <
> --
>
> (1) Association:
>
> It is important to describe where this association exist and what role
> does that play, to me the importance of the association is at the
> Parent PCE only and thus the existing Stateful H-PCE [1] procedures
>
> should be enough IMHO.
> See figure 2 in your I-D, ASSOC 1 LSPs are distributed between all the
> other child PCEs and thus not at clear why a child PCE need to be
> aware of the association when it does not know any other LSP (outside
>
> of its domain, that are part of the same association group).
>
>
> Quan>>I agree with you and thanks for your suggestion. The Stitching LSP
>
> association is created and maintained at parent PCE. The Stitching LSP
>
> association is used in inter-Area scenario. The association is useful
> when the
>
>  LSPs from multiple domains are aready created and the parent PCE may
>
>  associate them into a group and achieve the end-to-end LSP. I will
> update
>
> and clarify the use case and the detailed operation  as following shown.
>
>
>
>
Dhruv: The key question is why does the child PCE (PCE-1,2,3) needs to be
aware of this association once it is created at the parent PCE? In other
words what do you expect the child PCE to do when it receives a PCUpd
message with the association information? Answering this question would
help to clarify the need.

>
> (2) Path Segment:
>
> I saw the spring I-D [2] as well, and was thrown by the use of path
> segment as a way to stitch. My gut feeling was isn't that more like a
> binding segment? Also for stitching label in PCE, please check
> Olivier's I-D [3].
> So, some clarity on what exactly you would like to achieve and the
> reason behind the use of association and path segment is required.
>
> Quan>>I have compared my draft with [3] before. I think my draft focus on
>
> the SR inter-domain scenario and provide end-to-end solution with path
>
> segment. The path segment is the path identifier and it can be used to
>
> correlate SR paths. When the path segment is used to correlate two
>
> inter-domain LSPs, it is used as a stitching label and the path segment
>
> in SR networks can be viewed as an instantiation or specific application
>
> for the stitching label which proposed in draft[3]. The path segment used
>
> as a stitching label in inter-AS scenario as following shown.
>
>
>
Dhruv: I understand what you want to achieve, but I am not able to grasp
why use Path segment for it. Anyways the use of path segment in this way
should get consensuses in SPRING WG first.

Safe Travels!

Thanks!
Dhruv


>
> I hope you would focus on these aspects during your presentation.
> Discussion on the list would be even better.
>
> Thanks,
> Dhruv
>
> [1] https://tools.ietf.org/html/draft-ietf-pce-stateful-hpce-11
> [2]
> https://tools.ietf.org/id/draft-xiong-spring-path-segment-sr-inter-domain-00.txt
> [3] https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdomain-02
>
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Mike Koldychev (mkoldych)]

Hi Cyril,

Thanks a lot for your feedback!

Maybe I need to make it clear that the problem we’re trying to solve is a 
single optimization objective resulting in multiple ECMP/UCMP paths. This is 
motivated by SR-TE Policy use case, where each Candidate Path represents a 
single optimization objective. The Candidate Path has a set of Segment Lists 
that satisfy the optimization objective.

You seem to want to solve a different problem: two or more different 
optimization objectives and each ECMP path is mapped to a different objective. 
In that case Solution 1 is absolutely necessary and it would not have any of 
the down-sides, because the PCC knows in advance how many optimization 
objectives it has and can create that many PCEP LSPs. However for our problem, 
Solution 1 would introduce a lot of implementation complexity and protocol 
overhead.

We have a side-meeting scheduled on Wednesday at 8:30 to discuss this topic, 
you are welcome to attend if you want to contribute your input.

Thanks,
Mike.

From: Cyril Margaria 
Sent: Friday, July 19, 2019 9:37 AM
To: Mike Koldychev (mkoldych) 
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set of 
EROs/Label switch paths using RFC6007, including multi-domain and multi-PCEs 
scenarios. This can be used for computing a set of EROs for SR candidate paths, 
one case that can apply to the candidate path and explicitly mentioned by the 
RFC is "Two or more end-to-end diverse paths".  This does not cover the 
stateful PCE case directly, but there are similar situations to what RFC6007 in 
the form of path protection (primary/secondary/standby) for statefull PCE, 
which use the association mechanism. Those two existing mechanism exists to 
coordinate several paths and could be used to indicate how multiple paths are 
related and on how to signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated 
LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to be 
an advantage as its less restrictive. Having the same restriction on a set of 
paths is easy, relaxing a restriction on the ERO #5 is more complicated (in 
term of encoding).
  - There is a set of options to achieve the "signal the set of paths together":
 a)  set of LSPs can be reported in the same message, it can be enforced by 
the document defining that specific association type.
 b) SVEC/SVEC List can be extended to statefull PCEP,

That solution would work in case of multi-domain PCEs, and also be helpful for 
OAM and auto-bw mechanism.
As a segment list is one path in the network, that maps nicely to one LSP.


Solution 2:
  - This limit the set of constraints to be applied, policies like "10% of the 
traffic does not need to be protected" cannot be expressed (it can be with 
solution 1, clear L bit of LSPA on one TE-LSP out of 10)
  - 2.a when the LSP is reported down : which ERO is down?, the same is 
applicable for auto-bw and any form of OAM data.
  - Solution 2.b allows for Optimized branch encoding, that should be disabled 
for that solution


Slide "Comparison of Solutions":
   - There are solutions to most of the points raised for solution 1
   - The database problem seems specific to one implementation, other 
implementation will have the problem for solution 2
   -  multi-PCE and multi-domain are not evaluated. Solutions and consideration 
are available for solution 1, not for solution 2. (experimental Inter-domain 
P2MP tree solutions exists).

Best Regards,
Cyril

On Fri, 12 Jul 2019 at 22:02, Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi WG,

As per SPRING WG, SR Policy may contain multiple Candidate Paths and each 
Candidate Path may contain multiple Segment Lists. Existing SR standards in 
PCEP allow only a single ERO (one Segment List) for the SR Path in a stateful 
PCEP message. There is a need to signal multiple Segment Lists in PCEP for this 
as well as other load balancing use cases.

See the link that describes this, as well as list possible ways to achieve 
this. Please provide your feedback on the list or during the WG session.

https://github.com/dhruvdhody-huawei/105/blob/master/multiple_ERO_jl03a.pdf

Thanks,
Mike.

___
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

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Cyril Margaria]

Hi Mike,

One of my point is that one optimization is a peculiar case of n
optimization. For the particuliar case of candidate path, it can be
attached to a given association, each TE-LSP can have the same optimization
criterias.

I understand the argument for Option 2 as "I want to carry and manage my
constraint  (and candidate path) as one PCEP entity", the drawback is that
it will become complicated in case of inter-domain and OAM which are per
path.
The case for option 1 is one path, one LSP, but as you pointed out it
becomes complicated when there is one candidate path that desire a behavior
similar to  LOAD-BALANCING where the PCC ask the PCE to decide how many
path are needed.

I think that option 1 is better in term of protocol reuse and will offer
more flexibility, but that depends on how to deal with the PCE-managed
number of paths.

I will not attend the IETF meeting,

Best regards,
Cyril



On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) 
wrote:

> Hi Cyril,
>
>
>
> Thanks a lot for your feedback!
>
>
>
> Maybe I need to make it clear that the problem we’re trying to solve is a
> single optimization objective resulting in multiple ECMP/UCMP paths. This
> is motivated by SR-TE Policy use case, where each Candidate Path represents
> a single optimization objective. The Candidate Path has a set of Segment
> Lists that satisfy the optimization objective.
>
>
>
> You seem to want to solve a different problem: two or more different
> optimization objectives and each ECMP path is mapped to a different
> objective. In that case Solution 1 is absolutely necessary and it would not
> have any of the down-sides, because the PCC knows in advance how many
> optimization objectives it has and can create that many PCEP LSPs. However
> for our problem, Solution 1 would introduce a lot of implementation
> complexity and protocol overhead.
>
>
>
> We have a side-meeting scheduled on Wednesday at 8:30 to discuss this
> topic, you are welcome to attend if you want to contribute your input.
>
>
>
> Thanks,
>
> Mike.
>
>
>
> *From:* Cyril Margaria 
> *Sent:* Friday, July 19, 2019 9:37 AM
> *To:* Mike Koldychev (mkoldych) 
> *Cc:* pce@ietf.org
> *Subject:* Re: [Pce] Proposal for signaling ECMP or UCMP paths
>
>
>
> Hi,
>
>
>
> On slide "LSP objectives and constraints": Stateless  PCE can compute set
> of EROs/Label switch paths using RFC6007, including multi-domain and
> multi-PCEs scenarios. This can be used for computing a set of EROs for SR
> candidate paths, one case that can apply to the candidate path and
> explicitly mentioned by the RFC is "Two or more end-to-end diverse
> paths".  This does not cover the stateful PCE case directly, but there are
> similar situations to what RFC6007 in the form of path protection
> (primary/secondary/standby) for statefull PCE, which use the association
> mechanism. Those two existing mechanism exists to coordinate several paths
> and could be used to indicate how multiple paths are related and on how to
> signal them together (SVEC)
>
>
>
> On slide "Analysis of Solution 1":
>   - For PCC-Initated LSPs: what prevents the PCE to to create
> PCE-Initiated LSPs using the same association id? This would tackle the
> problem.
>
>   - The possibility of each path to have different objective does seems to
> be an advantage as its less restrictive. Having the same restriction on a
> set of paths is easy, relaxing a restriction on the ERO #5 is more
> complicated (in term of encoding).
>   - There is a set of options to achieve the "signal the set of paths
> together":
>  a)  set of LSPs can be reported in the same message, it can be
> enforced by the document defining that specific association type.
>
>  b) SVEC/SVEC List can be extended to statefull PCEP,
>
>
> That solution would work in case of multi-domain PCEs, and also be helpful
> for OAM and auto-bw mechanism.
>
> As a segment list is one path in the network, that maps nicely to one LSP..
>
>
>
>
>
> Solution 2:
>
>   - This limit the set of constraints to be applied, policies like "10% of
> the traffic does not need to be protected" cannot be expressed (it can be
> with solution 1, clear L bit of LSPA on one TE-LSP out of 10)
>
>   - 2.a when the LSP is reported down : which ERO is down?, the same is
> applicable for auto-bw and any form of OAM data.
>
>   - Solution 2.b allows for Optimized branch encoding, that should be
> disabled for that solution
>
>
>
>
>
> Slide "Comparison of Solutions":
>
>- There are solutions to most of the points raised for solution 1
>
>- The database problem seems specific to one implementation, other
> implementation will have the problem for solution 2
>
>-  multi-PCE and multi-domain are not evaluated. Solutions and
> consideration are available for solution 1, not for solution 2.
> (experimental Inter-domain P2MP tree solutions exists).
>
>
>
> Best Regards,
>
> Cyril
>
>
>
> On Fri, 12 Jul 2019 at 22:02, Mike Koldychev (mkoldych) <
> mkold...@cisco.com> wrote:
>

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Mike Koldychev (mkoldych)]

Hi Cyril,

Like I wrote in the slides… Solution 1 may work if you *only* do PCE-initiated, 
because the PCC never requests anything from the PCE, it simply installs 
whatever the PCE pushes down. Even for PCE-initiated, there are some issues, 
such as forcing the PCE to encode all the LSP objects into one message, to 
force them to get installed at the same time. Also you would need to handle 
fragmentation, if you cannot fit all the LSPs into a single message.

Thanks,
Mike.

From: Cyril Margaria 
Sent: Friday, July 19, 2019 12:23 PM
To: Mike Koldychev (mkoldych) 
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi Mike,

One of my point is that one optimization is a peculiar case of n optimization. 
For the particuliar case of candidate path, it can be attached to a given 
association, each TE-LSP can have the same optimization criterias.

I understand the argument for Option 2 as "I want to carry and manage my 
constraint  (and candidate path) as one PCEP entity", the drawback is that it 
will become complicated in case of inter-domain and OAM which are per path.
The case for option 1 is one path, one LSP, but as you pointed out it becomes 
complicated when there is one candidate path that desire a behavior similar to  
LOAD-BALANCING where the PCC ask the PCE to decide how many path are needed.

I think that option 1 is better in term of protocol reuse and will offer more 
flexibility, but that depends on how to deal with the PCE-managed number of 
paths.

I will not attend the IETF meeting,

Best regards,
Cyril



On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi Cyril,

Thanks a lot for your feedback!

Maybe I need to make it clear that the problem we’re trying to solve is a 
single optimization objective resulting in multiple ECMP/UCMP paths. This is 
motivated by SR-TE Policy use case, where each Candidate Path represents a 
single optimization objective. The Candidate Path has a set of Segment Lists 
that satisfy the optimization objective.

You seem to want to solve a different problem: two or more different 
optimization objectives and each ECMP path is mapped to a different objective. 
In that case Solution 1 is absolutely necessary and it would not have any of 
the down-sides, because the PCC knows in advance how many optimization 
objectives it has and can create that many PCEP LSPs. However for our problem, 
Solution 1 would introduce a lot of implementation complexity and protocol 
overhead.

We have a side-meeting scheduled on Wednesday at 8:30 to discuss this topic, 
you are welcome to attend if you want to contribute your input.

Thanks,
Mike.

From: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Sent: Friday, July 19, 2019 9:37 AM
To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set of 
EROs/Label switch paths using RFC6007, including multi-domain and multi-PCEs 
scenarios. This can be used for computing a set of EROs for SR candidate paths, 
one case that can apply to the candidate path and explicitly mentioned by the 
RFC is "Two or more end-to-end diverse paths".  This does not cover the 
stateful PCE case directly, but there are similar situations to what RFC6007 in 
the form of path protection (primary/secondary/standby) for statefull PCE, 
which use the association mechanism. Those two existing mechanism exists to 
coordinate several paths and could be used to indicate how multiple paths are 
related and on how to signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated 
LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to be 
an advantage as its less restrictive. Having the same restriction on a set of 
paths is easy, relaxing a restriction on the ERO #5 is more complicated (in 
term of encoding).
  - There is a set of options to achieve the "signal the set of paths together":
 a)  set of LSPs can be reported in the same message, it can be enforced by 
the document defining that specific association type.
 b) SVEC/SVEC List can be extended to statefull PCEP,

That solution would work in case of multi-domain PCEs, and also be helpful for 
OAM and auto-bw mechanism.
As a segment list is one path in the network, that maps nicely to one LSP.


Solution 2:
  - This limit the set of constraints to be applied, policies like "10% of the 
traffic does not need to be protected" cannot be expressed (it can be with 
solution 1, clear L bit of LSPA on one TE-LSP out of 10)
  - 2.a when the LSP is reported down : which ERO is down?, the same is 
applicable for auto-bw and any form of OAM data.
  - Solution 2.b allows for Optimized branch encoding, that should b

Re: [Pce] Updated slides

[Mike Koldychev (mkoldych)]

Hi Dhruv,

I made a couple of minor spelling corrections and uploaded my latest version 
here:
https://github.com/mkoldych-cisco/ietf105/blob/master/multiple_ERO_jl18a.pptx

I plan to finalize it after the side-meeting on Wednesday.

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Friday, July 19, 2019 6:10 PM
To: Mike Koldychev (mkoldych) 
Subject: Updated slides

Hi Mike,

Do you have updated slides for 3.1. Supporting Multiple ERO (SID-List) in PCEP?

Thanks!
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce