Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
John E Drake <jdrake@juniper.net> Mon, 12 August 2013 17:12 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 AD27121F9A2A for <ccamp@ietfa.amsl.com>; Mon, 12 Aug 2013 10:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level:
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1]
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 2SNgruEHxSyq for <ccamp@ietfa.amsl.com>; Mon, 12 Aug 2013 10:11:51 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDF621F9A33 for <ccamp@ietf.org>; Mon, 12 Aug 2013 09:55:52 -0700 (PDT)
Received: from mail128-va3-R.bigfish.com (10.7.14.229) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Mon, 12 Aug 2013 16:55:49 +0000
Received: from mail128-va3 (localhost [127.0.0.1]) by mail128-va3-R.bigfish.com (Postfix) with ESMTP id B0B252000FE; Mon, 12 Aug 2013 16:55:49 +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: -23
X-BigFish: PS-23(zz9371Ic89bh542Iec9I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h)
Received-SPF: pass (mail128-va3: 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:(377454003)(51704005)(13464003)(199002)(189002)(51444003)(37854004)(31966008)(47446002)(33646001)(66066001)(74366001)(77982001)(81542001)(56776001)(54316002)(47736001)(74662001)(74316001)(54356001)(81342001)(65816001)(83072001)(80976001)(59766001)(50986001)(63696002)(47976001)(16406001)(74876001)(80022001)(19580395003)(51856001)(19580405001)(76796001)(69226001)(77096001)(49866001)(76786001)(79102001)(56816003)(19580385001)(4396001)(46102001)(74706001)(76482001)(76576001)(15202345003)(81686001)(83322001)(74502001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail128-va3 (localhost.localdomain [127.0.0.1]) by mail128-va3 (MessageSwitch) id 1376326547674533_11916; Mon, 12 Aug 2013 16:55:47 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.254]) by mail128-va3.bigfish.com (Postfix) with ESMTP id 9F1F418004C; Mon, 12 Aug 2013 16:55:47 +0000 (UTC)
Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 12 Aug 2013 16:55:47 +0000
Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 12 Aug 2013 16:55:46 +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; Mon, 12 Aug 2013 16:55:44 +0000
Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.235]) with mapi id 15.00.0731.000; Mon, 12 Aug 2013 16:55:43 +0000
From: John E Drake <jdrake@juniper.net>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Matt Hartley (mhartley)" <mhartley@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: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERCABER8AIAAGcGw
Date: Mon, 12 Aug 2013 16:55:43 +0000
Message-ID: <403c214579834abf91393c4a1cd2c4dd@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> <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se>
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: 09368DB063
Content-Type: text/plain; charset="iso-8859-1"
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: Mon, 12 Aug 2013 17:12:09 -0000
Daniele, Comments inline. However, the discussions since Berlin on UNI enhancements and/or adding additional information related to path computation into the PATH message lead me to the conclusion that we have a problem in CCAMP and that we really should suspend all solutions related work until we have a better idea of the problem we wish to solve. If you don't think we have a problem, please consider the list of active CCAMP drafts: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/ http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/ http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notification/ http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/ http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-metric-bound/ http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/ http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases/ http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects/ http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/ http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/ Yours Irrespectively, John > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Monday, August 12, 2013 7:29 AM > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP > (ccamp@ietf.org) > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt > > Hi John, all, > > I think there are cases in which the PCEP can't solve the issue. Suppose for > example the simple network below > > C1 --- C2 --- C3 C4 --- C5 --- C6 > \ / > S1 --- S2 --- S3 > > Where Cx are the client nodes and Sx the server nodes and C3-S1 and S3-C4 > the UNIs. > The usual behavior for the setup of an LSP in the client domain between C1 > and C6 consists on 1. "asking" C3 to setup a link in the client layer between > C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP between > C1 and C6 using the link between C3 and C4. JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It triggers C3 to establish a C3-C4 LSP. After this LSP is established, C3 forwards the C1-C6 Path message to C4. We already have CCAMP drafts from, I believe, Cyril and/or Fatai that describe how to embed the desired characteristics of the C3-C4 LSP within the ERO of the C1-C6 Path message. > > If you suppose to have a simpler approach consisting on a single step, it > would be possible to "ask" C1 to setup an end to end LSP between C1 and C6 > with loose ERO C1-C3-C4-C6. JD: See above. This has been a part of GMPLS since its inception. > > In the first case the trigger on C3 is provided by the operator with given > constraints (e.g. Objective functions and/or TE metric bounds) and it would > be easy to inject them into a PCEP request towards the PCE of the server > domains, but what happens in the second case? The operator only issues a > command to C1, which starts a signaling procedure. The RSVP-TE message > reaches C3 and triggers the setup of the link C3-C4 over the UNI. JD: See above. The second case is actually the GMPLS baseline behavior. > > IMHO putting the Objective Functions into RSVP-TE is useful to "convey" > such path computation requirements from C1 to C3. Once the PATH message > reaches C3, it can ask S1 to compute the path towards C4 via RSVP-TE or can > ask the server layer PCE via PCEP. JD: In addition to what is described above, it is also possible for C1 to use PCEP to expand the C3-C4 ERO and place the key associated with this expansion in the ERO of the C1-C6 Path message. > > This is one of the two reasons why I think that Objective Functions and TE > metric Bounds could be useful in RSVP-TE. The second one is that I agree > with Matt when saying that not in all cases the client nodes will be allowed to > access the server layer PCE. JD: The draft is proposing to embed PCEP within signaling. By definition, this *is* allowing the client to access the server layer PCE. This is no different than allowing the client to access the server layer PCE without embedding PCE within signaling. > > BR > Daniele > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: venerdì 9 agosto 2013 23:23 > > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > > Subject: Re: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound- > > 03.txt > > > > 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 >
- [CCAMP] draft-ali-ccamp-rc-objective-function-met… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Fatai Zhang
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Zafar Ali (zali)
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Zafar Ali (zali)
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Matt Hartley (mhartley)
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Lou Berger
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Lou Berger
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Daniele Ceccarelli
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Fatai Zhang
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Daniele Ceccarelli
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Fatai Zhang
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Daniele Ceccarelli
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Zafar Ali (zali)
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Gert Grammel
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… Zafar Ali (zali)
- Re: [CCAMP] draft-ali-ccamp-rc-objective-function… John E Drake