Re: [CCAMP] Objective function draft
Igor Bryskin <IBryskin@advaoptical.com> Wed, 19 September 2012 16:26 UTC
Return-Path: <IBryskin@advaoptical.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 0749A21F85D5 for <ccamp@ietfa.amsl.com>; Wed, 19 Sep 2012 09:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 dsq9ohML8hHi for <ccamp@ietfa.amsl.com>; Wed, 19 Sep 2012 09:26:07 -0700 (PDT)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC2C21F875B for <ccamp@ietf.org>; Wed, 19 Sep 2012 09:26:06 -0700 (PDT)
Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id q8JGQ25G017054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 18:26:02 +0200
Received: from MUC-SRV-MBX1.advaoptical.com (172.20.1.95) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.83.0; Wed, 19 Sep 2012 18:26:02 +0200
Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.508.9; Wed, 19 Sep 2012 18:26:01 +0200
Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0083.000; Wed, 19 Sep 2012 12:25:59 -0400
From: Igor Bryskin <IBryskin@advaoptical.com>
To: Julien Meuric <julien.meuric@orange.com>, John E Drake <jdrake@juniper.net>
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGvMjYkYKv7UmMh7Ftclf6H5eQSrkAgAAAqICAATpfAIAAS/CAgAAjlQCAAAKMgIAAIFcA///BdEA=
Date: Wed, 19 Sep 2012 16:25:58 +0000
Message-ID: <CDAC6F6F5401B245A2C68D0CF8AFDF0A1909DC81@atl-srv-mail10.atl.advaoptical.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>
In-Reply-To: <5059EBB8.8010304@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.1.81]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-19_04:2012-09-19, 2012-09-19, 1970-01-01 signatures=0
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 16:26:08 -0000
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
- Re: [CCAMP] Objective function draft George Swallow (swallow)
- [CCAMP] Objective function draft George Swallow (swallow)
- Re: [CCAMP] Objective function draft Adrian Farrel
- Re: [CCAMP] Objective function draft George Swallow (swallow)
- Re: [CCAMP] Objective function draft Daniele Ceccarelli
- Re: [CCAMP] Objective function draft Julien Meuric
- Re: [CCAMP] Objective function draft George Swallow (swallow)
- Re: [CCAMP] Objective function draft Dieter Beller
- Re: [CCAMP] Objective function draft Gert Grammel
- Re: [CCAMP] Objective function draft Dieter Beller
- Re: [CCAMP] Objective function draft Julien Meuric
- Re: [CCAMP] Objective function draft Daniele Ceccarelli
- Re: [CCAMP] Objective function draft Julien Meuric
- Re: [CCAMP] Objective function draft JP Vasseur (jvasseur)
- [CCAMP] R: Objective function draft BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Objective function draft George Swallow (swallow)
- Re: [CCAMP] Objective function draft Vishnu Pavan Beeram
- Re: [CCAMP] Objective function draft Ong, Lyndon
- Re: [CCAMP] Objective function draft Igor Bryskin
- Re: [CCAMP] Objective function draft John E Drake
- Re: [CCAMP] UNI/NNI (was: Objective function draf… Julien Meuric
- Re: [CCAMP] UNI/NNI (was: Objective function draf… Daniele Ceccarelli
- Re: [CCAMP] Objective function draft Gert Grammel
- Re: [CCAMP] Objective function draft John E Drake
- Re: [CCAMP] UNI/NNI Julien Meuric
- Re: [CCAMP] Objective function draft Lou Berger
- Re: [CCAMP] Objective function draft Julien Meuric
- Re: [CCAMP] Objective function draft John E Drake
- Re: [CCAMP] Objective function draft Julien Meuric
- Re: [CCAMP] Objective function draft Igor Bryskin
- Re: [CCAMP] Objective function draft Gert Grammel
- Re: [CCAMP] Objective function draft Lou Berger
- Re: [CCAMP] Objective function draft Igor Bryskin
- Re: [CCAMP] Objective function draft Lou Berger
- Re: [CCAMP] Objective function draft Dieter Beller
- Re: [CCAMP] Objective function draft John E Drake
- Re: [CCAMP] Objective function draft Igor Bryskin