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

Lou Berger <lberger@labn.net> Fri, 09 August 2013 22:25 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C521F9ABB for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 15:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.919
X-Spam-Level:
X-Spam-Status: No, score=-100.919 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxTggzfbt1GL for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 15:25:21 -0700 (PDT)
Received: from oproxy5-pub.mail.unifiedlayer.com (oproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A959111E8192 for <ccamp@ietf.org>; Fri, 9 Aug 2013 15:16:50 -0700 (PDT)
Received: (qmail 26944 invoked by uid 0); 9 Aug 2013 22:16:29 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy5.mail.unifiedlayer.com with SMTP; 9 Aug 2013 22:16:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=8J0jCQAopplvKVg8sQieQw3RyaA4b0wfRg4hxCRkMew=; b=ZCgbVp+UtSyH6lZIioOA6ruN2V1SJmfCwNMl9iQq7LCCHrNN9pCX6RT8ldoXgSqj9k3KNEfRPvB1A7nxfFZQbBqGQf17U+STIy7azljslxHwMDVRhlHrsiZzdb42cFNc;
Received: from box313.bluehost.com ([69.89.31.113]:38193 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1V7uyz-0004zB-0v; Fri, 09 Aug 2013 16:16:29 -0600
Message-ID: <52056A3C.2080008@labn.net>
Date: Fri, 09 Aug 2013 18:16:28 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: John E Drake <jdrake@juniper.net>
References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <F82A4B6D50F9464B8EBA55651F541CF84EE47162@SZXEML552-MBX.china.huawei.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <5205644C.9080400@labn.net> <988b78e813fd4815bc306dbc28f78279@BY2PR05MB142.namprd05.prod.outlook.com>
In-Reply-To: <988b78e813fd4815bc306dbc28f78279@BY2PR05MB142.namprd05.prod.outlook.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "CCAMP \(ccamp@ietf.org\)" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2013 22:25:31 -0000
X-List-Received-Date: Fri, 09 Aug 2013 22:25:31 -0000

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:lberger@labn.net]
>> Sent: Friday, August 09, 2013 2:51 PM
>> To: John E Drake
>> Cc: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org)
>> 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:mhartley@cisco.com]
>>>> Sent: Friday, August 09, 2013 1:53 PM
>>>> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org)
>>>> 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>> Behalf
>>>>> Of John E Drake
>>>>> Sent: Friday, August 09, 2013 1:49 AM
>>>>> To: CCAMP (ccamp@ietf.org)
>>>>> 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
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>
>>
> 
> 
>