[Pce] Domain Sequence

dhruv dhody <dhruvd@huawei.com> Thu, 17 December 2009 06:10 UTC

Return-Path: <dhruvd@huawei.com>
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 9B5A03A6B22 for <pce@core3.amsl.com>; Wed, 16 Dec 2009 22:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.121
X-Spam-Level:
X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 7mrTQD9JtJ37 for <pce@core3.amsl.com>; Wed, 16 Dec 2009 22:10:43 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 68D643A6B15 for <pce@ietf.org>; Wed, 16 Dec 2009 22:10:31 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS001N994A0L@szxga03-in.huawei.com> for pce@ietf.org; Thu, 17 Dec 2009 14:09:46 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS001LK94AJS@szxga03-in.huawei.com> for pce@ietf.org; Thu, 17 Dec 2009 14:09:46 +0800 (CST)
Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS002R4945CJ@szxml06-in.huawei.com> for pce@ietf.org; Thu, 17 Dec 2009 14:09:46 +0800 (CST)
Date: Thu, 17 Dec 2009 11:39:40 +0530
From: dhruv dhody <dhruvd@huawei.com>
To: qzhao@huawei.com, daniel@olddog.co.uk, tsaad@cisco.com
Message-id: <001c01ca7edf$874d5740$1f01120a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_usGP3QlRoEbpGuPaYtLHmA)"
Thread-index: Acp+34Ta0pk+EypgS5eVJgYt43IDLw==
Cc: pce@ietf.org
Subject: [Pce] Domain Sequence
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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/mail-archive/web/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>
X-List-Received-Date: Thu, 17 Dec 2009 06:10:51 -0000

Dear Authors,

 

In "draft-king-pce-hierarchy-fwk-02", section 5.6.2 [Hierarchical PCE
End-to-End Path Computation Procedure]: 

Domain paths are denoted as (S-BN11-BN21-D2-BN23-BN31-D,
S-BN11-BN21-D2-BN24-BN32-D, and S-BN13-BN41-D4-BN42-BN33-D). 

i.e. Parent PCE must know about the BNs and there interconnections. 

 

What is the need for this? 

 

Why can't the domain sequence be represented just by a sequence of domains
i.e. [S-D2-D and S-D4-D]? 

BRPC procedure can take domain sequence as input and figure out the
appropriate BNs and there interconnection while applying the VSPT algorithm.


Also note that, Child PCE can use the PCED-discovery [NEIG-PCE-DOMAIN
Sub-TLV] to specify the neighbor PCE-Domain(s) to Parent PCE, without
mentioning any BNs link-interconnection information.  

 

Background:

P2P inter-domain as in RFC 5441 [Section 4.1]

The PCC MAY indicate the sequence of domains to be traversed using the
Include Route Object (IRO) defined in [RFC5440] so that it is available to
all PCEs. 
 
Here domains sequence can be carried as SUB-OBJECTS [defined in RFC 3209],
Type = 32 for AS; a new Type = 5 for Area-id can be defined. There is no
need to carry BNs. That decision should be taken while applying the BRPC
procedures based on all the constraints. 
This works when domain sequence is administratively predetermined or
discovered. 
 
P2MP inter-domain as in
"draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02" [Section 8.2.2] 

The PCE Sequence Object is added to the existing PCE protocol.

 

Instead of PCE sequence, domain sequence works much better. 

-         Existing IRO and sub-objects can be used, similar to P2P BRPC
(backward compatible)

-         PCE(i) for a particular domain (i) is selected dynamically by
PCE(i-1) based on the domain information in the domain-sequence. For PCE
Sequence, PCC/PCE in domain (1), should know about all the PCEs before the
start of procedure, and cannot be changed on the fly.

 

In summary:

1) Domain sequence should carry only the domain-information and not the BNs.
[H-PCE]

2) Domain sequence can be used instead of PCE-Sequence [P2MP-BRPC]

 

Kindly give any comments/suggestions. 

 

Regards,

Dhruv Dhody

Huawei Technologies Co.,Ltd.

Bangalore, India

 

 

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!