Re: [CCAMP] Objective function draft

Julien Meuric <> Tue, 18 September 2012 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D03B521F8770 for <>; Tue, 18 Sep 2012 05:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IpW8PJeZIfZp for <>; Tue, 18 Sep 2012 05:27:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C374D21F8735 for <>; Tue, 18 Sep 2012 05:27:25 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 8F690410E49; Tue, 18 Sep 2012 14:27:24 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 856EE4110D6; Tue, 18 Sep 2012 14:27:24 +0200 (CEST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Sep 2012 14:27:24 +0200
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Sep 2012 14:27:22 +0200
Message-ID: <>
Date: Tue, 18 Sep 2012 14:27:16 +0200
From: Julien Meuric <>
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: Gert Grammel <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 18 Sep 2012 12:27:23.0122 (UTC) FILETIME=[F461A520:01CD9598]
Cc: "" <>
Subject: Re: [CCAMP] Objective function draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Sep 2012 12:27:26 -0000

Hi Gert.

As Daniele has just said, almost all the information in an inter-layer 
signaling can be seen as input/constraints to the routing process. The 
IGP-TE brings some link-state information to some network nodes so as to 
achieve path computation; the result is used in the signaling protocol, 
on a per LSP basis. I would said that:
- the routing task involves both the IGP and the signaling protocol, 
especially in case of loose hops or crankbacks;
- the objective function only makes sense per LSP, which allows to 
consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to 
IGPs or LMP).

I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some 
great confusion in the vocabulary: it is a superset of 
draft-beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the 
ITU-T reference point. A possible option is just to avoid those terms 
and stick to protocols, namely RSVP-TE and IGP-TE.



Le 17/09/2012 23:22, Gert Grammel a écrit :
> Hi George,
> The objective function is in the end a routing information. Mixing routing and signaling in one protocol is something I don't feel comfortable with.
> In other words, if routing is needed between client and server, UNI is the wrong choice. ENNI should be considered instead and
> Draft-beeram-ccamp-gmpls-enni would be a good starting point.
> Gert
> ________________________________________
> From: on behalf of George Swallow (swallow)
> Hi Julien -
> On 9/17/12 9:37 AM, "Julien Meuric" <> wrote:
>> 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.
> As I understand it, in the optical and OTN cases, the border model would
> not be popular
> as in many organizations this crosses political boundaries.
> The point of the draft is to keep the UNI implementation simple and not
> require a PCEP on the uni-c or necessarily on the uni-n.  We will keep the
> format aligned so if the UNI-N needs to make a request of a PCS, it can do
> so rather simply.
>> 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.
> The idea is simply to allow the client to express its needs/wishes.  The
> UNI-N remains in control.  By policy it can use the objective function or
> not.  Further if it does use the objective function and fails to find a
> path it can either say that there was no path or it
> proceed to setup what it can.
>> (That is also why I preferred to consider your
>> I-Ds separately during the CCAMP meeting.)
> Agreed.  I will ask for separate slots.  The discussion at the end was
> rather disjointed.
>> 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.
> I'm happy to widen the scope in this way.
> ...George
>> 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
> _______________________________________________
> CCAMP mailing list