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:09 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 5ABF221E80E6 for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 23:09:28 -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.000, 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 b02qOw3fOsI6 for <ccamp@ietfa.amsl.com>; Tue, 8 Oct 2013 23:09:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9F21E80E7 for <ccamp@ietf.org>; Tue, 8 Oct 2013 23:09:20 -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 AYT19979; Wed, 09 Oct 2013 06:09:19 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) 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:08:55 +0100
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:09:19 +0100
Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.167]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 14:09:07 +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/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABN/2rAAHhLcgAABOZAg
Date: Wed, 09 Oct 2013 06:09:06 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B18A4813F@szxeml510-mbx.china.huawei.com>
References: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> <B6585D85A128FD47857D0FD58D8120D30F654FDD@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30F654FDD@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:09:28 -0000
Hi, Zafar, What I understand is quite the opposite. In the "RSVP-TE signaling based solution" you mentioned below, which entity will be able to understand the LSP identifiers and translate it to a node/link list? IMHO, only a stateful PCE can do so. Isn't that the case? 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:37 To: Daniele Ceccarelli; Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Daniele: The main difference between the drafts is that one is RSVP-TE signaling based solution, while the other forces customers to deploy stateful PCE. Calling a RSVP-TE based signaling solution that is a WG document "useless" to force a "stateful" PCE based solution/ architecture to service providers is very inappropriate. Thanks Regards Š Zafar -----Original Message----- From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Date: Tuesday, October 8, 2013 12:32 PM To: Fatai Zhang <zhangfatai@huawei.com>, "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 >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 >_______________________________________________ >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] Resource ReserVation Protocol-Traffic Eng… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Daniele Ceccarelli
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zhangxian (Xian)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zhangxian (Xian)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Margaria, Cyril (Coriant - DE/Munich)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Daniele Ceccarelli
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake