Subject: [Pce] Fwd: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt

From: Edward Crabbe <[email-masked]>
Date: Sun, 16 Oct 2011 22:33:19 -0700

Hello;

We've submitted a draft for the group's consideration.  We know that
stateful PCE has been discussed by the working group in the past. We believe
that we have addressed some of the issues that have been raised in previous
discussions and have specific use cases that make stateful PCE valuable. We
hope you'll find the time to look through the draft and comment on the list
before the WG meeting in Taipei, and hope that we'll be able to have a
fruitful and lively discussion there.

best,

   -Edward

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Oct 16, 2011 at 7:51 PM
Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been
successfully submitted by Edward Crabbe and posted to the IETF repository.

Filename:        draft-crabbe-pce-stateful-pce
Revision:        00
Title:           PCEP Extensions for Stateful PCE
Creation date:   2011-10-16
WG ID:           Individual Submission
Number of pages: 39

Abstract:
  The Path Computation Element Communication Protocol (PCEP) provides
  mechanisms for Path Computation Elements (PCEs) to perform path
  computations in response to Path Computation Clients (PCCs) requests.

  Although PCEP explicitly makes no assumptions regarding the
  information available to the PCE, it also makes no provisions for
  synchronization or PCE control of timing and sequence of path
  computations within and across PCEP sessions.  This document
  describes a set of extensions to PCEP to enable this functionality,
  providing stateful control of Multiprotocol Label Switching (MPLS)
  Traffic Engineering Label Switched Paths (TE LSP) via PCEP.

The IETF Secretariat

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Oct 2011 13:39:49 +0100

Hi Ed,
 
Interesting work, thanks. As you know, the concept of stateful PCE was in our
minds all through the architecture phase of PCE and is included as a concept in
RFC 4655.
 
I think stateful PCE was left on one side over the last few years because it
added complexity and the use cases were far more sophisticated than applied to
initial use cases. But now that PCE is established as an idea, it is interesting
to look at the more advanced uses that you describe and see how stateful PCE
could be a benefit.
 
It is good that you have a section on policy, because it is likely that
operators will want to tweak this function in different ways according to how
they run their networks. It might be interesting to make a reference to RFC 5394
and show how that description of policy fits in. Maybe the authors of 5394 could
comment?
 
You don't mention RFC 5557. Is this because you think GCO is too complex to be
valuable or because it is not one of your primary use cases?
 
Thanks,
Adrian
 
From: Edward Crabbe [mailto:[email-masked]] 
Sent: 17 October 2011 06:33
To: [email-masked]
Cc: JP Vasseur; Julien Meuric
Subject: Fwd: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt
 
Hello;
 
We've submitted a draft for the group's consideration.  We know that stateful
PCE has been discussed by the working group in the past. We believe that we have
addressed some of the issues that have been raised in previous discussions and
have specific use cases that make stateful PCE valuable. We hope you'll find the
time to look through the draft and comment on the list before the WG meeting in
Taipei, and hope that we'll be able to have a fruitful and lively discussion
there.  
 
best,
 
   -Edward
 
---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Oct 16, 2011 at 7:51 PM
Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been successfully
submitted by Edward Crabbe and posted to the IETF repository.

Abstract:

The IETF Secretariat

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 18 Oct 2011 18:32:10 -0700

Adrian;

I think not mentioning 5557 is clearly an oversight on our part.  We will
remedy this in the next version of the draft.

Optimization of resource usage is certainly an interesting use case for
stateful PCE (although by no means the only one), and the draft would
benefit from a comparison with what is achievable via stateful extensions
relative to 5557.

Global control of LSP operation sequence in 5557 is predicated on the use of
what is effectively a stateful (or semi-stateful) NMS, which is either not
local to the switch (in which case we are required to use another northbound
interface for LSP attribute changes) or local/collocated, in which case we
have some significant issues with efficiency in resource usage.

Stateful adds a few features here in that:

1) the requirements for the NMS and additional northbound interface are
effectively removed
2) it allows the system with the greatest visibility of the system to
determine
which LSPs should reoptimized and on what time interval
3) the pce controls the sequence of events across pcc's, allowing for bulk
(if not global) optimization, lsp shuffling etc

Thanks much for pointing out the oversight.  :-/

best,

  -ed

On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel <[email-masked]> wrote:

