Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

[Lou Berger <[e-mail]>]

On 08/09/2013 06:01 PM, John E Drake wrote:
> Lou,
> 
> The last time I checked, PCE supported multi-layer path computation. 

Sure, if the multi-layer PCE is accessible in the client domain.  (or if
have cooperating PCE-PCE communication.) That's what I was referring to
in my 2nd paragraph.

There are also PCE deployment approaches that have the PCE inaccessible
from (untrusted) UNI clients/network and only accessed from the
provider/server side of the UNI.

> Btw, given this discussion, I found the following draft to be rather
> interesting:
> http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/
> 

Agreed & the defined extensions & discussions seem reasonable (to me).

Lou

> Yours Irrespectively,
> 
> John
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Friday, August 09, 2013 2:51 PM
>> To: John E Drake
>> Cc: Matt Hartley (mhartley); Fatai Zhang; CCAMP ([e-mail])
>> Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
>> 03.txt
>>
>> John,
>> 	So how does a PCE *in the server layer* learn about the service
>> parameters desired by for an LSP, e.g., desired LSP latency, signaled across a
>> UNI?
>>
>> Now certainly a PCE server in the client layer is a different matter.
>>
>> BTW I'm not advocating any particular draft or solution in this message, I'm
>> just trying to understand your model. I do agree that it's always best to
>> understand what is needed/missing before jumping into discussions on
>> solution details.
>>
>> Lou
>>
>> On 08/09/2013 05:22 PM, John E Drake wrote:
>>> PCEP can be deployed whenever the server network wishes to provide a
>> path computation service.  What possible advantage to anyone is gained by
>> embedding PCEP in RSVP-TE signaling?
>>>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Matt Hartley (mhartley) [mailto:[e-mail]]
>>>> Sent: Friday, August 09, 2013 1:53 PM
>>>> To: Fatai Zhang; John E Drake; CCAMP ([e-mail])
>>>> Cc: Matt Hartley (mhartley)
>>>> Subject: RE: [CCAMP]
>>>> draft-ali-ccamp-rc-objective-function-metric-bound-
>>>> 03.txt
>>>>
>>>> Fatai, John,
>>>>
>>>> I don't think you can guarantee that PCE will be deployed absolutely
>>>> everywhere, or that you can guarantee the client will be permitted
>>>> access to the server PCE when it is. In those cases, this draft is useful.
>>>>
>>>> Cheers
>>>>
>>>> Matt
>>>>
>>>>> Hi John,
>>>>>
>>>>> Completely agree.
>>>>>
>>>>> I also raised this comment in front of the mic during Berlin meeting.
>>>>>
>>>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>> Fatai
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf
>>>>> Of John E Drake
>>>>> Sent: Friday, August 09, 2013 1:49 AM
>>>>> To: CCAMP ([e-mail])
>>>>> Subject: [CCAMP]
>>>>> draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have a real concern with this draft because it appears to be
>>>>> heading us down the road of re-inventing PCEP in RSVP signaling with
>>>>> the dubious justification that it is needed in those situations in
>>>>> which a PCE is not available.  However, if you re-invent PCEP in
>>>>> RSVP signaling, then you have effectively ensured that there are no
>>>>> situations in which a PCE or its signaling equivalent are not available.
>>>>>
>>>>> Why is this better than simply ensuring that a PCE is available in
>>>>> those situations in which it is needed?
>>>>>
>>>>> Yours Irrespectively,
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>
>>
> 
> 
>