Re: [CCAMP] Objective function draft

Julien Meuric <> Wed, 19 September 2012 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 928EE21F86E3 for <>; Wed, 19 Sep 2012 08:58:53 -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 FjSgpynka97j for <>; Wed, 19 Sep 2012 08:58:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 32C1821F86E1 for <>; Wed, 19 Sep 2012 08:58:52 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id AAEA01074002; Wed, 19 Sep 2012 18:01:28 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id A276BE301B1; Wed, 19 Sep 2012 18:01:28 +0200 (CEST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 17:58:50 +0200
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 17:58:50 +0200
Message-ID: <>
Date: Wed, 19 Sep 2012 17:58:48 +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: John E Drake <>
References: <>, <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-2"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Sep 2012 15:58:50.0351 (UTC) FILETIME=[A8F8E7F0:01CD967F]
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: Wed, 19 Sep 2012 15:58:53 -0000

Hi John.

Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
- "this memo describes how introducing a representation of server layer 
network resources into a client layer network topology enhances client 
layer networking in the overlay model";
- "this document uses the term 'External Network Network Interface 
(E-NNI)' to describe this interface between a client and server network".

E-NNI for client-server (and overlay): this is exactly where I start to 
get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to 
follow on this.)


On 09/19/2012 16:03, John E Drake wrote:
> Julien,
> This is the terminology we have been using in draft-beeram.
> Yours irrespectively,
> John
>> -----Original Message-----
>> From: [] On Behalf
>> Of Julien Meuric
>> Lou, Gert,
>> You are right: my previous 1st sentence was too specific, "inter-layer
>> signaling" should be replaced by "client-server signaling". We agree on
>> that, it was not my intention to question that part.
>> Regards,
>> Julien
>> Le 19/09/2012 13:46, Lou Berger a écrit :
>>> Julien,
>>> 	Just to add to Gert's point about UNI/ENNI not being related to
>>> layers; you can find the same terminology in the context of MPLS-TP,
>>> see RFCs
>>> 6215 and 5921.  We already have RFC4208 which provides the foundation
>>> of a GMPLS UNI, and the related RFC5787(bis) work.
>>> I personally see this as the foundation and context for this (and the
>>> beeram) discussion.
>>> Lou
>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>> Hi Julien,
>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>> with the remark that UNI/ENNI are terms defined in G.709 and do not
>> relate to layers. They are reference points. You can think to place
>> them in the middle of the fiber between a router and a ROADM. Since it
>> is just fiber, it is pretty clear that no layer crossing is happening
>> there.
>>>> In IETF we have the overlay concept which also doesn't relate to
>> layers but to an administrative domain. Hence an operator can choose to
>> place a 'GMPLS-UNI' where he wants.
>>>> Admittedly common wisdom places UNI as inter-layer communication and
>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well
>> as the notion of a 'UNI-protocol' have been brought up in OIF. For
>> whatever it is or was, initial UNI was from SDH/SONET client to
>> SDH/SONET server, hence again no layer crossing even at the protocol
>> level.
>>>> If different layer switching is involved on both sides of an
>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>> They define a consistent multi-layer switching and adaptation model.
>>>> So in order to stay inside a consistent terminology we decided to go
>> strictly with IETF terminology. That's the best we can do for now.
>>>> To your points:
>>>> - the routing task involves both the IGP and the signaling protocol,
>>>> especially in case of loose hops or crankbacks;
>>>> --> what you mean with routing task? Is it the routing process
>> itself or something more?
>>>> - 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).
>>>> --> an objective function could make sense per LSP if routing
>> information is insufficient. It starts with the assumption that a
>> router down the road may be able to find a better path than what the
>> ingress router does. Given that the ingress has no means to verify if
>> the objective has been followed this may turn out to become a debugging
>> nightmare.
>>>> Gert
>>>> -----Original Message-----
>>>> From: JP Vasseur (jvasseur) []
>>>> 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
>>>> _______________________________________________
>>>> CCAMP mailing list
>> _______________________________________________
>> CCAMP mailing list