Re: [CCAMP] Objective function draft

Is there a requirement that the objective function specified by the user be acceptable to the network?

Yours irrespectively,

John

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Igor Bryskin
> Sent: Tuesday, September 18, 2012 8:05 AM
> To: George Swallow (swallow); Gert Grammel; Julien Meuric
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
> 
> I completely agree with George. Signaling the objective function is no
> different from signaling EROs or affinities, this is just another
> service specific policy, an instruction to the network as to how the
> service needs to be routed across the network domain. I think Georges
> documents complement our (GMPLS-ENNI) solution. We have the same
> objective but target different groups of clients. Specifically,
> George's clients are those who cannot or won't deal with the routing
> information leaked by the network, but have certain preferences' as to
> how their services need to be routed and rely fully on the network to
> do the routing. Our clients are those that are capable and willing to
> process the network advertisements and to control the routing
> themselves.
> 
> Cheers,
> Igor
> 
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of George Swallow (swallow)
> Sent: Tuesday, September 18, 2012 9:45 AM
> To: Gert Grammel; Julien Meuric
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
> 
> Gert -
> 
> Agreed.  I was loose in my terminology.  The Objective function is
> information that is signaled to the routing function as a constraint.
> There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-
> hop in an ERO.  Another example would be Resource Affinities signaled
> in the Session Attribute object.
> 
> ...George
> 
> On 9/17/12 5:22 PM, "Gert Grammel" <ggrammel@juniper.net> wrote:
> 
> >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