Re: [CCAMP] Objective function draft

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

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
> Sent: Wednesday, September 19, 2012 6:54 AM
> To: Lou Berger
> Cc: [e-mail]
> Subject: Re: [CCAMP] Objective function draft
> 
> 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