> Hi Ed,****
>
> ** **
>
> Interesting work, thanks. As you know, the concept of stateful PCE was in
> our minds all through the architecture phase of PCE and is included as a
> concept in RFC 4655.****
>
> ** **
>
> I think stateful PCE was left on one side over the last few years because
> it added complexity and the use cases were far more sophisticated than
> applied to initial use cases. But now that PCE is established as an idea, it
> is interesting to look at the more advanced uses that you describe and see
> how stateful PCE could be a benefit.****
>
> ** **
>
> operators will want to tweak this function in different ways according to
> how they run their networks. It might be interesting to make a reference to
> RFC 5394 and show how that description of policy fits in. Maybe the authors
> of 5394 could comment?****
>
> ** **
>
> You don't mention RFC 5557. Is this because you think GCO is too complex to
> be valuable or because it is not one of your primary use cases?****
>
> ** **
>
> Thanks,****
>
> Adrian****
>
> ** **
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* 17 October 2011 06:33
> *To:* [email-masked]
> *Cc:* JP Vasseur; Julien Meuric
> *Subject:* Fwd: New Version Notification for
> draft-crabbe-pce-stateful-pce-00.txt****
>
> ** **
>
> Hello;****
>
> ** **
>
> fruitful and lively discussion there.  ****
>
> ** **
>
> best,****
>
> ** **
>
>    -Edward****
>
> ** **
>
> The IETF Secretariat****
> ** **

---

From: Jan Medved <[email-masked]>
Date: Wed, 19 Oct 2011 23:55:13 -0700

Hi Adrian

Good point about policy. The current revision of draft-crabbe-pce-stateful-pce only covers only basic policy settings for the PCC. We also need to cover PCE-side policies, inter-component communication (e.g. what information must be carried in State Reports form a PCE for use of a policy implemented on a PCE), etc.

IMO the PCE/PCC policy framework defined in RFC5394 by and large applies to stateful PCEs as well. There will be stateful PCEP–specific use cases and examples, policy attributes, and inter-component communication.  They would  need to be identified and documented.But the overall framework should be directly applicable.

Thanks,
Jan

On 10/18/11 5:39 AM, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ed,

Interesting work, thanks. As you know, the concept of stateful PCE was in our minds all through the architecture phase of PCE and is included as a concept in RFC 4655.

I think stateful PCE was left on one side over the last few years because it added complexity and the use cases were far more sophisticated than applied to initial use cases. But now that PCE is established as an idea, it is interesting to look at the more advanced uses that you describe and see how stateful PCE could be a benefit.

It is good that you have a section on policy, because it is likely that operators will want to tweak this function in different ways according to how they run their networks. It might be interesting to make a reference to RFC 5394 and show how that description of policy fits in. Maybe the authors of 5394 could comment?

You don't mention RFC 5557. Is this because you think GCO is too complex to be valuable or because it is not one of your primary use cases?

Thanks,
Adrian

To: [email-masked]<mailto:[email-masked]>

Hello;

We've submitted a draft for the group's consideration.  We know that stateful PCE has been discussed by the working group in the past. We believe that we have addressed some of the issues that have been raised in previous discussions and have specific use cases that make stateful PCE valuable. We hope you'll find the time to look through the draft and comment on the list before the WG meeting in Taipei, and hope that we'll be able to have a fruitful and lively discussion there.

best,

   -Edward

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Sun, Oct 16, 2011 at 7:51 PM
Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been successfully submitted by Edward Crabbe and posted to the IETF repository.

Abstract:

The IETF Secretariat

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 25 Oct 2011 22:57:38 -0700

Hi Ed,

I agree these are important usecases to consider in defining a new
architecture for PCE.

Thanks,
Vishwas
On Tue, Oct 18, 2011 at 6:32 PM, Edward Crabbe <[email-masked]> wrote:

> Global control of LSP operation sequence in 5557 is predicated on the
> use of what is effectively a stateful (or semi-stateful) NMS, which is
> either not local to the switch (in which case we are required to use
> another northbound interface for LSP attribute changes) or local/collocated,
> in which case we have some significant issues with efficiency in
> resource usage.
>
> On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel <[email-masked]>wrote:
>
>>  Hi Ed,****
>>
>> ** **
>>
>> You don't mention RFC 5557. Is this because you think GCO is too complex
>> to be valuable or because it is not one of your primary use cases?****
>>
>> ** **
>>
>> Thanks,****
>>
>> Adrian****
>>
>> ** **
>>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>