Re: [CCAMP] Objective function draft

[Lou Berger <[e-mail]>]

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
> 
> 
> 
>