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

[Daniele Ceccarelli <[e-mail]>]

Fatai,

John and I are saying exactly the same thing. We don't disagree on procedures, we only disagree on PCEP vs RSVP-TE

BR
Daniele

> -----Original Message-----
> From: Fatai Zhang [mailto:[e-mail]]
> Sent: mercoledì 14 agosto 2013 10:09
> To: Daniele Ceccarelli; John E Drake; Matt Hartley (mhartley); CCAMP
> ([e-mail])
> Cc: Adrian Farrel
> Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
> 03.txt
> 
> Hi Daniele and John,
> 
> I totally agree with John on his following main points. [draft-zhang-ccamp-
> gmpls-h-lsp-mln] is to address what John said.
> 
> Let's go further to see how the second case works.
> 
> If there are no multiple PCEs for inter-layer or multi-domain communications
> (or edge node as a surrogate as John said), what is the value to carry the
> latency info in the signaling? For example, if you want to create an E2E
> connection from C1 to C6 with latency like X, and it takes latency Y from C1 to
> C3, how does it know how much latency needed from C3 to C4 when the
> latency of C4 to C6 is unknown (even the route of C4-C6 is not known).
> 
> 
> ============================================================
> ================================================
> 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.
> 
> 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.
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----Original Message-----
> From: Daniele Ceccarelli [mailto:[e-mail]]
> Sent: Tuesday, August 13, 2013 4:22 PM
> To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP
> ([e-mail])
> Cc: Adrian Farrel
> Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
> 03.txt
> 
> 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-notifi
> > cation/
> >
> > 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-ca
> > ses/
> >
> > 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-l
> > sp/
> >
> > 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
> > >
> >