Re: [Pce] PCReq changing state - draft-koldychev-pce-operational

[Mike Koldychev (mkoldych)]

Hi Andrew,

Thanks for the feedback, yes I think we can use absence of LSP object to mean 
“truly stateless” PCReq.

To WG,

Also wanted to address a couple of comments that were mentioned about 
Association being a container for Tunnels vs container for LSPs. The reason why 
we said it’s a container for LSPs is because it has implications on signaling. 
For example when Tunnel T1 has LSP 1 and creates another LSP 2 as part of MBB, 
then if we say that the tunnel is already in some Association then it would 
imply that the PCC does not have to include the Association object in the PCRpt 
message of LSP 2, when first reporting it. Since, LSP 2 would just “inherit” 
the Association membership of T1. On the other hand, if we say that Association 
is a container for LSPs, then LSP 2 PCRpt would need to contain the Association 
object. Clearly if two vendors interpret this differently, then they could look 
at the same PCEP messages, but end up in different ASSO-DB states! So a single 
rule is needed for how to update ASSO-DB.

If we consider disjoint path association, for example if there’s two Tunnels: 
T1 and T2 that are disjoint. Suppose T1 has two LSPs, because it’s going 
through MBB (without changing disjointness type). Then the disjoint Association 
would contain 3 LSPs:

A1 = [T1.LSP1, T1.LSP2, T2.LSP1].

It is understood that this *does not* mean that these 3 LSPs are 3-way disjoint 
from each other. It simply means that T1 and T2 are requesting disjoint paths.

Thanks,
Mike.

From: Stone, Andrew (Nokia - CA/Ottawa) 
Sent: Thursday, July 25, 2019 2:15 PM
To: pce@ietf.org; Mike Koldychev (mkoldych) 
Subject: Re: PCReq changing state - draft-koldychev-pce-operational

Hi Mike and WG,

First, wanted to say thanks for driving draft-koldychev-pce-operational as 
there’s definitely a need for it.

To expand on my comments a bit more from today, the concern I have is with the 
following statement:


“the PCE MUST NOT modify LSP-DB state based on PCReq messages. “

Existing implementation(s) already deployed may choose to do reservations in 
their LSP-DB/TEDB from a PCReq, this is primarily in the case of bandwidth 
allocation. Ex: PCE gives out bandwidth to LSP1 from PCReq1 and PCE wants to 
ensure it doesn’t give out the same BW to LSP2 PCReq2 that immediately follows. 
Since there should be no expectation of a PCRep to follow a PCReq , these 
implementations likely rely on a timeout mechanism to release the resources 
when no PCRep is received.

I believe the language should be changed to something such as “PCE MAY modify 
LSP-DB state, but MUST NOT require a PCRep message to follow a PCReq” to 
clarify this.

From the discussions, my understanding is there are 2 main reasons for why this 
statement was originally added:


  1.  Some vendors may have required PCReq to be sent before PCRep
  2.  The desire for a stateful PCE to do truly stateless PCReq for other 
purposes such as OAM

Item (1) is covered in other statements in the draft, which I’m good with.
Item (2) causes a problem(creating state, timeout for resource release) for 
those implementations which do make reservations (i.e above).

For (2), Is there another way in which we can indicate to PCE to truly treat 
the PCReq as being stateless?

For example, LSPObject is optional in the PCREQ. In the absence of LSPObject in 
the request, PCE cannot make a reservation.  Therefore, for stateless PCReq, do 
not include LSPObject in my PCReq.

Are there use cases in which the need for a stateless PCReq (for example OAM) 
to also include the LSPObject/LSP identifiers?  (I haven’t thought through this 
TBH)

If no: then the absence of that object tells PCE to not do reservation
If yes: then I think we may want to consider another flag to mark the PCReq as 
being truly stateless, when it’s being sent to a stateful PCE.

Thanks
Andrew
___
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 Jeff, and WG,

To follow up on your comment about making these 2 separate documents: one for 
ECMP within a single LSP and another for ECMP among different LSPs.

That may be a good idea, since the mechanisms for achieving these two are quite 
different, so they are better kept separate. Just as long as it’s understood 
that they are not “conflicting” solutions.

Thanks,
Mike.

From: Mike Koldychev (mkoldych)
Sent: Tuesday, July 23, 2019 9:03 AM
To: Mike Koldychev (mkoldych) ; Cyril Margaria 

Cc: pce@ietf.org
Subject: RE: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

I have updated the slides based on our discussion.

https://github.com/mkoldych-cisco/ietf105/blob/master/pcep_multiple_ERO.pptx

We plan to discuss the issue further on Wednesday at 8:30 at the side meeting.

https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings

Thanks,
Mike.

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of Mike 
Koldychev (mkoldych)
Sent: Friday, July 19, 2019 1:03 PM
To: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

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 mailto:cyril.marga...@gmail.com>>
Sent: Friday, July 19, 2019 12:23 PM
To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
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 

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

[Jeff Tantsura]

Mike,

Thanks for the consideration.
That was exactly my point, having a number of different drafts that are short, 
concise and focused on a particular problem has always been my preference.
The use cases are different, while they don’t conflict they are also don’t 
“require” each other. It is perfectly fine for drafts to reference each other 
and outline the interdependencies, if any.

Cheers,
Jeff
On Jul 26, 2019, 5:55 AM -0400, Mike Koldychev (mkoldych) , 
wrote:
> Hi Jeff, and WG,
>
> To follow up on your comment about making these 2 separate documents: one for 
> ECMP within a single LSP and another for ECMP among different LSPs..
>
> That may be a good idea, since the mechanisms for achieving these two are 
> quite different, so they are better kept separate. Just as long as it’s 
> understood that they are not “conflicting” solutions.
>
> Thanks,
> Mike.
>
> From: Mike Koldychev (mkoldych)
> Sent: Tuesday, July 23, 2019 9:03 AM
> To: Mike Koldychev (mkoldych) ; Cyril Margaria 
> 
> Cc: pce@ietf.org
> Subject: RE: [Pce] Proposal for signaling ECMP or UCMP paths
>
> Hi,
>
> I have updated the slides based on our discussion.
>
> https://github.com/mkoldych-cisco/ietf105/blob/master/pcep_multiple_ERO.pptx
>
> We plan to discuss the issue further on Wednesday at 8:30 at the side meeting.
>
> https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings
>
> Thanks,
> Mike.
>
> From: Pce  On Behalf Of Mike Koldychev (mkoldych)
> Sent: Friday, July 19, 2019 1:03 PM
> To: Cyril Margaria 
> Cc: pce@ietf.org
> Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths
>
> 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)  
> 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 dive