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

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Wed, 14 August 2013 13:35 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26921F9D4F for <ccamp@ietfa.amsl.com>; Wed, 14 Aug 2013 06:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.824
X-Spam-Level:
X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVZqf-O2HMK8 for <ccamp@ietfa.amsl.com>; Wed, 14 Aug 2013 06:35:33 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 61FAF21F8F9A for <ccamp@ietf.org>; Wed, 14 Aug 2013 06:35:32 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-82-520b87a26505
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FF.55.22048.2A78B025; Wed, 14 Aug 2013 15:35:30 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.105]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 14 Aug 2013 15:35:30 +0200
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Fatai Zhang <zhangfatai@huawei.com>, John E Drake <jdrake@juniper.net>, "Matt Hartley (mhartley)" <mhartley@cisco.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//uHWkIADr6aA//+DwWA=
Date: Wed, 14 Aug 2013 13:35:29 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48138D4D@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> <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se> <F82A4B6D50F9464B8EBA55651F541CF85AF34412@SZXEML552-MBS.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF85AF34412@SZXEML552-MBS.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvre6idu4ggxtfDS1+9Nxgtngy5waL xZy7zhZzXjJb9DWfZ3Vg9ZjyeyOrR8uRt6weS5b8ZPK43nSV3WPF5pWMAaxRXDYpqTmZZalF +nYJXBkr531mKTibUvF30w22Bsa3vl2MHBwSAiYSdzt4uxg5gUwxiQv31rN1MXJxCAkcZpR4 fu4klLOEUeL7tZWMIA1sAlYSTw75gDSICKxklNj0KRfEZhZQlzja+4gVxBYWCJCYs/wjG0RN oMTbz3Oh7CSJ5ffmg9WwCKhKPOr9BxbnFfCW+LV2PzPErjMsEs93v2UGSXAKhEm8nv6NBcRm FJCVmLB7ESPEMnGJW0/mM0FcLSCxZM95ZghbVOLl43+sELaSxI8Nl1gg6vUkbkydwgZha0ss W/iaGWKxoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKkT03MTMnvdx8EyMwtg5u+W2wg3HT fbFDjNIcLErivJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYLTpq6xVaNsZku+76UOR 49eg6PO92he297SzaGVvM/9lZx2+7ruw/ImDRevqc2baRMbGtGyWv7Dt2KuZ53w3XX0pZb+r +NDWpOWrtOYFBq3RXimxninD1PHqzksLQ5r7zUuXiOQKr+XZYtLPNW8RV1ix6mOFh0x/ns7V 7f4osuOpLdvZS+VmDUosxRmJhlrMRcWJAGC3EKp7AgAA
Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2013 13:35:38 -0000

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:zhangfatai@huawei.com]
> Sent: mercoledì 14 agosto 2013 10:09
> To: Daniele Ceccarelli; John E Drake; Matt Hartley (mhartley); CCAMP
> (ccamp@ietf.org)
> 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:daniele.ceccarelli@ericsson.com]
> Sent: Tuesday, August 13, 2013 4:22 PM
> To: John E Drake; 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
> 
> 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:jdrake@juniper.net]
> > Sent: lunedì 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
> >
> > 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: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
> > >
> >