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

John E Drake <jdrake@juniper.net> Fri, 09 August 2013 22:10 UTC

Return-Path: <jdrake@juniper.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 80ABF11E81AB for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 15:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.911
X-Spam-Level:
X-Spam-Status: No, score=-4.911 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 JcLrLe5cvwpF for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 15:10:22 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5C811E81A4 for <ccamp@ietf.org>; Fri, 9 Aug 2013 15:01:39 -0700 (PDT)
Received: from mail104-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE030.bigfish.com (10.236.130.93) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 22:01:37 +0000
Received: from mail104-co9 (localhost [127.0.0.1]) by mail104-co9-R.bigfish.com (Postfix) with ESMTP id 49E5210024D; Fri, 9 Aug 2013 22:01:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: PS-24(zzbb2dI98dI9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h)
Received-SPF: pass (mail104-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(51704005)(13464003)(199002)(189002)(37854004)(24454002)(33646001)(31966008)(66066001)(47446002)(74366001)(54316002)(54356001)(77982001)(56776001)(81542001)(19580405001)(47736001)(74662001)(16406001)(50986001)(59766001)(81342001)(83072001)(65816001)(63696002)(74316001)(47976001)(80976001)(79102001)(76482001)(80022001)(4396001)(46102001)(51856001)(76796001)(77096001)(76786001)(49866001)(69226001)(74876001)(19580395003)(74502001)(19580385001)(74706001)(76576001)(83322001)(15202345003)(81686001)(56816003)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail104-co9 (localhost.localdomain [127.0.0.1]) by mail104-co9 (MessageSwitch) id 1376085695739488_13360; Fri, 9 Aug 2013 22:01:35 +0000 (UTC)
Received: from CO9EHSMHS001.bigfish.com (unknown [10.236.132.245]) by mail104-co9.bigfish.com (Postfix) with ESMTP id AF89442004A; Fri, 9 Aug 2013 22:01:35 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS001.bigfish.com (10.236.130.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 22:01:35 +0000
Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 22:01:34 +0000
Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 22:01:31 +0000
Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 22:01:31 +0000
From: John E Drake <jdrake@juniper.net>
To: Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERCAAAkiAIAAAkaw
Date: Fri, 9 Aug 2013 22:01:31 +0000
Message-ID: <988b78e813fd4815bc306dbc28f78279@BY2PR05MB142.namprd05.prod.outlook.com>
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>
In-Reply-To: <5205644C.9080400@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.224.54]
x-forefront-prvs: 0933E9FD8D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
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:10:35 -0000

Lou,

The last time I checked, PCE supported multi-layer path computation.  Btw, given this discussion, I found the following draft to be rather interesting:  http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/

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