Re: [CCAMP] Objective function draft

[Vishnu Pavan Beeram <[e-mail]>]

Totally agree with Daniele.

On a side note, I think it is time we defined within CCAMP what we really
mean by the terms "GMPLS-UNI" and "GMPLS-ENNI". I wouldn't want to avoid
using these terms -- would rather want to see the confusion around these
terms lifted once and for all.

Regards,
-Vishnu

On Tue, Sep 18, 2012 at 3:19 AM, Daniele Ceccarelli <
[e-mail]> wrote:

> +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
> >
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>