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 17:39:32 +0200

Hi Igor 

> -----Message d'origine-----
> De : Igor Bryskin [mailto:[email-masked]] 
> Envoyé : mercredi 27 juillet 2005 17:13
> À : LE ROUX Jean-Louis RD-CORE-LAN; 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
> 
> JL,
> 
> PCE1 could reflect "low importance" in the request sent to 
> PCE2, by mean of specific objective function selection (IB>> 
> which?  how?),

Solution to encode objective function are not yet specified, btw this should be addressed in future PCEP revisions.
But have a look at the text related to objective function and parameterization of these functions in the communication protocol generic requirements. 
This may allow to request for what you call "cheap" or "expansive" heuristics...

> 
> request priority (IB>> won't help, PCE2 will just move 
> request into lower priority task)

Right

> 
> or potentially using a dedicated parameter (yet not defined).
> IB>> And the point is why not to use the original requestor ID as the
> dedicated parameter you mentioned, so that PCE2 could apply 
> the policy of its own?

Hence PCE2 would have to be aware of all PCCs in other domains...
Think about scalability, confidentiality, and policy configurations...
This is up to PCE1 to notify the importance of the request to PCE2.
In the PCC->PCE1->PCE2 cascade, PCC IS NOT a client of PCE2, PCC is a client of PCE1, so if PCE1 considers that the request is not so "important" it should reflect that in the request sent to PCE2 (control of objective function, or maybe using a specific "importance" parameter). 
We should consider that PCEs may not be aware of PCCs in other domains

> 
> Please not that in inter-AS/SP environment there may be cases 
> where PCE2 MUST not have knowledge of PCC...
> IB>> No problem here, original requestor ID will be 
> "unknown", and PCE2
> might have a policy for such clients as well

So, if I follow you, the same policies would be applied for all unknow clients...This does not sound really acceptable.

Regards,

JL

> 
> Igor
> 
> Regards,
> 
> JL
> 
> > -----Message d'origine-----
> > De : Igor Bryskin [mailto:[email-masked]] Envoyé : mercredi 27 
> > juillet 2005 16:45 À : LE ROUX Jean-Louis RD-CORE-LAN; 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
> >
> > 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
> >
> > > -----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...
> >
> > 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
> >
> > >, 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: "Igor Bryskin" <[email-masked]>
Date: Wed, 27 Jul 2005 13:05:14 -0400

Jl,

1. PCE2 publishes its presence, hence it must be prepared to receive
requests from many clients and may have policies for some of them. In our
example the PCE2 could get a request directly from the PCC, may have a
policy for the PCC (not necessarily identical to the policy that the PCE1
has).

2. PCE1 in our example can always put its own ID as request originator ID in
the request to PCE2 and modify the request to reflect its importance as far
as it sees it (exactly your model). Alternatively. PCE1 may choose not to
modify the request (changing neither request originator ID nor constraints)
and let PCE2 treat the request according to its own policies. In the latter
case: PCC->PCE1->PCE2->PCE1->PCC and PCC->PCE1->PCC->PCE2->PCC sequences
will likely to produce the same resulting paths.

In any case enabling all PCEs involved in the request to be aware of the
"real" originator seems to me a more flexible approach.

On more general note it is obvious that articulating policies between PCE
wrt specific request has never been discussed and we should IMO, starting
with the architecture.

See you in Paris,
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 11:39 AM
Subject: RE: [Pce] Changes in the new revision of the architecture I-D

Hi Igor

> PCE2, by mean of specific objective function selection (IB>>

Solution to encode objective function are not yet specified, btw this should
be addressed in future PCEP revisions.
But have a look at the text related to objective function and
parameterization of these functions in the communication protocol generic
requirements.
This may allow to request for what you call "cheap" or "expansive"
heuristics...

Right

Hence PCE2 would have to be aware of all PCCs in other domains...
Think about scalability, confidentiality, and policy configurations...
This is up to PCE1 to notify the importance of the request to PCE2.
In the PCC->PCE1->PCE2 cascade, PCC IS NOT a client of PCE2, PCC is a client
of PCE1, so if PCE1 considers that the request is not so "important" it
should reflect that in the request sent to PCE2 (control of objective
function, or maybe using a specific "importance" parameter).
We should consider that PCEs may not be aware of PCCs in other domains

> might have a policy for such clients as well

So, if I follow you, the same policies would be applied for all unknow
clients...This does not sound really acceptable.

Regards,

JL