[Pce] Review of draft-ietf-pce-inter-area-as-applicability
Dhruv Dhody <dhruv.dhody@huawei.com> Thu, 31 March 2016 04:22 UTC
Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F286912D93A; Wed, 30 Mar 2016 21:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level:
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9GeQAD-ah5u; Wed, 30 Mar 2016 21:22:04 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29A612D532; Wed, 30 Mar 2016 21:22:03 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml702-cah.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOM13630; Wed, 30 Mar 2016 23:22:01 -0500 (CDT)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 31 Mar 2016 05:20:45 +0100
Received: from BLREML509-MBX.china.huawei.com ([169.254.7.249]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Thu, 31 Mar 2016 09:50:34 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "draft-ietf-pce-inter-area-as-applicability@ietf.org" <draft-ietf-pce-inter-area-as-applicability@ietf.org>
Thread-Topic: Review of draft-ietf-pce-inter-area-as-applicability
Thread-Index: AdGLBKrw/DsK4E4kRtSQjAAEDrp08w==
Date: Thu, 31 Mar 2016 04:20:33 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8C6D5711@BLREML509-MBX.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.244.252]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.56FCA5EA.0005, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.249, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3c412e0cafcfd61fa600834e24fe63ad
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/0w7aMLGF59sXdTg0HThDr63AKm8>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: [Pce] Review of draft-ietf-pce-inter-area-as-applicability
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 31 Mar 2016 04:22:06 -0000
Hi Authors, WG, As promised here is the review of the Inter-Area and AS applicability draft. Main Points - ************* (1) We should add text to indicate that the inter-domain considerations for stateful PCE is out of scope and may be handled in a different document. (2) The draft has some content common with RFC6805, we can (a) add reference and keep the text; (b) add reference and condense the text; (c) keep as it is; (3) A section on inter-AS link and boundary node (ABR/ASBR) considerations can be added. (4) Some text is repetitive, editors can look if reorganization would help to avoid it. (5) Some inter-area considerations (5.1.3 and 5.2) can also be applied to inter-AS, we should also have section for - (a) Inter-AS Diverse Path Computation (perhaps merged with Inter-AS Recovery?) (b) Control and Recording of AS Crossing Minor - ******* Section 1.5 Regarding the last statement The PCE discovery mechanism defined in [RFC5088] and [RFC5089] allow the discovery of PCEs and disclosure of information related to inter-area and inter-AS capable PCEs across area and AS boundaries. This seem to suggest that the the information is leaned across AS boundary, which IGP based discovery wont do. I suggest to remove "across area and AS boundaries". Also the section heading doesn't match the text, I think we can make this section "Inter-area and Inter-AS Capable PCE Discovery". Section 4.3 The heading "Domain Meshes" seem to suggest a mesh between domains, but the text seem to focus on the topology within domain. Section 4.4 OLD Whenever an specific connectivity service is required to have 1+1 protection feature, two completely disjoint paths must be established on an end to end fashion. In a multi-domain environment without, this can be accomplished either by selecting domain diversity, or by ensuring diverse connection within a domain. In order to compute the route diversity, it could be helpful to have SRLG information in the domains. NEW Whenever an specific connectivity service is required to have 1+1 protection feature, two completely disjoint paths must be established in an end to end fashion. In a multi-domain environment, this can be accomplished either by selecting domain diversity, or by ensuring diverse connection within a domain. The domain diversity ensures diversity in the transit domain, the diverse path should be computed within the ingress and egress domain. In order to compute the path diversity, it could be helpful to also have SRLG information in the domains. Section 4.5 Should we also mention the capability for Synchronized domain diverse path computation? Section 5.1.1 - Repeated text from Section 5 can be removed. - [draft-ietf-pce-pcep-domain-sequence] added include or exclude area itself. Section 6.1.1 Better description in section 6.1.3 (of the same title), this can be removed. Section 6.2 Add reference to RFC4216 Section 6.3 Can this text be made more crisp? - backup can be computed after primary or at the same time - not sure about "PCE protection and redundancy" in this context? - s/patch computation/batch computation/ Section 7.1 - Inter-as connectivity can be populated via [RFC5392] and [RFC5316]. - In last para, I am not sure about the relationship between boundary node in TED and selecting the next PCE in the path? Section 7.2 Can this be made '7.1.1' to indicate "Provisioning Techniques" relates to TED? Section 7.5 Why is per-domain [RFC5152] considered in this section? Section 7.6 RFC 6805 doesn't mention discovery of parent/child PCE? Only static configuration is defined there. Section 12.1 The text is currently from RFC6805, with focus on "across AS" and "aggregation". Perhaps this can be updated a bit to include the use of BGP-LS in the context of PCE servers. Section 13.1, 13.2 Text relevant to specific inter-as and inter-area considerations can be added. Section 14 We can add some more details regarding - PCEP over TCP [RFC6952] - Support for TCP-AO [RFC5925] and [PCEPS] Editorial - *********** Expand on first use - - Autonomous System (AS) - Operational Support System (OSS) Section 1 - s/used to discovery the/used to discover the/ Section 1.1 - [Extra space] "area ( as per [RFC4726]" - Suggested rewording avoiding "route computation" and clarifying that small topologies refer to number of domains. OLD: It is assumed that the PCE architecture should only be applied to small inter-domain topologies and not to solve route computation issues across large groups of domains, i.e. the entire Internet. NEW: It is assumed that the PCE architecture is not applied to a large group of domains, such as Internet. Section 1.2.1 OLD The PCC-PCE capability awareness can configured using static configuration or by listening to the periodic advertisements generated by PCEs. NEW The PCC-PCE capability awareness can be configured using static configurations or by automatic and dynamic PCE discovery procedures. Regarding the last para A PCE may cooperate with other PCEs to determine intermediate loose hops. End-to-end path segments may be kept confidential through the application of path keys, to protect partial or full path information. A path key that is a token that replaces a path segment in an explicit route. The path key mechanism is described in [RFC5520] Since this paragraph is about path keys, I see the first statement about loose hops to be misplaced. The path keys were introduced as alternate to loose hope signaling. Section 2 - The term CSPF not used in the document, can be removed Section 3.2 s/else the receiving PCE PCC will be/ /else the receiving PCE or PCC will be/ Section 4.6 Last sentence - s/IGP area or an Autonomous Systems./ /IGP area or a 4-Byte AS number./ Section 5.1.3 Add H-PCE [RFC6805] in last sentence. Section 7.4 s/Otherwise, BRPC [RFC5441] will be used./ /Otherwise, BRPC [RFC5441] or HPCE [RFC6805] will be used./ Section 9 s/PCEP P2MP procedures defined in [RFC7334]./ /inter-domain P2MP procedures defined in [RFC7334]./ Section 11 s/delegated/requested/ - as delegation has a different meaning in stateful PCE ****** Thank You! Apologies for taking some time with this promised review. Regards, Dhruv
- [Pce] Review of draft-ietf-pce-inter-area-as-appl… Dhruv Dhody
- Re: [Pce] Review of draft-ietf-pce-inter-area-as-… Daniel King