Re: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions

saquib khan <saquibk@huawei.com> Fri, 21 November 2008 03:09 UTC

Return-Path: <pce-bounces@ietf.org>
X-Original-To: pce-archive@megatron.ietf.org
Delivered-To: ietfarch-pce-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C923A6A5A; Thu, 20 Nov 2008 19:09:31 -0800 (PST)
X-Original-To: pce@core3.amsl.com
Delivered-To: pce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F353A6A41 for <pce@core3.amsl.com>; Thu, 20 Nov 2008 19:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbaeG32YO3Le for <pce@core3.amsl.com>; Thu, 20 Nov 2008 19:09:28 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B915A3A6A01 for <pce@ietf.org>; Thu, 20 Nov 2008 19:09:28 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAN0059BY3H4J@szxga04-in.huawei.com> for pce@ietf.org; Fri, 21 Nov 2008 11:09:17 +0800 (CST)
Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAN003P6Y3HL2@szxga04-in.huawei.com> for pce@ietf.org; Fri, 21 Nov 2008 11:09:17 +0800 (CST)
Received: from hpSAQUIB ([10.18.5.57]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KAN001ZDY3F78@szxml05-in.huawei.com> for pce@ietf.org; Fri, 21 Nov 2008 11:09:17 +0800 (CST)
Date: Fri, 21 Nov 2008 08:39:15 +0530
From: saquib khan <saquibk@huawei.com>
In-reply-to: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4B3209@ENFIMBOX1.ad.datcon.co.uk>
To: 'Nic Neate' <Nic.Neate@dataconnection.com>, 'Quintin Zhao' <qzhao@huawei.com>, 'Aria - Adrian Farrel Personal' <adrian@olddog.co.uk>
Message-id: <009201c94b86$89e11420$3905120a@china.huawei.com>
Organization: htipl
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Thread-index: AclKiHqezXI/YPsdRbqX5Q6CAL9jFQAolHqQAACFhuAAFiej0A==
Cc: pce@ietf.org, 'Mohamad CHAITOU' <mohamad.chaitou@gmail.com>, Jeanlouis.Leroux@orange-ftgroup.com, daniel@olddog.co.uk
Subject: Re: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: saquibk@huawei.com
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pce-bounces@ietf.org
Errors-To: pce-bounces@ietf.org


Hi Nic,
If we consider S2L diversity for all the leaves in the tree, automatically
the complete tree will become diverse, then why do we require a new
diversity option?


-----Original Message-----
From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Nic
Neate
Sent: Thursday, November 20, 2008 10:04 PM
To: Quintin Zhao; Aria - Adrian Farrel Personal
Cc: Jeanlouis.Leroux@orange-ftgroup.com; 'Mohamad CHAITOU'; pce@ietf.org;
daniel@olddog.co.uk
Subject: Re: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions

Hi Quintin,

I don't think "partial path diversity for certain leaves" is quite the point
I was suggesting.

The idea of S2L sub-path diversity is that, when you're doing 1+1
protection, you don't need complete tree diversity.  It is sufficient just
to ensure that, for any given leaf, the S2L sub-paths to that leaf in the
two trees are diverse.  Then, following some network failure, traffic will
still be delivered to all leaves on at least one of the two trees.

Two P2MP LSPs going in opposite ways around a ring is the easiest way to
picture this.

Nic

-----Original Message-----
From: Quintin Zhao [mailto:qzhao@huawei.com]
Sent: 20 November 2008 16:16
To: Aria - Adrian Farrel Personal; Nic Neate
Cc: Jeanlouis.Leroux@orange-ftgroup.com; pce@ietf.org; daniel@olddog.co.uk;
'Mohamad CHAITOU'; fabien.verhaeghe@marben-products.com; zali@cisco.com;
takeda.tomonori@lab.ntt.co.jp
Subject: RE: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions

Nic and Adrian,

Thanks for your suggestions!

By using the existing SVEC functionality, PCC can request the secondary P2MP
LSP path computation to protect the whole P2MP path tree by specifying the
S/N/L bit in the SVEC object.

If we understand the new requirements you suggested for S2L sub-path
diversity, you want the PCC to be able to ask the PCE to compute secondary
P2MP path tree with partial path diversity for certain leaves or certain S2L
sub-path.

We will address these new requirements in our next version of the draft.

Quintin

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, November 19, 2008 3:49 PM
To: Nic Neate; qzhao@huawei.com; Mohamad.Chaitou@orange-ftgroup.com
Cc: Jeanlouis.Leroux@orange-ftgroup.com; pce@ietf.org; daniel@olddog.co.uk
Subject: Re: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions

Ah, that is an interesting and valid point, Nic.

And I think one might also consider "directional diversity" for your ring
example.

A
----- Original Message -----
From: "Nic Neate" <Nic.Neate@dataconnection.com>
To: <qzhao@huawei.com>; <Mohamad.Chaitou@orange-ftgroup.com>
Cc: <Jeanlouis.Leroux@orange-ftgroup.com>; <pce@ietf.org>;
<daniel@olddog.co.uk>
Sent: Wednesday, November 19, 2008 8:28 PM
Subject: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions


Hi,

I have a suggestion for a small extension to the PCEP P2MP draft.

I believe the base PCEP specification currently has three options for
calculating diverse protection paths: link diverse, node diverse and SRLG
diverse (draft-ietf-pce-pcep section 7.13.2).

In P2MP, S2L sub-path diverse is another important case.  I think it would
be good to allow the PCC to request computation of S2L sub-path diverse
protection paths.

This is useful when doing 1+1 protection in a ring topology, for example.

Nic




----------------------------------------------------------------------------
----


> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>



_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce