Re: [CCAMP] Objective function draft
Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 18 September 2012 13:50 UTC
Return-Path: <vishnupavan@gmail.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 E540121F860D for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 06:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 bCmrjwoSR4oQ for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 06:50:19 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D67921F8608 for <ccamp@ietf.org>; Tue, 18 Sep 2012 06:50:19 -0700 (PDT)
Received: by qafi29 with SMTP id i29so2566324qaf.10 for <ccamp@ietf.org>; Tue, 18 Sep 2012 06:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LocIzuyh1oEnaGj3lRGbLXHhbWxVOlVFlgd7TDul2H0=; b=SOgfB2z12gH4IK9C9WkFH+UwOSauMIatYisE/6FRuyZnKBfBKHEgW1626AHJGIUxmS 0r8kMd+6FzIJQ9ChKZ4YR+5lXOzLP0hCm6yXvLc5M/LKcnOe4heGgNaR8DUqGlB02c09 SUibdcHueqAhuwkQhNlhoN7h3husTxGyGPO065zDvS+21dN62WRJbrczwS/V+7B9NJR7 KYOq1AEbVHR/Oq9LuWWyVSEW9w0+DZglWcXBKL0FGxCueKrG4+K6NsBTxcenkR35ehQk onF5ZYWxxTtDe17cH2vvEgi2AnuMiFx0lInKIscxezuEi92PKjQi7pK/p53yjVQkFfqh STaA==
MIME-Version: 1.0
Received: by 10.229.136.17 with SMTP id p17mr80991qct.139.1347976218876; Tue, 18 Sep 2012 06:50:18 -0700 (PDT)
Received: by 10.49.51.197 with HTTP; Tue, 18 Sep 2012 06:50:18 -0700 (PDT)
In-Reply-To: <B5630A95D803744A81C51AD4040A6DAA26E0C5B495@ESESSCMS0360.eemea.ericsson.se>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> <B5630A95D803744A81C51AD4040A6DAA26E0C5B495@ESESSCMS0360.eemea.ericsson.se>
Date: Tue, 18 Sep 2012 09:50:18 -0400
Message-ID: <CA+YzgTvgOBNqZWNcwM0GKUaHSWbBPhKLZAAW+cSUsXh6qqJViA@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Content-Type: multipart/alternative; boundary="00248c70f9f1b11ac604c9fa2b85"
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 13:50:21 -0000
Totally agree with Daniele. On a side note, I think it is time we defined within CCAMP what we really mean by the terms "GMPLS-UNI" and "GMPLS-ENNI". I wouldn't want to avoid using these terms -- would rather want to see the confusion around these terms lifted once and for all. Regards, -Vishnu On Tue, Sep 18, 2012 at 3:19 AM, Daniele Ceccarelli < daniele.ceccarelli@ericsson.com> wrote: > +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 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 >
- 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