Re: [CCAMP] Objective function draft

[Daniele Ceccarelli <[e-mail]>]

+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: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Gert Grammel
>Sent: lunedì 17 settembre 2012 23.22
>To: George Swallow (swallow); Julien Meuric
>Cc: [e-mail]
>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: [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
>