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

Hi John,

Agree. 

We should figure out use case, applicability, requirement, framework, etc, and then go to solution. Otherwise, it is really not a good idea to drive something by some specific solutions. 

Best Regards

Fatai

-----Original Message-----
From: John E Drake [mailto:jdrake@juniper.net] 
Sent: Tuesday, August 13, 2013 12:56 AM
To: Daniele Ceccarelli; Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org)
Cc: Adrian Farrel
Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

Daniele,

Comments inline.  However, the discussions since Berlin on UNI enhancements and/or adding additional information related to path computation into the PATH message lead me to the conclusion that we have a problem in CCAMP and that we really should suspend all solutions related work until we have a better idea of the problem we wish to solve.

If you don't think we have a problem, please consider the list of active CCAMP drafts:

http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/

http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/

http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/

http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/

http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/

http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notification/

http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/

http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-metric-bound/

http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/

http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases/

http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects/

http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/

http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/

Yours Irrespectively,

John

> -----Original Message-----
> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Sent: Monday, August 12, 2013 7:29 AM
> To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP
> (ccamp@ietf.org)
> Subject: 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.

JD:  No, that's incorrect.  The C1-C6 Path message arrives at C3.  It triggers C3 to
establish a C3-C4 LSP.  After this LSP is established, C3 forwards the C1-C6 Path
message to C4.  We already have CCAMP drafts from, I believe, Cyril and/or Fatai
that describe how to embed the desired characteristics of the C3-C4 LSP within
the ERO of the C1-C6 Path message.

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

JD:  See above.  This has been a part of GMPLS since its inception.

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

JD:  See above.  The second case is actually the GMPLS baseline behavior.

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

JD:   In addition to what is described above, it is also possible for C1 to use PCEP
to expand the C3-C4 ERO and place the key associated with this expansion in the
ERO of the C1-C6 Path message.

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

JD:  The draft is proposing to embed PCEP within signaling.  By definition, this
*is* allowing the client to access the server layer PCE.  This is no different than
allowing the client to access the server layer PCE without embedding PCE
within signaling.

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