[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!
- [Pce] Domain Sequence dhruv dhody
- Re: [Pce] Domain Sequence Adrian Farrel