Re: [CCAMP] Objective function draft

Gert Grammel <ggrammel@juniper.net> Wed, 19 September 2012 17:03 UTC

Return-Path: <ggrammel@juniper.net>
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 9265D21F861C for <ccamp@ietfa.amsl.com>; Wed, 19 Sep 2012 10:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level:
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
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 6415REO+9Vmh for <ccamp@ietfa.amsl.com>; Wed, 19 Sep 2012 10:03:14 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 402D721F8622 for <ccamp@ietf.org>; Wed, 19 Sep 2012 10:03:14 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUFn60f9dLd5Y0upCBplOFy6C/NqFxG5C@postini.com; Wed, 19 Sep 2012 10:03:14 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Sep 2012 10:00:52 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Sep 2012 10:00:51 -0700
Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Sep 2012 10:06:24 -0700
Received: from mail52-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 17:00:43 +0000
Received: from mail52-co1 (localhost [127.0.0.1]) by mail52-co1-R.bigfish.com (Postfix) with ESMTP id 5F0F660015F for <ccamp@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Wed, 19 Sep 2012 17:00:43 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -43
X-BigFish: PS-43(zzbb2dI98dI9371Ic89bh542Mec9Q1432Id6eah4015I328cMd6f1izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail52-co1 (localhost.localdomain [127.0.0.1]) by mail52-co1 (MessageSwitch) id 1348074040652519_27690; Wed, 19 Sep 2012 17:00:40 +0000 (UTC)
Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.245]) by mail52-co1.bigfish.com (Postfix) with ESMTP id 90895A4004A; Wed, 19 Sep 2012 17:00:40 +0000 (UTC)
Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 17:00:14 +0000
Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.4.151]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 17:00:11 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: Igor Bryskin <IBryskin@advaoptical.com>, Julien Meuric <julien.meuric@orange.com>, John E Drake <jdrake@juniper.net>
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGKyfc7fsst0WOjIXQZVY+W5eQB6sAgAAAqICAAAIGwIABhEmAgAAjlACAAAKNgIAAIFcAgAAHlwCAAAmPVQ==
Date: Wed, 19 Sep 2012 17:00:11 +0000
Message-ID: <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com>
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> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>, <CDAC6F6F5401B245A2C68D0CF8AFDF0A1909DC81@atl-srv-mail10.atl.advaoptical.com>
In-Reply-To: <CDAC6F6F5401B245A2C68D0CF8AFDF0A1909DC81@atl-srv-mail10.atl.advaoptical.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.159.4]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
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 17:03:15 -0000

Lets try to be more precise and write instead:

- "this document uses the term 'External Network Interface (E-NNI)' to describe this interface between two network domains. Both domains may switch on different layers and form a client/server relationship.

Although I agree with better readability of the BCP, we have to address the concern of the WG and be precise. So let's try perfecting our language ...

Gert

________________________________________
From: ccamp-bounces@ietf.org on behalf of Igor Bryskin
Sent: Wednesday, September 19, 2012 12:25:58 PM
To: Julien Meuric; John E Drake
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi Julien,

This should say:
- "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network domains".

The important thing is that there is a TE domain demarcation between network and its client. The similar demarcation exists between adjacent network domains in a multi-domain environment. In either case the domains are inter-connected via access/inter-domain links in the data plane and GMPLS-ENNI in the control plane.

Hope this helps.
Igor



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Julien Meuric
Sent: Wednesday, September 19, 2012 11:59 AM
To: John E Drake
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

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.)

Julien


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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 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) [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
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> 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