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

[Daniele Ceccarelli <[e-mail]>]

Hi John,

That's an option, maybe a good one.

By the way while it may seem like a large amount of documents, they do align somewhat. The use cases do point to these other specific signaling extensions drafts, including the objective function draft. 
We need to work a lot towards aligning the documents better.

WRT your comments in line what I meant is that (as you pointed out) the GMPLS already supports both of them, either the signaling of an end to end LSP initiated by C1 via RSVP-TE or the signaling between C3 and C4 that generates a link in the client layer (e.g. FA) and allows for its advertisement (draft-previdi-isis-te-metric-extensions-03 and OSPF Traffic Engineering (TE) Metric Extensions) utilization e.g. via LDP.

Finally, wrt your comment:

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

There is a subtle difference: what the client node has access to is the server border node (policy, addressing and so on) and not the PCE. Then the server border node is in charge of querying the PCE.

BR
Daniele



> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: lunedì 12 agosto 2013 18:56
> To: Daniele Ceccarelli; Matt Hartley (mhartley); Fatai Zhang; CCAMP
> ([e-mail])
> 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:[e-mail]]
> > Sent: Monday, August 12, 2013 7:29 AM
> > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP
> > ([e-mail])
> > 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: [e-mail] [mailto:[e-mail]] On
> > Behalf
> > > Of John E Drake
> > > Sent: venerdì 9 agosto 2013 23:23
> > > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP ([e-mail])
> > > 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:[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
> >
>