Re: [CCAMP] Objective function draft

Julien Meuric <julien.meuric@orange.com> Wed, 19 September 2012 13:54 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3F21F8644 for <ccamp@ietfa.amsl.com>; Wed, 19 Sep 2012 06:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh-oNRFfxGcX for <ccamp@ietfa.amsl.com>; Wed, 19 Sep 2012 06:53:59 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 518A321F861D for <ccamp@ietf.org>; Wed, 19 Sep 2012 06:53:59 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1CE715D8A02; Wed, 19 Sep 2012 15:53:58 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0DD5C5D89FE; Wed, 19 Sep 2012 15:53:58 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 15:53:57 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 15:53:57 +0200
Message-ID: <5059CE74.6030803@orange.com>
Date: Wed, 19 Sep 2012 15:53:56 +0200
From: Julien Meuric <julien.meuric@orange.com>
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: Lou Berger <lberger@labn.net>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com> <ECF78C00-0A85-4C81-AFF4-529C6996DEDF@cisco.com> <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net>
In-Reply-To: <5059B09B.3050005@labn.net>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Sep 2012 13:53:57.0317 (UTC) FILETIME=[36C6A750:01CD966E]
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Objective function draft
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2012 13:54:00 -0000

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) [mailto:jvasseur@cisco.com]
>>
>> 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" <julien.meuric@orange.com> 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: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>>>>
>>>> Hi Julien -
>>>>
>>>> On 9/17/12 9:37 AM, "Julien Meuric" <julien.meuric@orange.com> 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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>