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

Fatai Zhang <zhangfatai@huawei.com> Wed, 09 October 2013 06:12 UTC

Return-Path: <zhangfatai@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 495DE21E80E3 for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 23:12:40 -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 HQVucKTyUPLb for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 23:12:36 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7188421E80FE for <ccamp@ietf.org>; Tue, 8 Oct 2013 23:12:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT20197; Wed, 09 Oct 2013 06:12:20 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:11:56 +0100
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:12:18 +0100
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.86]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 14:12:05 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, "Zhangxian (Xian)" <zhang.xian@huawei.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//9yNXCAAJkkgP//eVVw
Date: Wed, 09 Oct 2013 06:12:04 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF85CA7841F@SZXEMA504-MBS.china.huawei.com>
References: <C636AF2FA540124E9B9ACB5A6BECCE6B18A48123@szxeml510-mbx.china.huawei.com> <B6585D85A128FD47857D0FD58D8120D30F6550E0@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30F6550E0@xmb-rcd-x14.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.72.159]
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:12:40 -0000

Hi Zafar,

Really interesting for your assertion. 

Did you mean that RFC 5520 is specific for stateful PCE? 

In additon, please look at "Control of Function through Configuration and Policy" of RFC 5520 and RFC5553. 


Best Regards

Fatai


-----Original Message-----
From: Zafar Ali (zali) [mailto:zali@cisco.com] 
Sent: Wednesday, October 09, 2013 2:07 PM
To: Zhangxian (Xian); CCAMP (ccamp@ietf.org)
Cc: John E Drake; Fatai Zhang
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

Hi Zhangxian: 

State does not always means RSVP TE states in the network. PCE (sever)
needs to remember path information (possibly with other path attributes)
it computed for indefinite time. These are states that PCE needs to
remember. Hence, stateful PCE.

Thanks

Regards … Zafar


-----Original Message-----
From: "Zhangxian   (Xian)" <zhang.xian@huawei.com>
Date: Wednesday, October 9, 2013 2:02 AM
To: zali <zali@cisco.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Cc: "jdrake@juniper.net" <jdrake@juniper.net>, Fatai Zhang
<zhangfatai@huawei.com>
Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Path Diversity using Exclude Routes

>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