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