From daniel@olddog.co.uk Wed Jan 9 11:10:38 2013 Return-Path: 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 5FDE821F84C9 for ; Wed, 9 Jan 2013 11:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs4-OWxGafic for ; Wed, 9 Jan 2013 11:10:33 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5040A21F848B for ; Wed, 9 Jan 2013 11:10:33 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r09JARXO013771; Wed, 9 Jan 2013 19:10:28 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r09JAQhw013759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Jan 2013 19:10:27 GMT From: "Daniel King" To: References: <50CF64A3.8060208@cisco.com> In-Reply-To: <50CF64A3.8060208@cisco.com> Date: Wed, 9 Jan 2013 19:10:23 -0000 Message-ID: <003301cdee9c$fa5e8620$ef1b9260$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL6XZGcxOVmDrMTXfdHvuLoNLqd7pXofgcg Content-Language: en-gb Cc: pce@ietf.org, pce-chairs@tools.ietf.org Subject: Re: [Pce] [mpls] draft-ietf-karp-routing-tcp-analysis review requested X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 19:10:38 -0000 Hi Stewart, I was asked to review the document (draft-ietf-karp-routing-tcp-analysis-06). The document provides an analysis of various routing and signaling protocols, including BGP, LDP, PCEP and MSDP, and highlights issues according to the KARP design guide (RFC6518). My review focused on the PCEP sections. In general there are no specific PCEP (PCE WG) actions, the document simply outlines some areas for PCEP security improvement via cryptographic mechanisms. Please find my general comments: - The opening paragraph Section 2.4. (PCEP) is ambiguous. The text refers to LDP, whereas PCE applicability is firmly targeting towards TE (RSVP-TE) LSPs. - Inter-domain security is discussed but does not mention existing methods developed by the PCE WG to minimise security issues and network/service confidentiality (including PCE ID, PATH-KEY, etc.). - Using TCP encryption, like IPsec, can also provide PCEP privacy. - The document would benefit from referencing the MPLS/GMPLS Security Framework (RFC5920). Br, Dan. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: 17 December 2012 18:30 To: idr mailing list; mpls@ietf.org; pce@ietf.org; pim@ietf.org; idr-chairs@tools.ietf.org; mpls-chairs@tools.ietf.org; pce-chairs@tools.ietf.org; pim-chairs@toosl.ietf.org Cc: rtg-ads@tools.ietf.org Subject: [mpls] draft-ietf-karp-routing-tcp-analysis review requested Hi all, draft-ietf-karp-routing-tcp-analysis is on the IESG agenda for 10/Jan. It has been through IETF LC, but we realize that it would be useful for the IDR, MPLS, PCE and PIM working groups to pay special attention to the draft review the sections of this draft that are relevant to their (your) work. I would appreciate feedback from anyone in the WG, but it would be helpful if the WG Chairs could nominate at least one person to review the draft on behalf of the WG. Thanks Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From julien.meuric@orange.com Tue Jan 15 09:34:29 2013 Return-Path: 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 CDD9B21F8703 for ; Tue, 15 Jan 2013 09:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk9xgqm5Weg1 for ; Tue, 15 Jan 2013 09:34:29 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8C21F86CD for ; Tue, 15 Jan 2013 09:34:29 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1081816C004 for ; Tue, 15 Jan 2013 18:34:28 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id CD7B616C002 for ; Tue, 15 Jan 2013 18:34:27 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jan 2013 18:34:27 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jan 2013 18:34:27 +0100 Message-ID: <50F59322.9010208@orange.com> Date: Tue, 15 Jan 2013 18:34:26 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2013 17:34:27.0286 (UTC) FILETIME=[91323760:01CDF346] Subject: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:34:30 -0000 Hi all and best wishes for 2013. This e-mail starts a WG last call on draft-ietf-pce-gmpls-aps-req-06. Please send your comments to the PCE. You may review the document in front of the corresponding extension I-D, which should be last called soon. This WG LC will end on Wednesday January 30, noon UTC. Regards, JP & Julien P.S.: An IPR was disclosed on this I-D in August 2012 (https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-pce-gmpls-aps-req). From morita@kddilabs.jp Tue Jan 15 16:28:56 2013 Return-Path: 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 6DD2111E80DE; Tue, 15 Jan 2013 16:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75jgsxiis2gJ; Tue, 15 Jan 2013 16:28:55 -0800 (PST) Received: from zen.kddilabs.jp (zen.kddilabs.jp [IPv6:2001:200:601:12::31]) by ietfa.amsl.com (Postfix) with ESMTP id B51DE11E80AE; Tue, 15 Jan 2013 16:28:52 -0800 (PST) Received: from localhost (zen.kddilabs.jp [127.0.0.1]) by zen.kddilabs.jp (Postfix) with ESMTP id AC4AB17480FF; Wed, 16 Jan 2013 09:28:48 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from zen.kddilabs.jp ([127.0.0.1]) by localhost (zen.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Er1HTO2K-r; Wed, 16 Jan 2013 09:28:47 +0900 (JST) Received: from localhost (pink.lan.kddilabs.jp [172.19.98.9]) by zen.kddilabs.jp (Postfix) with ESMTP id 929E617480FC; Wed, 16 Jan 2013 09:28:47 +0900 (JST) Received: from [172.19.110.31] (dhcp31.wlan.kddilabs.jp [172.19.110.31]) by localhost (Postfix) with ESMTP id 85D9B34E8327; Wed, 16 Jan 2013 09:28:47 +0900 (JST) Message-ID: <50F5F43F.9060609@kddilabs.jp> Date: Wed, 16 Jan 2013 09:28:47 +0900 From: Itsuro Morita User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mpls@ietf.org, ccamp@ietf.org, pce@ietf.org, mpls-tp@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Jan 2013 00:54:39 -0800 Subject: [Pce] iPOP2013 1st CFP X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:32:40 -0000 (Apologies if you received multiple copies of this message.) Dear CCAMP, PCE, MPLS and MPLS-TP subscribers, iPOP2013 Call for Presentation is now open as follows. The deadline for submitting presentation proposal is February 15th, 2013. Best Regards, iPOP2013 TPC Co-Chair Eiji Oki and Itsuro Morita --------------------------------------------------------------------- Call for Presentation 9th International Conference on IP + Optical Network (iPOP 2013) May 30 - 31, 2013 TKP Otemachi Conference Center, KDDI Otemachi Build., Tokyo, Japan http://www.pilab.jp/ipop2013/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 15, 2013 Notification of acceptance: March 29, 2013 Submission deadline of final presentation slides: April 19, 2013 The Technical Program Committee for iPOP 2013 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not be limited to the following: * Photonic Network for NxGN and NwGN * Multi-layer network (MLN) / Multi-region network (MRN) * Inter-area/Inter-AS network * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS/ASON technologies * GMPLS Network management, OA&M * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Path Computation Element (PCE), Traffic engineering * Application with high-bandwidth demand * L1VPN, Bandwidth on Demand, and Photonic Grid * MPLS and Ethernet networking for Inter-data center connectivity for cloud computing * Carrier Ethernet and MPLS-TP for backhauling * Software Defined Networking * Optical Networking/Switching for Cloud Services * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of 400 words and a maximum of 1 page, including figures and diagrams, speaker$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2013-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2013/ for more details. From quintin.zhao@huawei.com Wed Jan 16 15:06:29 2013 Return-Path: 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 253B811E80DC for ; Wed, 16 Jan 2013 15:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Kabg06fu8T for ; Wed, 16 Jan 2013 15:06:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3710111E809A for ; Wed, 16 Jan 2013 15:06:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANP49896; Wed, 16 Jan 2013 23:06:16 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Jan 2013 23:06:02 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Jan 2013 23:06:15 +0000 Received: from QZHAO (10.212.246.123) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server id 14.1.323.3; Wed, 16 Jan 2013 15:06:06 -0800 From: Quintin Zhao To: , "'Daniel King'" Date: Wed, 16 Jan 2013 18:06:08 -0500 Message-ID: <006c01cdf43e$139cdf50$3ad69df0$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CDF414.2AC6D750" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac30PhERlbUdmJ2mTwuiHToisy4iIA== Content-Language: zh-cn X-Originating-IP: [10.212.246.123] X-CFilter-Loop: Reflected Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:06:29 -0000 ------=_NextPart_000_006D_01CDF414.2AC6D750 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Dan and Adrian, As we discussed I focused on providing text for GCO. The text and diagrams may not be formatted correctly so I also attach text file. If it would be good, I will create some more text for a GCO and VNT scenario. 3.5 Global Concurrent Optimization Global Concurrent Optimization (GCO) is defined in [RFC5557] and represents a key technology for maximizing network efficiency by computing a set of traffic engineered paths concurrently. A GCO path computation request will simultaneously consider the entire topology of the network, and existing LSPs, when computing new services (TE LSPs) or an existing set of services. A GCO may be requested in a number of scenarios, these include: o Routing of new services where the PCE should consider existing services or network topology. o A reoptimization of existing services due to fragmented network resources or sub-optimized placement of sequential computed services. o Recovery of connectivity for bulk services in the event of a large network failure. [RFC5557] states that a GCO is primarily an NMS or a PCE-Server-based solution, due to nature of GCO path computation requests and the need for network and service synchronization. Therefore the ABNO architecture represents a suitable framework for implementing GCO capable path computation functionality. It may be possible that a service provider would want to compute and deploy new services based on predicted traffic matrix. The GCO functionality and capability to perform concurrent computation, provides a significant network optimization advantage to avoid blocking and utilize network resources optimally. The following use case shows how the ABNO architecture and components are used to deploy GCO-enabled services. Furthermore, this use case also includes a capability to consider multi-layer network (MLN) concurrency, in order to optimize network efficiency or meet client network connectivity or bandwidth requirements. 3.5.1 GCO with MLN Use Case The following IP over optical network represents a typical Client and Server network: +-----+ | NMS | | | +--+--+ | +--+---------------------------------------+ | ABNO | | | +---------------------------------------+-++ | | | | +---------------------------------------+--+ / IP/MPLS (Client) Network Layer \ +----------------------------------------------+ | +--------------------------------------------+---+ / Optical (Server) Network Layer \ +----------------------------------------------------+ Figure x: Network Architecture The above network uses an IP/MPLS network layer which is Packet Switching Capable (PSC). The optical layer is Lambda Switching Capable (LSC). The IP packets are aggregated into lambda optical channels using TE LSP tunnels. The lambda optical channels using within the optical network layer may be fixed or convertible. When considering the GCO path computation problem, we can split the requirements into two categories of concurrency optimization objectives, these are: o Minimize aggregate Bandwidth Consumption (MBC). o Minimize the load of the Most Loaded Link (MLL). o Minimize Cumulative Cost of a set of paths (MCC). The use case assumes the GCO request will be offline and be initiated from an NMS, that is it will take significant time to compute the service and the paths reported as part of the request response may want to be verified by the user before being provisioned within the relevant network layer. 1. Request Management The NMS issues a request for new service connectivity for bulk services. The ABNO Controller verifies that the Application Service Coordinator has sufficient rights to make the service request and apply a GCO attribute. Each service request has a source and destination location, bandwidth request and a fixed starting time and duration. The bandwidth request could vary from a few Mbps to the maximum capacity of a lambda optical channel. Various algorithms and computation techniques may be applied to compute the services on a specific set of network planning constraints, but are not described in this procedure. 2. Service Path Computation in the Packet Layer The ABNO Controller sends a GCO-enabled path computation request to the packet layer PCE to compute a suitable path for the requested services. Upon receipt of the service requests the packet PCE then computes the requested paths concurrently applying relevant concurrent capable algorithms. The PCE uses the appropriate policy for the request and consults the TED for the packet network layer. If required, the PCE may compute two bulk service requests based on the requested objective (MBC, MLL or MCC). To compute a set of services for the GCO application, PCEP supports synchronization VECtor (SVEC) lists for synchronized dependent path computations requests as defined in [RFC5440] and described in [RFC6007]. Once the requested GCO service path computation completes, the PCE sends the resulting paths back to the ABNO Controller. The response includes a fully computed explicit path for each service (TE LSP) that needs to be established. The ABNO Controller will forward the candidate paths back to the NMS for user approval before being provisioned within the relevant network layer. 3. Coordination of MLN resources using VNTM and Path Computation in the Optical Layer The ABNO architecture supports both immediate connectivity requirements and advanced scheduling (reservation) of resources. Given a service request that exceeds the current capability of the current packet layer the PCE may invoke the VNTM for the creation of necessary links in the virtual network topology to meet the requirements of immediate or scheduled resources. This interaction is documented in Figure 11 ( Invocation of VNTM and Optical Layer Path Computation). Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes may require a set of existing TE LSPs to be re-computed, or new virtual TE links to be added to the VNT. 4. Provisioning in the Optical Layer These may be immediate or scheduled optical resources (lambdas) dependent on if the initial service requests are immediate or scheduled. 5. Reoptimization of Existing Services (Defragmentation of Network) If it is not possible to provision new resources to meet the bulk service request then it may be possible via traffic grooming of existing LSPs (either packet or optical) to optimize the capacity utilization of the network layer. 1. The packet or optical PCE will compute the new service request and provide a response to the ABNO Controller with the order in which existing TE LSPs should be reoptimized so as to minimize traffic disruption. 2. The PCE will compute the make-before-break replacement service. The PCE will also need to indicate for each request the order in which the old TE LSP should be removed and the order in which the new TE LSP should be setup. If the removal order is lower than the setup order, then the make-before-break may not be performed for the request. 3. Once the initial defragmentation of the network resources has been performed then the new bulk request for services can be performed. Thanks Quintin! * To: "'Daniel King'" >, "'Quintin Zhao'" > * Subject: Re: [Pce] A new draft on an architecture for application-based network operations * From: "Adrian Farrel" > * Date: Fri, 7 Dec 2012 15:13:08 -0000 * Cc: pce at ietf.org * Delivered-to: pce at ietfa.amsl.com * In-reply-to: <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk > * List-archive: * List-help: * List-id: Path Computation Element * List-post: * List-subscribe: , * List-unsubscribe: , * References: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN at mx.google.com > <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk > * Reply-to: adrian at olddog.co.uk * Thread-index: AQFrZjbRxLc5+InYH8ThqvcxIMjyVAEBEe1kmMpCNpA= _____ Hi Quintin, Following up with some more detail on top of Dan's email. >> The draft is very good and is helpful coordinate PCE and TE technologies >> between applications and network. I focused on some sections and have >> following questions and suggestions. Thanks for reading and commenting. Answers in line. >> (1) Applicability of ABNO Architecture. >> Your document abstract and introduction discusses scenarios including >> content and data-center interconnection ("Services such as content >> distribution, distributed databases, or inter-data center connectivity >> place a set of new requirements on the operation of networks."). I >> think the architecture is also relevant to lots of other environments: >> mobile backhaul, core transport, packet switch network, etc. Do you >> agree? > > DK>> Yes, that?s true. We did focus on the data center applicability as > we presented some slides at MPLS Washington 2012 which discussed > that specific scenario and the draft followed some of the same language. I agree. We were trying to describe some service environments rather than network environments, and we certainly don't want to imply any limitations on the uses or the network environments. We expect that the architecture could be used in a whole range of applications: both at the static end of the spectrum (such as mobile backhaul), and for more dynamic services. We will highlight this point in the next revision. >> (2) ABNO Controller. >> Section 2.2.13 (ABNO controller) needs to be discussed in more detail. >> Do you think multiple ABNO controllers or just one ABNO controller >> will be required? Maybe an implementation will use a ABNO Controller >> per "application" (Service Coordinator/NMS/OSS)? > > DK>> When we were white boarding and discussing the architecture we > certainly considered that a number of the ABNO components would require > multiple instances per deployment, including the ABNO Controller. As per > your next point we will try to be more specific in the ABNO text. > >> (3) PCE or PCE's? >> Figure 1 shows *a* PCE. It is expected that multiple PCE' would be used, >> this is important for VNTM Use Case. Maybe you can show more PCE's >> in the figure 1 or describe it? > > DK>> As Above, yes. As Dan says, there can certainly be multiple instances of the functional components in the figure. This could arise within an implementation to load-share, provide specialist capabilities (as you suggest for the ABNO Controller), to maintain confidentiality or separation of function (as you suggest for PCE), or to distribute the function across platforms. We are keen to stress that this is a functional architecture, not an implementation road-map. I think we will add a section on "Implementation of the Architecture" to discuss these points. >> (4) Network Resiliency. >> I am interested in ABNO managing network failures that may be >> protected with shared mesh protection at the network which could >> be MPLS TP or WDM. ABNO would provide a shared path protection >> which optimizes as network conditions change. This is based on >> client layer requirements of reliability and protection restoration >> time. To make this possible the shared mesh protection paths would >> need to be client layer traffic aware and have customer SLA >> information. Do you think this is a good use case? > > DK>> Cool. I think this could represent quite a complex multi-layer > optimization problem. Please let Adrian and me have more > information on the scenario. Ideally documenting the various > component functions (specific for the use case) and each > component interaction, again with some detail on what information > needs provided and perhaps propose protocol mechanism or > extensions. Think of the draft as a tool kit. We would like to reuse > existing technology as much as possible. The use case should reflect > this. Yes, this sounds like an interesting use case. Shared mesh protection (and also 1:n protection) can be a complex provisioning problem, and changes in services as well as changes in network availability can require significant dynamic reassessment of the placement of LSPs. If you would like to suggest text for a use case, I think we would be happy to see it. >> (5) Custom (Abstracted) Topologies. >> Could ABNO provide abstracted topologies via the north-bound >> interface to the requester (provisioning tool)? In China we have >> the customers who would like IPv6 deployment in IPv4 backbone. >> If provider can assign specific nodes and links to be used for >> logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS) >> architecture could be used to provide abstracted topology based >> on the preferred equipment for carrying tunneled IPv6 traffic. Is >> this another use case that may be useful? > > DK>>Maybe we can focus on the SMP use case first. This use case > might benefit from some of the discussion Young raised yesterday, > in terms of the virtual topology presentation. Actually, I think the model already supports exporting information from the TED as described in Section 2.2.2.4. This section does not clearly explain that the TED could be "abstracted", but it should! We will add some text. >> (6) Manageability and Security. >> Are you going to provide Manageability and Security sections in >> future versions of the ABNO document or another document? >> It is an important area for ABNO that needs further discussion. > > DK>> We will most definitely include some discussion in the ABNO > framework, along with policy. Agreed. (Unless someone else writes the text first :-) Thanks, Adrian ------=_NextPart_000_006D_01CDF414.2AC6D750 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear Dan = and Adrian,

 

As we discussed I focused on providing text for GCO. The = text and diagrams may not be formatted correctly so I also attach text = file. If it would be good, I will create some more text for a GCO and = VNT scenario.

 

3.5 Global Concurrent Optimization

 

Global Concurrent Optimization = (GCO) is defined in [RFC5557] and represents a key technology for = maximizing network efficiency by computing a set of traffic engineered = paths concurrently. A GCO path computation request will simultaneously = consider the entire topology of the network, and existing LSPs, when = computing new services (TE LSPs) or an existing set of = services.

 

 

A GCO may be requested in a number of scenarios, these = include:

 

o Routing of new services where the PCE should consider = existing   

  services or network = topology. 

 

o A reoptimization of existing services due to fragmented = network

  resources or sub-optimized placement of sequential = computed services.

 

o Recovery of connectivity for bulk services in the event = of a

  large network failure.

 

[RFC5557] states that a GCO is = primarily an NMS or a PCE-Server-based solution, due to nature of GCO = path computation requests and the need for network and service = synchronization. Therefore the ABNO architecture represents a suitable = framework for implementing GCO capable path

computation = functionality.  

 

It may be possible that a = service provider would want to compute and deploy new services based on = predicted traffic matrix. The GCO functionality and capability to = perform concurrent computation, provides a significant network = optimization advantage to avoid blocking and utilize network resources = optimally.

 

The following use case shows how the ABNO architecture and = components are used to deploy GCO-enabled services. Furthermore, this = use case also includes a capability to consider multi-layer network = (MLN) concurrency, in order to optimize network efficiency or meet = client network connectivity or bandwidth requirements. =

 

3.5.1 GCO with MLN Use Case

 

The following IP over optical = network represents a typical Client and Server

network:

 

 

         = +-----+

         | NMS = |

         = |     |

         = +--+--+

      =       |

         = +--+---------------------------------------+

         = |            =       = ABNO           &nb= sp;        |

         = |            =             &= nbsp;           &n= bsp;     |

         = +---------------------------------------+-++

          =             &= nbsp;         =             &= nbsp;    | |

          =             &= nbsp;           &n= bsp;           &nb= sp;  | |

         = +---------------------------------------+--+

        = /        IP/MPLS (Client) Network = Layer      \

       = +----------------------------------------------+

          =        =             &= nbsp;           &n= bsp;         |

      = +--------------------------------------------+---+

<= p class=3DMsoPlainText>     = /           Optical = (Server) Network Layer         = \

    = +----------------------------------------------------+<= /p>

 

          =        Figure x: Network = Architecture

 

The above network uses an IP/MPLS network layer which is = Packet Switching Capable (PSC). The optical layer is Lambda Switching = Capable (LSC). The IP packets are aggregated into lambda optical = channels using TE LSP tunnels.

The lambda optical channels = using within the optical network layer may be fixed or = convertible.

 

When considering the GCO path computation problem, we can = split the requirements into two categories of concurrency optimization = objectives, these are:

 

o Minimize aggregate Bandwidth = Consumption (MBC).

 

o Minimize the load of the Most Loaded Link = (MLL).

 

o Minimize Cumulative Cost of a set of paths = (MCC).

 

The use case assumes the GCO request will be offline and be = initiated from an NMS, that is it will take significant time to compute = the service and the paths reported as part of the request response may = want to be verified by the user before being provisioned within the = relevant network layer.

 

1. Request = Management

 

The NMS issues a request for new service connectivity for = bulk services.

The ABNO Controller verifies that the Application Service = Coordinator has sufficient rights to make the service request and apply = a GCO attribute.

 

Each service request has a source and destination location, = bandwidth request and a fixed starting time and duration. The bandwidth = request could vary from a few Mbps to the maximum capacity of a lambda = optical channel.

Various algorithms and computation techniques may be = applied to compute the services on a specific set of network planning = constraints,

but are not described in this procedure.   =

 

2. Service Path Computation in the Packet Layer =

 

The ABNO Controller sends a GCO-enabled path computation = request to the packet layer PCE to compute a suitable path for the = requested services.

Upon receipt of the service requests the packet PCE then = computes the requested paths concurrently applying relevant concurrent = capable algorithms.

 

The PCE uses the appropriate policy for the request and = consults the TED for the packet network layer. If required, the PCE may = compute two bulk service requests based on the requested objective (MBC, = MLL or MCC). To compute a set of services for the GCO application, PCEP = supports synchronization VECtor (SVEC) lists for synchronized dependent = path computations requests as defined in [RFC5440] and described in = [RFC6007].

 

Once the requested GCO service path computation completes, = the PCE sends the resulting paths back to the ABNO Controller. The = response includes a fully computed explicit path for each service (TE = LSP) that needs to be established. The ABNO Controller will forward the = candidate paths back to the NMS for user approval before being = provisioned within the relevant network layer.

 

3. Coordination of MLN resources = using VNTM and Path Computation in the Optical = Layer

 

The ABNO architecture supports both immediate connectivity = requirements and advanced scheduling (reservation) of resources. Given a = service request that exceeds the current capability of the current = packet layer the PCE may invoke the VNTM for the creation of necessary = links in the virtual network topology to meet the requirements of = immediate or scheduled resources. This interaction is documented in = Figure 11 ( Invocation of VNTM and Optical Layer Path Computation). =

 

Triggers for VNT reconfiguration, such as traffic demand = changes, network failures, and topological configuration changes may = require a set of existing TE LSPs to be re-computed, or new virtual TE = links to be added to the VNT.

 

4. Provisioning in the Optical = Layer

 

These may be immediate or scheduled optical resources = (lambdas) dependent on if the initial service requests are immediate or = scheduled.

 

5. Reoptimization of Existing Services (Defragmentation of = Network)

 

If it is not possible to provision new resources to meet = the bulk service request then it may be possible via traffic grooming of = existing LSPs (either packet or optical) to optimize the capacity = utilization of the network layer.

 

   1. The packet or = optical PCE will compute the new service

   request and = provide a response to the ABNO Controller with the order =

   in which existing TE LSPs should be = reoptimized so as to minimize

   traffic = disruption.

 

   2. The PCE will compute the make-before-break = replacement service.

   The PCE will also need to indicate for = each request the order in which

   the old TE LSP = should be removed and the order in which the new TE LSP =

   should be setup.  =

   

   If the removal = order is lower than the setup order, then the

   make-before-break may not be performed = for the request.

 

   3. Once the initial defragmentation of the = network resources has been

   performed then = the new bulk request for services can be = performed.

 

Thanks Quintin! 

 

 

 

Hi =
Quintin,
 
Following up with some more detail on top of Dan's =
email.
 
>> The draft is very good and is helpful coordinate =
PCE and TE technologies
>> between applications and network. I focused on =
some sections and have
>> following questions and suggestions. =

 
Thanks for reading and =
commenting.
Answers in =
line.
 
>> (1) Applicability of ABNO Architecture. =

>> Your document =
abstract and introduction discusses scenarios =
including
>> =
content and data-center interconnection ("Services such as =
content
>> =
distribution, distributed databases, or inter-data center =
connectivity
>> =
place a set of new requirements on the operation of networks."). =
I
>> think the =
architecture is also relevant to lots of other =
environments:
>> =
mobile backhaul, core transport, packet switch network, etc. Do =
you
>> agree? =

> 
> DK>> Yes, that?s true. We did focus on the data =
center applicability as
> we presented some slides at MPLS Washington 2012 which =
discussed
> that =
specific scenario and the draft followed some of the same =
language.
 
I =
agree. We were trying to describe some service environments rather =
than
network =
environments, and we certainly don't want to imply any limitations =
on
the uses or the =
network environments. We expect that the architecture could =
be
used in a whole range =
of applications: both at the static end of the =
spectrum
(such as mobile =
backhaul), and for more dynamic =
services.
 
We =
will highlight this point in the next =
revision.
 
>> (2) ABNO =
Controller.
>> =
Section 2.2.13 (ABNO controller) needs to be discussed in more =
detail.
>> Do you =
think multiple ABNO controllers or just one ABNO =
controller
>> will =
be required? Maybe an implementation will use a ABNO =
Controller
>> per =
"application" (Service Coordinator/NMS/OSS)? =

> 
> DK>> When we were white boarding and discussing =
the architecture we
> =
certainly considered that a number of the ABNO components would =
require
> multiple =
instances per deployment, including the ABNO Controller. As =
per
> your next point =
we will try to be more specific in the ABNO text. =

> 
>> (3) PCE or =
PCE's?
>> Figure 1 =
shows *a* PCE. It is expected that multiple PCE' would be =
used,
>> this is =
important for VNTM Use Case. Maybe you can show more =
PCE's
>> in the =
figure 1 or describe it?
> 
> DK>> As Above, =
yes.
 
As =
Dan says, there can certainly be multiple instances of the =
functional
components in =
the figure. This could arise within an implementation =
to
load-share, provide =
specialist capabilities (as you suggest for the =
ABNO
Controller), to =
maintain confidentiality or separation of function (as =
you
suggest for PCE), or =
to distribute the function across platforms. We are keen =
to
stress that this is a =
functional architecture, not an implementation road-map. =
I
think we will add a =
section on "Implementation of the Architecture" to =
discuss
these =
points.
 
>> (4) Network =
Resiliency.
>> I am =
interested in ABNO managing network failures that may be =

>> protected with =
shared mesh protection at the network which =
could
>> be MPLS TP =
or WDM. ABNO would provide a shared path =
protection
>> which =
optimizes as network conditions change. This is based =
on
>> client layer =
requirements of reliability and protection =
restoration
>> =
time. To make this possible the shared mesh protection paths =
would
>> need to be =
client layer traffic aware and have customer =
SLA
>> information. =
Do you think this is a good use case?
> 
> DK>> Cool. I think this could represent quite a =
complex multi-layer
> =
optimization problem. Please let Adrian and me have =
more
> information on =
the scenario. Ideally documenting the =
various
> component =
functions (specific for the use case) and =
each
> component =
interaction, again with some detail on what =
information
> needs =
provided and perhaps propose protocol mechanism =
or
> extensions. Think =
of the draft as a tool kit. We would like to =
reuse
> existing =
technology as much as possible. The use case should =
reflect
> this. =

 
Yes, =
this sounds like an interesting use case. Shared mesh protection (and =
also
1:n protection) can =
be a complex provisioning problem, and changes in =
services
as well as =
changes in network availability can require significant =
dynamic
reassessment of =
the placement of LSPs. If you would like to suggest text for =
a
use case, I think we =
would be happy to see it.
 
>> (5) Custom (Abstracted) Topologies. =
      
>> Could ABNO provide abstracted topologies via the =
north-bound
>> =
interface to the requester (provisioning tool)? In China we =
have
>> the =
customers who would like IPv6 deployment in IPv4 =
backbone.
>> If =
provider can assign specific nodes and links to be used =
for
>> logically =
isolated IPv6 plane, then the ABNO (I2RS and =
BGP-LS)
>> =
architecture could be used to provide abstracted topology =
based
>> on the =
preferred equipment for carrying tunneled IPv6 traffic. =
Is
>> this another =
use case that may be useful?
> 
> DK>>Maybe we can focus on the SMP use case =
first. This use case
> =
might benefit from some of the discussion Young raised =
yesterday,
> in terms =
of the virtual topology presentation. =
 
 
Actually, I think the model already supports exporting =
information from the TED
as described in Section 2.2.2.4. This section does not =
clearly explain that the
TED could be "abstracted", but it should! We will =
add some text.
 
>> (6) Manageability and Security.  =

>> Are you going =
to provide Manageability and Security sections =
in
>> future =
versions of the ABNO document or another document? =

>> It is an =
important area for ABNO that needs further discussion. =

> 
> DK>> We will most definitely include some =
discussion in the ABNO 
> framework, along with policy. =

 
Agreed. (Unless someone else writes the text first =
:-)
 
Thanks,
Adrian
 

 

------=_NextPart_000_006D_01CDF414.2AC6D750-- From adrian@olddog.co.uk Thu Jan 17 08:47:01 2013 Return-Path: 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 0233921F879B for ; Thu, 17 Jan 2013 08:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LF-Xg-cgrPR for ; Thu, 17 Jan 2013 08:46:58 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7A07221F879A for ; Thu, 17 Jan 2013 08:46:57 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0HGkmIL024439; Thu, 17 Jan 2013 16:46:48 GMT Received: from 950129200 (089144192047.atnat0001.highway.a1.net [89.144.192.47]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0HGkULx024017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jan 2013 16:46:33 GMT From: "Adrian Farrel" To: "'Quintin Zhao'" References: <006c01cdf43e$139cdf50$3ad69df0$@zhao@huawei.com> In-Reply-To: <006c01cdf43e$139cdf50$3ad69df0$@zhao@huawei.com> Date: Thu, 17 Jan 2013 16:46:29 -0000 Message-ID: <013301cdf4d2$3692eb00$a3b8c100$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01CDF4D2.36A5FDD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJqqmkGGC9PCpoR3bdxkUSmeu5+zpcUTjZg Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:47:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0134_01CDF4D2.36A5FDD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Quintin, Thanks for this text. Looks good. Dan and I will work to fold it into the document. It is quite a substantial piece of text. Do you mind if we name you as a Contributing Author? Wrt a scenario for GCO and VNT, that also sounds interesting. Slightly worried that it may get a bit complicated, but if you are capable of documenting it, I think it would be a fine addition to the document. Thanks, Adrian From: Quintin Zhao [mailto:quintin.zhao@huawei.com] Sent: 16 January 2013 23:06 To: adrian@olddog.co.uk; 'Daniel King' Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations Dear Dan and Adrian, As we discussed I focused on providing text for GCO. The text and diagrams may not be formatted correctly so I also attach text file. If it would be good, I will create some more text for a GCO and VNT scenario. 3.5 Global Concurrent Optimization Global Concurrent Optimization (GCO) is defined in [RFC5557] and represents a key technology for maximizing network efficiency by computing a set of traffic engineered paths concurrently. A GCO path computation request will simultaneously consider the entire topology of the network, and existing LSPs, when computing new services (TE LSPs) or an existing set of services. A GCO may be requested in a number of scenarios, these include: o Routing of new services where the PCE should consider existing services or network topology. o A reoptimization of existing services due to fragmented network resources or sub-optimized placement of sequential computed services. o Recovery of connectivity for bulk services in the event of a large network failure. [RFC5557] states that a GCO is primarily an NMS or a PCE-Server-based solution, due to nature of GCO path computation requests and the need for network and service synchronization. Therefore the ABNO architecture represents a suitable framework for implementing GCO capable path computation functionality. It may be possible that a service provider would want to compute and deploy new services based on predicted traffic matrix. The GCO functionality and capability to perform concurrent computation, provides a significant network optimization advantage to avoid blocking and utilize network resources optimally. The following use case shows how the ABNO architecture and components are used to deploy GCO-enabled services. Furthermore, this use case also includes a capability to consider multi-layer network (MLN) concurrency, in order to optimize network efficiency or meet client network connectivity or bandwidth requirements. 3.5.1 GCO with MLN Use Case The following IP over optical network represents a typical Client and Server network: +-----+ | NMS | | | +--+--+ | +--+---------------------------------------+ | ABNO | | | +---------------------------------------+-++ | | | | +---------------------------------------+--+ / IP/MPLS (Client) Network Layer \ +----------------------------------------------+ | +--------------------------------------------+---+ / Optical (Server) Network Layer \ +----------------------------------------------------+ Figure x: Network Architecture The above network uses an IP/MPLS network layer which is Packet Switching Capable (PSC). The optical layer is Lambda Switching Capable (LSC). The IP packets are aggregated into lambda optical channels using TE LSP tunnels. The lambda optical channels using within the optical network layer may be fixed or convertible. When considering the GCO path computation problem, we can split the requirements into two categories of concurrency optimization objectives, these are: o Minimize aggregate Bandwidth Consumption (MBC). o Minimize the load of the Most Loaded Link (MLL). o Minimize Cumulative Cost of a set of paths (MCC). The use case assumes the GCO request will be offline and be initiated from an NMS, that is it will take significant time to compute the service and the paths reported as part of the request response may want to be verified by the user before being provisioned within the relevant network layer. 1. Request Management The NMS issues a request for new service connectivity for bulk services. The ABNO Controller verifies that the Application Service Coordinator has sufficient rights to make the service request and apply a GCO attribute. Each service request has a source and destination location, bandwidth request and a fixed starting time and duration. The bandwidth request could vary from a few Mbps to the maximum capacity of a lambda optical channel. Various algorithms and computation techniques may be applied to compute the services on a specific set of network planning constraints, but are not described in this procedure. 2. Service Path Computation in the Packet Layer The ABNO Controller sends a GCO-enabled path computation request to the packet layer PCE to compute a suitable path for the requested services. Upon receipt of the service requests the packet PCE then computes the requested paths concurrently applying relevant concurrent capable algorithms. The PCE uses the appropriate policy for the request and consults the TED for the packet network layer. If required, the PCE may compute two bulk service requests based on the requested objective (MBC, MLL or MCC). To compute a set of services for the GCO application, PCEP supports synchronization VECtor (SVEC) lists for synchronized dependent path computations requests as defined in [RFC5440] and described in [RFC6007]. Once the requested GCO service path computation completes, the PCE sends the resulting paths back to the ABNO Controller. The response includes a fully computed explicit path for each service (TE LSP) that needs to be established. The ABNO Controller will forward the candidate paths back to the NMS for user approval before being provisioned within the relevant network layer. 3. Coordination of MLN resources using VNTM and Path Computation in the Optical Layer The ABNO architecture supports both immediate connectivity requirements and advanced scheduling (reservation) of resources. Given a service request that exceeds the current capability of the current packet layer the PCE may invoke the VNTM for the creation of necessary links in the virtual network topology to meet the requirements of immediate or scheduled resources. This interaction is documented in Figure 11 ( Invocation of VNTM and Optical Layer Path Computation). Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes may require a set of existing TE LSPs to be re-computed, or new virtual TE links to be added to the VNT. 4. Provisioning in the Optical Layer These may be immediate or scheduled optical resources (lambdas) dependent on if the initial service requests are immediate or scheduled. 5. Reoptimization of Existing Services (Defragmentation of Network) If it is not possible to provision new resources to meet the bulk service request then it may be possible via traffic grooming of existing LSPs (either packet or optical) to optimize the capacity utilization of the network layer. 1. The packet or optical PCE will compute the new service request and provide a response to the ABNO Controller with the order in which existing TE LSPs should be reoptimized so as to minimize traffic disruption. 2. The PCE will compute the make-before-break replacement service. The PCE will also need to indicate for each request the order in which the old TE LSP should be removed and the order in which the new TE LSP should be setup. If the removal order is lower than the setup order, then the make-before-break may not be performed for the request. 3. Once the initial defragmentation of the network resources has been performed then the new bulk request for services can be performed. Thanks Quintin! * To: "'Daniel King'" >, "'Quintin Zhao'" > * Subject: Re: [Pce] A new draft on an architecture for application-based network operations * From: "Adrian Farrel" > * Date: Fri, 7 Dec 2012 15:13:08 -0000 * Cc: pce at ietf.org * Delivered-to: pce at ietfa.amsl.com * In-reply-to: <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk > * List-archive: * List-help: * List-id: Path Computation Element * List-post: * List-subscribe: , * List-unsubscribe: , * References: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN at mx.google.com > <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk > * Reply-to: adrian at olddog.co.uk * Thread-index: AQFrZjbRxLc5+InYH8ThqvcxIMjyVAEBEe1kmMpCNpA= _____ Hi Quintin, Following up with some more detail on top of Dan's email. >> The draft is very good and is helpful coordinate PCE and TE technologies >> between applications and network. I focused on some sections and have >> following questions and suggestions. Thanks for reading and commenting. Answers in line. >> (1) Applicability of ABNO Architecture. >> Your document abstract and introduction discusses scenarios including >> content and data-center interconnection ("Services such as content >> distribution, distributed databases, or inter-data center connectivity >> place a set of new requirements on the operation of networks."). I >> think the architecture is also relevant to lots of other environments: >> mobile backhaul, core transport, packet switch network, etc. Do you >> agree? > > DK>> Yes, that?s true. We did focus on the data center applicability as > we presented some slides at MPLS Washington 2012 which discussed > that specific scenario and the draft followed some of the same language. I agree. We were trying to describe some service environments rather than network environments, and we certainly don't want to imply any limitations on the uses or the network environments. We expect that the architecture could be used in a whole range of applications: both at the static end of the spectrum (such as mobile backhaul), and for more dynamic services. We will highlight this point in the next revision. >> (2) ABNO Controller. >> Section 2.2.13 (ABNO controller) needs to be discussed in more detail. >> Do you think multiple ABNO controllers or just one ABNO controller >> will be required? Maybe an implementation will use a ABNO Controller >> per "application" (Service Coordinator/NMS/OSS)? > > DK>> When we were white boarding and discussing the architecture we > certainly considered that a number of the ABNO components would require > multiple instances per deployment, including the ABNO Controller. As per > your next point we will try to be more specific in the ABNO text. > >> (3) PCE or PCE's? >> Figure 1 shows *a* PCE. It is expected that multiple PCE' would be used, >> this is important for VNTM Use Case. Maybe you can show more PCE's >> in the figure 1 or describe it? > > DK>> As Above, yes. As Dan says, there can certainly be multiple instances of the functional components in the figure. This could arise within an implementation to load-share, provide specialist capabilities (as you suggest for the ABNO Controller), to maintain confidentiality or separation of function (as you suggest for PCE), or to distribute the function across platforms. We are keen to stress that this is a functional architecture, not an implementation road-map. I think we will add a section on "Implementation of the Architecture" to discuss these points. >> (4) Network Resiliency. >> I am interested in ABNO managing network failures that may be >> protected with shared mesh protection at the network which could >> be MPLS TP or WDM. ABNO would provide a shared path protection >> which optimizes as network conditions change. This is based on >> client layer requirements of reliability and protection restoration >> time. To make this possible the shared mesh protection paths would >> need to be client layer traffic aware and have customer SLA >> information. Do you think this is a good use case? > > DK>> Cool. I think this could represent quite a complex multi-layer > optimization problem. Please let Adrian and me have more > information on the scenario. Ideally documenting the various > component functions (specific for the use case) and each > component interaction, again with some detail on what information > needs provided and perhaps propose protocol mechanism or > extensions. Think of the draft as a tool kit. We would like to reuse > existing technology as much as possible. The use case should reflect > this. Yes, this sounds like an interesting use case. Shared mesh protection (and also 1:n protection) can be a complex provisioning problem, and changes in services as well as changes in network availability can require significant dynamic reassessment of the placement of LSPs. If you would like to suggest text for a use case, I think we would be happy to see it. >> (5) Custom (Abstracted) Topologies. >> Could ABNO provide abstracted topologies via the north-bound >> interface to the requester (provisioning tool)? In China we have >> the customers who would like IPv6 deployment in IPv4 backbone. >> If provider can assign specific nodes and links to be used for >> logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS) >> architecture could be used to provide abstracted topology based >> on the preferred equipment for carrying tunneled IPv6 traffic. Is >> this another use case that may be useful? > > DK>>Maybe we can focus on the SMP use case first. This use case > might benefit from some of the discussion Young raised yesterday, > in terms of the virtual topology presentation. Actually, I think the model already supports exporting information from the TED as described in Section 2.2.2.4. This section does not clearly explain that the TED could be "abstracted", but it should! We will add some text. >> (6) Manageability and Security. >> Are you going to provide Manageability and Security sections in >> future versions of the ABNO document or another document? >> It is an important area for ABNO that needs further discussion. > > DK>> We will most definitely include some discussion in the ABNO > framework, along with policy. Agreed. (Unless someone else writes the text first :-) Thanks, Adrian ------=_NextPart_000_0134_01CDF4D2.36A5FDD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Quintin,

 

Thanks for this text. Looks good. Dan and I will = work to fold it into the document.

 

It is = quite a substantial piece of text. Do you mind if we name you as a = Contributing Author?

 

Wrt a = scenario for GCO and VNT, that also sounds interesting. Slightly worried = that it may get a bit complicated, but if you are capable of documenting = it, I think it would be a fine addition to the = document.

 

Thanks,

Adrian

 

From: Quintin Zhao = [mailto:quintin.zhao@huawei.com]
Sent: 16 January 2013 = 23:06
To: adrian@olddog.co.uk; 'Daniel King'
Cc: = pce@ietf.org
Subject: Re: [Pce] A new draft on an architecture = for application-based network = operations

 

Dear Dan = and Adrian,

 <= /o:p>

As we = discussed I focused on providing text for GCO. The text and diagrams may = not be formatted correctly so I also attach text file. If it would be = good, I will create some more text for a GCO and VNT scenario. =

 <= /o:p>

3.5 Global = Concurrent Optimization

 <= /o:p>

Global = Concurrent Optimization (GCO) is defined in [RFC5557] and represents a = key technology for maximizing network efficiency by computing a set of = traffic engineered paths concurrently. A GCO path computation request = will simultaneously consider the entire topology of the network, and = existing LSPs, when computing new services (TE LSPs) or an existing set = of services.

 <= /o:p>

 <= /o:p>

A GCO may = be requested in a number of scenarios, these = include:

 <= /o:p>

o Routing = of new services where the PCE should consider existing    =

  = services or network topology. 

 <= /o:p>

o A = reoptimization of existing services due to fragmented = network

  = resources or sub-optimized placement of sequential computed services. =

 <= /o:p>

o Recovery = of connectivity for bulk services in the event of = a

  = large network failure.

 <= /o:p>

[RFC5557] = states that a GCO is primarily an NMS or a PCE-Server-based solution, = due to nature of GCO path computation requests and the need for network = and service synchronization. Therefore the ABNO architecture represents = a suitable framework for implementing GCO capable path =

computation = functionality.  

 <= /o:p>

It may be = possible that a service provider would want to compute and deploy new = services based on predicted traffic matrix. The GCO functionality and = capability to perform concurrent computation, provides a significant = network optimization advantage to avoid blocking and utilize network = resources optimally.

 <= /o:p>

The = following use case shows how the ABNO architecture and components are = used to deploy GCO-enabled services. Furthermore, this use case also = includes a capability to consider multi-layer network (MLN) concurrency, = in order to optimize network efficiency or meet client network = connectivity or bandwidth requirements.

 <= /o:p>

3.5.1 GCO = with MLN Use Case

 <= /o:p>

The = following IP over optical network represents a typical Client and = Server

network:

 <= /o:p>

 <= /o:p>

  =        +-----+

  =        | NMS |

  =        |     = |

  =        +--+--+

  =     =       |

  =        = +--+---------------------------------------+

  =        = |            =       = ABNO           &nb= sp;        |

  =        = |            =             &= nbsp;           &n= bsp;     |

  =        = +---------------------------------------+-++

  =             &= nbsp;           &n= bsp;     =             &= nbsp;    | |

  =             &= nbsp;           &n= bsp;           &nb= sp;          | = |

  =        = +---------------------------------------+--+

  =       = /        IP/MPLS (Client) Network = Layer      \

  =      = +----------------------------------------------+

  =             &= nbsp;  =             &= nbsp;           &n= bsp;         |

  =     = +--------------------------------------------+---+

<= p class=3DMsoPlainText>  =    = /           Optical = (Server) Network Layer         = \

  =   = +----------------------------------------------------+<= /p>

 <= /o:p>

  =             &= nbsp;  Figure x: Network Architecture

 <= /o:p>

The above = network uses an IP/MPLS network layer which is Packet Switching Capable = (PSC). The optical layer is Lambda Switching Capable (LSC). The IP = packets are aggregated into lambda optical channels using TE LSP = tunnels.

The lambda = optical channels using within the optical network layer may be fixed or = convertible.

 <= /o:p>

When = considering the GCO path computation problem, we can split the = requirements into two categories of concurrency optimization objectives, = these are:

 <= /o:p>

o Minimize = aggregate Bandwidth Consumption (MBC).

 <= /o:p>

o Minimize = the load of the Most Loaded Link (MLL).

 <= /o:p>

o Minimize = Cumulative Cost of a set of paths (MCC).

 <= /o:p>

The use = case assumes the GCO request will be offline and be initiated from an = NMS, that is it will take significant time to compute the service and = the paths reported as part of the request response may want to be = verified by the user before being provisioned within the relevant = network layer.

 <= /o:p>

1. Request = Management

 <= /o:p>

The NMS = issues a request for new service connectivity for bulk services. =

The ABNO = Controller verifies that the Application Service Coordinator has = sufficient rights to make the service request and apply a GCO = attribute.

 <= /o:p>

Each = service request has a source and destination location, bandwidth request = and a fixed starting time and duration. The bandwidth request could vary = from a few Mbps to the maximum capacity of a lambda optical = channel.

Various = algorithms and computation techniques may be applied to compute the = services on a specific set of network planning constraints, =

but are not = described in this procedure.  

 <= /o:p>

2. Service = Path Computation in the Packet Layer

 <= /o:p>

The ABNO = Controller sends a GCO-enabled path computation request to the packet = layer PCE to compute a suitable path for the requested services. =

Upon = receipt of the service requests the packet PCE then computes the = requested paths concurrently applying relevant concurrent capable = algorithms.

 <= /o:p>

The PCE = uses the appropriate policy for the request and consults the TED for the = packet network layer. If required, the PCE may compute two bulk service = requests based on the requested objective (MBC, MLL or MCC). To compute = a set of services for the GCO application, PCEP supports synchronization = VECtor (SVEC) lists for synchronized dependent path computations = requests as defined in [RFC5440] and described in [RFC6007]. =

 <= /o:p>

Once the = requested GCO service path computation completes, the PCE sends the = resulting paths back to the ABNO Controller. The response includes a = fully computed explicit path for each service (TE LSP) that needs to be = established. The ABNO Controller will forward the candidate paths back = to the NMS for user approval before being provisioned within the = relevant network layer.

 <= /o:p>

3. = Coordination of MLN resources using VNTM and Path Computation in the = Optical Layer

 <= /o:p>

The ABNO = architecture supports both immediate connectivity requirements and = advanced scheduling (reservation) of resources. Given a service request = that exceeds the current capability of the current packet layer the PCE = may invoke the VNTM for the creation of necessary links in the virtual = network topology to meet the requirements of immediate or scheduled = resources. This interaction is documented in Figure 11 ( Invocation of = VNTM and Optical Layer Path Computation).

 <= /o:p>

Triggers = for VNT reconfiguration, such as traffic demand changes, network = failures, and topological configuration changes may require a set of = existing TE LSPs to be re-computed, or new virtual TE links to be added = to the VNT.

 <= /o:p>

4. = Provisioning in the Optical Layer

 <= /o:p>

These may = be immediate or scheduled optical resources (lambdas) dependent on if = the initial service requests are immediate or scheduled. =

 <= /o:p>

5. = Reoptimization of Existing Services (Defragmentation of = Network)

 <= /o:p>

If it is = not possible to provision new resources to meet the bulk service request = then it may be possible via traffic grooming of existing LSPs (either = packet or optical) to optimize the capacity utilization of the network = layer.

 <= /o:p>

  = 1. The packet or optical PCE will compute the new service =

  =  request and provide a response to the ABNO Controller with the = order

  =  in which existing TE LSPs should be reoptimized so as to minimize =

  =  traffic disruption.

 <= /o:p>

  = 2. The PCE will compute the make-before-break replacement service. =

  =  The PCE will also need to indicate for each request the order in = which

  =  the old TE LSP should be removed and the order in which the new TE = LSP

  =  should be setup. 

  =  

  =  If the removal order is lower than the setup order, then the =

  =  make-before-break may not be performed for the = request.

 <= /o:p>

  = 3. Once the initial defragmentation of the network resources has been =

  =  performed then the new bulk request for services can be = performed.

 <= /o:p>

Thanks = Quintin! 

 <= /o:p>

 <= /o:p>

 <= /o:p>

Hi =
Quintin,
 <=
/o:p>
Following =
up with some more detail on top of Dan's =
email.
 <=
/o:p>
>> =
The draft is very good and is helpful coordinate PCE and TE =
technologies
>> =
between applications and network. I focused on some sections and =
have
>> =
following questions and suggestions. 
 <=
/o:p>
Thanks for =
reading and commenting.
Answers in =
line.
 <=
/o:p>
>> =
(1) Applicability of ABNO Architecture. =

>> =
Your document abstract and introduction discusses scenarios =
including
>> =
content and data-center interconnection ("Services such as =
content
>> =
distribution, distributed databases, or inter-data center =
connectivity
>> =
place a set of new requirements on the operation of networks."). =
I
>> =
think the architecture is also relevant to lots of other =
environments:
>> =
mobile backhaul, core transport, packet switch network, etc. Do =
you
>> =
agree? 
>&nb=
sp;
> =
DK>> Yes, that?s true. We did focus on the data center =
applicability as
> we =
presented some slides at MPLS Washington 2012 which =
discussed
> that =
specific scenario and the draft followed some of the same =
language.
 <=
/o:p>
I agree. We =
were trying to describe some service environments rather =
than
network =
environments, and we certainly don't want to imply any limitations =
on
the uses or =
the network environments. We expect that the architecture could =
be
used in a =
whole range of applications: both at the static end of the =
spectrum
(such as =
mobile backhaul), and for more dynamic =
services.
 <=
/o:p>
We will =
highlight this point in the next =
revision.
 <=
/o:p>
>> =
(2) ABNO Controller.
>> =
Section 2.2.13 (ABNO controller) needs to be discussed in more =
detail.
>> Do =
you think multiple ABNO controllers or just one ABNO =
controller
>> =
will be required? Maybe an implementation will use a ABNO =
Controller
>> =
per "application" (Service Coordinator/NMS/OSS)? =

>&nb=
sp;
> =
DK>> When we were white boarding and discussing the architecture =
we
> =
certainly considered that a number of the ABNO components would =
require
> =
multiple instances per deployment, including the ABNO Controller. As =
per
> your =
next point we will try to be more specific in the ABNO text. =

>&nb=
sp;
>> =
(3) PCE or PCE's?
>> =
Figure 1 shows *a* PCE. It is expected that multiple PCE' would be =
used,
>> =
this is important for VNTM Use Case. Maybe you can show more =
PCE's
>> in =
the figure 1 or describe it?
>&nb=
sp;
> =
DK>> As Above, yes.
 <=
/o:p>
As Dan =
says, there can certainly be multiple instances of the =
functional
components =
in the figure. This could arise within an implementation =
to
load-share, =
provide specialist capabilities (as you suggest for the =
ABNO
Controller),=
 to maintain confidentiality or separation of function (as =
you
suggest for =
PCE), or to distribute the function across platforms. We are keen =
to
stress that =
this is a functional architecture, not an implementation road-map. =
I
think we =
will add a section on "Implementation of the Architecture" to =
discuss
these =
points.
 <=
/o:p>
>> =
(4) Network Resiliency.
>> I =
am interested in ABNO managing network failures that may be =

>> =
protected with shared mesh protection at the network which =
could
>> be =
MPLS TP or WDM. ABNO would provide a shared path =
protection
>> =
which optimizes as network conditions change. This is based =
on
>> =
client layer requirements of reliability and protection =
restoration
>> =
time. To make this possible the shared mesh protection paths =
would
>> =
need to be client layer traffic aware and have customer =
SLA
>> =
information. Do you think this is a good use =
case?
>&nb=
sp;
> =
DK>> Cool. I think this could represent quite a complex =
multi-layer
> =
optimization problem. Please let Adrian and me have =
more
> =
information on the scenario. Ideally documenting the =
various
> =
component functions (specific for the use case) and =
each
> =
component interaction, again with some detail on what =
information
> needs =
provided and perhaps propose protocol mechanism =
or
> =
extensions. Think of the draft as a tool kit. We would like to =
reuse
> =
existing technology as much as possible. The use case should =
reflect
> this. =

 <=
/o:p>
Yes, this =
sounds like an interesting use case. Shared mesh protection (and =
also
1:n =
protection) can be a complex provisioning problem, and changes in =
services
as well as =
changes in network availability can require significant =
dynamic
reassessment=
 of the placement of LSPs. If you would like to suggest text for =
a
use case, I =
think we would be happy to see it.
 <=
/o:p>
>> =
(5) Custom (Abstracted) Topologies.       =

>> =
Could ABNO provide abstracted topologies via the =
north-bound
>> =
interface to the requester (provisioning tool)? In China we =
have
>> =
the customers who would like IPv6 deployment in IPv4 =
backbone.
>> If =
provider can assign specific nodes and links to be used =
for
>> =
logically isolated IPv6 plane, then the ABNO (I2RS and =
BGP-LS)
>> =
architecture could be used to provide abstracted topology =
based
>> on =
the preferred equipment for carrying tunneled IPv6 traffic. =
Is
>> =
this another use case that may be =
useful?
>&nb=
sp;
> =
DK>>Maybe we can focus on the SMP use case first. This use =
case
> might =
benefit from some of the discussion Young raised =
yesterday,
> in =
terms of the virtual topology presentation. =
 
 <=
/o:p>
Actually, I =
think the model already supports exporting information from the =
TED
as =
described in Section 2.2.2.4. This section does not clearly explain that =
the
TED could =
be "abstracted", but it should! We will add some =
text.
 <=
/o:p>
>> =
(6) Manageability and Security.  
>> =
Are you going to provide Manageability and Security sections =
in
>> =
future versions of the ABNO document or another document? =

>> It =
is an important area for ABNO that needs further discussion. =

>&nb=
sp;
> =
DK>> We will most definitely include some discussion in the ABNO =

> =
framework, along with policy. 
 <=
/o:p>
Agreed. =
(Unless someone else writes the text first =
:-)
 <=
/o:p>
Thanks,=

Adrian<=
/o:p>
 <=
/o:p>

 <= /o:p>

------=_NextPart_000_0134_01CDF4D2.36A5FDD0-- From adrian@olddog.co.uk Thu Jan 17 08:47:12 2013 Return-Path: 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 9623A21F87B6 for ; Thu, 17 Jan 2013 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+ftuKhsu5+b for ; Thu, 17 Jan 2013 08:47:12 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1401F21F87B3 for ; Thu, 17 Jan 2013 08:47:10 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0HGl9rr024923 for ; Thu, 17 Jan 2013 16:47:09 GMT Received: from 950129200 (089144192047.atnat0001.highway.a1.net [89.144.192.47]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0HGkUM4024017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Jan 2013 16:47:07 GMT From: "Adrian Farrel" To: Date: Thu, 17 Jan 2013 16:46:29 -0000 Message-ID: <014701cdf4d2$4a259960$de70cc20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac30ztoEFPljqJoYTkS2j666yfwqYA== Content-Language: en-gb Subject: [Pce] Ramblings of two old dogs X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:47:12 -0000 Hi, Over the years Dan and I have been asked a number of questions about PCE and how it fits into different uses in the network. Although we feel that the ABNO document (draft-farrkingel-pce-abno-architecture) goes a long way to explain the bigger picture, there are a lot of smaller, everyday questions that need attention. In an attempt to reduce the email we see, we have collected these into an Informational I-D as below. Obviously, if you all send us comments and thoughts on this document you will successfully thwart our plans :-) Adrian and Dan > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 17 January 2013 15:30 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrkingel-pce-questions-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Unanswered Questions in the Path Computation Element > Architecture > Author(s) : Adrian Farrel > Daniel King > Filename : draft-farrkingel-pce-questions-00.txt > Pages : 22 > Date : 2013-01-17 > > Abstract: > The Path Computation Element (PCE) architecture is set out in RFC > 4655. The architecture is extended for multi-layer networking with > the introduction of the Virtual Network Topology Manager in RFC > 5623, and generalized to Hierarchical PCE in RFC 6805. > > These three architectural views of PCE deliberately leave some key > questions unanswered especially with respect to the interactions > between architectural components. This document draws out those > questions and discusses them in an architectural context with > reference to other architectural components, existing protocols, and > recent IETF work efforts. > > This document does not update the architecture documents and does not > define how protocols or components must be used. It does, however, > suggest how the architectural components might be combined to provide > advanced PCE function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrkingel-pce-questions > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrkingel-pce-questions-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From quintin.zhao@huawei.com Thu Jan 17 18:43:06 2013 Return-Path: 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 5781121F8503 for ; Thu, 17 Jan 2013 18:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNSTBC-CsxSi for ; Thu, 17 Jan 2013 18:43:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF6121F84E4 for ; Thu, 17 Jan 2013 18:42:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANQ43188; Fri, 18 Jan 2013 02:42:53 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 02:42:36 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 02:42:52 +0000 Received: from QZHAO (10.212.246.110) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.3; Thu, 17 Jan 2013 18:42:47 -0800 From: Quintin Zhao To: References: In-Reply-To: Date: Thu, 17 Jan 2013 21:42:43 -0500 Message-ID: <002a01cdf525$8007ead0$8017c070$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac300k8KBDHiK7zzRLWYpHwtFZW4VQAUk6eA Content-Language: zh-cn X-Originating-IP: [10.212.246.110] X-CFilter-Loop: Reflected Cc: pce@ietf.org Subject: Re: [Pce] Pce Digest, Vol 100, Issue 5 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 02:43:06 -0000 Adrian, Thanks and I will be glad to join you and Dan to work on this. Quintin ---------------------------------------------------------------------------- ------------------------ Message: 1 Date: Thu, 17 Jan 2013 16:46:29 -0000 From: "Adrian Farrel" To: "'Quintin Zhao'" Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations Message-ID: <013301cdf4d2$3692eb00$a3b8c100$@olddog.co.uk> Content-Type: text/plain; charset="us-ascii" Hi Quintin, Thanks for this text. Looks good. Dan and I will work to fold it into the document. It is quite a substantial piece of text. Do you mind if we name you as a Contributing Author? Wrt a scenario for GCO and VNT, that also sounds interesting. Slightly worried that it may get a bit complicated, but if you are capable of documenting it, I think it would be a fine addition to the document. Thanks, Adrian From: Quintin Zhao [mailto:quintin.zhao@huawei.com] Sent: 16 January 2013 23:06 To: adrian@olddog.co.uk; 'Daniel King' Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations Dear Dan and Adrian, As we discussed I focused on providing text for GCO. The text and diagrams may not be formatted correctly so I also attach text file. If it would be good, I will create some more text for a GCO and VNT scenario. 3.5 Global Concurrent Optimization Global Concurrent Optimization (GCO) is defined in [RFC5557] and represents a key technology for maximizing network efficiency by computing a set of traffic engineered paths concurrently. A GCO path computation request will simultaneously consider the entire topology of the network, and existing LSPs, when computing new services (TE LSPs) or an existing set of services. A GCO may be requested in a number of scenarios, these include: o Routing of new services where the PCE should consider existing services or network topology. o A reoptimization of existing services due to fragmented network resources or sub-optimized placement of sequential computed services. o Recovery of connectivity for bulk services in the event of a large network failure. [RFC5557] states that a GCO is primarily an NMS or a PCE-Server-based solution, due to nature of GCO path computation requests and the need for network and service synchronization. Therefore the ABNO architecture represents a suitable framework for implementing GCO capable path computation functionality. It may be possible that a service provider would want to compute and deploy new services based on predicted traffic matrix. The GCO functionality and capability to perform concurrent computation, provides a significant network optimization advantage to avoid blocking and utilize network resources optimally. The following use case shows how the ABNO architecture and components are used to deploy GCO-enabled services. Furthermore, this use case also includes a capability to consider multi-layer network (MLN) concurrency, in order to optimize network efficiency or meet client network connectivity or bandwidth requirements. 3.5.1 GCO with MLN Use Case The following IP over optical network represents a typical Client and Server network: +-----+ | NMS | | | +--+--+ | +--+---------------------------------------+ | ABNO | | | +---------------------------------------+-++ | | | | +---------------------------------------+--+ / IP/MPLS (Client) Network Layer \ +----------------------------------------------+ | +--------------------------------------------+---+ / Optical (Server) Network Layer \ +----------------------------------------------------+ Figure x: Network Architecture The above network uses an IP/MPLS network layer which is Packet Switching Capable (PSC). The optical layer is Lambda Switching Capable (LSC). The IP packets are aggregated into lambda optical channels using TE LSP tunnels. The lambda optical channels using within the optical network layer may be fixed or convertible. When considering the GCO path computation problem, we can split the requirements into two categories of concurrency optimization objectives, these are: o Minimize aggregate Bandwidth Consumption (MBC). o Minimize the load of the Most Loaded Link (MLL). o Minimize Cumulative Cost of a set of paths (MCC). The use case assumes the GCO request will be offline and be initiated from an NMS, that is it will take significant time to compute the service and the paths reported as part of the request response may want to be verified by the user before being provisioned within the relevant network layer. 1. Request Management The NMS issues a request for new service connectivity for bulk services. The ABNO Controller verifies that the Application Service Coordinator has sufficient rights to make the service request and apply a GCO attribute. Each service request has a source and destination location, bandwidth request and a fixed starting time and duration. The bandwidth request could vary from a few Mbps to the maximum capacity of a lambda optical channel. Various algorithms and computation techniques may be applied to compute the services on a specific set of network planning constraints, but are not described in this procedure. 2. Service Path Computation in the Packet Layer The ABNO Controller sends a GCO-enabled path computation request to the packet layer PCE to compute a suitable path for the requested services. Upon receipt of the service requests the packet PCE then computes the requested paths concurrently applying relevant concurrent capable algorithms. The PCE uses the appropriate policy for the request and consults the TED for the packet network layer. If required, the PCE may compute two bulk service requests based on the requested objective (MBC, MLL or MCC). To compute a set of services for the GCO application, PCEP supports synchronization VECtor (SVEC) lists for synchronized dependent path computations requests as defined in [RFC5440] and described in [RFC6007]. Once the requested GCO service path computation completes, the PCE sends the resulting paths back to the ABNO Controller. The response includes a fully computed explicit path for each service (TE LSP) that needs to be established. The ABNO Controller will forward the candidate paths back to the NMS for user approval before being provisioned within the relevant network layer. 3. Coordination of MLN resources using VNTM and Path Computation in the Optical Layer The ABNO architecture supports both immediate connectivity requirements and advanced scheduling (reservation) of resources. Given a service request that exceeds the current capability of the current packet layer the PCE may invoke the VNTM for the creation of necessary links in the virtual network topology to meet the requirements of immediate or scheduled resources. This interaction is documented in Figure 11 ( Invocation of VNTM and Optical Layer Path Computation). Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes may require a set of existing TE LSPs to be re-computed, or new virtual TE links to be added to the VNT. 4. Provisioning in the Optical Layer These may be immediate or scheduled optical resources (lambdas) dependent on if the initial service requests are immediate or scheduled. 5. Reoptimization of Existing Services (Defragmentation of Network) If it is not possible to provision new resources to meet the bulk service request then it may be possible via traffic grooming of existing LSPs (either packet or optical) to optimize the capacity utilization of the network layer. 1. The packet or optical PCE will compute the new service request and provide a response to the ABNO Controller with the order in which existing TE LSPs should be reoptimized so as to minimize traffic disruption. 2. The PCE will compute the make-before-break replacement service. The PCE will also need to indicate for each request the order in which the old TE LSP should be removed and the order in which the new TE LSP should be setup. If the removal order is lower than the setup order, then the make-before-break may not be performed for the request. 3. Once the initial defragmentation of the network resources has been performed then the new bulk request for services can be performed. Thanks Quintin! * To: "'Daniel King'" >, "'Quintin Zhao'" > * Subject: Re: [Pce] A new draft on an architecture for application-based network operations * From: "Adrian Farrel" > * Date: Fri, 7 Dec 2012 15:13:08 -0000 * Cc: pce at ietf.org * Delivered-to: pce at ietfa.amsl.com * In-reply-to: <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk > * List-archive: * List-help: * List-id: Path Computation Element * List-post: * List-subscribe: , * List-unsubscribe: , * References: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN at mx.google.com > <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk > * Reply-to: adrian at olddog.co.uk * Thread-index: AQFrZjbRxLc5+InYH8ThqvcxIMjyVAEBEe1kmMpCNpA= _____ Hi Quintin, Following up with some more detail on top of Dan's email. >> The draft is very good and is helpful coordinate PCE and TE technologies >> between applications and network. I focused on some sections and have >> following questions and suggestions. Thanks for reading and commenting. Answers in line. >> (1) Applicability of ABNO Architecture. >> Your document abstract and introduction discusses scenarios including >> content and data-center interconnection ("Services such as content >> distribution, distributed databases, or inter-data center connectivity >> place a set of new requirements on the operation of networks."). I >> think the architecture is also relevant to lots of other environments: >> mobile backhaul, core transport, packet switch network, etc. Do you >> agree? > > DK>> Yes, that?s true. We did focus on the data center applicability as > we presented some slides at MPLS Washington 2012 which discussed > that specific scenario and the draft followed some of the same language. I agree. We were trying to describe some service environments rather than network environments, and we certainly don't want to imply any limitations on the uses or the network environments. We expect that the architecture could be used in a whole range of applications: both at the static end of the spectrum (such as mobile backhaul), and for more dynamic services. We will highlight this point in the next revision. >> (2) ABNO Controller. >> Section 2.2.13 (ABNO controller) needs to be discussed in more detail. >> Do you think multiple ABNO controllers or just one ABNO controller >> will be required? Maybe an implementation will use a ABNO Controller >> per "application" (Service Coordinator/NMS/OSS)? > > DK>> When we were white boarding and discussing the architecture we > certainly considered that a number of the ABNO components would require > multiple instances per deployment, including the ABNO Controller. As per > your next point we will try to be more specific in the ABNO text. > >> (3) PCE or PCE's? >> Figure 1 shows *a* PCE. It is expected that multiple PCE' would be used, >> this is important for VNTM Use Case. Maybe you can show more PCE's >> in the figure 1 or describe it? > > DK>> As Above, yes. As Dan says, there can certainly be multiple instances of the functional components in the figure. This could arise within an implementation to load-share, provide specialist capabilities (as you suggest for the ABNO Controller), to maintain confidentiality or separation of function (as you suggest for PCE), or to distribute the function across platforms. We are keen to stress that this is a functional architecture, not an implementation road-map. I think we will add a section on "Implementation of the Architecture" to discuss these points. >> (4) Network Resiliency. >> I am interested in ABNO managing network failures that may be >> protected with shared mesh protection at the network which could >> be MPLS TP or WDM. ABNO would provide a shared path protection >> which optimizes as network conditions change. This is based on >> client layer requirements of reliability and protection restoration >> time. To make this possible the shared mesh protection paths would >> need to be client layer traffic aware and have customer SLA >> information. Do you think this is a good use case? > > DK>> Cool. I think this could represent quite a complex multi-layer > optimization problem. Please let Adrian and me have more > information on the scenario. Ideally documenting the various > component functions (specific for the use case) and each > component interaction, again with some detail on what information > needs provided and perhaps propose protocol mechanism or > extensions. Think of the draft as a tool kit. We would like to reuse > existing technology as much as possible. The use case should reflect > this. Yes, this sounds like an interesting use case. Shared mesh protection (and also 1:n protection) can be a complex provisioning problem, and changes in services as well as changes in network availability can require significant dynamic reassessment of the placement of LSPs. If you would like to suggest text for a use case, I think we would be happy to see it. >> (5) Custom (Abstracted) Topologies. >> Could ABNO provide abstracted topologies via the north-bound >> interface to the requester (provisioning tool)? In China we have >> the customers who would like IPv6 deployment in IPv4 backbone. >> If provider can assign specific nodes and links to be used for >> logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS) >> architecture could be used to provide abstracted topology based >> on the preferred equipment for carrying tunneled IPv6 traffic. Is >> this another use case that may be useful? > > DK>>Maybe we can focus on the SMP use case first. This use case > might benefit from some of the discussion Young raised yesterday, > in terms of the virtual topology presentation. Actually, I think the model already supports exporting information from the TED as described in Section 2.2.2.4. This section does not clearly explain that the TED could be "abstracted", but it should! We will add some text. >> (6) Manageability and Security. >> Are you going to provide Manageability and Security sections in >> future versions of the ABNO document or another document? >> It is an important area for ABNO that needs further discussion. > > DK>> We will most definitely include some discussion in the ABNO > framework, along with policy. Agreed. (Unless someone else writes the text first :-) Thanks, Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 100, Issue 5 *********************************** From zhangfatai@huawei.com Thu Jan 17 23:40:47 2013 Return-Path: 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 C8BB921F8AB7 for ; Thu, 17 Jan 2013 23:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyf4Jl1qxSij for ; Thu, 17 Jan 2013 23:40:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5821F89CB for ; Thu, 17 Jan 2013 23:40:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOW80504; Fri, 18 Jan 2013 07:40:45 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 07:40:29 +0000 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 07:40:45 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 18 Jan 2013 15:40:39 +0800 From: Fatai Zhang To: "adrian@olddog.co.uk" , "pce@ietf.org" Thread-Topic: [Pce] Ramblings of two old dogs Thread-Index: Ac30ztoEFPljqJoYTkS2j666yfwqYAAd5MZg Date: Fri, 18 Jan 2013 07:40:37 +0000 Message-ID: References: <014701cdf4d2$4a259960$de70cc20$@olddog.co.uk> In-Reply-To: <014701cdf4d2$4a259960$de70cc20$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Ramblings of two old dogs X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 07:40:47 -0000 Hi Adrian, Very interesting and useful draft. A few small comments from me for discussion. (1) What Is Topology Information? Should SRLG/SRG information be mentioned? (2) Does H-PCE Solve The Internet? It is obviously that the answer is "NO". However, another question could be= addressed: how many domains and how many levels (hierachical levels) can b= e handled by H-PCE? (3) What Is A Stateful PCE For? It says: "A Stateful PCE maintains a database of LSPs that are active in th= e network (the LSP-DB). This database allows a PCC to refer to an LSP usin= g only its identifier - all other details can be retrieved by the PCE from = the LSP-DB.". What do you mean for *active LSPs* here? Could a protecting LSP be regarded= as *active* when it is not in the Operational state? Scheduling LSPs (in q= uestion 22) are active or not? (4) Is An Active PCE with LSP Delegation Just a Fancy NMS? I agree that in many ways the answer here is "yes", especially from the fun= ction perspective. When NMS is doing this "delegation" as it has been done = in the real deployment, there is no need to do the "delegation" in a per-LS= P way. So my question is: when an active PCE is used to do the delegation f= unction, is it necessary in a per-LSP way? Or it could be done in the *NMS*= way? (5) Where Does Policy Fit In? I think if [RFC5394] is used to set up the policies as much as possible, it= can reduce many PCEP extensions to make PCE just focus on *computation*.=20 Best Regards Fatai -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adria= n Farrel Sent: Friday, January 18, 2013 12:46 AM To: pce@ietf.org Subject: [Pce] Ramblings of two old dogs Hi, Over the years Dan and I have been asked a number of questions about PCE an= d how it fits into different uses in the network. Although we feel that the ABNO document (draft-farrkingel-pce-abno-architec= ture) goes a long way to explain the bigger picture, there are a lot of smaller, everyday questions that need attention. In an attempt to reduce the email we see, we have collected these into an Informational I-D as below. Obviously, if you all send us comments and thou= ghts on this document you will successfully thwart our plans :-) Adrian and Dan > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of internet-drafts@ietf.org > Sent: 17 January 2013 15:30 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrkingel-pce-questions-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : Unanswered Questions in the Path Computation Element > Architecture > Author(s) : Adrian Farrel > Daniel King > Filename : draft-farrkingel-pce-questions-00.txt > Pages : 22 > Date : 2013-01-17 >=20 > Abstract: > The Path Computation Element (PCE) architecture is set out in RFC > 4655. The architecture is extended for multi-layer networking with > the introduction of the Virtual Network Topology Manager in RFC > 5623, and generalized to Hierarchical PCE in RFC 6805. >=20 > These three architectural views of PCE deliberately leave some key > questions unanswered especially with respect to the interactions > between architectural components. This document draws out those > questions and discusses them in an architectural context with > reference to other architectural components, existing protocols, and > recent IETF work efforts. >=20 > This document does not update the architecture documents and does not > define how protocols or components must be used. It does, however, > suggest how the architectural components might be combined to provide > advanced PCE function. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrkingel-pce-questions >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrkingel-pce-questions-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ogondio@tid.es Fri Jan 18 00:48:44 2013 Return-Path: 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 7494621F8881 for ; Fri, 18 Jan 2013 00:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.145 X-Spam-Level: X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOTgyZuK8gAW for ; Fri, 18 Jan 2013 00:48:43 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9197721F8877 for ; Fri, 18 Jan 2013 00:48:42 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MGT009GOCGNJR@tid.hi.inet> for pce@ietf.org; Fri, 18 Jan 2013 09:48:41 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id F5.C3.02896.86C09F05; Fri, 18 Jan 2013 09:48:41 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MGT009KECH4JR@tid.hi.inet> for pce@ietf.org; Fri, 18 Jan 2013 09:48:40 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([fe80::e1e3:e2fc:beda:deb9%15]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 09:45:29 +0100 Date: Fri, 18 Jan 2013 08:48:39 +0000 From: =?Windows-1252?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: <014701cdf4d2$4a259960$de70cc20$@olddog.co.uk> X-Originating-IP: [10.95.64.115] To: "adrian@olddog.co.uk" , "pce@ietf.org" Message-id: <7CFF94B047D8864CB6268315034E35DE1B21F1EB@EX10-MB2-MAD.hi.inet> Content-id: <6A6FF18DD90B7740B7796D002DC17038@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [Pce] Ramblings of two old dogs Thread-index: Ac30ztoEFPljqJoYTkS2j666yfwqYAAicD6A user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7f636d000000b50-91-50f90c6894d7 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCFe9nqJvJ8zPAYPF/Joum+zfYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXnRF6aCqxYV69rfMjcwLtLtYuTkkBAwkXi1bAIThC0mceHe erYuRi4OIYFtjBInPl8CSwgJfGOUeLPOASKxiVFi0ceJjCAJFgFViZWbb4DZbAJOEg0958Fs YQEdiYtrz7CB2JwC1hIbJnWwQWxQkPhz7jELiC0i4CfRsrKDFcTmFfCW2L98H1gvs4CZxOvD B9kg4oISPybfY4GI60l8/HMbqkZcYs6viawQtrbEk3cXwGxGAVmJledPM0LM15VYta8HyjaS mPXmIDuILQo0p+3YGXaIewQkluw5zwxhi0q8fPyPdQKj+CwkZ8xCcsYsJGfMQnLGLCRnLGBk XcUoVpxUlJmeUZKbmJmTbmCkl5Gpl5mXWrKJERJfmTsYl+9UOcQowMGoxMN74OznACHWxLLi ytxDjJIcTEqivLZcPwOE+JLyUyozEosz4otKc1KLDzFKcDArifC2HvwRIMSbklhZlVqUD5OS 4eBQkuD9CdImWJSanlqRlpkDTCIwaSYOTpB2HqB2BW6gGt7igsTc4sx0iPwpRlWOGRN7njMK seTl56VKifOGgRQJgBRllObBzXnFKA50sDCvOEiWB5gG4Sa8AhrOBDRc5OJ3kOEliQgpqQbG Y1cD+9z1nppm/ma7tui92mz1Nflrr/Isalj0Snr5eh+W92f1/mzbGnHIvyJF+f0bk0S780+e y8RqmtbOYDtkoLKR6+q9bTX9P1yYLmS3Sv9xtVVe4CDjt/BI6idDhdLk0rqEYPO4rz9vewte tZjNPSn3V7qLpvmdTqcvSiUhM/ViPsoxTVikxFKckWioxVxUnAgAqM7DeUADAAA= Subject: Re: [Pce] Ramblings of two old dogs X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 08:48:44 -0000 Dear Adrian, Lots of thanks for the nice document, explanations, open questions = and views. Please find bellow some comments: About what is Topology Information/TED: (point 2) "In short, the TED needs to contain as much information as is needed to satisfy the path computation requests subject to the objective functions." This can be tricky. In optical, if you want to be really precise, you should also know the impact of the rest of established connections (signals) in a new connection. Thus, it could be argued that TED is also LSP information (in some particular cases). Also, should the path computation constraint be "disjoint with this particular LSP", one could also argue that LSP information is TED=8A. So=8A be careful defining TED as all the information needed to perform a path computation. Regarding TED definition and maintenance (points 2 and 3), Olivier Dugeon started a nice work draft-dugeon-pce-ted-reqs-01 that would be interesting not to abandon. Point 5: In the STRONGEST project Ramon Casellas, Francesco Pauloci and myself developed the idea of "specialized PCEs" and "proxy PCE" that is able to redirect a request to the specialized PCE. That is, you could have a set of PCEs fed with the same TED, each focused on a specific task. Point 6: "a process of "sticky resources" that are temporarily reduced in the TED after a computation may be applied purely as a local implementation issue." It does not need only to be local. We tested succesfully a mechanism to push the "sticky resources" information to other PCEs. Point 7: Pushing the reachability information (end-point - domain correspondance) from the PCEs could be another reasonable choice in case you don't want to use BGP. Point 8: Not only the Child PCE needs to authenticate its identity. The parent PCE should also have a proof that he is what he claims to be and not a fraudulent PCE. This is specially interesting in inter-carrier/inter-domain environments where the decision can have monetary implications=8A.. Point 11: BGP-LS seems a very reasonable choice. In the STRONGEST project H-PCE prototype we used a mechanism based on forwarding the LSAs to the H-PCE in a proprietary way. I guess BGP-LS is the "standard" way of doing the same. Point 13: "When a PCE computes a path it has a reasonable idea that an LSP will be set up and that resources will be allocated within the network" Well=8A the PCE does not know if the computation is to set up an LSP, or just a query to know if there is room for that LSP, or is a test from the operator. Thus=8A. I must say PCE should not assume that. A simple choice can be allowing the PCC to tell "hey, my intention is to set up the LSP, so, count on it" or not. So "What happens if a path computation was made only to investigate the potential for an LSP, but not to actually set one up?" Can be solved by providing the info from the PCE. The problem of multiple PCEs can be solved forwarding the "sticky resources" "Some of these issues can be mitigated by using a Stateful PCE" Partly, yes, but the "sticky resources" policy would be also needed in the stateful PCE. If you rely on the information of already established LSPs you would run with the same issues with consecutive requests. In case of the active PCE.. I guess it will be intelligent enough=8A. Point 14: I think Active PCE is very different from stateful PCE. Stateful PCE should be just a PCE that has the TED and the LSP database. Active PCE extends the stateful PCE. With that for today is enough=8A continuing the read and review over the weekend. Thanks again for the nice document. Oscar El 17/01/13 17:46, "Adrian Farrel" escribi=F3: >Hi, > >Over the years Dan and I have been asked a number of questions about PCE >and how >it fits into different uses in the network. > >Although we feel that the ABNO document >(draft-farrkingel-pce-abno-architecture) >goes a long way to explain the bigger picture, there are a lot of smaller, >everyday questions that need attention. > >In an attempt to reduce the email we see, we have collected these into an >Informational I-D as below. Obviously, if you all send us comments and >thoughts >on this document you will successfully thwart our plans :-) > >Adrian and Dan > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of internet-drafts@ietf.org >> Sent: 17 January 2013 15:30 >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-farrkingel-pce-questions-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> >> >> Title : Unanswered Questions in the Path Computation Elem= ent >> Architecture >> Author(s) : Adrian Farrel >> Daniel King >> Filename : draft-farrkingel-pce-questions-00.txt >> Pages : 22 >> Date : 2013-01-17 >> >> Abstract: >> The Path Computation Element (PCE) architecture is set out in RFC >> 4655. The architecture is extended for multi-layer networking with >> the introduction of the Virtual Network Topology Manager in RFC >> 5623, and generalized to Hierarchical PCE in RFC 6805. >> >> These three architectural views of PCE deliberately leave some key >> questions unanswered especially with respect to the interactions >> between architectural components. This document draws out those >> questions and discusses them in an architectural context with >> reference to other architectural components, existing protocols, and >> recent IETF work efforts. >> >> This document does not update the architecture documents and does not >> define how protocols or components must be used. It does, however, >> suggest how the architectural components might be combined to provide >> advanced PCE function. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-farrkingel-pce-questions >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-farrkingel-pce-questions-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From daniel@olddog.co.uk Sat Jan 19 13:47:41 2013 Return-Path: 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 6F78421F85A0 for ; Sat, 19 Jan 2013 13:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBLiOaTWZrBX for ; Sat, 19 Jan 2013 13:47:40 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8EA21F858C for ; Sat, 19 Jan 2013 13:47:40 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0JLlcWQ013660; Sat, 19 Jan 2013 21:47:39 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0JLlbiC013651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 19 Jan 2013 21:47:38 GMT From: "Daniel King" To: Date: Sat, 19 Jan 2013 21:47:33 -0000 Message-ID: <002701cdf68e$973479c0$c59d6d40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac32jXEO34jZNeUaQTmi4+WJNLVqCQ== Content-Language: en-gb Subject: [Pce] New Version Notification for draft-farrkingel-pce-abno-architecture-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:47:41 -0000 Hi All,=20 Please find a new version of the ABNO Architecture draft: http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-02 Updates include: - Discussion on the LSP database and the applicability of other = databases.=20 - Further description of the VNTM.=20 - New use case (GCO - Thanks to Quintin Zhao). - Some new section placeholders (ALTO Server, Survivability and = Redundancy) - Various nits and readability updates.=20 As always, thanks for your attention and comments.=20 Br, Adrian and Dan.=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 19 January 2013 20:14 To: adrian@olddog.co.uk Cc: daniel@olddog.co.uk Subject: New Version Notification for = draft-farrkingel-pce-abno-architecture-02.txt A new version of I-D, draft-farrkingel-pce-abno-architecture-02.txt has been successfully submitted by Adrian Farrel and posted to the IETF = repository. Filename: draft-farrkingel-pce-abno-architecture Revision: 02 Title: A PCE-based Architecture for Application-based Network = Operations Creation date: 2013-01-19 WG ID: Individual Submission Number of pages: 38 URL: = http://www.ietf.org/internet-drafts/draft-farrkingel-pce-abno-architectur= e-02.txt Status: = http://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture Htmlized: = http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-02 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farrkingel-pce-abno-architecture= -02 Abstract: Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to- point connectivity, network virtualization, or mobile backhaul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet this type of requirement is said to have Application-Based Network Operations (ABNO). ABNO brings together several existing technologies for gathering information about the resources available in a network, for consideration of topologies and how those topologies map to underlying network resources, for requesting path computation, and for provisioning or reserving network resources. Thus, ABNO may be seen as the use of a toolbox of existing components enhanced with a few new elements. The key component within an ABNO is the Path Computation Element (PCE), which can be used for computing paths and is further extended to provide policy enforcement capabilities for ABNO. This document describes an architecture and framework for ABNO showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. = =20 The IETF Secretariat From ramon.casellas@cttc.es Mon Jan 21 08:06:05 2013 Return-Path: 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 08E1721F8499 for ; Mon, 21 Jan 2013 08:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXbz9QGKteUg for ; Mon, 21 Jan 2013 08:06:04 -0800 (PST) Received: from marchena.puc.rediris.es (unknown [IPv6:2001:720:418:ca00::4]) by ietfa.amsl.com (Postfix) with ESMTP id 7B27821F8479 for ; Mon, 21 Jan 2013 08:06:04 -0800 (PST) Received: from [84.88.62.208] (helo=leo) by marchena.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TxJso-0000US-8a for pce@ietf.org; Mon, 21 Jan 2013 17:06:02 +0100 Received: from [192.168.101.80] (unknown [192.168.101.80]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 79007200F6 for ; Mon, 21 Jan 2013 17:05:57 +0100 (CET) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <50FD6767.3050200@cttc.es> Date: Mon, 21 Jan 2013 17:05:59 +0100 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: pce@ietf.org References: <50F59322.9010208@orange.com> In-Reply-To: <50F59322.9010208@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SPF-Received: 4 X-Spamina-Bogosity: Ham Subject: Re: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 16:06:05 -0000 El 15/01/2013 18:34, Julien Meuric escribió: > > This e-mail starts a WG last call on draft-ietf-pce-gmpls-aps-req-06. Please send your comments to the PCE. You may review the document in front of the corresponding extension I-D, which should be last called soon. Dear all, Some random nits and comments after a fast read: * Several paragraphs (incl. Section 4.1) refer to an expired: [CSPF] T. Otani, et al, "Considering Generalized Multiprotocol Label Switching Traffic Engineering Attributes During Path Computation", draft-otani-ccamp-gmpls-cspf-constraints- 07.txt, Feb., 2008. * I am not sure of the implications of Section 3.2 - are must, should etc. MUST / SHOULD as per rfc2119?. In my humble opinion it could help understanding since, as of now, the basic assumptions could seem to imply that a PCE will not reply a e.g. strict ERO with different regions/layers as long as they are ok within the GMPLS hierarchy, although the paragraph below seems to allow otherwise. * Decouple requirements from solutions? the draft cites PCEP-EXT (a solutions document) to refer to requirements. PCEP-EXT refers to: [PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-ietf- pce-gmpls-PCEP-EXTs, in progress. (incorrect reference btw) * May need to be updated: [PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and Wavelength Assignment",draft-ietf-pce-wson-routing- wavelength, in progress. * Would be nice to reflect Danielle et al. work on OTN post RFC4328 [OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to OSPF for Generalized MPLS(GMPLS) Control of Evolving G.709 OTN Networks", in progress. [RSVP-TE-G709] Fatai Zhang,et al,"Generalized Multi-Protocol Label Switching(GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Network Control", in progress. thanks R. From zhang.xian@huawei.com Mon Jan 21 19:53:07 2013 Return-Path: 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 2AA6A21F875C for ; Mon, 21 Jan 2013 19:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKs-Ickh8TyV for ; Mon, 21 Jan 2013 19:53:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBE921F8750 for ; Mon, 21 Jan 2013 19:53:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANT28451; Tue, 22 Jan 2013 03:53:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 03:52:54 +0000 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 03:53:03 +0000 Received: from SZXEML535-MBX.china.huawei.com ([169.254.3.136]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 22 Jan 2013 11:52:59 +0800 From: "Zhangxian (Xian)" To: "adrian@olddog.co.uk" , "pce@ietf.org" Thread-Topic: [Pce] Ramblings of two old dogs Thread-Index: Ac30ztoEFPljqJoYTkS2j666yfwqYADeJ5KQ Date: Tue, 22 Jan 2013 03:52:59 +0000 Message-ID: References: <014701cdf4d2$4a259960$de70cc20$@olddog.co.uk> In-Reply-To: <014701cdf4d2$4a259960$de70cc20$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.105.102] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Ramblings of two old dogs X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 03:53:07 -0000 SGksIERlYXIgQWRyaWFuLCANCg0KICAgIFRoYW5rIHlvdSBhbmQgRGFuIGZvciBzdWNoIGEgdXNl ZnVsIFEvQSBsaXN0LiBJIGZpbmQgdGhpcyBkcmFmdCBxdWl0ZSB1c2VmdWwgaW4gdGhlIGNvbnRl eHQgb2YgdGhlIHRvcGljcyBjdXJyZW50bHkgdW5kZXIgZGlzY3Vzc2lvbi4gUGxlYXNlIGZpbmQg bXkgY29tbWVudHMgYXMgZGV0YWlsZWQgYmVsb3c6DQoNClExNToNClVzaW5nIGludGVybWVkaWF0 ZSBub2RlcyBhbG9uZyBhbiBMU1AgdG8gcmVwb3J0IExTUCBzdGF0ZSB0byBQQ0Ugc291bmRzIGEg Z29vZCBhcHByb2FjaCwgZXNwZWNpYWxseSBpbiB0aGUgY2FzZXMgZXhwbGFpbmVkIChpLmUuIGhl YWQtZW5kIG5vZGVzIGRvIG5vdCBzdXBwb3J0IFBDRVAgb3IgdW5hd2FyZSBvZiB0aGUgTFNQIHJl cG9ydCByZXF1aXJlbWVudCkuIEJ1dCB3aWxsIHRoaXMgYnVyZGVuIHRoZSBQQ0UgaWYgaW50ZXJt ZWRpYXRlIG5vZGVzIChtYXliZSBtb3JlIHRoYW4gb25lIGFsb25nIG9uZSBMU1ApIG9wZW4gUENF UCBzZXNzaW9uIG9ubHkgZm9yIHN0YXRlIHJlcG9ydGluZyBwdXJwb3NlPyBJIGFsc28gZG91YnQg dGhlIHVzZWZ1bG5lc3Mgb2YgcGFydGlhbCBMU1AgYXdhcmVuZXNzIG9mIHN0YXRlZnVsIFBDRS4g DQoNClExNjoNCkkgdGhpbmsgdGhlIHRleHQgcHJvdmlkZWQgaXMgYWN0dWFsbHkgd2lkZXIgdGhh biB0aGUgcXVlc3Rpb24gImhvdyBhIHJlZHVuZGFudCBzdGF0ZWZ1bCBQQ0VzIHN5bmNocm9uaXpl IHN0YXRlIi4gSWYgcmVkdW5kYW50IG1lYW5zIGJhY2t1cCwgdGhlbiBpbiBvcmRlciB0byBtYWtl IGl0IHN5bmNocm9uaXplZCwgYSBkdW1iIERCIGR1bXAgd2lsbCBzdWZmaWNlLiBJTUhPLCB0aGUg dGV4dCBiZWxvdyBzaG91bGQgYWxzbyBhcHBseSB0byB0aGUgZGlzdHJpYnV0ZWQvbXVsdGlwbGUg cGFzc2l2ZSBQQ0VzIGNhc2UgaWYgdGhleSBlYWNoIGFyZSByZXNwb25zaWJsZSBmb3IgYSBzdWJz ZXQgb2YgUENDcycgcmVxdWVzdHMsIGFzc3VtaW5nIHRoZXkgc3luY2hyb25pemUgZWFjaCBvdGhl ciBpbnN0ZWFkIG9mIG9idGFpbmluZyB0aGUgc3RhdGVzIGZyb20gdGhlIG5ldHdvcms6DQoNCiIg Tm90ZSwgaG93ZXZlciwgdGhhdCBpbg0KICAgdGhlIGNhc2Ugb2YgZGlzdHJpYnV0ZWQgUENFcyB0 aGF0IGFyZSBhbHNvIEFjdGl2ZSBQQ0VzIChzZWUgU2VjdGlvbg0KICAgMTcpLCBlYWNoIFBDRSB3 aWxsIGJlIGNyZWF0aW5nIGVudHJpZXMgaW4gaXRzIG93biBMU1AtREIsIHNvIHRoZQ0KICAgc3lu Y2hyb25pemF0aW9uIG9mIGRhdGFiYXNlcyBtdXN0IGJlIGluY3JlbWVudGFsIGFuZCBiaWRpcmVj dGlvbmFsLA0KICAgbm90IGp1c3Qgc2ltcGx5IGEgZGF0YWJhc2UgZHVtcC4iDQoNClExOToNCklz IHRoZXJlIGEgcmVhc29uIHdoeSB0aGUgb3RoZXIgc3ViLXR5cGUgb2YgYW4gYWN0aXZlIFBDRSBp cyBsZWZ0IG91dD8gSU1ITywgYW4gYWN0aXZlIFBDRSB3aXRoIHRoZSBhYmlsaXR5IHRvIGlzc3Vl IG5ldyByb3V0ZSByZWNvbW1lbmRhdGlvbnMgd291bGQgYmUgYWxzbywgbWF5YmUgZXZlbiBtb3Jl LCBsaWtlIGFuIE5NUywgYXMgY29tcGFyZWQgdG8gdGhlIGNhc2UgbWVudGlvbmVkLiBGb3IgYW4g YWN0aXZlIFBDRSB3aXRoIExTUCBkZWxlZ2F0aW9uLCBhdCBsZWFzdCB0aGUgTFNQIGlzIGluaXRp YXRlZCBieSB0aGUgaGVhZC1lbmQgbm9kZXMgYW5kIGl0IGhhcyB0aGUgcm9vdCBjb250cm9sIHdo ZW4gbmVlZGVkLiA6LSkgDQoNClEyMToNCkFmdGVyIHJlYWRpbmcgdGhpcyBwYXJ0IGFuZCBicm93 c2luZyB0aHJvdWdoIFtJLUQuZmFycmtpbmdlbC1wY2UtYWJuby1hcmNoaXRlY3R1cmVdLCBpdCBz ZWVtcyB0byBtZSB0aGF0IGFkZGl0aW9uYWwgaW50ZXJmYWNlIHNob3VsZCBiZSBhZGRlZCB0byBG aWd1cmUgMSBvZiBbSS1ELmZhcnJraW5nZWwtcGNlLWFibm8tYXJjaGl0ZWN0dXJlXS4gSW4gUkZD NTYyMywgdGhyZWUgb3V0IG9mIGZvdXIgbXVsdGktbGF5ZXIgbW9kZWxzIHNwZWNpZmllcyB0aGUg cHJvdmluc2lvbmluZyBjYXBhYmlsaXR5IG9mIFZOVE0uIFNvLCB0aGVyZSBzaG91bGQgYmUgYSBk aXJlY3QgbGluayBiZXR3ZWVuIFZOVE0gYW5kIHRoZSBuZXR3b3JrLCBvciBhdCBsZWFzdCB0aGUg c2VydmVyIG5ldHdvcmsgbGF5ZXJzPyBCdXQgd2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIHRoZSBw cm92aXNpb25pbmcgbWFuYWdlciwgSSB3b25kZXIgd2hldGhlciB3b3VsZCBpdCBtYWtlcyBiZXR0 ZXIgc2Vuc2UgdG8gc3VwcHJlc3MgdGhpcyBmdW5jdGlvbiBvZiBWTlRNPyBJZiBzbywgdGhlbiBw cm9iYWJseSBQQ0UrcHJvdmlzaW9uaW5nIG1hbmFnZXIrVk5UTSA9IGFjdGl2ZSBtdWx0aS1sYXll ciBQQ0U/DQoNCkFub3RoZXIgcXVlc3Rpb24gb2YgbWluZSBpczogc2hvdWxkIFBDRVAgd29yayBm b3IgdGhlIGludGVyZmFjZSBmcm9tIHdoaWNoIFZOVE0gbGVhcm4gYWJvdXQgdGhlIG5lZWQgb2Yg YWRkaXRpb25hbCBURSBsaW5rcyBmcm9tIHVwcGVyIGxheWVyIFBDRT8gQXMgbGVhc3QgZnJvbSBS RkM1NjIzLCBpdCBpbmRpY2F0ZXMgc28uIENvcnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFuZGluZyBp cyBub3QgY29ycmVjdC4gDQoNCiBIb3BlIHRoZXNlIGNvbW1lbnRzIG1ha2Ugc2Vuc2UgYW5kIGhl bHBzIHRvIGxlYWQgdG8gdmVyc2lvbiB0aGF0IHdpbGwgcmVkdWNlcyBmdXJ0aGVyIHF1ZXN0aW9u cywgOi0pLiANCg0KUmVnYXJkcywNCg0KWGlhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNClNlbnQ6IDIwMTPE6jHUwjE4yNUgMDo0Ng0K VG86IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogW1BjZV0gUmFtYmxpbmdzIG9mIHR3byBvbGQgZG9n cw0KDQpIaSwNCg0KT3ZlciB0aGUgeWVhcnMgRGFuIGFuZCBJIGhhdmUgYmVlbiBhc2tlZCBhIG51 bWJlciBvZiBxdWVzdGlvbnMgYWJvdXQgUENFIGFuZCBob3cNCml0IGZpdHMgaW50byBkaWZmZXJl bnQgdXNlcyBpbiB0aGUgbmV0d29yay4NCg0KQWx0aG91Z2ggd2UgZmVlbCB0aGF0IHRoZSBBQk5P IGRvY3VtZW50IChkcmFmdC1mYXJya2luZ2VsLXBjZS1hYm5vLWFyY2hpdGVjdHVyZSkNCmdvZXMg YSBsb25nIHdheSB0byBleHBsYWluIHRoZSBiaWdnZXIgcGljdHVyZSwgdGhlcmUgYXJlIGEgbG90 IG9mIHNtYWxsZXIsDQpldmVyeWRheSBxdWVzdGlvbnMgdGhhdCBuZWVkIGF0dGVudGlvbi4NCg0K SW4gYW4gYXR0ZW1wdCB0byByZWR1Y2UgdGhlIGVtYWlsIHdlIHNlZSwgd2UgaGF2ZSBjb2xsZWN0 ZWQgdGhlc2UgaW50byBhbg0KSW5mb3JtYXRpb25hbCBJLUQgYXMgYmVsb3cuIE9idmlvdXNseSwg aWYgeW91IGFsbCBzZW5kIHVzIGNvbW1lbnRzIGFuZCB0aG91Z2h0cw0Kb24gdGhpcyBkb2N1bWVu dCB5b3Ugd2lsbCBzdWNjZXNzZnVsbHkgdGh3YXJ0IG91ciBwbGFucyA6LSkNCg0KQWRyaWFuIGFu ZCBEYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpLWQtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn XQ0KPiBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IDE3IEph bnVhcnkgMjAxMyAxNTozMA0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IFN1YmplY3Q6 IEktRCBBY3Rpb246IGRyYWZ0LWZhcnJraW5nZWwtcGNlLXF1ZXN0aW9ucy0wMC50eHQNCj4gDQo+ IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMNCmRpcmVjdG9yaWVzLg0KPiANCj4gDQo+IAlUaXRsZSAgICAgICAgICAg OiBVbmFuc3dlcmVkIFF1ZXN0aW9ucyBpbiB0aGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50DQo+ IEFyY2hpdGVjdHVyZQ0KPiAJQXV0aG9yKHMpICAgICAgIDogQWRyaWFuIEZhcnJlbA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIERhbmllbCBLaW5nDQo+IAlGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1mYXJya2luZ2VsLXBjZS1xdWVzdGlvbnMtMDAudHh0DQo+IAlQYWdlcyAgICAgICAgICAg OiAyMg0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMy0wMS0xNw0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKFBDRSkgYXJjaGl0ZWN0dXJlIGlzIHNl dCBvdXQgaW4gUkZDDQo+ICAgIDQ2NTUuIFRoZSBhcmNoaXRlY3R1cmUgaXMgZXh0ZW5kZWQgZm9y IG11bHRpLWxheWVyIG5ldHdvcmtpbmcgd2l0aA0KPiAgICB0aGUgaW50cm9kdWN0aW9uIG9mIHRo ZSBWaXJ0dWFsIE5ldHdvcmsgVG9wb2xvZ3kgTWFuYWdlciBpbiBSRkMNCj4gICAgNTYyMywgYW5k IGdlbmVyYWxpemVkIHRvIEhpZXJhcmNoaWNhbCBQQ0UgaW4gUkZDIDY4MDUuDQo+IA0KPiAgICBU aGVzZSB0aHJlZSBhcmNoaXRlY3R1cmFsIHZpZXdzIG9mIFBDRSBkZWxpYmVyYXRlbHkgbGVhdmUg c29tZSBrZXkNCj4gICAgcXVlc3Rpb25zIHVuYW5zd2VyZWQgZXNwZWNpYWxseSB3aXRoIHJlc3Bl Y3QgdG8gdGhlIGludGVyYWN0aW9ucw0KPiAgICBiZXR3ZWVuIGFyY2hpdGVjdHVyYWwgY29tcG9u ZW50cy4gIFRoaXMgZG9jdW1lbnQgZHJhd3Mgb3V0IHRob3NlDQo+ICAgIHF1ZXN0aW9ucyBhbmQg ZGlzY3Vzc2VzIHRoZW0gaW4gYW4gYXJjaGl0ZWN0dXJhbCBjb250ZXh0IHdpdGgNCj4gICAgcmVm ZXJlbmNlIHRvIG90aGVyIGFyY2hpdGVjdHVyYWwgY29tcG9uZW50cywgZXhpc3RpbmcgcHJvdG9j b2xzLCBhbmQNCj4gICAgcmVjZW50IElFVEYgd29yayBlZmZvcnRzLg0KPiANCj4gICAgVGhpcyBk b2N1bWVudCBkb2VzIG5vdCB1cGRhdGUgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudHMgYW5kIGRv ZXMgbm90DQo+ICAgIGRlZmluZSBob3cgcHJvdG9jb2xzIG9yIGNvbXBvbmVudHMgbXVzdCBiZSB1 c2VkLiAgSXQgZG9lcywgaG93ZXZlciwNCj4gICAgc3VnZ2VzdCBob3cgdGhlIGFyY2hpdGVjdHVy YWwgY29tcG9uZW50cyBtaWdodCBiZSBjb21iaW5lZCB0byBwcm92aWRlDQo+ICAgIGFkdmFuY2Vk IFBDRSBmdW5jdGlvbi4NCj4gDQo+IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZmFycmtpbmdlbC1wY2UtcXVlc3Rpb25zDQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZmFycmtpbmdlbC1wY2UtcXVlc3Rpb25zLTAwDQo+IA0KPiANCj4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJ LUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo YWRvdy1zaXRlcy50eHQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClBjZSBtYWlsaW5nIGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg== From cyril.margaria@nsn.com Mon Jan 28 03:50:07 2013 Return-Path: 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 DDC6321F880B for ; Mon, 28 Jan 2013 03:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFZVmrAphDsj for ; Mon, 28 Jan 2013 03:50:07 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4921F87FE for ; Mon, 28 Jan 2013 03:50:06 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0SBnwew010687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Jan 2013 12:49:59 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0SBnrZ8002467; Mon, 28 Jan 2013 12:49:57 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 12:49:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jan 2013 12:49:12 +0100 Message-ID: In-Reply-To: <50F59322.9010208@orange.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06 Thread-Index: Ac3zRpTa5PgjHRSPT3Ssf03f3G8fKgKBJRtg References: <50F59322.9010208@orange.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Julien Meuric" , X-OriginalArrivalTime: 28 Jan 2013 11:49:53.0386 (UTC) FILETIME=[95F62CA0:01CDFD4D] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1387 X-purgate-ID: 151667::1359373799-00003C02-0330C7E0/0-0/0-0 Subject: Re: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:50:08 -0000 Dear all,=20 Some minor comments from my side: =20 Section 3.2 : it could be useful to state the general requirement after = the TDM example Section 4.1 : editorial : The solution document is not a source of reqs. Some nits :=20 The references also need some editing, the html version from = tools.ietf.org seems not to process them correctly. Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > ext Julien Meuric > Sent: Tuesday, January 15, 2013 6:34 PM > To: pce@ietf.org > Subject: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06 >=20 > Hi all and best wishes for 2013. >=20 > This e-mail starts a WG last call on draft-ietf-pce-gmpls-aps-req-06. > Please send your comments to the PCE. You may review the document in > front of the corresponding extension I-D, which should be last called > soon. >=20 > This WG LC will end on Wednesday January 30, noon UTC. >=20 > Regards, >=20 > JP & Julien >=20 >=20 > P.S.: An IPR was disclosed on this I-D in August 2012 > = (https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&docume= > nt_search=3Ddraft-ietf-pce-gmpls-aps-req). >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From julien.meuric@orange.com Wed Jan 30 09:25:52 2013 Return-Path: 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 8CCF721F87D6 for ; Wed, 30 Jan 2013 09:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ctgOqrqD7uN for ; Wed, 30 Jan 2013 09:25:51 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 75D0121F8867 for ; Wed, 30 Jan 2013 09:25:51 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 308991074006 for ; Wed, 30 Jan 2013 18:30:48 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 2A37DE301DB for ; Wed, 30 Jan 2013 18:30:48 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 18:25:49 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 18:25:49 +0100 Message-ID: <5109579C.9010705@orange.com> Date: Wed, 30 Jan 2013 18:25:48 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: pce@ietf.org References: <50F59322.9010208@orange.com> In-Reply-To: <50F59322.9010208@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Jan 2013 17:25:49.0331 (UTC) FILETIME=[D8AACE30:01CDFF0E] Subject: Re: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:25:52 -0000 Hi all. This WG LC has ended. I will send my review soon. Authors, please address and/or discuss the comments received to build a proper update. Thanks, Julien Le 15/01/2013 18:34, Julien Meuric a écrit : > Hi all and best wishes for 2013. > > This e-mail starts a WG last call on draft-ietf-pce-gmpls-aps-req-06. > Please send your comments to the PCE. You may review the document in > front of the corresponding extension I-D, which should be last called > soon. > > This WG LC will end on Wednesday January 30, noon UTC. > > Regards, > > JP & Julien > > > P.S.: An IPR was disclosed on this I-D in August 2012 > (https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-pce-gmpls-aps-req). > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From julien.meuric@orange.com Wed Jan 30 09:30:40 2013 Return-Path: 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 BCAB621F88B9 for ; Wed, 30 Jan 2013 09:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcsKC-nA9tcW for ; Wed, 30 Jan 2013 09:30:40 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B823421F889C for ; Wed, 30 Jan 2013 09:30:39 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EA614DE400A for ; Wed, 30 Jan 2013 18:32:19 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id DF71BDE4004 for ; Wed, 30 Jan 2013 18:32:19 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 18:30:38 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 18:30:38 +0100 Message-ID: <510958BD.7080305@orange.com> Date: Wed, 30 Jan 2013 18:30:37 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: pce@ietf.org References: <50F59322.9010208@orange.com> In-Reply-To: <50F59322.9010208@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Jan 2013 17:30:38.0060 (UTC) FILETIME=[84C35AC0:01CDFF0F] Subject: Re: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:30:40 -0000 Hi. Authors of draft-ietf-pce-gmpls-aps-req, here is my review of your I-D, as a chair. As a general comment, in the context of PCE, I tend to prefer the word "path" to the word "route", but the I-D seems consistent in that use, so no change look necessary there. ---------- Abstract ----- - s/effort of PCE WG/effort of the PCE WG/ - [Wrong expansion or right hyphen? :-) ] s/Multi-protocol/Multiprotocol/ - RFC 2119 is referenced there, and again in section 2. I do not see these keywords used in the document: either the I-D needs a deep update to make an efficient use of them, or the RFC 2119 reference should be (double) dropped. ---------- Section 1 ----- - s/effort of PCE WG/effort of the PCE WG/ - s/in GMPLS networks/in GMPLS-controlled networks/ - s/and (non-packet switch capable) GMPLS networks/and GMPLS-controlled networks/ [Why excluding PSC?] - s/complements these documents/complements these RFCs/ [repetition] - s/definition of series of PCE related protocols/definition of PCE-related protocols/ - s/Constraint based/Constraint-based/ - s/is more stringent/is usually more stringent/ - The reference to [CSPF] should be removed here. - s/[RFC3471, RFC3473]/[RFC3473]/ [The latter already references the former.] - s/SRLG, and/SRLGs and/ - s/for the end points/of the end points/ ---------- Section 2 ----- To be dropped? (See above.) ---------- Section 3.1 ----- I am not sure that section is in the scope of the document. Instead, it feels rather related to RFC 4927 and RFC 5376. ---------- Section 3.2 ----- - To emphasize Ramon's comment: * the first sentence, which refers to [CSPF], looks useless and could be dropped; * the full sentence from "[CSPF] indicates" to "created LSP." could be dropped also. - Here again, there is no reason to exclude PSC (which is a typical use case of asymmetric bandwidth from section 3.4). - s/The non-packet GMPLS networks/GMPLS-controlled networks/ - s/These GMPLS networks/These GMPLS-controlled networks/ - s/applying PCE to non-packet networks, for example/applying PCE to, for example/ - s/TDM(SDH)/TDM (SDH)/ [twice] ---------- Section 4 ----- The sentence duplicates the section title. ---------- Section 4.1 ----- - s/Requirements of Path/Requirements on Path/ - s/in GMPLS networks/in GMPLS-controlled networks/ - s/appropriately according to tables in [CSPF] once a PCC/appropriately once a PCC/ - As mentioned by Ramon and Cyril, [PCEP-EXT] should not be referenced in the corresponding requirement document. - s/[ PCE-WSON-REQ]/[PCE-WSON-REQ]/ - s/control(ELC),the /control, the/ - s/as follows: [RFC5440]/as follows:/ - In (1), among switching capabilities, EVPL is missing (RFC6004). - s/Technology specific/Technology-specific/ - s/such as wavelength label as defined in [RFC6205], or labels defined in [RFC4606], [RFC6060] or [RFC6002]/such as defined in [RFC4606], [RFC6060], [RFC6002] or [RFC6205]/ - The wording of (13) is not consistent with the previous ones. Proposed text: "Support of label restrictions in the requests/responses, similarly to RSVP-TE." (A reference may be useful.) ---------- Section 4.2 ----- - s/Requirements of Path/Requirements on Path/ - I got lost with the first sentence. I would drop it and start the paragraph by: "As described above, a PCE should compute..." - s/Concatenation path computation/Path computation with concatenation/ - s/case of concatenation path computation/case of path computation involving concatenation/ - s/compute the path which satisfies the specified concatenation constraints./compute a path accordingly./ - s/For contiguous concatenation path computation/For path computation involving contiguous concatenation/ - s/the routes of each member signal must be co-routed and/a single route is required and/ - s/For virtual concatenation path computation/For path computation involving virtual concatenation/ - s/and maybe there are/and there may be/ - s/case that/case where/ - s/doesn't/does not/ - s/the label/the exact label(s)/ - s/the route and label assignment computation procedure/the route computation and label assignment procedures/ - I would drop "but is only one instance of it", which is redundant with the phrase "typical case". - s/in GMPLS networks/, in GMPLS-controlled networks,/ - s/selection constraint/selection constraints/ - s/the labels or set of label/the label or set of labels/ - The sentence about PCEReq should be removed ("Reply" section). - s/should be capable of indicating which one is working or protection route./should allow to distinguish the working (nominal) and the protection routes./ ---------- Section 4.3 ----- - s/PCE related/PCE-related/ - s/referred to accommodate/referred to so as to accommodate/ ---------- Section 5 ----- - s/PCE extensions/PCEP extensions/ ---------- Section 8 ----- The reference section deserves an update: evolving documents, comments addressed in this I-D, missing spaces after commas, authors' first names and surnames in various orders... ---------- Best regards, Julien Le 15/01/2013 18:34, Julien Meuric a écrit : > Hi all and best wishes for 2013. > > This e-mail starts a WG last call on > draft-ietf-pce-gmpls-aps-req-06. Please send your comments to the > PCE. You may review the document in front of the corresponding > extension I-D, which should be last called soon. > > This WG LC will end on Wednesday January 30, noon UTC. > > Regards, > > JP & Julien > > > P.S.: An IPR was disclosed on this I-D in August 2012 > (https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-pce-gmpls-aps-req). > > > > > > _______________________________________________ > Pce mailing list Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From jmedved@cisco.com Wed Jan 30 14:00:03 2013 Return-Path: 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 83B6821F8855 for ; Wed, 30 Jan 2013 14:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ-06Hc9LFeU for ; Wed, 30 Jan 2013 14:00:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9221F8865 for ; Wed, 30 Jan 2013 14:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=364; q=dns/txt; s=iport; t=1359583202; x=1360792802; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VzFHfwFH1xXFmVA4j2Pvu6zyW/yu2kcM2wRswzzk2fs=; b=BmhIzBGQ3UI+P+E9+Je5w5O8ZkY/6p1oXP0KL4mEvFxXw69wqce0/UHl XgRNLfhujRDu8X6dqEdY+/7QZL99VFmpo6iMzFpq5aGR3400V6+pLp+o3 qeL4E5nXvNisgS419k/4vcGVfWL2/bnGLQL7GvW8lPhBTlXVdtWltUu5Z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFAPaWCVGtJV2Y/2dsb2JhbABFhgG5DhZzgiABBDpRASoUQicEG4gJDKBPoSuQK2EDlymPL4J3giQ X-IronPort-AV: E=Sophos;i="4.84,572,1355097600"; d="scan'208";a="170802606" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 30 Jan 2013 22:00:00 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0UM00BT012583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Jan 2013 22:00:00 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.78]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 16:00:00 -0600 From: "Jan Medved (jmedved)" To: "pce@ietf.org" Thread-Topic: New I-D about discovering stateful PCE capabilities Thread-Index: AQHN/zUletIyqfJ4UE+hzYpxy0YrLw== Date: Wed, 30 Jan 2013 21:59:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.170] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Pce] New I-D about discovering stateful PCE capabilities X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 22:00:03 -0000 Dear PCE'rs, We've posted an I-D about discovering stateful PCE capabilities, building u= pon the PCE discovery mechanisms described in RFCs 5088 and 5089.=20 The draft can be found here:=20 http://datatracker.ietf.org/doc/draft-sivabalan-pce-disco-stateful/ Your feedback and comments are most welcome and appreciated. Thanks, Siva and Jan=