Re: [CCAMP] Objective function draft
John E Drake <jdrake@juniper.net> Thu, 20 September 2012 09:36 UTC
Return-Path: <jdrake@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 77E6A21F877B for <ccamp@ietfa.amsl.com>; Thu, 20 Sep 2012 02:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.682
X-Spam-Level:
X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 XIrpig-TKZL0 for <ccamp@ietfa.amsl.com>; Thu, 20 Sep 2012 02:36:13 -0700 (PDT)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id C719121F877A for <ccamp@ietf.org>; Thu, 20 Sep 2012 02:36:11 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUFrjhUXIA34L8uWWzaBv85xgOIyVW/rQ@postini.com; Thu, 20 Sep 2012 02:36:11 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::3c95:ce07:f642:ecd2%10]) with mapi; Thu, 20 Sep 2012 02:34:10 -0700
From: John E Drake <jdrake@juniper.net>
To: Dieter Beller <Dieter.Beller@alcatel-lucent.com>, Lou Berger <lberger@labn.net>, Gert Grammel <ggrammel@juniper.net>, Igor Bryskin <IBryskin@advaoptical.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Date: Thu, 20 Sep 2012 02:34:07 -0700
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: Ac2WxXo7onj/BPwgQWq/bM9nZixcxQATRNew
Message-ID: <5E893DB832F57341992548CDBB333163A63321B9B5@EMBX01-HQ.jnpr.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> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>, <CDAC6F6F5401B245A2C68D0CF8AFDF0A1909DC81@atl-srv-mail10.atl.advaoptical.com> <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com> <505A0D6C.5000402@labn.net> <505A60CC.2080806@alcatel-lucent.com>
In-Reply-To: <505A60CC.2080806@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_"; type="multipart/alternative"
MIME-Version: 1.0
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: Thu, 20 Sep 2012 09:36:15 -0000
Dieter, I researched the terms when we made the switch from UNI to E-NNI and from what I recall, UNI is strictly signaling. I think the terms are defined in G.8080 and I have copied Malcolm Betts in hope that he will provide a definitive explanation of the terms. Yours irrespectively, John From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com] Sent: Wednesday, September 19, 2012 5:18 PM To: Lou Berger; Gert Grammel; Igor Bryskin; John E Drake; ccamp@ietf.org Subject: Re: [CCAMP] Objective function draft Hi all, the terms UNI and E-NNI are defining reference points or boundaries if you will between a user (device) and a network (device) and between network domains, respectively (see RFC4208 or ITU-T G.8080). These reference points are located on data plane links between two network devices. Hence, the information that is exchanged across these reference points, ie.e, the infomation on either end of the link is exactly the same, which means that no network layer is crossed at these reference points! Therefore, these reference points are associated with a horizontal interface between the devices (same network layer). Now, orthogonal to that, we have layer transitions in the date plane if we are in a multi-layer environment which means that a client signal is encapsulated into a server layer signal and then carried transparently across the server layer network. This is a data plane client/server relationship and we better talk about data plane layer transitions and do not link these vertical inter-layer relationships to the terms UNI or E-NNI because they have a different meaning as described above. If we are sloppy regarding terminology we may end up creating a lot of confusion. I am in agreement with those who have posted similar messages. Thanks, Dieter On 19.09.2012 20:22, Lou Berger wrote: Gert/Igor/John, I sympathize with Julien's comments. It seems to me that the draft intermingles the concepts of multi-domain (which includes UNI/ENNI) and multi-layer (which includes, for example MPLS over optical). While there certainly is much commonality in mechanisms, I think the draft could be clearer on the conceptual definitions and discussions... Lou On 9/19/2012 1:00 PM, Gert Grammel wrote: 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<mailto: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<mailto: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> [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<mailto: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> [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><mailto: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<mailto: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><mailto: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<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp -- [cid:image001.jpg@01CD96D8.68B3AB40] DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE NETWORKS GROUP, OPTICS DIVISION TERRESTRIAL OPTICS UNIT Lorenzstrasse 10 70435 Stuttgart, Germany T: +49 711 821 43125 M: +49 175 7266874 Dieter.Beller@alcatel-lucent.com<mailto:Dieter.Beller@alcatel-lucent.com> Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart * Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) * Hans-Jörg Daub * Dr. Rainer Fechner * Andreas Gehe This e-mail and its attachments, if any, may contain confidential information. If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately. If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.
- 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