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
>