From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: John E Drake <jdrake@juniper.net>,
 "Matt Hartley (mhartley)" <mhartley@cisco.com>,
 Fatai Zhang <zhangfatai@huawei.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mD//+dlgP/7p/MwgAjEd4D//uHWkA==
Date: Tue, 13 Aug 2013 08:21:37 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se>
References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com>
 <F82A4B6D50F9464B8EBA55651F541CF84EE47162@SZXEML552-MBX.china.huawei.com>
 <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com>
 <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com>
 <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se>
 <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com>
In-Reply-To: <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
Precedence: list

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 alig=
n somewhat. The use cases do point to these other specific signaling extens=
ions drafts, including the objective function draft.=20
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 GMP=
LS 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 genera=
tes 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 definitio=
n, this
> *is* allowing the client to access the server layer PCE.  This is no diff=
erent
> 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 ser=
ver border node (policy, addressing and so on) and not the PCE. Then the se=
rver border node is in charge of querying the PCE.

BR
Daniele



> -----Original Message-----
> From: John E Drake [mailto:jdrake@juniper.net]
> Sent: luned=EC 12 agosto 2013 18:56
> 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
>=20
> Daniele,
>=20
> 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.
>=20
> If you don't think we have a problem, please consider the list of active =
CCAMP
> drafts:
>=20
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/
>=20
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/
>=20
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/
>=20
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/
>=20
> http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/
>=20
> http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notificat=
ion/
>=20
> http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/
>=20
> http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-met=
ric-
> bound/
>=20
> http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/
>=20
> http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases=
/
>=20
> http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-
> subobjects/
>=20
> http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/
>=20
> http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/
>=20
> Yours Irrespectively,
>=20
> John
>=20
> > -----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.
>=20
> JD:  No, that's incorrect.  The C1-C6 Path message arrives at C3.  It tri=
ggers 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 th=
e
> C3-C4 LSP within the ERO of the C1-C6 Path message.
>=20
> >
> > 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.
>=20
> JD:  See above.  This has been a part of GMPLS since its inception.
>=20
> >
> > 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.
>=20
> JD:  See above.  The second case is actually the GMPLS baseline behavior.
>=20
> >
> > 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.
>=20
> 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.
>=20
> >
> > 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.
>=20
> JD:  The draft is proposing to embed PCEP within signaling.  By definitio=
n, this
> *is* allowing the client to access the server layer PCE.  This is no diff=
erent
> than allowing the client to access the server layer PCE without embedding=
 PCE
> within signaling.
>=20
> >
> > BR
> > Daniele
> >
> >
> >
> > > -----Original Message-----
> > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> > Behalf
> > > Of John E Drake
> > > Sent: venerd=EC 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, t=
his
> draft is useful.
> > > >
> > > > Cheers
> > > >
> > > > Matt
> > > >
> > > > > Hi John,
> > > > >
> > > > > Completely agree.
> > > > >
> > > > > I also raised this comment in front of the mic during Berlin meet=
ing.
> > > > >
> > > > >
> > > > >
> > > > > 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
> >
>=20