Re: [CCAMP] Objective function draft

Dieter Beller <> Mon, 17 September 2012 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9667521E8037 for <>; Mon, 17 Sep 2012 13:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.791
X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m4EqgnJb3-HR for <>; Mon, 17 Sep 2012 13:11:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0BB3D21F8616 for <>; Mon, 17 Sep 2012 13:11:45 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3/ICT) with ESMTP id q8HKBfli003664 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Sep 2012 22:11:41 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 17 Sep 2012 22:11:41 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Mon, 17 Sep 2012 16:11:38 -0400
Message-ID: <>
Date: Mon, 17 Sep 2012 22:11:36 +0200
From: Dieter Beller <>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "George Swallow (swallow)" <>
References: <>
In-Reply-To: <>
Content-Type: multipart/related; boundary="------------050902010300070005060504"
X-Originating-IP: []
X-Scanned-By: MIMEDefang 2.69 on
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: Mon, 17 Sep 2012 20:11:47 -0000

Hi George,

I tend to agree that the object function carried in RSVP signaling can be used
whenever path computation is invoked. This should be pretty much independent
whether path computation is done by a CP instance (UNI-N node or E-NNI node)
or a PCE instance.
In case a PCE approach is used, the objective function needs
to be forwarded to the PCE instance using the PCEP.


On 17.09.2012 18:19, George Swallow (swallow) wrote:
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?



CCAMP mailing list" rel="nofollow">



Lorenzstrasse 10
70435 Stuttgart, Germany
T: +49 711 821 43125
M: +49 175 7266874

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub ·
Dr. Rainer Fechner · Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the
e-mail and its attachments, if any, immediately. If you have received this e-mail in
error, you must not forward or make use of the e-mail and its attachments, if any.