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

Fatai Zhang <zhangfatai@huawei.com> Wed, 09 October 2013 07:24 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 1F12721E80D4 for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 00:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 dQtC5FPDvyeB for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 00:24:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE6E021E80C7 for <ccamp@ietf.org>; Wed, 9 Oct 2013 00:23:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYU04692; Wed, 09 Oct 2013 07:23:54 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 08:23:12 +0100
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 08:23:43 +0100
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.86]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 15:23:32 +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//eVVwgACSuID//3dPMA==
Date: Wed, 09 Oct 2013 07:23:31 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF85CA784BD@SZXEMA504-MBS.china.huawei.com>
References: <F82A4B6D50F9464B8EBA55651F541CF85CA7841F@SZXEMA504-MBS.china.huawei.com> <B6585D85A128FD47857D0FD58D8120D30F65515E@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30F65515E@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 07:24:05 -0000

Hi Zafar,

This is operator's policy, and timer can help as what RFC5520 and RFC 5553 defined.

I really don't want to spend my time on discussing the terminology or philosophy (on what is stateful PCE), but I more care about how your draft can work. 

Could you clarify John's question below (it is also my question)? 
How does your draft work in the real implementation? Who can interpret the *LSP identifier* (5ple) defined in your draft? 

==============================================================================================================================
>>"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.



Best Regards

Fatai


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

Fatai- 

In RFC 5520 and RFC5553, PCE is only expected to keep the (path key, Path
info) state for only a short amount of time. Time that is required to
signal an LSP provides an upper bound on the time the (path key, Path
info) state needs to be stored by the PCE. The RFC5520 specifically talks
about path key expiration and is purged. 16 bit path keys are used as
reuse of the path key is assumed.

In your draft the PCE needs to remember the (path key, path info) "states"
for "indefinite" time. If you like we call such PCE "path-stateful PCE"
but it is stateful. Also, the solution is not scalable as a PCE can only
hold 64K of (path key, path info) states.

Thanks

Regards … Zafar


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

>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/?includ
>>>>>e
>>>> >_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
>