Re: [CCAMP] Objective function draft

["George Swallow (swallow)" <[e-mail]>]

John -

The UNI-N can simply respond with no-route-to-destination.  Or would you
prefer a more policy specific error.  In any case the UNI-N has control.
AFAIK, that is the primary reason for a UNI in the first place!

//George


On 9/18/12 11:07 AM, "John E Drake" <[e-mail]> wrote:

>Is there a requirement that the objective function specified by the user
>be acceptable to the network?
>
>Yours irrespectively,
>
>John
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Igor Bryskin
>> Sent: Tuesday, September 18, 2012 8:05 AM
>> To: George Swallow (swallow); Gert Grammel; Julien Meuric
>> Cc: [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of George Swallow (swallow)
>> Sent: Tuesday, September 18, 2012 9:45 AM
>> To: Gert Grammel; Julien Meuric
>> Cc: [e-mail]
>> 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" <[e-mail]> 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: [e-mail] on behalf of George Swallow (swallow)
>> >Sent: Monday, September 17, 2012 12:19:21 PM
>> >To: Julien Meuric
>> >Cc: [e-mail]
>> >Subject: Re: [CCAMP] Objective function draft
>> >
>> >Hi Julien -
>> >
>> >On 9/17/12 9:37 AM, "Julien Meuric" <[e-mail]> 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
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ccamp
>> >
>> >
>> 
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp