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

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

Lou,

The last time I checked, PCE supported multi-layer path computation.  Btw, given this discussion, I found the following draft to be rather interesting:  http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/

Yours Irrespectively,

John

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Friday, August 09, 2013 2:51 PM
> To: John E Drake
> Cc: Matt Hartley (mhartley); Fatai Zhang; CCAMP ([e-mail])
> Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
> 03.txt
> 
> John,
> 	So how does a PCE *in the server layer* learn about the service
> parameters desired by for an LSP, e.g., desired LSP latency, signaled across a
> UNI?
> 
> Now certainly a PCE server in the client layer is a different matter.
> 
> BTW I'm not advocating any particular draft or solution in this message, I'm
> just trying to understand your model. I do agree that it's always best to
> understand what is needed/missing before jumping into discussions on
> solution details.
> 
> Lou
> 
> On 08/09/2013 05:22 PM, John E Drake wrote:
> > 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:[e-mail]]
> >> Sent: Friday, August 09, 2013 1:53 PM
> >> To: Fatai Zhang; John E Drake; CCAMP ([e-mail])
> >> 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf
> >>> Of John E Drake
> >>> Sent: Friday, August 09, 2013 1:49 AM
> >>> To: CCAMP ([e-mail])
> >>> 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
> >>> [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
> >
> 
>