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

John E Drake <jdrake@juniper.net> Fri, 09 August 2013 17:13 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 9E39321F9406 for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 10:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.16
X-Spam-Level:
X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[AWL=2.439, 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 kwCm1cZRT9zo for <ccamp@ietfa.amsl.com>; Fri, 9 Aug 2013 10:13:47 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D721F9D2C for <ccamp@ietf.org>; Fri, 9 Aug 2013 10:07:42 -0700 (PDT)
Received: from mail159-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 17:07:41 +0000
Received: from mail159-tx2 (localhost [127.0.0.1]) by mail159-tx2-R.bigfish.com (Postfix) with ESMTP id 8E6E41001A5; Fri, 9 Aug 2013 17:07:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h)
Received-SPF: pass (mail159-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(13464003)(189002)(199002)(51704005)(377454003)(33646001)(56776001)(76786001)(4396001)(74876001)(74662001)(76482001)(54316002)(47446002)(74502001)(53806001)(83072001)(74366001)(54356001)(16406001)(81342001)(31966008)(59766001)(77982001)(79102001)(63696002)(46102001)(65816001)(76576001)(80022001)(51856001)(77096001)(19580395003)(74316001)(76796001)(69226001)(80976001)(19580405001)(50986001)(83322001)(49866001)(56816003)(74706001)(47976001)(81542001)(47736001)(81686001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail159-tx2 (localhost.localdomain [127.0.0.1]) by mail159-tx2 (MessageSwitch) id 1376068016369747_20148; Fri, 9 Aug 2013 17:06:56 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.253]) by mail159-tx2.bigfish.com (Postfix) with ESMTP id 54AD92004B; Fri, 9 Aug 2013 17:06:56 +0000 (UTC)
Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 17:06:55 +0000
Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 17:06:52 +0000
Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 17:06:50 +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 17:06:50 +0000
From: John E Drake <jdrake@juniper.net>
To: "Zafar Ali (zali)" <zali@cisco.com>, Fatai Zhang <zhangfatai@huawei.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNFqQAgAACAgA=
Date: Fri, 9 Aug 2013 17:06:50 +0000
Message-ID: <5016733261cf49a9a2d888b67e7a8f17@BY2PR05MB142.namprd05.prod.outlook.com>
References: <F82A4B6D50F9464B8EBA55651F541CF84EE47162@SZXEML552-MBX.china.huawei.com> <B6585D85A128FD47857D0FD58D8120D30EA01E48@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30EA01E48@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.224.36]
x-forefront-prvs: 0933E9FD8D
Content-Type: text/plain; charset="iso-8859-2"
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%
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 17:13:52 -0000

Yours Irrespectively,

John

> -----Original Message-----
> From: Zafar Ali (zali) [mailto:zali@cisco.com]
> Sent: Friday, August 09, 2013 9:46 AM
> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org)
> Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
> 03.txt
> 
> Hi John/ Fatai-
> 
> ERO expansion is an already supported functionality since early days of RSVP-
> TE and is widely deployed.  There is a new requirement to convey latency
> bound in TE networks. Hence a very simple and logical extension in RSVP TE
> to support the newly defined TE (latency) metrics.

JD:  From the draft:  " In these scenarios, there is a need for the ingress node to
       convey the optimization criteria including the TE metrics (e.g., IGP metric, TE
       metric, hop counts, latency, etc.) to be used for the path computation to the
      node performing route computation or expansion."

This is a lot more than just latency and sounds like a description of PCEP.

> 
> If we go with your logic, any operator that wants to deploy latency metric will
> be forced to deploy a PCE (including in the existing deployments) which is a
> no-go.

JD:  Any operator that wishes to provide a path computation service to its clients.  The
'no-go' is simply an assertion.

> Especially given the RSVP TE extensions are so simple.

JD:  Another assertion.

> 
> Latency is an important "traffic engineering" metric and suggesting not to
> support it in RSVP-TE ("traffic engineering") is much odd.

JD:  RSVP-TE is a signaling protocol not a path computation protocol.

> If we go with your
> logic, we should just simply retire RSVP-TE and FORCE every SP to deploy PCE
> (in addition of RSVP-TE) for TE.

JD:  RSVP-TE for signaling and PCEP for path computation.

> 
> Thanks
> 
> Regards Š Zafar
> 
> 
> -----Original Message-----
> From: Fatai Zhang <zhangfatai@huawei.com>
> Date: Thursday, August 8, 2013 10:04 PM
> To: "jdrake@juniper.net" <jdrake@juniper.net>et>, "ccamp@ietf.org"
> <ccamp@ietf.org>
> Subject: Re: [CCAMP]
> draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
> 
> >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
> 
>