Re: [CCAMP] 答复: 答复: draft-ali-ccamp-lsp-inquiry-00

"Matt Hartley (mhartley)" <mhartley@cisco.com> Wed, 31 July 2013 17:05 UTC

Return-Path: <mhartley@cisco.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 45A7A11E8167 for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 10:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345]
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 kZuy-r5sckJ0 for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 10:05:34 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C149721F9F8F for <ccamp@ietf.org>; Wed, 31 Jul 2013 10:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37133; q=dns/txt; s=iport; t=1375290334; x=1376499934; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wI3oCNLhqz0YQBG2Dg3/i5ChXjIGXEBUXXF1+iEWrSU=; b=W2Vw2DuRhENlT4+LaLWzW+hvExbJxvlP9lodZEwXHJIrUs7RQnXIUo4U YotJ6ssWTTMk6z16bJWY8+ewTTbdWSasO62M3PWyPO1Ux6ARasVtAuJSf BQSMBdSykQAiAmPfTJptUw1b0qv+l3MhzWZUdOhd6glrmuywBf3CRRkGO E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAIVD+VGtJV2d/2dsb2JhbABbgkJENVCDELJSiD8XgQIWdIIkAQEBBC1MEAIBBgIRAwEBAQsWAQYFAgIwFAYDCAIEAQ0FCBECh3UMjAibQAiRS49WFgoRBgGCYTdzA5kIkCSDFIIq
X-IronPort-AV: E=Sophos; i="4.89,788,1367971200"; d="scan'208,217"; a="241864436"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2013 17:05:33 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6VH5XaE007532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 17:05:33 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 12:05:32 -0500
From: "Matt Hartley (mhartley)" <mhartley@cisco.com>
To: Fatai Zhang <zhangfatai@huawei.com>, "Zafar Ali (zali)" <zali@cisco.com>, Khuzema Pithewan <kpithewan@infinera.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiC08Li0OiAgZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1?= =?gb2312?Q?iry-00?=
Thread-Index: AQHOjeFCpw0OE+evg0GwwUbNPtHgBpl/AzEg
Date: Wed, 31 Jul 2013 17:05:31 +0000
Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105872C8@xmb-rcd-x03.cisco.com>
References: <F82A4B6D50F9464B8EBA55651F541CF84EE43E6F@SZXEML552-MBX.china.huawei.com> <B6585D85A128FD47857D0FD58D8120D30E9F4125@xmb-rcd-x14.cisco.com> <F82A4B6D50F9464B8EBA55651F541CF84EE43F1D@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF84EE43F1D@SZXEML552-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.216.107]
Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC105872C8xmbrcdx03ciscoc_"
MIME-Version: 1.0
Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogtPC4tDogIGRyYWZ0LWFsaS1jY2FtcC1sc3At?= =?gb2312?b?aW5xdWlyeS0wMA==?=
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, 31 Jul 2013 17:05:40 -0000

Fatai,

The core network can only re-evaluate the path based on the properties of the currently-established LSP, but the UNI-C may wish to change things like constraints in between attempts in the interests of finding the best compromise between desired constraints and actually finding a path that’s available.

But yes, we can certainly clarify the requirements in the next revision.

Cheers

Matt


Hi Zafar,

I would like to see much  clearer requirements of your drafts, e.g, if you want the UNC-C to probe the feasibility of a path (e.g, for optimization purpose), I would say this is not the business of the UNI-C, this will be done e.g, based on the policy of the operator from the UNI-N domains (and then there are lots of existing measurements to achieve the objectives).


Thanks

Fatai


发件人: Zafar Ali (zali) [mailto:zali@cisco.com]
发送时间: 2013年7月31日 18:19
收件人: Fatai Zhang; Khuzema Pithewan; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>)
主题: Re: 答复: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Fatai:

Service provider may NOT use PCE in all deployments, e.g., as it is the case of most, if not all, of the current deployments. I would also argue that PCE is not be best place for the inquiry type procedure as scope of PCE is path computation. Path inquiry is not about path computation but about probing feasibility of a path.

Thanks

Regards … Zafar

From: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>
Date: Wednesday, July 31, 2013 5:32 AM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, Khuzema Pithewan <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: 答复: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Zafar,

Please have a  look at draft-zhang-ccamp-gmpls-uni-app<http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-04.txt>xt>, which has a very good solution to address the requirements in your this  draft (and some other requirements in your other drafts).

I don’t think it is a good idea to overload RSVP-TE by introducing path computation functions (or PCEP objects like OF you described in another draft).

Thanks

Fatai



发件人: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] 代表 Zafar Ali (zali)
发送时间: 2013年7月31日 17:00
收件人: Khuzema Pithewan; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>)
主题: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Khuzema:

Please see in-line.

Thanks

Regards … Zafar

From: Khuzema Pithewan <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Zafar,

The point I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly same in terms of object re-use and both of them defines new bits for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not desirable.


The inquire/ potential reopt LSP is likely not to follow path of the currently active LSP. Hence this cannot be implemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP.

Thanks
Khuzema

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Khuzema:

For signaling inquiry LSP with resource locking, we are using the Pre-Planned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking.

Thanks

Regards … Zafar

From: Khuzema Pithewan <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Well.. not really.

You are defining new bits for LSP_ATTRIBUTES for resource locking… aren’t you?

Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP life cycle management, which would be quite cumbersome.

Regards
Khuzema

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Khuzema:

The point is to reuse what already exists. The Pre-Planned LSP flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] and is a glove fit.

Thanks

Regards … Zafar

From: Khuzema Pithewan <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Another point I spoke about in the meeting ..

Why can’t we extend Admin Status object to signal resource locking, checking for re-optimization. Since this operation is typically done in maintenance window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.

This will save network element to manage life of additional LSP and control plane failure related issues attached to the additional LSP.

Khuzema