Re: [CCAMP] Objective function draft

Daniele Ceccarelli <> Tue, 18 September 2012 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C55421E8064 for <>; Tue, 18 Sep 2012 00:19:18 -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_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 76DLCGJ-70OH for <>; Tue, 18 Sep 2012 00:19:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C3D2321E8043 for <>; Tue, 18 Sep 2012 00:19:16 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-24-50582073780a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 04.3B.25676.37028505; Tue, 18 Sep 2012 09:19:15 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Tue, 18 Sep 2012 09:19:15 +0200
From: Daniele Ceccarelli <>
To: Gert Grammel <>, "George Swallow (swallow)" <>, Julien Meuric <>
Date: Tue, 18 Sep 2012 09:19:13 +0200
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGKyfc7fsst0WOjIXQZVY+W5ePrzgg
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: it-IT, en-US
Content-Language: en-US
acceptlanguage: it-IT, en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvrW6xQkSAQccSDYsnc26wWCzZtYzF 4s/pv0wWt6c0MTqweEz5vZHVY8mSn0we15uusnu0PDvJFsASxWWTkpqTWZZapG+XwJXR97WV tWCXfcWqF53sDYwvbLsYOTkkBEwk9k88wghhi0lcuLeerYuRi0NI4BSjxNOGe4wQzgJGiekd l9m7GDk42ASsJJ4c8gGJiwg0M0ps+n+UHaSbWUBVou36KVYQmwXIvrPoPzOILSygK/FzfycT iC0ioCfxePcSdgjbSOLMxftsIDavQLjEu1PbwXqFBGIkLj28AFbPKRArMX3pdLAaRgFZiQm7 FzFC7BKXuPVkPhPE1QISS/acZ4awRSVePv7HClEvI/Fr0zdWkJuZBTQl1u/Sh2hVlJjS/ZAd Yq2gxMmZT1gmMIrNQjJ1FkLHLCQds5B0LGBkWcUonJuYmZNebqSXWpSZXFycn6dXnLqJERhh B7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwNq/K3uvw +vX93mObHy1MfvzL8dP2Y6dkF3t1HvpbcOjk+j4BP76epNzJaaHR7baSfXO2rKrZqLau0u+3 x6yyzn9/JzEeFeneytTUHxLq0FW9p2da4Iv3L69tFJV4FfYiIP502fw5tyNXN01akn9j62Vt va5zjKu+OZ6yX2OkbLypOqX3s8NWZyWW4oxEQy3mouJEAKrA859+AgAA
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 07:19:18 -0000


Fully agree on the second part of your statement. At the time of RFC4208 the UNI allowed the exchange of signaling and routing messages. Now that we're defining also the E-NNI i would prefer to have:

- UNI: signaling only
- E-NNI: signaling AND routing (i would prefer to call it reachability rather than routing, because it is not a topology info)

That said, i think that objective function (despite the correct comments from Julien) is not routing but a constraint. The ingress node of the overlay network asks the ingress node of the core network for a path computation with given constraints. 

Viceversa in the case of E-NNI if the objective function was exported to the overlay network as a "property" of a virtual link, then i agree it was routing (reachability) information.


>-----Original Message-----
>From: [] 
>On Behalf Of Gert Grammel
>Sent: lunedì 17 settembre 2012 23.22
>To: George Swallow (swallow); Julien Meuric
>Subject: Re: [CCAMP] Objective function draft
>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
>CCAMP mailing list