Re: [CCAMP] Objective function draft

Julien Meuric <julien.meuric@orange.com> Mon, 17 September 2012 13:37 UTC

Return-Path: <julien.meuric@orange.com>
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 A192521F84C2 for <ccamp@ietfa.amsl.com>; Mon, 17 Sep 2012 06:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wH0i2IpxsoP for <ccamp@ietfa.amsl.com>; Mon, 17 Sep 2012 06:37:28 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9E01721F846E for <ccamp@ietf.org>; Mon, 17 Sep 2012 06:37:28 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A39AF1074003; Mon, 17 Sep 2012 15:40:02 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9C9B81074002; Mon, 17 Sep 2012 15:40:02 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Sep 2012 15:37:27 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Sep 2012 15:37:26 +0200
Message-ID: <50572795.20005@orange.com>
Date: Mon, 17 Sep 2012 15:37:25 +0200
From: Julien Meuric <julien.meuric@orange.com>
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "George Swallow (swallow)" <swallow@cisco.com>
References: <CC750935.C0DF%swallow@cisco.com>
In-Reply-To: <CC750935.C0DF%swallow@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 17 Sep 2012 13:37:26.0678 (UTC) FILETIME=[937BA360:01CD94D9]
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Objective function draft
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, 17 Sep 2012 13:37:29 -0000

Hi George.

Sorry for the late response. You are right: the minutes are not enough 
to trace the full discussion (which we also resumed right after the 
meeting). Let us start by thanking Adrian (as AD? former PCE co-chair? 
author of... ;-) ) for bringing the PCE-associated vocabulary to a 
common understanding.

Actually my concern is sustained by 2 points:

1- The scope of the draft is about giving control of the routing 
objective function to the client node facing a transport layer. I see 
already several existing solution to achieve it:
- a PCEP request from the signaling head node is an option (which is 
associated to the advertisement of the supported objectives in PCEP);
- building IGP adjacencies between client and transport edge nodes 
(a.k.a. "border model") is another one.
In this context, it do not think extending RSVP-TE for this kind of 
application is worth the effort, since the requirement can already be 
addressed.

2- There are cases when previous options are ruled out of a given 
deployment. I do believe that it is not simply due to protocol 
exclusion, but rather to the fact that the SP wants transport routing 
decisions to remain entirely within the transport network (in order to 
fully leave the routing policy in the hands of people doing the layer 
dimensioning). Thus, I feel this trade-off in path selection tuning is 
rather unlikely to happen and I fear we may be talking about RSVP-TE 
over-engineering here. (That is also why I preferred to consider your 
I-Ds separately during the CCAMP meeting.)

However, my comments are mostly related to the client/transport 
relationship. If the I-D is extended to cover more use cases with wider 
scopes (Adrian has made interesting suggestions), turning the overlay 
interconnection into one among a longer list, then my conclusion may be 
different.

Regards,

Julien


Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
> Julien -
>
> Reading the CCAMP notes (which capture little of the actual 
> discussion) I see that there may have been a perception in the room 
> that PCE functionality at the UNI-N was assumed (actual or proxy).
>
> This is not the case. The reason for our draft is that with the UNI, 
> much of the functionality that resides at the headend is moved to the 
> UNI-N. So the UNI-C needs a way to express an objective function even 
> if there is no PCE.
>
> Operationally it seems burdensome to require a PCEP at the UNI-C and a 
> PCEP at the UNI-N, when all that is being done is enabling the UNI-N 
> to perform what the client would do if it were connected to the 
> network via a normal link.
>
> Do you still object to the draft?
>
> Thanks,
>
> …George