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:51:53 +0200

Hi Igor,

PCE1 could reflect "low importance" in the request sent to PCE2,
by mean of specific objective function selection, request priority or potentially using a dedicated parameter (yet not defined).

Please not that in inter-AS/SP environment there may be cases where PCE2 MUST not have knowledge of PCC...

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 11:12:42 -0400

JL,

PCE1 could reflect "low importance" in the request sent to PCE2,
by mean of specific objective function selection (IB>> which?  how?),

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

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?

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

Igor

Regards,

JL