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

Fatai Zhang <zhangfatai@huawei.com> Wed, 09 October 2013 01:18 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 0847111E80E6 for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 18:18:13 -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=[BAYES_00=-2.599, 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 5RbiVawjI9S4 for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 18:18:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2959B21F9FCA for <ccamp@ietf.org>; Tue, 8 Oct 2013 18:18:05 -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 AYT01222; Wed, 09 Oct 2013 01:18:03 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 02:17:39 +0100
Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 02:18:02 +0100
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.86]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 09:17:55 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, John E Drake <jdrake@juniper.net>, "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/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABN/2rAAErujkA==
Date: Wed, 09 Oct 2013 01:17:55 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF85CA7827E@SZXEMA504-MBS.china.huawei.com>
References: <a7a636bf5b6942a8b74ebf2c71a3212f@BY2PR05MB142.namprd05.prod.outlook.com> <F82A4B6D50F9464B8EBA55651F541CF85CA77C4B@SZXEMA504-MBS.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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 01:18:13 -0000

Hi Daniele,

I don't think your point 2 is an issue. 

If the WG realize that a WG document is *useless*, I think the WG document should stop there and let it die (ie., I don't think a WG document have preference to lead the WG to the wrong direction if this WG document is nothing but wrong). 





Best Regards

Fatai


-----Original Message-----
From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] 
Sent: Wednesday, October 09, 2013 12:32 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

Thanks John for pointing that out. When I first read the draft I missed that point.

I see two differences between the two drafts:
1. utilization of 5ple vs Path key
2. The path diversity draft does not say how to collect the 5ple (which in some cases could not be available at all), the path key draft covers this aspect also

Re 1 I have a moderate preference for the path key for the security reasons that lead to the definition of the Path Key years ago and secondly it's simpler.
Re 2 I don't know how the WG will manage the issue of two competing drafts (one wg, the other individual) but in any case it's an issue that need to be fixed somehow.

BR
Daniele

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Fatai Zhang
> Sent: martedì 8 ottobre 2013 09:02
> To: John E Drake; CCAMP (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-
> pathkey-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_text=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/?include_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