Re: [CCAMP] Objective function draft

"George Swallow (swallow)" <> Tue, 18 September 2012 13:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 576BD21F865C for <>; Tue, 18 Sep 2012 06:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ltKDul8NepyX for <>; Tue, 18 Sep 2012 06:45:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E961A21F865B for <>; Tue, 18 Sep 2012 06:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5031; q=dns/txt; s=iport; t=1347975912; x=1349185512; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aHdA87ApjGEn5+158p2EKUNfLC8LmVm/YA726j4j7F4=; b=iQUlYz6seyVNDsb+LDds55pL5sh8XttwDIl413fCAK7Kl3bZc/iQTft2 iFeD5Ogi05OsDltrWibNldkQ2sRMr4fGNcytB25eiwWcB9MmZuTp8Heny OZJwDZTmQlWRcGq99J72h3oQuXJbJH2kKxQxTDTavqDsxd4QqCMAz753a Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122763159"
Received: from ([]) by with ESMTP; 18 Sep 2012 13:45:05 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q8IDj48E021945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 13:45:04 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 08:45:04 -0500
From: "George Swallow (swallow)" <>
To: Gert Grammel <>, Julien Meuric <>
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqG4OOKfbxolEe2spFvFX1LfJeQLiYA
Date: Tue, 18 Sep 2012 13:45:04 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--52.086500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <>
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 13:45:13 -0000

Gert -

Agreed.  I was loose in my terminology.  The Objective function is
information that is signaled to the routing function as a constraint.
There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-hop
in an ERO.  Another example would be Resource Affinities signaled in the
Session Attribute object.


On 9/17/12 5:22 PM, "Gert Grammel" <> wrote:

>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.
>From: on behalf of George Swallow (swallow)
>Sent: Monday, September 17, 2012 12:19:21 PM
>To: Julien Meuric
>Subject: Re: [CCAMP] Objective function draft
>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
>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
>I'm happy to widen the scope in this way.
>>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