Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ?

From: Julien Meuric <[email-masked]>
Date: Wed, 11 Apr 2012 16:39:20 +0200

Hi Meral.

I believe the freshly posted minutes bring an answer to you question.

Beyond the generic scope in which this I-D was presented, I feel the 
advantages and drawbacks of that proposal are off balance. On the one 
hand, focusing on a single PCE solution removes a lot from the PCE 
architecture (or requires heavy complementary mechanisms, i.e. yet 
another strong shortcoming). On the other hand, it aims at "saving a few 
crankbacks" (quoting Oscar) in the control plane, which is likely to end 
up by saving a negligible time with respect to the data plane timescale, 
especially for WDM where the label resource is scarcer (1st and longer 
use case in the draft).
Finally, knowing that an implementation could make use of the proposed 
idea based on a simple PCE policy, such an unbalanced protocol extension 
seems more than questionable...

Regards,

Julien

Le 29/03/2012 19:55, Meral Shirazipour a écrit :
>
> Hi JP,
>
>   I may have missed part of the discussion today after Oscar 
> presented. What was the next step for draft: 
> http://tools.ietf.org/html/draft-gonzalezdedios-pce-reservation-state-01 ?
>
> Thanks,
>
> Meral
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 11 Apr 2012 13:53:28 -0400

Hi,
   Thank you for the reply. 
IMPO there is a need for such a functionality: if after all the PCEs processing work  we have to rely on crankback, then the question is why do we use PCEs at the first place. There may also be other use cases that can benefit from prereservation, and we should not only consider this from  a "cranckback saving" angle.

It seems that there are 2 distinct points to the discussion regarding the draft:
1- Consensus that there is a problem if resources are not pre-reserved. 
2- There are various ways to solve this problem, each with pros and cons.

I think point #1 is clear enough to anyone who faced or studied the problem. And if I recall correctly, the comments after Oscar's presentation (including those regarding the NMS-PCE relation) were all related to point #2 above. I think these comments can all be addressed by the wg. 

Best regards,
Meral

-----Original Message-----
From: Julien Meuric [mailto:[email-masked]] 
Sent: April-11-12 10:39 AM
To: Meral Shirazipour
Cc: JP Vasseur; [email-masked]
Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ?

Hi Meral.

Beyond the generic scope in which this I-D was presented, I feel the advantages and drawbacks of that proposal are off balance. On the one hand, focusing on a single PCE solution removes a lot from the PCE architecture (or requires heavy complementary mechanisms, i.e. yet another strong shortcoming). On the other hand, it aims at "saving a few crankbacks" (quoting Oscar) in the control plane, which is likely to end up by saving a negligible time with respect to the data plane timescale, especially for WDM where the label resource is scarcer (1st and longer use case in the draft).
Finally, knowing that an implementation could make use of the proposed idea based on a simple PCE policy, such an unbalanced protocol extension seems more than questionable...

Regards,

Julien

---

From: Leeyoung <[email-masked]>
Date: Wed, 11 Apr 2012 18:59:39 +0000

Hi Meral,

I agree with your analysis on Point #1. Many PCE implementations as far as I know use this kind of mechanism in place. Regarding comment on the use of crankback, this may not be the best mechanism to depend on especially when dealing with restoration situations which is one of the main applications for Oscar's draft. 

On Point #2, if PCE is the best mechanism to do this function is debatable; yet I think it is a good way to support this function. Again for restoration situations NMS based solution may not be the best choice due to timeliness factor. 

Regards,
Young 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meral Shirazipour
Sent: Wednesday, April 11, 2012 12:53 PM
To: Julien Meuric
Cc: [email-masked]; JP Vasseur
Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ?

Hi,
   Thank you for the reply. 

Best regards,
Meral

-----Original Message-----
From: Julien Meuric [mailto:[email-masked]] 
Sent: April-11-12 10:39 AM
To: Meral Shirazipour
Cc: JP Vasseur; [email-masked]
Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ?

Hi Meral.

Regards,

Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Apr 2012 14:21:52 +0100

Hi,

My two cents here as an individual are: optimise for the general case and be
very careful about optimising for the specific. The thing to avoid is complexity
that creeps into the general implementation in order to enhance behavior in a
corner case.

I am not commenting on whether this *is* a corner case. To do that I would have
to read the draft more carefully, but it seems to me that it is a question of
likely allocation congestion versus required setup speed. Having built and
deployed this stuff in optical equipment, I think that the existing signaling
mechanisms are usually enough.

However, I will note that many PCEs perform "sticky" reservations as a matter of
course (indeed many LSRs with head-end PCE functionality have done this since
the start of MPLS-TE). This has been a local policy and one that has not needed
protocol support. Indeed, how is a PCC to know whether reservations should be
sticky or not except by local policy configuration? And if so, isn't it easier
to configure the one or two PCEs rather than the very many PCCs?

Lastly, when looking at sticky reservations, and assuming there is an intent to
arrive at a "perfect" non-crankback situation, we would have to address
synchronisation across multiple PCEs.

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Leeyoung
> Sent: 11 April 2012 20:00
> To: Meral Shirazipour; Julien Meuric
> I agree with your analysis on Point #1. Many PCE implementations as far as I
know
> use this kind of mechanism in place. Regarding comment on the use of
crankback,
> this may not be the best mechanism to depend on especially when dealing with
> restoration situations which is one of the main applications for Oscar's
draft.
> 
> On Point #2, if PCE is the best mechanism to do this function is debatable;
yet I
> think it is a good way to support this function. Again for restoration
situations
> NMS based solution may not be the best choice due to timeliness factor.
> 
> Regards,
> Young
> 
> IMPO there is a need for such a functionality: if after all the PCEs
processing work
> we have to rely on crankback, then the question is why do we use PCEs at the
> first place. There may also be other use cases that can benefit from
> prereservation, and we should not only consider this from  a "cranckback
saving"
> angle.
> I think point #1 is clear enough to anyone who faced or studied the problem.
And
> if I recall correctly, the comments after Oscar's presentation (including
those
> regarding the NMS-PCE relation) were all related to point #2 above. I think
these
> comments can all be addressed by the wg.
> 
> Best regards,
> Meral
> 
> 
> 
> 
advantages
> and drawbacks of that proposal are off balance. On the one hand, focusing on a
> single PCE solution removes a lot from the PCE architecture (or requires heavy
> complementary mechanisms, i.e. yet another strong shortcoming). On the other
> hand, it aims at "saving a few crankbacks" (quoting Oscar) in the control
plane,
> which is likely to end up by saving a negligible time with respect to the data
plane
> timescale, especially for WDM where the label resource is scarcer (1st and
longer
> use case in the draft).
> Finally, knowing that an implementation could make use of the proposed idea
> based on a simple PCE policy, such an unbalanced protocol extension seems
> more than questionable...
> 
> Regards,
> 
> Julien
> 
>