Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

"Zhangxian (Xian)" <zhang.xian@huawei.com> Wed, 09 October 2013 06:02 UTC

Return-Path: <zhang.xian@huawei.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 DA9B111E812B for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 23:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 zQqcQbGT-NR0 for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 23:02:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D920611E8136 for <ccamp@ietf.org>; Tue, 8 Oct 2013 23:02:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWP18775; Wed, 09 Oct 2013 06:02:19 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:01:44 +0100
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:02:15 +0100
Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.167]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 14:02:05 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes
Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYD//7cKgIAAdVAA//9yNXA=
Date: Wed, 09 Oct 2013 06:02:05 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B18A48123@szxeml510-mbx.china.huawei.com>
References: <a216a142647f4616aba1bffd7b5b0d6f@BY2PR05MB142.namprd05.prod.outlook.com> <B6585D85A128FD47857D0FD58D8120D30F654FB8@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30F654FB8@xmb-rcd-x14.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes
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, 09 Oct 2013 06:02:36 -0000

Hi, Zafar, 
    
    Thank you for sharing the thoughts. But I cannot agree with what you said below. 

    Path key solution does not necessarily need the presence of a stateful PCE. Similarly with RFC5553, the path key owner needs to retain this information so that I can interpret when used at a later time. Retaining such information does not equal to a stateful PCE which needs to know the LSP states of the whole network it serves. 

Regards,
Xian

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 2013年10月9日 13:26
To: John E Drake; Fatai Zhang; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

Hi John: 

No, RFC 5520/ RFC5533 are fine. The issue is that solution proposed by
draft-zhang-ccamp-route-exclusion-pathkey-00.txt forces customers to
deploy a stateful PCE where PCE need to remember path it has served for
indefinite time. 

Thanks

Regards ... Zafar


-----Original Message-----
From: "jdrake@juniper.net" <jdrake@juniper.net>
Date: Tuesday, October 8, 2013 6:26 PM
To: zali <zali@cisco.com>, Fatai Zhang <zhangfatai@huawei.com>,
"ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Path Diversity using Exclude Routes

>Zafar,
>
>So, is your assertion that RFC5553 is broken?
>
>Yours Irrespectively,
>
>John
>
>> -----Original Message-----
>> From: Zafar Ali (zali) [mailto:zali@cisco.com]
>> Sent: Tuesday, October 08, 2013 10:47 AM
>> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org)
>> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
>> (RSVP-TE) Path Diversity using Exclude Routes
>> 
>> Fatai and all-
>> 
>> In a stateless PCE, Path Keys are transient and they expire. For this
>>solution
>> to work you need a PCE that can keep Paths associated with a Path Key
>> around (a stateful PCE where states are path computed by the PCE).
>> 
>> Thanks
>> 
>> Regards Š Zafar
>> 
>> 
>> -----Original Message-----
>> From: Fatai Zhang <zhangfatai@huawei.com>
>> Date: Tuesday, October 8, 2013 3:01 AM
>> To: "jdrake@juniper.net" <jdrake@juniper.net>, "ccamp@ietf.org"
>> <ccamp@ietf.org>
>> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
>> (RSVP-TE) Path Diversity using Exclude Routes
>> 
>> >Hi John,
>> >
>> >Totally agree with you, I already found these two drafts are much
>> >*useless*.
>> >
>> >This is why we made a new draft (very simple and useful) and put our
>> >feet on the ground.
>> >
>> >http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-p
>> >ath
>> >key-00.txt
>> >
>> >
>> >
>> >
>> >Best Regards
>> >
>> >Fatai
>> >
>> >
>> >-----Original Message-----
>> >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>> Behalf
>> >Of John E Drake
>> >Sent: Thursday, October 03, 2013 2:27 AM
>> >To: CCAMP (ccamp@ietf.org)
>> >Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
>> >(RSVP-TE) Path Diversity using Exclude Routes
>> >
>> >HI,
>> >
>> >I was reading:
>> >http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?include
>> >_te xt=1, and I happened to notice the following paragraph:
>> >
>> >"The means by which the node calculating or expanding the route of the
>> >signaled LSP discovers the route of the path(s) from which the signaled
>> >LSP  requires diversity are beyond the scope of this document. "
>> >
>> >Doesn't this disclaimer effectively render this draft useless?  The
>> >draft also does not define how the node that initially signaled the LSP
>> >finds the 'node calculating or expanding the route'  nor how it
>> >delivers the signaled LSP request to that node.
>> >
>> >As an aside, the draft:
>> >http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route/?
>> >inc
>> >lude_text=1 would be subject to the same criticism except that the
>> >above quoted paragraph is replaced with:
>> >
>> >"The above-mentioned use cases require relevant path inclusion
>> >requirements to be communicated to the route expanding nodes.  This
>> >document addresses  these requirements and defines procedures to
>> >address them."
>> >
>> >Even though this is helpful, the draft doesn't actually define these
>> >procedures.
>> >
>> >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