Re: [CCAMP] Objective function draft

"JP Vasseur (jvasseur)" <> Tue, 18 September 2012 12:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A464221E80C6 for <>; Tue, 18 Sep 2012 05:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5skaflUitwB4 for <>; Tue, 18 Sep 2012 05:29:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 10C9221E80CC for <>; Tue, 18 Sep 2012 05:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6143; q=dns/txt; s=iport; t=1347971379; x=1349180979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iozB3h6iCNlUH2ecIyOw3IaFEW1JF94otARw1ybVQ3U=; b=LdBwNmMO7VeHl6ZSd8gQavs5H//AIEI3tM6XT0KLE9wv+h23YMAW7pci gTGmk61Bdokuje86Ta+3rcsILeqpLMDBczPJygmVYWzKQmWVGuYPaUQNA jq3XX20rFRMhh2PDJwA4nIPEd7IFrTxAZ4K1DE4+40N2yDu3vKJm6TR0N Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122502607"
Received: from ([]) by with ESMTP; 18 Sep 2012 12:29:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q8ICTc9E006603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 12:29:38 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 07:29:37 -0500
From: "JP Vasseur (jvasseur)" <>
To: Julien Meuric <>
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlZjwJMkJXyGYTMStcjFZG+YUXJeQB1f0
Date: Tue, 18 Sep 2012 12:29:37 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--59.681300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:29:40 -0000

I an completely sharing Julien's point of view. 

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 18 sept. 2012, at 05:27, "Julien Meuric" <> wrote:

> 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.
> Regards,
> Julien
> 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
> _______________________________________________
> CCAMP mailing list