Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes
"Margaria, Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com> Wed, 09 October 2013 07:21 UTC
Return-Path: <cyril.margaria@coriant.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 3B0A321E80E7 for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 00:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Level:
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
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 p76RiPSwcd5g for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 00:21:35 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id F16AD21E80D4 for <ccamp@ietf.org>; Wed, 9 Oct 2013 00:21:26 -0700 (PDT)
Received: from mail26-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 07:21:26 +0000
Received: from mail26-ch1 (localhost [127.0.0.1]) by mail26-ch1-R.bigfish.com (Postfix) with ESMTP id 0BB5B3A0163; Wed, 9 Oct 2013 07:21:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.165; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0411HT002.eurprd04.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: PS-24(zz9371Ic89bh542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h1155h)
Received-SPF: pass (mail26-ch1: domain of coriant.com designates 157.56.249.165 as permitted sender) client-ip=157.56.249.165; envelope-from=cyril.margaria@coriant.com; helo=AM2PRD0411HT002.eurprd04.prod.outlook.com ; .outlook.com ;
Received: from mail26-ch1 (localhost.localdomain [127.0.0.1]) by mail26-ch1 (MessageSwitch) id 1381303283742201_20367; Wed, 9 Oct 2013 07:21:23 +0000 (UTC)
Received: from CH1EHSMHS031.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail26-ch1.bigfish.com (Postfix) with ESMTP id AFCE510006B; Wed, 9 Oct 2013 07:21:23 +0000 (UTC)
Received: from AM2PRD0411HT002.eurprd04.prod.outlook.com (157.56.249.165) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 07:21:23 +0000
Received: from AM2PRD0411MB422.eurprd04.prod.outlook.com ([169.254.4.83]) by AM2PRD0411HT002.eurprd04.prod.outlook.com ([10.255.163.37]) with mapi id 14.16.0371.000; Wed, 9 Oct 2013 07:21:21 +0000
From: "Margaria, Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Fatai Zhang <zhangfatai@huawei.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/2rAAHhLcgAABdsyw
Date: Wed, 09 Oct 2013 07:21:22 +0000
Message-ID: <523C37072C291347B9730C9291CCA07D02DB2DB2@AM2PRD0411MB422.eurprd04.prod.outlook.com>
References: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> <B6585D85A128FD47857D0FD58D8120D30F654FDD@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30F654FDD@xmb-rcd-x14.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [62.159.77.165]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: coriant.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn%
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:21:41 -0000
Hi Zafar, In my understanding the PKS draft does not require any stateful PCE capability, only a PKS resolution capability. Could you detail why you see stateful a requierement? Mit freundlichen Grüßen / Best Regards Cyril Margaria > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Zafar Ali (zali) > Sent: Wednesday, October 09, 2013 7:37 AM > 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