Subject: RE: [Pce] Changes in the new revision of the architecture I-D

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 27 Jul 2005 16:14:42 +0200

Hi Igor

Please see inline 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Igor Bryskin
> Envoyé : mercredi 27 juillet 2005 16:01
> À : JP Vasseur; [email-masked]; Ash, Gerald R 
> (Jerry), ALABS; Lou Berger
> Cc : [email-masked]
> Objet : Re: [Pce] Changes in the new revision of the architecture I-D
> 
> Hi,
> 
> I think Lou has just brought up a very important discussion.
> 
> A PCE can apply a policy for a particular path computation 
> request only IFF it can identify original requestor. Consider 
> the situation when a single request involves 2 PCEs: 
> PCC<=>PCE1<=>PCE2.
> 
> PCE1 can identify the PCC and apply the polices for this PCC 
> or this class of PCCs. However, PCE2 will not be capable to 
> identify PCC ( we seem to agree already that PCC-PCE and 
> PCE-PCE is the same protocol, hence PCE2 will see PCE1 as 
> PCC)

And where is the problem? Policy have a local PCC-PCE meaning
PCE1 that sends a request to PCE2 is considered as a PCC, and PCE2 applies the policy to PCE1
PCE1 offers a service to PCC, PCE2 offers a service to PCE1,
To my mind policies must have a local client-server scope.
Path requests have a local PCC-PCE scope.
PCE2 doesn't care whether PCE1 request has been triggered by PCC request to PCE1 or not. It serves a request from PCE1 and that's all...

>, and will apply a wrong policy. For instance, it may 
> invoke a computationally expensive algorithm, which it won't 
> do if the PCC requested computation directly from PCC2.

And what is the problem?, this is up to PCE1 to apply correct policies

> 
> So, in the architecture document the reasons should be 
> described why the identity of the original requestor should 
> be available for all PCEs involved in particular path 
> computation request.

A path computation request should IMHO have a local scope
Multiple-PCE path computation should be considered as a cascade of 
requests rather than the propagation of the same request, and local PCC-PCE policies should be applied for each request...

Regards,

JL

> Secondly, the same point should be 
> reflected in the path computation communication protocol requirements.
> 
> Igor
> 
> ----- Original Message -----
> From: "Lou Berger" <[email-masked]>
> To: "JP Vasseur" <[email-masked]>; "Adrian Farrel"
> <[email-masked]>; "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, July 26, 2005 7:14 PM
> Subject: Re: [Pce] Changes in the new revision of the architecture I-D
> 
> 
> > At 09:24 AM 7/23/2005, JP Vasseur wrote:
> > >We think that the ID is pretty stable in term of technical content.
> > >As Adrian pointed out, there might be some editorial work 
> to be done
> > >before WG last call. So the short answer is "as soon as possible".
> > >
> > >Thanks.
> > >
> > >JP.
> >
> > JP/Adrian/Jerry,
> >          As you say, the draft has come together very nicely.  The
> > primary comment I have on the document is related to how policy is
> > presented in the draft:
> >
> > The draft does mention policy in multiple places, but these mentions
> > are more "in-passing" than as major component.  It seems to me that
> > Policy and the ability to support path computation based on, or
> > influenced by policies, must be a major part of the PCE
> > architecture.  I do agree with draft in that "policy between domains
> > and between PCEs, and is achieved through configuration not through
> > protocol communications."  That said, the PCC-PCE and PCE-PCE
> > communication protocols must support the communication of all
> > information needed to support the installed policies, as well as
> > support any policy triggered transactions that may result due to a
> > policy (or change in policy).  Also, in order to deliver viable
> > policy to PCE, policy must not be an after thought.  (Consider how
> > successful original RSVP was with bringing in policy after the core
> > work was complete.)
> >
> > In short, I think policy should be more prominent in the 
> draft and in
> > the PCE architecture.
> >
> > I suggest to:
> > - add policy related motivations in section 4,
> > - add a policy component to the PCE architecture(s) 
> presented in section
> 5,
> > - add a full fledged Policy sub-section to section 6 that 
> is separate
> > from confidentiality.
> > - and add a policy related evaluation metric to section 7.
> >
> > Please let me know what you think.
> >
> > I'll put together some specific text for fodder....
> >
> > Lou
> >
> >
> > _______________________________________________
> > Pce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pce
> >
> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Jul 2005 10:44:31 -0400

>PCE2 doesn't care whether PCE1 request has been 
>triggered by PCC request to PCE1 or not. It 
>serves a request from PCE1 and that's all...

Jean-Louis,
         I think this discussion, and the fact 
that you and Igor are disagreeing, highlights the 
need to clearly state the supported policy models 
and the corresponding requirements/implications 
in the PCE requirements documents...

Lou

At 10:14 AM 7/27/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote:
>PCE1 that sends a request to PCE2 is considered 
>as a PCC, and PCE2 applies the policy to PCE1
>PCE2 doesn't care whether PCE1 request has been 
>triggered by PCC request to PCE1 or not. It 
>serves a request from PCE1 and that's all...
>
>requests rather than the propagation of the same 
>request, and local PCC-PCE policies should be applied for each request...
>
>
>Regards,
>
>JL
>

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 27 Jul 2005 10:44:37 -0400

JL,

See in-line.

Igor

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; "JP Vasseur" <[email-masked]>;
<[email-masked]>; "Ash, Gerald R (Jerry), ALABS" <[email-masked]>; "Lou
Berger" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 27, 2005 10:14 AM
Subject: RE: [Pce] Changes in the new revision of the architecture I-D

Hi Igor

Please see inline

And where is the problem? Policy have a local PCC-PCE meaning
PCE1 that sends a request to PCE2 is considered as a PCC, and PCE2 applies
the policy to PCE1
PCE1 offers a service to PCC, PCE2 offers a service to PCE1,
To my mind policies must have a local client-server scope.
Path requests have a local PCC-PCE scope.
PCE2 doesn't care whether PCE1 request has been triggered by PCC request to
PCE1 or not. It serves a request from PCE1 and that's all...

IB>> The problem is in my opinion quite obvious. A PCC sends a request to
PCE1 with a lot of constraints and optimization objectives. PCE1 recognizes
the PCC as "unimportant" and is about to perform some "cheap" heuristic.
However, it does not have visibility to the destination, hence it relays the
request to PCE2. PCE2 recognizes the PCE1 as a "very important" client and
tries to satisfy the request as best as it can, which may take 25% of its
CPU capacity. Now, if you have several more such "unimportant" PCCs, you get
your PCE2 saturated very quickly.

Igor

A path computation request should IMHO have a local scope
Multiple-PCE path computation should be considered as a cascade of
requests rather than the propagation of the same request, and local PCC-PCE
policies should be applied for each request...

Regards,

JL