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:54:26 +0200

Hi Lou

> 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...
> 

You are right, and thanks for highlighting this point

JL

> -----Message d'origine-----
> De : Lou Berger [mailto:[email-masked]] 
> Envoyé : mercredi 27 juillet 2005 16:45
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : Igor Bryskin; JP Vasseur; [email-masked]; Ash, 
> Gerald R (Jerry), ALABS; Lou Berger; [email-masked]
> Objet : RE: [Pce] Changes in the new revision of the architecture I-D
> 
> 
> >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...
> 
> 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:
> >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: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 27 Jul 2005 22:47:57 +0200

Hi Igor,

Your were saying in previous email:

>IN ANY CASE enabling all PCEs involved in the request to be
>aware of the "REAL" originator seems to me a more flexible approach.

And I maintain that this is a wrong assertion.
For me the inclusion of what you call the "REAL" originator ID is irrelevant in VARIOUS CASES...

See also inline,

Regards,

JL

> De : Igor Bryskin [mailto:[email-masked]] 
> Envoyé : mercredi 27 juillet 2005 20:43
> À : 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,
> 
> Ok, one last attempt.

Please :-)

> 
> Nobody says that a PCE must have policies about every PCC, 
> but it might have about some and might want to apply them 
> whether the request comes directly or via some other PCE(s).

Fair enough

> 
> Your example when PCE1 and PCE2 belong to different providers 
> and PCE2's address is configured locally presents NO problem 
> - PCE1 knows about this fact and ALWAYS replaces the 
> originator ID with its own before sending the request to the 
> PCE2.

OK, so this is no longer the so called "REAL" orignator ID :-)

 But how about the case when multiple PCEs work within a 
> single provider, where all of them publish their presence and 
> the PCE2 may get a relayed request from the PCE1 OR direct 
> from the PCC? Why is it not wiser to let PCE2 apply its own 
> policy wrt the PCC?

I recall that intially we were addresing multiple PCE path computation...
Here your exemple is related to PCE proxying, which is actually quite different from multiple-PCE path computation. And I agree that in the particular case of proxying, the inclusion of the originator ID could be useful

> Just to state "I disagree, in various 
> cases policing based on the originator does not make sense 
> and cannot work" is not good enough.

:-)))))
OK, you were saying "IN ANY CASE being aware of the REAL originator ID is useful".
I replied and I strongly maintain that this is wrong, there are VARIOUS CASES (I never said in all cases) where this is not useful and cannot work... and now you just list cases where this is useful. We will never conclude like that...

> 
> Besides, I'd also like to hear what the architecture authors 
> think about this.

Sure, this would be helpful

> 
> Let's discuss more in Paris. I have some other issues with 
> the architecture anyway.

OK,

Best Regards

JL

