Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

Hi John, all,

I think there are cases in which the PCEP can't solve the issue. Suppose for example the simple network below

C1 --- C2 --- C3                               C4 --- C5 --- C6
                        \                             /
                           S1 --- S2 --- S3

Where Cx are the client nodes and Sx the server nodes and C3-S1 and S3-C4 the UNIs. 
The usual behavior for the setup of an LSP in the client domain between C1 and C6 consists on
1.  "asking" C3 to setup a link in the client layer between C3 and C4 and
2. after its provisioning, "asking" C1to setup an LSP between C1 and C6 using the link between C3 and C4.

If you suppose to have a simpler approach consisting on a single step, it would be possible to "ask" C1 to setup an end to end LSP between C1 and C6 with loose ERO C1-C3-C4-C6.

In the first case the trigger on C3 is provided by the operator with given constraints (e.g. Objective functions and/or TE metric bounds) and it would be easy to inject them into a PCEP request towards the PCE of the server domains, but what happens in the second case? The operator only issues a command to C1, which starts a signaling procedure. The RSVP-TE message reaches C3 and triggers the setup of the link C3-C4 over the UNI.

IMHO putting the Objective Functions into RSVP-TE is useful to "convey" such path computation requirements from C1 to C3. Once the PATH message reaches C3, it can ask S1 to compute the path towards C4 via RSVP-TE or can ask the server layer PCE via PCEP.

This is one of the two reasons why I think that Objective Functions and TE metric Bounds could be useful in RSVP-TE. The second one is that I agree with Matt when saying that not in all cases the client nodes will be allowed to access the server layer PCE.

BR
Daniele 

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of John E Drake
> Sent: venerdì 9 agosto 2013 23:23
> To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org)
> Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
> 03.txt
> 
> PCEP can be deployed whenever the server network wishes to provide a path
> computation service.  What possible advantage to anyone is gained by
> embedding PCEP in RSVP-TE signaling?
> 
> Yours Irrespectively,
> 
> John
> 
> > -----Original Message-----
> > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]
> > Sent: Friday, August 09, 2013 1:53 PM
> > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org)
> > Cc: Matt Hartley (mhartley)
> > Subject: RE: [CCAMP]
> > draft-ali-ccamp-rc-objective-function-metric-bound-
> > 03.txt
> >
> > Fatai, John,
> >
> > I don't think you can guarantee that PCE will be deployed absolutely
> > everywhere, or that you can guarantee the client will be permitted
> > access to the server PCE when it is. In those cases, this draft is useful.
> >
> > Cheers
> >
> > Matt
> >
> > > Hi John,
> > >
> > > Completely agree.
> > >
> > > I also raised this comment in front of the mic during Berlin meeting.
> > >
> > >
> > >
> > > Best Regards
> > >
> > > Fatai
> > >
> > >
> > > -----Original Message-----
> > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> > Behalf
> > > Of John E Drake
> > > Sent: Friday, August 09, 2013 1:49 AM
> > > To: CCAMP (ccamp@ietf.org)
> > > Subject: [CCAMP]
> > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
> > >
> > > Hi,
> > >
> > > I have a real concern with this draft because it appears to be
> > > heading us down the road of re-inventing PCEP in RSVP signaling with
> > > the dubious justification that it is needed in those situations in
> > > which a PCE is not available.  However, if you re-invent PCEP in
> > > RSVP signaling, then you have effectively ensured that there are no
> > > situations in which a PCE or its signaling equivalent are not available.
> > >
> > > Why is this better than simply ensuring that a PCE is available in
> > > those situations in which it is needed?
> > >
> > > Yours Irrespectively,
> > >
> > > John
> > >
> > >
> > > _______________________________________________
> > > CCAMP mailing list
> > > CCAMP@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ccamp
> > > _______________________________________________
> > > CCAMP mailing list
> > > CCAMP@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ccamp
> >
> 
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp