Re: [CCAMP] Objective function draft

[Lou Berger <[e-mail]>]

Julien,
	Just to add to Gert's point about UNI/ENNI not being related to layers;
you can find the same terminology in the context of MPLS-TP, see RFCs
6215 and 5921.  We already have RFC4208 which provides the foundation of
a GMPLS UNI, and the related RFC5787(bis) work.

I personally see this as the foundation and context for this (and the
beeram) discussion.

Lou

On 9/19/2012 3:14 AM, Gert Grammel wrote:
> Hi Julien,
> 
> Most of the discussions about UNI/ENNI are confusing. Let's start with the remark that UNI/ENNI are terms defined in G.709 and do not relate to layers. They are reference points. You can think to place them in the middle of the fiber between a router and a ROADM. Since it is just fiber, it is pretty clear that no layer crossing is happening there.
> In IETF we have the overlay concept which also doesn't relate to layers but to an administrative domain. Hence an operator can choose to place a 'GMPLS-UNI' where he wants.
> Admittedly common wisdom places UNI as inter-layer communication and here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well as the notion of a 'UNI-protocol' have been brought up in OIF. For whatever it is or was, initial UNI was from SDH/SONET client to SDH/SONET server, hence again no layer crossing even at the protocol level.
> 
> If different layer switching is involved on both sides of an interface, the best reference is RFC5212 (requirements) and RFC6001. They define a consistent multi-layer switching and adaptation model.
> 
> So in order to stay inside a consistent terminology we decided to go strictly with IETF terminology. That's the best we can do for now. 
> 
> To your points:
> - the routing task involves both the IGP and the signaling protocol, especially in case of loose hops or crankbacks;
> --> what you mean with routing task? Is it the routing process itself or something more?
> 
> - the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
> --> an objective function could make sense per LSP if routing information is insufficient. It starts with the assumption that a router down the road may be able to find a better path than what the ingress router does. Given that the ingress has no means to verify if the objective has been followed this may turn out to become a debugging nightmare.
> 
> Gert
> 
> 
> 
> 
> -----Original Message-----
> From: JP Vasseur (jvasseur) [mailto:[e-mail]] 
> Sent: Tuesday, September 18, 2012 2:30 PM
> To: Julien Meuric
> Cc: Gert Grammel; [e-mail]
> Subject: Re: [CCAMP] Objective function draft
> 
> I an completely sharing Julien's point of view. 
> 
> JP Vasseur
> Cisco Fellow
> 
> Sent from my iPhone
> 
> On 18 sept. 2012, at 05:27, "Julien Meuric" <[e-mail]> wrote:
> 
>> Hi Gert.
>>
>> As Daniele has just said, almost all the information in an inter-layer signaling can be seen as input/constraints to the routing process. The IGP-TE brings some link-state information to some network nodes so as to achieve path computation; the result is used in the signaling protocol, on a per LSP basis. I would said that:
>> - the routing task involves both the IGP and the signaling protocol, 
>> especially in case of loose hops or crankbacks;
>> - the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
>>
>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some great confusion in the vocabulary: it is a superset of draft-beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T reference point. A possible option is just to avoid those terms and stick to protocols, namely RSVP-TE and IGP-TE.
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 17/09/2012 23:22, Gert Grammel a écrit :
>>> 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)
>>>
>>> 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
> 
> 
> 
>