Subject: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

From: Oscar González de Dios <[email-masked]>
Date: Wed, 07 Nov 2012 22:04:10 +0000

Dear PCE WG chairs,

                In the last PCE meeting, it was mentioned by the WG chairs that the function of LSP initiation by the PCE  (presented in the draft draft-crabbe-pce-pce-initiated-lsp-00) is out of the scope of current WG charter. Current IETF stateful PCE draft () supports the function of delegation, which is an operation to grant a PCE temporary rights to modify a subset of tunnel parameters on one or more PCC's tunnels. However, current charter (http://datatracker.ietf.org/wg/pce/charter/) says nothing about this function, but the draft was (surprisingly) quickly accepted as WG document. Current charter says "The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs." That is "computation", not control... So,  could you explain why initiation is not in charter and delegation of control is in charter?

                My opinion in the matter of the stateful PCE is that we should separate the functionality is different functional elements, in the same way as it was done in the Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In such RFC, the roles of each functional element are clearly distinguished. Let be the stateful PCE a Path Computation element using the traffic engineering database and the LSP database, and then, define another functional element (call it LSP controller, call it manager) that is in care of the control issues.

                Said that, I must say that I like the new functionalities proposed , and I think they solve problems (and people also did like them, as the stateful draft was supported by the WG people). What I do not like at all is how it is being handled. There has been a solution quickly adopted without taking any care in the architectural/functional implications. In my opinion we should handle them now.

                Best Regards,

                               Óscar

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 7 Nov 2012 17:58:28 -0500

Oscar, comments inline.

>                  In the last PCE meeting, it was mentioned by the WG
> chairs that the function of LSP initiation by the PCE  (presented in the
> draft draft-crabbe-pce-pce-initiated-lsp-00) is out of the scope of current
> WG charter. Current IETF stateful PCE draft () supports the function of
> delegation, which is an operation to grant a PCE temporary rights to modify
> a subset of tunnel parameters on one or more PCC's tunnels. However,
> current charter (http://datatracker.ietf.org/wg/pce/charter/) says
> nothing about this function, but the draft was (surprisingly) quickly
> accepted as WG document. Current charter says “The PCE Working Group is
> chartered to specify the required protocols so as to enable a Path
> Computation Element (PCE)-based architecture for the computation of paths
> for MPLS and GMPLS Point to Point and Point to Multi-point Traffic
> Engineered LSPs.” That is “computation”, not control… So,  could you
> explain why initiation is not in charter and delegation of control is in
> charter?
>

IMO: they're the same thing, the only difference is directionality and
asynchrony.

>                  My opinion in the matter of the stateful PCE is that we
> should separate the functionality is different functional elements, in the
> same way as it was done in the Framework for PCE-Based Inter-Layer MPLS and
> GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In such
> RFC, the roles of each functional element are clearly distinguished. Let be
> the stateful PCE a Path Computation element using the traffic engineering
> database and the LSP database, and then, define another functional element
> (call it LSP controller, call it manager) that is in care of the control
> issues.
>

This argument is orthogonal to the previous paragraph regarding the
charter;  let's separate the two discussions. ;)
w/r/t *element* separation: I think that's a poor idea, sorry.  It makes
total sense to me that a given PCE would be able to negotiate and support
stateful or stateless functionality.

>                 Said that, I must say that I like the new functionalities
> proposed , and I think they solve problems (and people also did like them,
> as the stateful draft was supported by the WG people). What I do not like
> at all is how it is being handled. There has been a solution quickly
> adopted without taking any care in the architectural/functional
> implications. In my opinion we should handle them now.
>

Define quickly man?  The original draft went through multiple rounds of
review both on list and in multiple (technically two but really three) IETF
meetings before acceptance.  It has received, as you said, broad support
and review by many people on the list, including you. ;) It is at a
relatively low rev count and is still a work in progress.

 best,
  -ed

---

From: Oscar González de Dios <[email-masked]>
Date: Thu, 08 Nov 2012 00:16:56 +0000

Hi Ed, answers inline,

IMO: they're the same thing, the only difference is directionality and asynchrony.
[Oscar] Agree.. Let's see what our WG chairs say.

This argument is orthogonal to the previous paragraph regarding the charter;  let's separate the two discussions. ;)
[Oscar] Agree, it's a separate discussion.

w/r/t *element* separation: I think that's a poor idea, sorry.  It makes total sense to me that a given PCE would be able to negotiate and support stateful or stateless functionality.
[Oscar] What I mean is to have a demarcation of the functional blocks. My problem is that I may be too picky, but I like to call things by its name... and for me still Path Computation refers to the computation function and not controlling. So path computation and control of a delegated LSP (or even initiation) are different functions, which are tightly connected to solve the problems. I guess when you refer to negotiate "stateful" functionality you are referring to negotiate the delegation+whatever control functionalities and not only the fact of using (and synchronizing) the LSP Database. The confusion may come from the fact you see the "stateful PCE" as the sum of a controller + a PCE + TEDB+LSPDB....  I like that entity, but, strictly speaking, it is more than a PCE ...... But it is only a matter of naming, we all have agreed that the functionality is needed, and that PCEP is a good protocol to support it.
I see this "controller" functional block as a generalization of the VNTM functional block defined in RFC 5623 for the specific case of controlling/managing an overlay network.

Define quickly man?  The original draft went through multiple rounds of review both on list and in multiple (technically two but really three) IETF meetings before acceptance.
 It has received, as you said, broad support and review by many people on the list, including you. ;) It is at a relatively low rev count and is still a work in progress.
[Oscar] And I do support it and like it! I meant quickly because it went through directly as a solution. Other pieces of work had to deal first with the framework/requirements and then jump in the solution, there are plenty of examples around, you can see the time of the first draft of the framework/requirements and the time of the adoption of the first WG solution.... (Interlayer, GMPLS, H-PCE)... This stateful PCE approach has a lot of implications, this is why I think we should take it with care and make it work together, with a clear architecture and make a good framework to have solid foundations.

 best,
  -ed

Best Regards,

                Óscar

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 8 Nov 2012 06:11:53 +0000

Hi Oscar, Ed and all,

I totally agree with Oscar.

I think we should follow the regular procedures of PCE WG (IETF as well) to define the foundation work first including FWK, requirement, applicability before dropping into the solution stuff.

Guidance from WG chairs on this stateful PCE work must be appreciated.

Best Regards