> 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 1:36 PM
> Subject: RE: [Pce] Changes in the new revision of the architecture I-D
> 
> 
> Hi Igor
> 
> See inline
> 
> > De : Igor Bryskin [mailto:[email-masked]]
> > Envoyé : mercredi 27 juillet 2005 19:05
> > À : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur;
> > [email-masked]; Ash, Gerald R (Jerry), ALABS; Lou Berger
> > Cc : [email-masked]
> > 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.
> 
> This is a strong assumption...
> PCE2 does not necessarily publish its presence accross domains,
> please see section 6.2 of [PCE-DISC].
> 
> E.g. let's assume that PCE1 and PCE2 belong to distinct 
> service providers
> (let say SP1 and SP2)...
> A possible ( and valuable :-) approach is that PCE1 
> statically discover
> PCE2. PCCs in SP1 are not aware of PCE2. There is a policy on 
> PCE2 so that
> all requests coming from SP1 are rejected except those from PCE1.
> Hence all the trust rely on PCE1-PCE2 communication. In that case
> advertising orignator id so as to apply a specific policy on 
> PCE2 does not
> really make sense as PCE2 is not aware of PCCs in SP1...
> 
> >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.
> 
> OK in this case PCE1 is simply acting as a proxy, but again 
> this requires
> that  PCE2 be aware of PCCs in domain 1 which is IMHO a 
> strong assumption
> not always (and not often when domain = SP) valid...
> Again think about confidentiality, scalability accross AS/SPs...
> 
> It seems that it is time to start working on application specific
> requirements...
> 
> >
> > In any case enabling all PCEs involved in the request to be
> > aware of the "real" originator seems to me a more flexible approach.
> 
> I disagree, in various cases policing based on the orignator 
> does not make
> sense and cannot work
> 
> 
> >
> > 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.
> 
> Fully agree
> 
> >
> > See you in Paris,
> 
> OK let's discuss this point in Paris
> 
> Best Regards,
> 
> JL
> 
> > Igor
> >
> > 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
> >
> > > 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]
> > > 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
> > >
> > > > 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
> > > >
> > > > 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
> > > >
> > > > > 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,
> > > > >
> > > > > 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)
> > > >
> > > > 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.
> > > > 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.
> > > >
> > > described why
> > > > > the identity of the original requestor should be
> > > available for all
> > > > > PCEs involved in particular path computation request.
> > > >
> > > 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
> > > >
> > > > > > >before WG last call. So the short answer is "as soon as
> > > > possible".
> > > > > > >
> > > > > > >Thanks.
> > > > > > >
> > > > > > >JP.
> > > > > >
> > > > > > JP/Adrian/Jerry,
> > > > > > are more "in-passing" than as major component.  It seems
> > > > to me that

---

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

Hi Alia

What you propose sounds valuable in case of PCE proxying.

But we definitely need to make the distinction between PCE proxying,
and multiple-PCE path computation which are actually quite different functions IMO.

In case of multiple-PCE path computation, cascaded requests are independant and a PCE should not care whether the cascade was initially triggered by X, Y, or Z, and should only apply policies based on the "direct" requestor and not based on any "proxied originator"...

Best Regards,

JL

> De : Alia Atlas [mailto:[email-masked]] 
> Envoyé : mercredi 27 juillet 2005 21:37
> À : Igor Bryskin
> Cc : LE ROUX Jean-Louis RD-CORE-LAN; JP Vasseur; 
> Berger; [email-masked]
> On 7/27/05, Igor Bryskin <[email-masked]> wrote:
> > Nobody says that a PCE must have policies about every PCC, but it 
> > might have about some and might want to apply them whether 
> the request 
> > comes directly or via some other PCE(s).
> > 
> > Your example when PCE1 and PCE2 belong to different providers and 
> > PCE2's address is configured locally presents NO problem - 
> PCE1 knows 
> > about this fact and ALWAYS replaces the originator ID with its own 
> > before sending the request to the PCE2. But how about the case when 
> > multiple PCEs work within a single provider, where all of 
> them publish 
> > their presence and the PCE2 may get a relayed request from 
> the PCE1 OR 
> > direct from the PCC? Why is it not wiser to let PCE2 apply its own 
> > policy wrt the PCC? Just to state "I disagree, in various cases 
> > policing based on the originator does not make sense and 
> cannot work" is not good enough.
> 
> Does it help to change the assumption that PCE1 can only have 
> one sourcing identity?  I.e., let PCE1 apply policy to the 
> originator PCC
> & derive an proxy originator to pass on to PCE2.   Then PCE2 just
> needs to know about and have policy on the set of proxy 
> originators that it agrees to support from PCE1.
> 
> Basically, PCE1 decides how to set the originator based on 
> where PCE2 is and what agreements may be in force with PCE2.
> 
> In the first case, where PCE1 and PCE2 belong to the same 
> service provider (or possibly are just in the same area, 
> depending on distributed knowledge), PCE1 can decide not to 
> proxy the originator and just specify an orginator = PCC.
> 
> In the second case, where PCE1 and PCE2 belong to different 
> service providers, PCE1 can decide to proxy the originator so 
> that originator = proxy(PCC, policy(PCE1, PCE2)).
> 
> Alia
>