Re: [CCAMP] Objective function draft

[Lou Berger <[e-mail]>]

Igor,
	I completely agree, but don't see this clearly articulated in the
current draft.

Lou

On 9/19/2012 2:36 PM, Igor Bryskin wrote:
> Lou,
> 
> In the context of ENNI/UNI the multi-domain aspect is important, the
> multi-layer aspect is not important at all. Although, generally
> speaking, network and client physically exist in different layers
> (which by the way not always the case) they always peer each other in
> the same (client) layer, virtual topology exposed to the client also
> belongs to the same (client) layer.
> 
> Igor
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Wednesday, September 19, 2012 2:23 PM
> To: Gert Grammel; Igor Bryskin; John E Drake
> Cc: Julien Meuric; [e-mail]
> Subject: Re: [CCAMP] Objective function draft
> 
> Gert/Igor/John,
> 	I sympathize with Julien's comments.  It seems to me that the draft intermingles the concepts of multi-domain (which includes UNI/ENNI) and multi-layer (which includes, for example MPLS over optical).  While there certainly is much commonality in mechanisms, I think the draft could be clearer on the conceptual definitions and discussions...
> 
> Lou
> 
> On 9/19/2012 1:00 PM, Gert Grammel wrote:
>> Lets try to be more precise and write instead:
>>
>> - "this document uses the term 'External Network Interface (E-NNI)' to describe this interface between two network domains. Both domains may switch on different layers and form a client/server relationship.
>>
>> Although I agree with better readability of the BCP, we have to address the concern of the WG and be precise. So let's try perfecting our language ...
>>
>> Gert
>>
>> ________________________________________
>> From: [e-mail] on behalf of Igor Bryskin
>> Sent: Wednesday, September 19, 2012 12:25:58 PM
>> To: Julien Meuric; John E Drake
>> Cc: [e-mail]
>> Subject: Re: [CCAMP] Objective function draft
>>
>> Hi Julien,
>>
>> This should say:
>> - "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network domains".
>>
>> The important thing is that there is a TE domain demarcation between network and its client. The similar demarcation exists between adjacent network domains in a multi-domain environment. In either case the domains are inter-connected via access/inter-domain links in the data plane and GMPLS-ENNI in the control plane.
>>
>> Hope this helps.
>> Igor
>>
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf 
>> Of Julien Meuric
>> Sent: Wednesday, September 19, 2012 11:59 AM
>> To: John E Drake
>> Cc: [e-mail]
>> Subject: Re: [CCAMP] Objective function draft
>>
>> Hi John.
>>
>> Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
>> - "this memo describes how introducing a representation of server 
>> layer network resources into a client layer network topology enhances 
>> client layer networking in the overlay model";
>> - "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network".
>>
>> E-NNI for client-server (and overlay): this is exactly where I start 
>> to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier 
>> to follow on this.)
>>
>> Julien
>>
>>
>> On 09/19/2012 16:03, John E Drake wrote:
>>> Julien,
>>>
>>> This is the terminology we have been using in draft-beeram.
>>>
>>> Yours irrespectively,
>>>
>>> John
>>>
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>> Behalf Of Julien Meuric
>>>>
>>>> Lou, Gert,
>>>>
>>>> You are right: my previous 1st sentence was too specific, 
>>>> "inter-layer signaling" should be replaced by "client-server 
>>>> signaling". We agree on that, it was not my intention to question that part.
>>>>
>>>> Regards,
>>>>
>>>> Julien
>>>>
>>>>
>>>> Le 19/09/2012 13:46, Lou Berger a écrit :
>>>>> 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]]
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> 
> 
> 
>