Re: [CCAMP] Objective function draft
Dieter Beller <Dieter.Beller@alcatel-lucent.com> Tue, 18 September 2012 09:54 UTC
Return-Path: <dieter.beller@alcatel-lucent.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 0B51721F85C0 for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 02:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.791
X-Spam-Level:
X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8]
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 T3+DVeClVHW2 for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 02:54:07 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 888C721F8744 for <ccamp@ietf.org>; Tue, 18 Sep 2012 02:54:05 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8I9mL2B014713 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Sep 2012 11:53:55 +0200
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 18 Sep 2012 11:53:15 +0200
Received: from [135.244.34.90] (135.5.27.18) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 18 Sep 2012 05:53:12 -0400
Message-ID: <50584485.8050100@alcatel-lucent.com>
Date: Tue, 18 Sep 2012 11:53:09 +0200
From: Dieter Beller <Dieter.Beller@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> <B5630A95D803744A81C51AD4040A6DAA26E0C5B495@ESESSCMS0360.eemea.ericsson.se>
In-Reply-To: <B5630A95D803744A81C51AD4040A6DAA26E0C5B495@ESESSCMS0360.eemea.ericsson.se>
X-SubSwitch: [CCAMP]; [CCAMP]
Content-Type: multipart/related; boundary="------------030404030103080906030607"
X-Originating-IP: [135.5.27.18]
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
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: Tue, 18 Sep 2012 09:54:08 -0000
+1
I fully agree with your comments/clarifications.
Thanks,
Dieter
+0.5 Fully agree on the second part of your statement. At the time of RFC4208 the UNI allowed the exchange of signaling and routing messages. Now that we're defining also the E-NNI i would prefer to have: - UNI: signaling only - E-NNI: signaling AND routing (i would prefer to call it reachability rather than routing, because it is not a topology info) That said, i think that objective function (despite the correct comments from Julien) is not routing but a constraint. The ingress node of the overlay network asks the ingress node of the core network for a path computation with given constraints. Viceversa in the case of E-NNI if the objective function was exported to the overlay network as a "property" of a virtual link, then i agree it was routing (reachability) information. Cheers, Daniele-----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gert Grammel Sent: lunedì 17 settembre 2012 23.22 To: George Swallow (swallow); Julien Meuric Cc: ccamp@ietf.org Subject: Re: [CCAMP] Objective function draft 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) Sent: Monday, September 17, 2012 12:19:21 PM To: Julien Meuric Cc: ccamp@ietf.org Subject: Re: [CCAMP] Objective function draft 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 arenot enoughto 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 (inorder tofully leave the routing policy in the hands of people doing the layer dimensioning). Thus, I feel this trade-off in path selectiontuning israther 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 caseswith widerscopes (Adrian has made interesting suggestions), turning the overlay interconnection into one among a longer list, then myconclusion may bedifferent.I'm happy to widen the scope in this way. ...GeorgeRegards, 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 withthe UNI,much of the functionality that resides at the headend ismoved to theUNI-N. So the UNI-C needs a way to express an objectivefunction evenif there is no PCE. Operationally it seems burdensome to require a PCEP at theUNI-C anda 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 wereconnected to thenetwork 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" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp_______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp
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
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