Fatai

发件人: [email-masked] [mailto:[email-masked]] 代表 Oscar González de Dios
发送时间: 2012年11月8日 8:17
收件人: Edward Crabbe
抄送: [email-masked]
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Hi Ed, answers inline,

IMO: they're the same thing, the only difference is directionality and asynchrony.
[Oscar] Agree.. Let’s see what our WG chairs say.

This argument is orthogonal to the previous paragraph regarding the charter;  let's separate the two discussions. ;)
[Oscar] Agree, it’s a separate discussion.

w/r/t *element* separation: I think that's a poor idea, sorry.  It makes total sense to me that a given PCE would be able to negotiate and support stateful or stateless functionality.
[Oscar] What I mean is to have a demarcation of the functional blocks. My problem is that I may be too picky, but I like to call things by its name… and for me still Path Computation refers to the computation function and not controlling. So path computation and control of a delegated LSP (or even initiation) are different functions, which are tightly connected to solve the problems. I guess when you refer to negotiate “stateful” functionality you are referring to negotiate the delegation+whatever control functionalities and not only the fact of using (and synchronizing) the LSP Database. The confusion may come from the fact you see the “stateful PCE” as the sum of a controller + a PCE + TEDB+LSPDB….  I like that entity, but, strictly speaking, it is more than a PCE …… But it is only a matter of naming, we all have agreed that the functionality is needed, and that PCEP is a good protocol to support it.
I see this “controller” functional block as a generalization of the VNTM functional block defined in RFC 5623 for the specific case of controlling/managing an overlay network.

Define quickly man?  The original draft went through multiple rounds of review both on list and in multiple (technically two but really three) IETF meetings before acceptance.
 It has received, as you said, broad support and review by many people on the list, including you. ;) It is at a relatively low rev count and is still a work in progress.
[Oscar] And I do support it and like it! I meant quickly because it went through directly as a solution. Other pieces of work had to deal first with the framework/requirements and then jump in the solution, there are plenty of examples around, you can see the time of the first draft of the framework/requirements and the time of the adoption of the first WG solution…. (Interlayer, GMPLS, H-PCE)… This stateful PCE approach has a lot of implications, this is why I think we should take it with care and make it work together, with a clear architecture and make a good framework to have solid foundations.

 best,
  -ed

Best Regards,

                Óscar

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 8 Nov 2012 02:57:10 -0500

AFAIK:

(a): we are getting guidance from the chairs on an ongoing basis and
(b): the solution and framework are coupled and are reasonably well defined
currently, modulo the (largely aesthetic) considerations raised

On Thu, Nov 8, 2012 at 1:11 AM, Fatai Zhang <[email-masked]> wrote:

>  Hi Oscar, Ed and all,****
>
> ** **
>
> I totally agree with Oscar. ****
>
> ** **
>
> I think we should follow the regular procedures of PCE WG (IETF as well)
> to define the foundation work first including FWK, requirement,
> applicability before dropping into the solution stuff. ****
>
> ** **
>
> Guidance from WG chairs on this stateful PCE work must be appreciated.****
>
> ** **
>
> ** **
>
> Best Regards****
>
> ** **
>
> Fatai****
>
> ** **
>
> *发件人:* [email-masked] [mailto:[email-masked]] *代表 *Oscar González
> de Dios
> *发送时间:* 2012年11月8日 8:17
> *收件人:* Edward Crabbe
> *抄送:* [email-masked]
> *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and
> opinion about stateful PCE****
>
> ** **
>
> Hi Ed, answers inline,****
>
>  ****
>
>  ****
>
> asynchrony. ****
> [Oscar] Agree.. Let’s see what our WG chairs say.****
>
>  ****
>
> issues.****
>   ****
> charter;  let's separate the two discussions. ;)****
>
> [Oscar] Agree, it’s a separate discussion.****
>
>  ****
>
> stateful or stateless functionality. ****
>
> [Oscar] What I mean is to have a demarcation of the functional blocks. My
> problem is that I may be too picky, but I like to call things by its name…
> and for me still Path Computation refers to the computation function and
> not controlling. So path computation and control of a delegated LSP (or
> even initiation) are different functions, which are tightly connected to
> solve the problems. I guess when you refer to negotiate “stateful”
> functionality you are referring to negotiate the delegation+whatever
> control functionalities and not only the fact of using (and synchronizing)
> the LSP Database. The confusion may come from the fact you see the
> “stateful PCE” as the sum of a controller + a PCE + TEDB+LSPDB….  I like
> that entity, but, strictly speaking, it is more than a PCE …… But it is
> only a matter of naming, we all have agreed that the functionality is
> needed, and that PCEP is a good protocol to support it.****
>
> I see this “controller” functional block as a generalization of the VNTM
> functional block defined in RFC 5623 for the specific case of
> controlling/managing an overlay network.****
>
>  ****
>
>                  Said that, I must say that I like the new
> functionalities proposed , and I think they solve problems (and people also
> did like them, as the stateful draft was supported by the WG people). What
> I do not like at all is how it is being handled. There has been a solution
> quickly adopted without taking any care in the architectural/functional
> implications. In my opinion we should handle them now.****
>
>   ****
>
> meetings before acceptance. ****
>
>  It has received, as you said, broad support and review by many people on
> the list, including you. ;) It is at a relatively low rev count and is
> still a work in progress.    ****
>
> [Oscar] And I do support it and like it! I meant quickly because it went
> through directly as a solution. Other pieces of work had to deal first with
> the framework/requirements and then jump in the solution, there are plenty
> of examples around, you can see the time of the first draft of the
> framework/requirements and the time of the adoption of the first WG
> solution…. (Interlayer, GMPLS, H-PCE)… This stateful PCE approach has a lot
> of implications, this is why I think we should take it with care and make
> it work together, with a clear architecture and make a good framework to
> have solid foundations.****
>
>  ****
>
>  best,****
>
>   -ed****
>
>  ****
>
> Best Regards,****
>
>  ****
>
>                 Óscar****
>
> ** **
>  ------------------------------
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx****
>

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 8 Nov 2012 15:52:18 +0100

Hi, 

I agree with oscar and Fatai The delegation/update and the initiation are related.

Regarding a) I recall the in the WG meeting,  one comment from the chairs  was the service request in RFC4655 is not part of the computation part.

In this regard it would be good to address those architectural points, but if we have some doubts we could ask network management related WGs ;-)

