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 19:36:44 +0200

Hi Igor

See inline 

> -----Message d'origine-----
> 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]
> Objet : Re: [Pce] Changes in the new revision of the architecture I-D
> 
> 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
> 
> ----- 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
> 
> > -----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 14:42:50 -0400

JL,

Ok, one last attempt.

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.

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

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

Regards,
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 1:36 PM
Subject: RE: [Pce] Changes in the new revision of the architecture I-D

Hi Igor

See inline

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

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

> 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

Fully agree

Best Regards,

JL

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 27 Jul 2005 15:45:32 -0400

Alia,

Sounds like one good way to address the problem. But this is just one
problem related to policies. The higher level discussion is necessary.

See you in Paris,
Igor

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

> 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

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Jul 2005 16:06:07 -0400

This sounds just right to me...

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Jul 2005 12:37:07 -0700

Alia