Re: [CCAMP] Objective function draft

[John E Drake <[e-mail]>]

George,

It was simply a question for clarification.  A framework document is definitely needed.

Yours irrespectively,

John


> -----Original Message-----
> From: George Swallow (swallow) [mailto:[e-mail]]
> Sent: Tuesday, September 18, 2012 1:47 PM
> To: John E Drake; Igor Bryskin; Gert Grammel; Julien Meuric
> Cc: [e-mail]
> Subject: Re: [CCAMP] Objective function draft
> 
> 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