Regarding b) this does not prevent to clarify where does it fit in the PCE architecture.

Best regards / Mit freundlichen Grüßen

Cyril Margaria

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Edward Crabbe
Sent: Thursday, November 08, 2012 8:57 AM
To: Fatai Zhang
Cc: [email-masked]
Subject: Re: [Pce]答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

AFAIK:

(b): the solution and framework are coupled and are reasonably well defined currently, modulo the (largely aesthetic) considerations raised

Hi Oscar, Ed and all,

 

Best Regards

Fatai

Hi Ed, answers inline,

 best,

  -ed

Best Regards,

                Óscar

---

From: Julien Meuric <[email-masked]>
Date: Thu, 08 Nov 2012 22:40:45 +0100

Oscar, all,

There are multiple issues in your messages, let us try to address them 
step by step.

About the adoption of draft-crabbe-pce-stateful-pce, your choice of 
words suggests that you are taxing the chairs of a process failure in 
building a WG consensus. However, you finally agree not only that the 
consensus was there (and rather clear than rough), and also that you 
were yourself a supporter of the I-D. Please, try to carefully choose 
your wording to avoid misunderstanding.

I would also like to remind you 2 things:
- we are not talking about an RFC nor even an I-D in LC: it is part of 
the normal WG process to discuss documents so as to progress them;
- as mentioned previously 
(http://www.ietf.org/mail-archive/web/pce/current/msg02738.html), what 
was adopted by the WG was an I-D with a defined (and limited) scope; 
from that point, it seems that there is a certain will to embrace 
everything that could be tagged "stateful", however we need to limit our 
scope of work (architecture and charter) to a reasonable problem space.

Then, concerning our current scope, you certainly should have a fresh 
look at RFC 4655. E.g., section 6.12:
"It may be that the PCC-PCE communications (see Section 6.6) can be 
usefully extended beyond a simple request/response interaction.[...] 
Additionally, the protocol could be used to collect and report 
information in support of a stateful PCE."
We are not machines, but as chairs, we consider that the original 
draft-crabbe-pce-stateful-pce, which was adopted by the WG, was 
consistent with this statement (which, since included in an RFC, passed 
IESG review).

Now, let us look at the figure 2 in section 5.2 of the very same RFC. 
The service request is directed to the head-node, and to the head-node 
only. This means that our _current_ architecture does not cover the case 
where this service request is sent to a "PCE-tagged box", no matter how 
close the technical solutions for both functions might be. One may argue 
that the service request towards the head-node might come from the 
"PCE-tagged box", and thus use PCEP, but some response lies in section 
5.5 (figure 5): the service request is identified as different from 
PCEP, even if we pack the NMS and the PCE into a common box, and the 1st 
service request always comes from the outside (e.g. the operator).

As you are aware, one of the outputs from our meeting this week was to 
consider an update to the architecture and charter, so as to reflect the 
areas where the WG wants to head to. Note that, at one point, this will 
have to be discussed with the IESG (starting by our AD). If you have 
ideas to propose (and I'm sure you aren't the only one), then you should 
start to write that architectural draft you mention: it will be a useful 
element to bring to that discussion, especially because we need to 
identify the functional blocks we are talking about. As highlighted by 
Adrian (http://www.ietf.org/mail-archive/web/pce/current/msg02722.html), 
"we have previously found that scoping the PCE work to well-understood 
and contained problem spaces [...] has made our work concrete and 
functional" (and also eases charter approval by the IESG); therefore the 
WG needs to discuss in order to identify a possible update of its scope.

Thanks for sharing your thoughts on the list, this is needed to move 
forward.

Julien

On 11/07/2012 23:04, Oscar González de Dios wrote:
>
 > Dear PCE WG chairs,
 >
 >
 >
 > In the last PCE meeting, it was mentioned by the WG chairs that the
 > function of LSP initiation by the PCE (presented in the draft
 > draft-crabbe-pce-pce-initiated-lsp-00) is out of the scope of current
 > WG charter. Current IETF stateful PCE draft () supports the function
 > of delegation, which is an operation to grant a PCE temporary rights
 > to modify a subset of tunnel parameters on one or more PCC's tunnels.
 > However, current charter
 > (http://datatracker.ietf.org/wg/pce/charter/) says nothing about this
 > function, but the draft was (surprisingly) quickly accepted as WG
 > document. Current charter says “The PCE Working Group is chartered to
 > specify the required protocols so as to enable a Path Computation
 > Element (PCE)-based architecture for the computation of paths for
 > MPLS and GMPLS Point to Point and Point to Multi-point Traffic
 > explain why initiation is not in charter and delegation of control is
 > in charter?
 >
 >
 >
 > My opinion in the matter of the stateful PCE is that we should
 > separate the functionality is different functional elements, in the
 > same way as it was done in the Framework for PCE-Based Inter-Layer
 > MPLS and GMPLS Traffic Engineering (RFC 5623) between a VNTM and the
 > PCE. In such RFC, the roles of each functional element are clearly
 > distinguished. Let be the stateful PCE a Path Computation element
 > using the traffic engineering database and the LSP database, and
 > then, define another functional element (call it LSP controller, call
 > it manager) that is in care of the control issues.
 >
 >
 >
 > Said that, I must say that I like the new functionalities proposed ,
 > and I think they solve problems (and people also did like them, as
 > the stateful draft was supported by the WG people). What I do not
 > like at all is how it is being handled. There has been a solution
 > quickly adopted without taking any care in the
 > architectural/functional implications. In my opinion we should handle
 > them now.
 >
 >
 >
 > Best Regards,
 >
 >
 >
 > Óscar
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 > -------------------------
 >
 > Este mensaje se dirige exclusivamente a su destinatario. Puede
 > consultar nuestra política de envío y recepción de correo electrónico
 > en el enlace situado más abajo. This message is intended exclusively
 > for its addressee. We only send and receive email on the basis of the
 > terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 >
 >
 > _______________________________________________ Pce mailing list
 > [email-masked] https://www.ietf.org/mailman/listinfo/pce

---

From: Oscar González de Dios <[email-masked]>
Date: Thu, 08 Nov 2012 22:28:19 +0000

Hi Julien

        Thanks for the reply. As you said, there where several parts of the message. I will now limit to cover the discussion of the scope of LSP delegation and LSP incitation procedures in the charter. For the rest, I will reply in separate mails, in private if you want, in sake of advancing the discussions, and my apologies if my words have been misunderstood or sounded harsh. Comments inline

"Then, concerning our current scope, you certainly should have a fresh look at RFC 4655. E.g., section 6.12:
"It may be that the PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction.[...] Additionally, the protocol could be used to collect and report information in support of a stateful PCE."
We are not machines, but as chairs, we consider that the original draft-crabbe-pce-stateful-pce, which was adopted by the WG, was consistent with this statement (which, since included in an RFC, passed IESG review)."

[Oscar]: The state synchronization functions, aimed at (citing literally)  provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE are consistent with this statement, they are beyond simple request/response interactions and collect and report information in support of a stateful PCE. Thus, this function is perfectly OK with RFC 4555.

However, I see that the LSP delegation function goes beyond reporting information to support a stateful PCE. It instructs the PCE to take control of the LSP, and, during the life-time of the LSP, citing literally "the PCC grants to a PCE the right to update LSP attributes on one or more LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect". Thus, delegation function clearly is not used to provide information to support later path computation. So... unless I have mistaken the read of RFC 4655, it is explicitly mentioned that the PCE architecture is aimed at solving the problem of path computation. I may have jumped over some paragraph where it says that the role of a Path Computation Element (stateful o not stateful) is to take care of the control of an LSP... but I honestly cannot find such statement anywhere. So... could you give me some arguments why the delegation of control is in scope of current RFC 4655? (Of course the scope can be widened in future, so let's try to stick to current RFC 4655)

Best Regards,

        Óscar

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Fri, 9 Nov 2012 01:11:40 +0000

Hi Oscar,

please see inline.

On Nov 8, 2012, at 2:28 PM, Oscar González de Dios wrote:

> However, I see that the LSP delegation function goes beyond reporting information to support a stateful PCE. It instructs the PCE to take control of the LSP, and, during the life-time of the LSP, citing literally "the PCC grants to a PCE the right to update LSP attributes on one or more LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect". Thus, delegation function clearly is not used to provide information to support later path computation. So... unless I have mistaken the read of RFC 4655, it is explicitly mentioned that the PCE architecture is aimed at solving the problem of path computation.

The PCE is not limited to path computation only. The PCE can set other LSP parameters as well: RFC5440 defines objects for bandwidth, setup & hold priorities, the local protection flag, etc. More LSP parameters have been added in subsequent RFCs and drafts.
 
> I may have jumped over some paragraph where it says that the role of a Path Computation Element (stateful o not stateful) is to take care of the control of an LSP... but I honestly cannot find such statement anywhere. So... could you give me some arguments why the delegation of control is in scope of current RFC 4655?

The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq message to a PCE requesting path computation (and parameter setting) for an LSP, it effectively delegates control over that LSP to the PCE. The delegation is valid for one request (and one path computation) only. 

Now, the PCC may or may not use the LSP path/parameters that it got from the PCE. But why would the PCC not use the PCE-computed path & parameters, if we want the whole scheme to work? The PCC goes to the PCE for LSP path because the PCE can do a better job at path computation (and LSP parameter setting) that the PCC itself. The PCC would only throw away the PCE-computed LSP parameters if there was an error condition and the LSP could not be established (the PCC may in this case compute the path locally).

So there is delegation in 4655, although it's implicit. Delegation is not so obvious for stateless PCEs - basically, a if PCC does not use a PCE-computed path, the impact on the stateless PCE and its path computations for other PCCs is not big, because the stateless PCE does not keep track of LSPs. 

The delegation concept is a lot stronger for stateful PCEs, where strict state synchronization between a PCC and a PCE is required. RFC4655 Section 6.8 states: "there is a strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network." So if a PCC does not use the path computed by the PCE, it must notify the PCE, and also tell it about the path/parameters that were used for the LSP. This points at a tighter PCE control by a PCE over a PCC's LSPs, which in turn requires stronger delegation.

In draft-ietf-pce-stateful-pce we had to make delegation explicit, because the PCE controls the timing of LSP setups/teardowns. So, when a PCC is ready to accept PCE's path computations and LSP setups, it *explicitly* delegates its LSPs to the PCE. Note that the PCC still owns all its LSPs, and can withdraw the LSP delegation from a PCE at any time. If a PCC decides not to use LSP path/parameters computed by a PCE - it can still do it, just like in the above cases. It simply revokes the LSP delegation from the PCE and does whatever it wants with the LSP. However, since it is a stateful PCC, it still MUST tell the PCE what it has done (sending a PCReport for the LSP).

> (Of course the scope can be widened in future, so let's try to stick to current RFC 4655)

As outlined above, IMO draft-ietf-pce-stateful-pce is compliant with RFC4655.

Thanks,
Jan

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 9 Nov 2012 08:20:39 +0000

Hi Jan,

>The PCE is not limited to path computation only. The PCE can set other LSP parameters as well: RFC5440 defines objects for bandwidth, setup & hold priorities, the local protection flag, etc. More LS…

[Fatai] I have to indicate that PCE cannot *set* other LSP parameters. The parameters (eg., bandwidth, priorities, etc) you mentioned are only used for *path computation*.

>The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq message to a PCE requesting path computation (and parameter setting) for an LSP, it effectively

> delegates control over that LSP to the PCE. The delegation is valid for one request (and one path computation) only.

[Fatai] I don't think that RFC4655 can support delegation of LSP *control* (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated to the PCE.

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Jan Medved (jmedved)
发送时间: 2012年11月9日 9:12
收件人: Oscar González de Dios
抄送: [email-masked]
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Hi Oscar,

please see inline.

Thanks,

Jan

_______________________________________________

Pce mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/pce

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Nov 2012 14:28:34 +0000

I completely agree with Oscar.

The statefull PCE as defined in RFC 4655 is clearly different from statefull PCE as defined in Ed's documents. The cleanest way to think about the latter IMO is a combination of stateless PCE and a network controller, which is a very reasonable combination, but is hardly something to be discussed in PCE working group unless it does not go beyond purely path computation issues.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar González de Dios
Sent: Thursday, November 08, 2012 5:28 PM
To: Julien Meuric
Cc: [email-masked]
Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Hi Julien

Best Regards,

        Óscar

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Fri, 9 Nov 2012 16:27:29 +0000

Faital,

By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

Now, whether we use "control", "authority", "power", "mandate", whatever - that does not change the fact that the PCC asks the PCC to determine what the LSP parameters are, and the PCE determines what the LSP parameters are. That's what we call delegation - the PCC "delegates" the computation of LSP path and determination of LSP parameters to the PCE.

My email states a little later: "the PCC may or may not use the LSP path/parameters that it got from the PCE". We all agree that the PCC has the ultimate control over the LSP - it may take the directions from the PCE, it may not.

draft-ietf-pce-stateful-pce does not change any of this. The PCC gives the PCE the control/authority/mandate/power to determine the LSP's parameter. But, rather than doing this implicitly by requesting the PCE to determine those parameters (in a PCReq message), it does it explicitly. Delegation does not change the paradigm set by RFC4655 and RFC5440 - but in addition to LSP parameters, it allows the PCE to determine the timing of the LSP setup.

If you don't like the term "delegation", please suggest another one. I don't particularly care what we call the mechanism.

Thanks,
Jan

---

From: Robert Varga <[email-masked]>
Date: Fri, 09 Nov 2012 17:43:22 +0100

> Hi Jan,

Hi Fatai,

> >The PCE is not limited to path computation only. The PCE can set other LSP 
> parameters as well: RFC5440 defines objects for bandwidth, setup & 
> hold priorities, the local protection flag, etc. More LSP parameters 
> have been added in subsequent RFCs and drafts.
>
> [Fatai] I have to indicate that PCE cannot *set* other LSP parameters. 
> The parameters (eg., bandwidth, priorities, etc) you mentioned are 
> only used for *path computation*.
>

I agree. The PCE does not set *any* parameters of the LSP. Only PCC can 
do that PCC. PCE can only provide suggestions and must be fully prepared 
to have them rejected.

I am not aware of any restriction on what information a PCE is allowed 
to suggest to be modified, apart from the fact that ERO and BANDWIDTH 
are explictly included in that set (section 5.1.5 of RFC4657).

Bye,
Robert

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Fri, 9 Nov 2012 17:16:00 +0000

Igor,

On Nov 9, 2012, at 6:28 AM, Igor Bryskin wrote:

> The statefull PCE as defined in RFC 4655 is clearly different from statefull PCE as defined in Ed's documents.

No it is not. Please see my emails to Oscar and Faital.

> The cleanest way to think about the latter IMO is a combination of stateless PCE and a network controller,

draft-ietf-pce-stateful-pce does not change the architecture outlined in RFC4655. It proposes an extension to the PCEP protocol that allows the PCE to do both spatial *and* temporal LSP optimization. The need to add the timing aspect (i.e. the timing of LSP setups) to LSP optimization is amply documented in use cases presented in the draft (and use cases presented in other drafts as well). 

draft-ietf-pce-stateful-pce does not change the control of the LSPs - it still remains with the PCC. A network controller would have to be able to dynamically add/delete LSPs in order to fit in the model that you described above. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf-pce-stateful-pce does not.
 
> which is a very reasonable combination, but is hardly something to be discussed in PCE working group unless it does not go beyond purely path computation issues.
> 
> Igor
> 

Thanks,
Jan

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Nov 2012 19:21:51 +0000

Jan,

You said:
=> draft-ietf-pce-stateful-pce does not change the control of the LSPs - it still remains with the PCC. A network controller would have to be able to dynamically add/delete LSPs in order to fit in the model that you described  
    above. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf-pce-stateful-pce does not.

By this you are acknowledging that statefull pce can do a sub-set of things that stateless pce - network controller combo is able to do.  So what is the point to discuss a solution that is worse than existing one?

Igor 

-----Original Message-----
From: Jan Medved (jmedved) [mailto:[email-masked]] 
Sent: Friday, November 09, 2012 12:16 PM
To: Igor Bryskin
Cc: Oscar González de Dios; Julien Meuric; [email-masked]
Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Igor,

 

Thanks,
Jan

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Fri, 9 Nov 2012 22:24:47 +0000

Igor,

On Nov 9, 2012, at 11:21 AM, Igor Bryskin wrote:

> Jan,
> 
> You said:
> => draft-ietf-pce-stateful-pce does not change the control of the LSPs - it still remains with the PCC. A network controller would have to be able to dynamically add/delete LSPs in order to fit in the model that you described above. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf-pce-stateful-pce does not.
> 
What we got here is... failure to communicate.

draft-etf-pce-stateful-pce is about a *stateful* PCE than can make temporal and spatial decisions about LSP placements. You are trying to compare it to a *stateless* PCE connected to a controller. Note that a controller can not make decisions about when to instantiate a particular LSP - the PCE must make those decisions, if you want to address use cases outlined in draft-ietf-pce-stateful-pce. Note also that a stateless PCE does not have the knowledge about LSPs in the network, so it can't make the same optimization decisions as a stateful PCE which does have the knowledge about LSPs; we need LSP knowledge in the PCE to address use cases outlined in draft-ietf-pce-stateful-pce.

I don't think that one solution is better than the other. They are different, because they are addressing different issues.

Thanks,
Jan

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 12 Nov 2012 02:56:58 +0000

Hi Jan,
You said:
=>By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

[Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, etc) are the constraints sent from PCC to PCE for *path computation*. For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE *cannot determine* these parameters.  The ERO is the path information (path list) that PCE returns to PCC after path computation.

If you want to introduce *delegation* function (whatever we call it), the delegation definintion should be defined clearly. And then the WG will/can discuss more whether this “delegation” is needed or not (and whether this “delegation” is in the scope of the existing charter).

Best Regards

Fatai

发件人: Jan Medved (jmedved) [mailto:[email-masked]]
发送时间: 2012年11月10日 0:27
收件人: Fatai Zhang
抄送: Oscar González de Dios; [email-masked]
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Faital,

Thanks,
Jan

---

From: Edward Crabbe <[email-masked]>
Date: Sun, 11 Nov 2012 19:58:36 -0800

We currently appear to be involved in some sort of pre-fiat working group
process debate.  Unfortunately, I think you're injecting a particularly
onerous and unnecessary sort of wg bureaucracy here, and for no discernible
reason.  At this point, given the lack of any substantive technical
argument, I have to say that I actually feel that you're being a bit
obstructionist. :-/  I hope that's not the case.

Obviously the working group can have any technical discussion it wants, to
within the bounds of reason and the chair's limits of tolerence.  ;)  So
let's do that, and try to make our time together here productive. ^_^

w/r/t the specific comments:

Yes, we already have introduced a delegation function and have had since
the first rev of the draft.  It is, IMO,  defined clearly in the
draft-crabbe-pce-stateful-pce-02.  You should read it.  If you don't think
the definition is clear, then we should discuss that so we can improve the
text.

I continue to maintain that the main differences between receipt of
computation results between 5440 and active PCEP as defined in
draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony.  If you
have a good reason for thinking that this is not the case, or have other
technical issues with the delegation model, then please, by all means...

On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang <[email-masked]> wrote:

>  Hi Jan,****
>
> You said:****
>
> =>By requesting a path computation from a PCE, the PCC gives the PCE
> authority to determine the ERO, LSP Bandwidth, protection, LSP setup and
> hold priorities, etc. The PCE is the entity that determines these
> parameters - would you agree? ****
>
> ** **
>
> [Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection,
> etc) are the constraints sent from PCC to PCE for **path computation**.
> For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs,
> and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE **cannot
> determine** these parameters.  The ERO is the path information (path
> list) that PCE returns to PCC after path computation. ****
>
> ** **
>
> If you want to introduce **delegation** function (whatever we call it),
> the delegation definintion should be defined clearly. And then the WG
> will/can discuss more whether this “delegation” is needed or not (and
> whether this “delegation” is in the scope of the existing charter). ****
>
> ** **
>
> ** **
>
> Best Regards****
>
> ** **
>
> Fatai****
>
> ** **
>
> *发件人:* Jan Medved (jmedved) [mailto:[email-masked]]
> *发送时间:* 2012年11月10日 0:27
> *收件人:* Fatai Zhang
> *抄送:* Oscar González de Dios; [email-masked]
> Faital, ****
> On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote:****
>
>
>
> ****
>
> >The delegation of LSP control to a PCE is *implicit* in RFC4655. When a
> PCC sends a PCReq message to a PCE requesting path computation (and
> parameter setting) for an LSP, it effectively****
>
> > delegates control over that LSP to the PCE. The delegation is valid for
> one request (and one path computation) only.****
>
>  ****
>
> [Fatai] I don't think that RFC4655 can support delegation of LSP *control*
> (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this
> LSP is delegated to the PCE.****
>
> ** **
>
> By requesting a path computation from a PCE, the PCC gives the PCE
> authority to determine the ERO, LSP Bandwidth, protection, LSP setup and
> hold priorities, etc. The PCE is the entity that determines these
> parameters - would you agree? ****
>
> ** **
>
> Now, whether we use "control", "authority", "power", "mandate", whatever -
> that does not change the fact that the PCC asks the PCC to determine what
> the LSP parameters are, and the PCE determines what the LSP parameters
> are. That's what we call delegation - the PCC "delegates" the computation
> of LSP path and determination of LSP parameters to the PCE.****
>
> ** **
>
> My email states a little later: "the PCC may or may not use the LSP
> path/parameters that it got from the PCE". We all agree that the PCC has
> the ultimate control over the LSP - it may take the directions from the
> PCE, it may not. ****
>
> ** **
>
> draft-ietf-pce-stateful-pce does not change any of this. The PCC gives the
> PCE the control/authority/mandate/power to determine the LSP's parameter.
> But, rather than doing this implicitly by requesting the PCE to determine
> those parameters (in a PCReq message), it does it explicitly. Delegation
> does not change the paradigm set by RFC4655 and RFC5440 - but in addition
> to LSP parameters, it allows the PCE to determine the timing of the LSP
> setup.****
>
> ** **
>
> If you don't like the term "delegation", please suggest another one. I
> don't particularly care what we call the mechanism. ****
>
> ** **
>
> ** **
>
> ** **
>
> Thanks,****
>
> Jan****
>
> ** **
>
> ** **
>

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 12 Nov 2012 04:50:50 +0000

I am surprised by your tone.

I am touching the tech points and trying to clarity why PCE cannot *determine* those parameters. You can correct me if I am wrong from the tech perspective.

If you still use this kind of tone, sorry, I will ignore your response.

Best Regards

Fatai

发件人: Edward Crabbe [mailto:[email-masked]]
发送时间: 2012年11月12日 11:59
收件人: Fatai Zhang
抄送: Jan Medved (jmedved); [email-masked]
主题: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

We currently appear to be involved in some sort of pre-fiat working group process debate.  Unfortunately, I think you're injecting a particularly onerous and unnecessary sort of wg bureaucracy here, and for no discernible reason.  At this point, given the lack of any substantive technical argument, I have to say that I actually feel that you're being a bit obstructionist. :-/  I hope that's not the case.

Obviously the working group can have any technical discussion it wants, to within the bounds of reason and the chair's limits of tolerence.  ;)  So let's do that, and try to make our time together here productive. ^_^

Yes, we already have introduced a delegation function and have had since the first rev of the draft.  It is, IMO,  defined clearly in the draft-crabbe-pce-stateful-pce-02.  You should read it.  If you don't think the definition is clear, then we should discuss that so we can improve the text.

I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony.  If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means...

On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jan,
You said:
=>By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

Best Regards

Fatai

发件人: Jan Medved (jmedved) [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2012年11月10日 0:27
收件人: Fatai Zhang
抄送: Oscar González de Dios; [email-masked]<mailto:[email-masked]>
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Faital,

Thanks,
Jan

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Edward Crabbe <[email-masked]>
Date: Sun, 11 Nov 2012 21:06:42 -0800

I'm surprised by your surprise.  ^_^

Seriously though, I don't mean to offend you:  I want to have a productive
discussion here.  Most of the conversation in this thread thus far is about
either language, or whether the functionality is within the scope of the
charter.  I believe one of our chairs has already weighed in on the scope
side, so I guess we're talking about either language or I'm missing some
 technical point you've made regarding mechanism.

W/rt whether the PCE can set parameters:  yes, it clearly can.  This is
consistent with rfc4655 IMO.  As I stated previously:

On Sun, Nov 11, 2012 at 8:50 PM, Fatai Zhang <[email-masked]> wrote:

>  I am surprised by your tone.****
>
> ** **
>
> I am touching the tech points and trying to clarity why PCE cannot **
> determine** those parameters. You can correct me if I am wrong from the
> tech perspective.****
>
> ** **
>
> If you still use this kind of tone, sorry, I will ignore your response.***
> *
>
> ** **
>
> ** **
>
> ** **
>
> Best Regards****
>
> ** **
>
> Fatai****
>
> ** **
>
> *发件人:* Edward Crabbe [mailto:[email-masked]]
> *发送时间:* 2012年11月12日 11:59
> *收件人:* Fatai Zhang
> *抄送:* Jan Medved (jmedved); [email-masked]
> *主题:* Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter
> and opinion about stateful PCE****
>
> ** **
>
> obstructionist. :-/  I hope that's not the case. ****
>
> ** **
>
> let's do that, and try to make our time together here productive. ^_^****
>
> ** **
>
> w/r/t the specific comments:****
>
> ** **
>
> text.  ****
> On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang <[email-masked]>
> wrote:****
>
> Hi Jan,****
>
> You said:****
>
> *抄送:* Oscar González de Dios; [email-masked]****
>
> *主题**:* Re: [Pce] Questions about stateful PCE, relation to WG charter
> and opinion about stateful PCE****
>
>  ****
>
> Faital, ****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/pce****
>
> ** **
>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 12 Nov 2012 05:09:20 +0000

Fatai,

On Nov 11, 2012, at 6:56 PM, Fatai Zhang wrote:

Hi Jan,
You said:

[Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, etc) are the constraints sent from PCC to PCE for *path computation*.

Please re-read rfc5440. A PCRep *may* contain all the above objects. There is nothing in the RFC5440 saying the PCE could not set these parameters as it sees fit - even change the BANDWIDTH parameter suggested by a PCC.

For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE *cannot determine* these parameters.  The ERO is the path information (path list) that PCE returns to PCC after path computation.

Please re-read rfc5440 - BANDWIDTH and all other LSP parameters are *optional* on PCReq. A use case where a PCC does not include BANDWIDTH on the PCReq message and leaves the determination of a path's bandwidth to the PCE is well within the spec. And as I said above, a PCRep may optionally contain bandwidth and other LSP parameters, not just the ERO.

Even if we say that the only thing that the PCE does is path computation, the PCC *delegates* path computation to the PCE. That means, delegation - as a concept - has been a part of the PCE architecture from the very beginning. Therefore, your arguments above about bandwidth, etc. are moot.

If you want to introduce *delegation* function (whatever we call it), the delegation definintion should be defined clearly.

We don't have to introduce it, it's already in the PCE architecture. That's a fact. You may disagree. You are, of course, entitled to your own opinions, but not to your own facts.

I tried to explain delegation in this email thread as clearly as I could. Please re-read it, and if you don't understand something, ask a pointed question. If you disagree with something i wrote, please address that clearly. Then we can have a meaningful discussion. But please do not try to reset the discussion to with general statements.

And then the WG will/can discuss more whether this “delegation” is needed or not (and whether this “delegation” is in the scope of the existing charter).

Where have you been when the WG discussed draft-ietf-pce-stateful-pce?

Best Regards

Fatai

Thanks,
Jan

Faital,

Thanks,
Jan

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 12 Nov 2012 06:12:07 +0000

Hi Jan,

[RFC5440] says:
If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. Conversely, if the requested bandwidth is not equal to 0,   the PCReq message MUST contain a BANDWIDTH object.

I don’t think this means that PCE can set the bandwdith. All the paratermetes (either optional or mandatory)  sent from PCC to PCE in the PCReq are the contranits that will be taken into acccount for PCE to perform path compution.

In addition, I would like to remind that *set* != *delegation*, maybe we stray a little from the point, :)

Best Regards

Fatai

发送时间: 2012年11月12日 13:09

Fatai,

Hi Jan,
You said:

Best Regards

Fatai

Thanks,
Jan

Faital,

Thanks,
Jan

---

From: Edward Crabbe <[email-masked]>
Date: Sun, 11 Nov 2012 22:49:11 -0800

>
>
> In addition, I would like to remind that **set** != **delegation**, maybe
> we stray a little from the point, J
>

Please clearly explain your perception of the difference.

> *发送时间:* 2012年11月12日 13:09
> *收件人:* Fatai Zhang
> Fatai, ****
> On Nov 11, 2012, at 6:56 PM, Fatai Zhang wrote:****
>
>
>
> ****
>
> Hi Jan,****
>
> You said:****
>
> parameters - would you agree?****
>
>  ****
>
> etc) are the constraints sent from PCC to PCE for **path computation**. **
> **
>
> ** **
>
> Please re-read rfc5440. A PCRep *may* contain all the above objects. There
> is nothing in the RFC5440 saying the PCE could not set these parameters as
> it sees fit - even change the BANDWIDTH parameter suggested by a PCC. ****
>
>
>
> ****
>
> list) that PCE returns to PCC after path computation.****
>
>  ****
>
> Please re-read rfc5440 - BANDWIDTH and all other LSP parameters are
> *optional* on PCReq. A use case where a PCC does not include BANDWIDTH on
> the PCReq message and leaves the determination of a path's bandwidth to the
> PCE is well within the spec. And as I said above, a PCRep may optionally
> contain bandwidth and other LSP parameters, not just the ERO.****
>
> ** **
>
> Even if we say that the only thing that the PCE does is path computation,
> the PCC *delegates* path computation to the PCE. That means, delegation -
> as a concept - has been a part of the PCE architecture from the very
> beginning. Therefore, your arguments above about bandwidth, etc. are moot.
> ****
>
> ** **
>
> the delegation definintion should be defined clearly. ****
>
>  ** **
>
> We don't have to introduce it, it's already in the PCE architecture.
> That's a fact. You may disagree. You are, of course, entitled to your own
> opinions, but not to your own facts. ****
>
>   ****
>
> I tried to explain delegation in this email thread as clearly as I could.
> Please re-read it, and if you don't understand something, ask a pointed
> question. If you disagree with something i wrote, please address that
> clearly. Then we can have a meaningful discussion. But please do not try to
> reset the discussion to with general statements.****
>
>
>
> ****
>
> And then the WG will/can discuss more whether this “delegation” is needed
> or not (and whether this “delegation” is in the scope of the existing
> charter).****
>
>  ****
>
> Where have you been when the WG discussed draft-ietf-pce-stateful-pce?****
>
>
>
> ****
>
>  ****
>
> Best Regards****
>
>  ****
>
> Fatai****
>
>  ****
>
> Thanks,****
>
> Jan****
>
>
>
> ****
>
> Faital,****
> parameters - would you agree?****
>
>  ****
>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 12 Nov 2012 07:08:06 +0000

Fatai,

On Nov 11, 2012, at 10:12 PM, Fatai Zhang wrote:

Hi Jan,

[RFC5440] says:

RFC5440 does not say anything about what a PCE MUST do when a PCC requests 0 bandwidth for an LSP. It may just grant a 0 bandwidth to the PCC, or it may determine what the bandwidth should be and include the BANDWIDTH object on a PCRep message to the PCC. The spec also does not say that the bandwidth requested by a PCC MUST be equal to the bandwidth granted by the PCE (the PCE may grant more, equal, or less bandwidth).

The point I was trying to make is that the spec already allows for multiple valid use cases (that's actually the beauty of the spec :-) ). One of those use cases is where the PCE can determine all the LSP parameters that can be carried on the PCRep message and "suggest" them to the PCC. Another use case is a PCE that will either compute the ERO for the bandwidth specified in PCC's constrains or respond with a NO-PATH. All are valid use cases.

Agreed.  *delegation* == *allow to set*.

When a PCC sends a PCReq to a PCC, the PCC allows the PCE to set the ERO for one of its LSPs.  (Let's just focus on the ERO for now; a PCE can determine other LSP parameters as well, but let's leave that aside for now and agree on the ERO.)

The PCC delegates, the PCE sets.

Best Regards

Fatai

Thanks,
Jan

Fatai,

Hi Jan,
You said:

Best Regards

Fatai

Thanks,
Jan

Faital,

Thanks,
Jan

---

From: Leeyoung <[email-masked]>
Date: Mon, 12 Nov 2012 14:05:25 +0000

Hi Ed and Fatai

PCE cannot set these TE parameters per RFC4655. These TE parameters are passed by PCC as part of the path constraints to which path computation would apply.
If any one of them cannot be met, the PCE will send the PCC with an indication of ‘not finding a path’ or this sort.

I thought it was clear in RFC 4655.

Young

From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Crabbe
Sent: Sunday, November 11, 2012 11:07 PM
To: Fatai Zhang
Cc: [email-masked]
Subject: Re: [Pce] 答复: 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Seriously though, I don't mean to offend you:  I want to have a productive discussion here.  Most of the conversation in this thread thus far is about either language, or whether the functionality is within the scope of the charter.  I believe one of our chairs has already weighed in on the scope side, so I guess we're talking about either language or I'm missing some  technical point you've made regarding mechanism.

W/rt whether the PCE can set parameters:  yes, it clearly can.  This is consistent with rfc4655 IMO.  As I stated previously:

On Sun, Nov 11, 2012 at 8:50 PM, Fatai Zhang <[email-masked]<mailto:[email-masked]>> wrote:
I am surprised by your tone.

Best Regards

Fatai

发件人: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2012年11月12日 11:59
收件人: Fatai Zhang
抄送: Jan Medved (jmedved); [email-masked]<mailto:[email-masked]>
主题: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Best Regards

Fatai

Faital,

Thanks,
Jan

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 12 Nov 2012 17:57:35 +0000

Hi Young,

On Nov 12, 2012, at 6:05 AM, Leeyoung wrote:

Hi Ed and Fatai

If any one of them cannot be met, the PCE will send the PCC with an indication of ‘not finding a path’ or this sort. PCE cannot set these TE parameters per RFC4655. These TE parameters are passed by PCC as part of the path constraints to which path computation would apply.

please see my response to Fatai. Here it is, in case you have not seen it.

"RFC5440 does not say anything about what a PCE MUST do when a PCC requests 0 bandwidth for an LSP. It may just grant a 0 bandwidth to the PCC, or it may determine what the bandwidth should be and include the BANDWIDTH object on a PCRep message to the PCC. The spec also does not say that the bandwidth requested by a PCC MUST be equal to the bandwidth granted by the PCE (the PCE may grant more, equal, or less bandwidth).

The point I was trying to make is that the spec already allows for multiple valid use cases (that's actually the beauty of the spec :-) ). One of those use cases is where the PCE can determine all the LSP parameters that can be carried on the PCRep message and "suggest" them to the PCC. Another use case is a PCE that will either compute the ERO for the bandwidth specified in PCC's constrains or respond with a NO-PATH. All are valid use cases."

Basically, what you describe above is a valid use case allowed by the spec. But it's not the ONLY valid use case.  If the PCC does not set any constrains, the PCE MAY use the optional parameters on PCRep to tell the PCC what to do. It's a matter of policy between the PCC and the PCE.

Young

Thanks,
Jan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Edward Crabbe
Sent: Sunday, November 11, 2012 11:07 PM
To: Fatai Zhang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] 答复: 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Best Regards

Fatai

Best Regards

Fatai

Faital,

Thanks,
Jan

---

From: Leeyoung <[email-masked]>
Date: Mon, 12 Nov 2012 19:19:59 +0000

Hi Jan,

I granted that there is a certain degree of ambiguity in RFC 5440. First, the zero bandwidth case is a corner case, I think. Second, this is different from PCE setting the TE parameters. When you say PCE can set the TE parameters, it sounds like PCE would set the path with any arbitrary parameters it would decide upon. PCE is reactive than proactive. There could be a certain degree of ‘negotiating’ (implicit or explicit) with PCC when the requested parameters are not met by PCE. But this is very different from claiming that PCE can set the TE parameters.

Thanks.
Young

From: Jan Medved (jmedved) [mailto:[email-masked]]
Sent: Monday, November 12, 2012 11:58 AM
To: Leeyoung
Cc: Edward Crabbe; Fatai Zhang; [email-masked]
Subject: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Hi Young,

Hi Ed and Fatai

Young

Thanks,
Jan

Best Regards

Fatai

Best Regards

Fatai

Faital,

Thanks,
Jan

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 13 Nov 2012 01:37:16 +0000

Hi Robert,

Yes, you are right.

Best Regards

Fatai

发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Varga
发送时间: 2012年11月10日 0:43
收件人: [email-masked]
主题: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

Hi Jan,

Hi Fatai,

I agree. The PCE does not set *any* parameters of the LSP. Only PCC can do that PCC. PCE can only provide suggestions and must be fully prepared to have them rejected.

I am not aware of any restriction on what information a PCE is allowed to suggest to be modified, apart from the fact that ERO and BANDWIDTH are explictly included in that set (section 5.1.5 of RFC4657).

Bye,
Robert