From pce-bounces@ietf.org Mon Jun 2 17:36:13 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143DC3A6AB4; Mon, 2 Jun 2008 17:36:13 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9117428C111; Mon, 2 Jun 2008 00:29:15 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdDqsKKiWli0; Mon, 2 Jun 2008 00:29:14 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5E52E28C14B; Mon, 2 Jun 2008 00:25:55 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m527PRMd027248; Mon, 2 Jun 2008 10:25:53 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 10:25:28 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 10:25:27 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 10:25:26 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72CBD93E@vaebe104.NOE.Nokia.com> In-Reply-To: <059e01c8c0c2$39360890$9001010a@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Magnus Westerlund: DISCUSS: draft-ietf-pce-pcep Thread-Index: AcjAwmOQmxtu1t89Q2yNLZzmBRD5FgDfZ5AA References: <20080522132121.1705328C298@core3.amsl.com> <059e01c8c0c2$39360890$9001010a@your029b8cecfe> From: To: , X-OriginalArrivalTime: 02 Jun 2008 07:25:27.0531 (UTC) FILETIME=[D48413B0:01C8C481] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 02 Jun 2008 17:36:12 -0700 Cc: draft-ietf-pce-pcep@tools.ietf.org, pce@ietf.org, pce-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Pce] Magnus Westerlund: DISCUSS: draft-ietf-pce-pcep X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Adrian Farrel wrote: > The full totality of material specified in BNF in this I-D is > reproduced below. As you will see, it is trivial to check this > by eye. Apparently, it is not trivial; otherwise, these rules would have been spotted earlier: > ::= > > ::= Best regards, Pasi _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jun 2 17:36:13 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440683A6ADE; Mon, 2 Jun 2008 17:36:13 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DB83A687F; Mon, 2 Jun 2008 13:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzyVcVxCg7P2; Mon, 2 Jun 2008 13:03:12 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 727E53A6809; Mon, 2 Jun 2008 13:03:11 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m52K36nV021952; Mon, 2 Jun 2008 23:03:10 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 23:03:07 +0300 Received: from lars.dhcp.nanog.merit.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 23:03:06 +0300 From: Lars Eggert To: Adrian Farrel In-Reply-To: <02c501c8be3d$3f7a95e0$9001010a@your029b8cecfe> X-Priority: 3 References: <02c501c8be3d$3f7a95e0$9001010a@your029b8cecfe> Message-Id: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 16:03:02 -0400 X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 02 Jun 2008 20:03:06.0927 (UTC) FILETIME=[AC6D6BF0:01C8C4EB] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 02 Jun 2008 17:36:12 -0700 Cc: draft-ietf-pce-pcep@tools.ietf.org, pce@ietf.org, pce-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Pce] Lars Eggert: Discusses and Comments on draft-ietf-pce-pcep X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, On 2008-5-25, at 3:59, ext Adrian Farrel wrote: >> Section 6.3., paragraph 0: >>> 6.3. Keepalive Message >> >> DISCUSS: I have a few suggestions on improving the keepalive >> mechanism. > > You have raised this as a Discuss, but you phrase it as > "suggestions." Please clarify whether for you it is imperative that > the Keepalive process is updated as you suggest, or whether these > may be treated as suggestions. I should have phrased this better. My discuss is on the currently- specified keepalive mechanism, which keeps generating keepalives absent any indication that the peer is currently receiving them and in a way that is inefficient compared to a traditional dummy request- response exchange that triggers when the deadtimer expires. (TCP guarantees delivery, so sending keepalives at a rate higher than the deadtimer doesn't add value - they can't get lost.) In order to make this discuss actionable, I've suggested an alternative design, but I'd be fine with any other alternative that doesn't suffer from these issues. (Another such example would be to use TCP-level keepalives, which although not part of the spec are implemented by all platforms I know.) I'm wondering if our different views stem from different views on what this mechanism is supposed to be good for. In my mind, keepalives are meant to let an end-point eventually discover non-responding connections. Is PCEP using keepalives for purposes that require more timely responses, such as failover? If so, TCP may simply be the wrong underlying protocol for PCEP, and SCTP may be a better match, given its design goal of supporting fail-over. >> (1) Both the PCC and PCE are allowed to send keepalives >> according to their timers. This wastes bandwidth. The reception of a >> keepalive request from the other end should restart the keepalive >> timer on the receiving end - the reception is an indication that the >> peer is alive. This means that keepalives will usually only be sent >> from one end (the one with the shorter keepalive timer) and responded >> to by the other end. > > Please note that Keepalive messages are not responded. > They are sent to the receiver according to the frequency specified > by the receiver. Thus the Keepalive may be unidirectional, or may be > very unbalanced according to the requirements of the peers. Thanks for the clarification. I misunderstood this when reading the spec. I still believe that this keep-alive design has undesirable features. A more traditional empty request-response exchange doesn't suffer from these drawbacks. >> (2) As long as a keepalive has not been responded >> to, a PCEP speaker MUST NOT send another one. TCP is a reliable >> protocol and will deliver the outstanding keepalive when it can. It >> is >> not lost, and there is no need to resend it. All that sending more >> keepalives does when there is no response if fill up the socket send >> buffer. > > The filling up of the socket send buffer (which might happen through > repeated sends of a Keepalive message that cannot be delivered) > seems a little improbable. The PCEP messages are four bytes long and > will carry the normal TCP/IP headers. It is true that an > implementation that opts to not receive Keepalives (or one that must > send them far more often than it must receive them) runs the risk of > not noticing a failed TCP connection and continuing to send > Keepalives until TCP itself eventually reports the problem. It seems > to us that this is an extreme fringe condition that can be protected > against by proper configuration of the protocol where the issue is > believed to be real. This depends on the keepalive frequency and the send buffer in use, as well as the duration of a connectivity disruption. I agree that this can be engineered away for most rational cases, but why do so when the issue can be completely eliminated through a more traditional keepalive scheme? >> Section 7.3., paragraph 10: >>> Keepalive (8 bits): maximum period of time (in seconds) between two >>> consecutive PCEP messages sent by the sender of this message. The >>> minimum value for the Keepalive is 1 second. When set to 0, once >>> the >>> session is established, no further Keepalive messages are sent to >>> the >>> remote peer. A RECOMMENDED value for the keepalive frequency is 30 >>> seconds. >> >> DISCUSS: 1 second is extremely short. If there is a requirement that >> PCEP detect failures on such short timescales and should fail over in >> some way, TCP is the wrong underlying transport protocol. If that's >> the motivation, PCEP should use SCTP, which was specifically designed >> for this case. Otherwise, I'd suggest 30 seconds as a reasonable >> minimum to use, and something larger as a recommended default. > > The timer range is designed to *allow* an operator to handle a > special case deployment where a very short timer is needed, but > *recommends* a default value of 30 seconds. Further, it allows the > operator to set a much larger value. > > I don't see this as any issue at all and no reason to change the > transport protocol. I understand that 1 is the minimum and 30 the default. Under what conditions would 1 second be a reasonable interval? If failover on short timescales is the goal, SCTP provides mechanisms for that. >> Section 9.1., paragraph 1: >>> PCEP uses a well-known TCP port. IANA is requested to assign a >>> port >>> number from the "System" sub-registry of the "Port Numbers" >>> registry. >> >> DISCUSS: Why is a system port (0-1023) required, wouldn't a >> registered >> port (1023-49151) suffice? > > Is this not a security issue? On most systems, system ports can only > be used by system (or root) processes or by programs executed by > privileged users. Registered ports can, on most systems, be used by > ordinary user processes or programs executed by ordinary users. > Thus, the use of a registered port for PCEP helps to stop a rogue > program on a PCE or a PCC from impersonating the server/client. A system port is not a security mechanism - attackers can as easily send from low port numbers as from high ones. > One might as well ask why HTTP uses port 80, or BGP port 179. It's an historic artifact that had its origins in trying to prevent regular users from running a Unix "system" service. Current security practice is to sandbox servers and not run them as root. Note that the IANA port alocation guidelines are under revision, and draft-cotton-tsvwg-iana-ports raises the bar on obtaining one (we're running out). This is why I'd like to see some stronger argument for allocating a low port: 4.2. Well Known (System) Ports The Well Known Ports are assigned by IANA and cover the range 0-1023. On many systems, they can only be used by system (or root) processes or by programs executed by privileged users. Registration requests for a Well Known port number MUST follow the "IETF Review" policy of [I-D.narten-iana-considerations-rfc2434bis]. Registrations for a port number in this range MUST document why a port number in the Registered Ports range will not fulfill the application needs. Registrations requesting more than a single port number for a single application in this space SHOULD be denied. >> Section 10.1., paragraph 1: >>> It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to >>> provide for the authenticity and integrity of PCEP messages. This >>> will allow protecting against PCE or PCC impersonation and also >>> against message content falsification. >> >> DISCUSS: Given all the issues with the continued use of TCP-MD5, I'm >> not convinced that we really want to recommend its use for a new >> protocol. Wouldn't draft-ietf-tcpm-tcp-auth-opt be the preferred >> alternative? Or TLS, since confidentiality is of key importance >> according to Section 10.2. (Also, nit, TCP-MD5 protects TCP segments >> and not PCEP messages.) > > See separate email on this. > Authors will look at TLS and fix the nit. > draft-ietf-tcpm-tcp-auth-opt is not available to use as a normative > part of this protocol. I think that a way forward would be to normatively refer to TCP-MD5 and say something to the effect that implementors are cautioned that TCP-MD5 is about to be obsoleted by a new IETF recommendation (TCP-AO) and that they should be prepared to update their implementations when this happens. The IESG might need to do an exception procedure similar to what we die for BGP's use of TCP-MD5; I'm hoping that the SEC ADs will chime in. >> Section 4.2.1., paragraph 4: >>> Successive retries are permitted but an implementation should make >>> use of an exponential back-off session establishment retry >>> procedure. >> >> s/should make/SHOULD make/ > > Section 4 provides an architectural overview and not normative > protocol definition. The use of RFC2119 language would be > inappropriate. OK, but in that case please describe this somewhere in the normative part - I couldn't find it there. >> Section 4.2.2., paragraph 4: >>> Once the PCC has selected a PCE, it sends the PCE a path computation >>> request to the PCE (PCReq message) that contains a variety of >>> objects >>> that specify the set of constraints and attributes for the path to >>> be >>> computed. >> >> Can a PCC send a second path computation request over the same TCP >> connection to a PCE when the answer to an earlier one is still >> outstanding? Can multiple TCP connections exist between the same PCC >> and PCE? > > Yes, multiple PCEP requests may be outstanding from the same PCC at > the same time. > No, multiple 'parallel' TCP connections must not be used, and a > specific error code exists to accompany the rejection of the second > connection. OK. Could you explicitly say so in the document? I gathered that was implicitly what the connection handling was supposed to result in; spelling it out wood be good IMO. >> Section 4.2.4., paragraph 1: >>> There are several circumstances in which a PCE may want to notify a >>> PCC of a specific event. For example, suppose that the PCE suddenly >>> gets overloaded, potentially leading to unacceptable response times. >> >> Can such notifications occur at any time, i.e., while another message >> is being sent? If so, how are they framed within the TCP byte stream? > > OK, "at any time" would be an exaggeration. It is also impossible to > send them in the past. I meant if they can happen while another message is being sent, and if the notification is interleaved into the TCP byte stream (requiring some application-level framing) or if the application will queue it until an ongoing transmission has ended. I gather it's the latter that is supposed to happen. Could you make this explicit in the document, i.e., that PCE messages are transmitted over TCP in a sequential order without the possibility for interleaving? >> Section 7.3., paragraph 13: >>> A sends an Open message to B with Keepalive=10 seconds and >>> Deadtimer=30 seconds. This means that A sends Keepalive messages >>> (or >>> ay other PCEP message) to B every 10 seconds and B can declare the >>> PCEP session with A down if no PCEP message has been received from A >>> within any 30 second period. > > [Editors: Please note s/ay/any/] > >> I'd be nice if the example followed the recommended values/fomulas >> above and used Keepalive=30 and DeadTimer=4*Keepalive (or whatever >> the >> defaults will be after addressing my comments above.) > > Yes, this is a good point. > It should be easy to change this to 30 and 120 seconds. OK >> Section 7.3., paragraph 14: >>> SID (PCEP session-ID - 8 bits): unsigned PCEP session number that >>> identifies the current session. The SID MUST be incremented each >>> time a new PCEP session is established and is used for logging and >>> troubleshooting purposes. There is one SID number in each >>> direction. >> >> What's the start value? Is it incremented for each connection to any >> PCEP peer or only for connections to the same PCEP peer? Does it >> matter when SID rolls over? The document doesn't discuss what the SID >> is used for at all. > > I asked similar questions during WG last call. > > The answers are: > Start where you like, the value is not important for the protocol. > The requirement is that the SID is 'sufficiently different' to avoid > confusion between instances of sessions to the same peer. > Thus, "incremented" is more like implementation advice than a strict > definition. In particular, incremented by 255 would be fine :-) > However, the usage (for logging and troubleshooting) might suggest > that incrementing by one is a helpful way of looking at things. > SID roll-over is not particularly a problem. > > Implementation could use a single source of SIDs across all peers, > or one source for each peer. The former might constrain the > implementation to only 255 concurrent sessions. The latter > potentially requires more state. Thanks for the clarification. It might be useful if a bit of this explanation was added to the document. Also, please have it say that the SID SHALL only be used for logging and troubleshooting, in order to avoid having implementors start using it creatively. >> Section 7.4.1., paragraph 14: >>> Request-ID-number (32 bits). The Request-ID-number value combined >>> with the source IP address of the PCC and the PCE address uniquely >>> identify the path computation request context. The Request-ID- >>> number >>> MUST be incremented each time a new request is sent to the PCE. The >>> value 0x0000000 is considered as invalid. If no path computation >>> reply is received from the PCE, and the PCC wishes to resend its >>> request, the same Request-ID-number MUST be used. Conversely, >>> different Request-ID-number MUST be used for different requests sent >>> to a PCE. The same Request-ID-number MAY be used for path >>> computation requests sent to different PCEs. The path computation >>> reply is unambiguously identified by the IP source address of the >>> replying PCE. >> >> It's redundant to identify requests by source and destination IP >> address, given that those are constant for requests going over the >> same TCP connection. Likewise, replies are implicitly identified by >> the TCP connection they arrive over. > > OK. The text could have said that the requests are uniquely > identified by the combination of TCP connection and request ID. > Since, as you point out, TCP connection is isomorphic to source/dest > IP addresses, the text is accurate and not redundant. > OK >> Section 8.3., paragraph 1: >>> PCEP includes a keepalive mechanism to check the liveliness of a >>> PCEP >>> peer and a notification procedure allowing a PCE to advertise its >>> congestion state to a PCC. >> >> s/congestion/overload/ for consistency, here and throughout the >> document > > Yes. Good catch. OK >> Section 9.1., paragraph 1: >>> PCEP uses a well-known TCP port. IANA is requested to assign a port >>> number from the "System" sub-registry of the "Port Numbers" >>> registry. >> >> Does "uses a well-known TCP port" mean that messages from the PCC to >> the PCE must come from that registered source port, or can they come >> from any port? (The former implies that only a single PCEP connection >> can exist between a PCC and a PCE. It also weakens security a bit, >> because an attacker doesn't need to guess the source port anymore.) > > Yes. "Yes" as in "source port MUST be the PCE port"? (As must the destination port, obviously.) If so, you should make this explicit in the document, because the default behavior of operating systems is to dynamically assign a random high port number as a source port, unless an app specifically requests otherwise. > Only one connection between a PCC and a PCE at any time. No need for > more than one has been identified. It might be claimed that two PCC > processes might exist on a single host/router, but no usage scenario > has been found. Further, the text currently bans a second > simultaneous connection between peers. OK. This came up earlier in this email; I suggest making this explicit. > Security is weaker and stronger. > Weaker as you point out. > Stronger because of the use of a system port as previously described. Disagree that a system port is a security mechanism, as per above. > It is debatable whether port number knowledge makes DoS any more > significant since the TCP stack may be attacked simply by a > connection-attempt storm on any port. SYN floods can be mitigated through SYN cookies (RFC4987), to a large degree at least. >> Section 10.3.1., paragraph 2: >>> o A PCE should avoid promiscuous TCP listens for PCEP TCP >>> connection >>> establishment. It should use only listens that are specific to >>> authorized PCCs. >> >> Authorized by what? TCP has no feature to restrict listens based on >> credentials. > > See below. > >> Section 10.3.1., paragraph 4: >>> o The use of access-list on the PCE so as to restrict access to >>> authorized PCCs. >> >> Is redundant with the first bullet (or I don't understand what it >> means). > > Yes. My reaction to your previous comment was to say that the > authors mean access lists. In which case this is redundant. > > Authors to clarify. Please do. >> Appendix A., paragraph 46: >>> If the system receives an Open message from the PCEP peer before the >>> expiration of the OpenWait timer, the system first examines all of >>> its sessions that are in the OpenWait or KeepWait state. If another >>> session with the same PCEP peer already exists (same IP address), >>> then the system performs the following collision resolution >>> procedure: >> >> The goal of this procedure seems to be to guarantee that there is >> only >> a single active PCEP connection between two peers, but it's >> cumbersome. It'd be much easier to require a peer to not initiate a >> connection to a peer it already has one established with, and to >> require it to immediately close a new TCP connection coming from a >> peer it has an active PCEP connection with. This handles everything >> at >> the TCP layer without needing to involve the PCEP state machine. > > I agree that this non-normative appendix seems to include overkill > for an unlikely scenario. > > As you have previously observed, the use of a well-known port > reduces the possibility for parallel connections. Thus it would > simply not be possible for the situation to arise. > > But, multiple IP addresses can be (often are) assigned to routers > giving the possibility for multiple connections that we cannot ask > the TCP stack to police. The problem can only be resolved at the > PCEP level by identifying the two sessions with the same peer. Understood, but the text in Appendix A doesn't help in this scenario, because it identifies peers by IP address - it won't catch the case where two peers talk across two different IP address pairs. Lars _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Jun 11 08:23:42 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1243A6878; Wed, 11 Jun 2008 08:23:42 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5433A6812 for ; Wed, 11 Jun 2008 08:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW9JIUsJfBFW for ; Wed, 11 Jun 2008 08:23:34 -0700 (PDT) Received: from guadiana.unex.es (guadiana.unex.es [158.49.17.23]) by core3.amsl.com (Postfix) with ESMTP id A590E3A6896 for ; Wed, 11 Jun 2008 08:23:34 -0700 (PDT) Received: from [158.49.247.136] (unknown [158.49.247.136]) by guadiana.unex.es (Postfix) with ESMTP id 7369D1FE4C; Wed, 11 Jun 2008 17:23:49 +0200 (CEST) Message-ID: <484FEDF9.7000402@unex.es> Date: Wed, 11 Jun 2008 15:23:37 +0000 From: Manuel Dominguez Dorado Organization: University of Extremadura User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: pce@ietf.org Subject: [Pce] About PCE inte-AS conectivity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mdomdor@unex.es List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hello, I'm interested on PCE issues, specially those issues related to inter-AS = PCE. In order to provide accurate results, I am trying to use the most = real network model (at least, as real as possible). So, this is my question: When in PCE WG it is said: "The PCE WG will work on application of this = model within a single domain or within a small group of domains (where a = domain is a layer, IGP area or Autonomous System with limited visibility = from the head-end LSR). At this time, applying this model to large = groups of domains such as the Internet is not thought to be possible, = and the PCE WG will not spend energy on that topic". What is the size we are speaking about? For example, a set of 200 = PCE-based autonomous systems and each one of them having 50 direct = adjacencies could be a good example? What would be the highest limit = (for both, number of implied AS and adjacency degree)? I need this = information in order to design solutions that are scalable enough to be = operative. Excuse me if it is an off-topic question. I have looked for the answer = for months but I found nothing related to Interdomain PCE. Thanks in advance. -- = ------------------------------------------------------------------------ MANUEL DOM=CDNGUEZ DORADO ------------------------------------------------------------------------ Addr.: Laboratorio de Ingenier=EDa Telem=E1tica Escuela Polit=E9cnica de C=E1ceres =C1rea de Ingenier=EDa Telem=E1tica Departamento de Ingenier=EDa de Sistemas Inform=E1ticos y Telem=E1t= icos Universidad de Extremadura Avda. de la Universidad s/n. 10071 - C=E1ceres - SPAIN Phone: +34 607 417 860 Fax..: +34 927 257 202 Email: mdomdor@unex.es Web.:: http://gitaca.unex.es/mdomdor ------------------------------------------------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Jun 11 17:56:33 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2323A68FE; Wed, 11 Jun 2008 17:56:33 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A154C3A68FE for ; Wed, 11 Jun 2008 17:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP0YQaZTpf0H for ; Wed, 11 Jun 2008 17:56:30 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 689F83A68AF for ; Wed, 11 Jun 2008 17:56:30 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m5C0utOq005300; Thu, 12 Jun 2008 01:56:55 +0100 Received: from your029b8cecfe (reverse.gdsz.cncnet.net [210.21.226.42] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m5C0uoNk005291; Thu, 12 Jun 2008 01:56:54 +0100 Message-ID: <010901c8cc27$337ab610$d106a8c0@your029b8cecfe> From: "Adrian Farrel" To: , References: <484FEDF9.7000402@unex.es> Date: Thu, 12 Jun 2008 01:56:47 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Pce] About PCE inte-AS conectivity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hello Manuel, > I'm interested on PCE issues, specially those issues related to inter-AS > PCE. Welcome aboard. > In order to provide accurate results, I am trying to use the most > real network model (at least, as real as possible). So, this is my > question: > > When in PCE WG it is said: "The PCE WG will work on application of this > model within a single domain or within a small group of domains (where a > domain is a layer, IGP area or Autonomous System with limited visibility > from the head-end LSR). At this time, applying this model to large > groups of domains such as the Internet is not thought to be possible, > and the PCE WG will not spend energy on that topic". > > What is the size we are speaking about? For example, a set of 200 > PCE-based autonomous systems and each one of them having 50 direct > adjacencies could be a good example? What would be the highest limit > (for both, number of implied AS and adjacency degree)? I need this > information in order to design solutions that are scalable enough to be > operative. Very good question. And hard to answer precisely. The intention of the text in the working group charter is to limit the scope of the PCE work to "connection-oriented" internet technologies (not IP forwarding), and to solve the problem of selecting path through a known set of domains rather than selecting the domain level path. It was considered sensible, when the working group was formed to be cautious about our scope, and to establish the technology as functional within a reasonably controlled environment. Section 5.1.15 of RFC 4657 gives some guidelines. - number of PCCs (1000/domain) - number of PCEs (100/domain) - number of PCCs communicating with a single PCE (1000) - number of PCEs communicated to by a single PCC (100) - number of domains (20) - number of path request messages (average of 10/second/PCE) - handling bursts of requests (burst of 100/second/PCE within a 10- second interval). But you will note that this does not talk about the connectedness of the domains. Neither the number of peer domains, nor the number of connections to any peer domain is mentioned. I would expect that these numbers would be unchanged from normal operation of (say) ASes in the Internet. I would say that some of the numbers listed above show top-end figures and one would not necessarily expect, for example, a standard deployment to have one PCC communication to 100 PCEs. > Excuse me if it is an off-topic question. I have looked for the answer > for months but I found nothing related to Interdomain PCE. Hope that helps. Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Jun 12 02:09:00 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6883A69EC; Thu, 12 Jun 2008 02:09:00 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BAE3A69AC for ; Thu, 12 Jun 2008 02:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJFVLJUTy2Pl for ; Thu, 12 Jun 2008 02:08:57 -0700 (PDT) Received: from guadiana.unex.es (guadiana.unex.es [158.49.17.23]) by core3.amsl.com (Postfix) with ESMTP id 9160E3A693D for ; Thu, 12 Jun 2008 02:08:57 -0700 (PDT) Received: from [158.49.247.136] (unknown [158.49.247.136]) by guadiana.unex.es (Postfix) with ESMTP id B81C41FF60; Thu, 12 Jun 2008 11:08:59 +0200 (CEST) Message-ID: <4850E7A0.2050801@unex.es> Date: Thu, 12 Jun 2008 09:08:48 +0000 From: Manuel Dominguez Dorado Organization: University of Extremadura User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 CC: pce@ietf.org References: <484FEDF9.7000402@unex.es> <010901c8cc27$337ab610$d106a8c0@your029b8cecfe> In-Reply-To: <010901c8cc27$337ab610$d106a8c0@your029b8cecfe> Subject: Re: [Pce] About PCE inte-AS conectivity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mdomdor@unex.es List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hello, > Welcome aboard. Thanks. :-). > - number of PCCs (1000/domain) > - number of PCEs (100/domain) > - number of PCCs communicating with a single PCE (1000) > - number of PCEs communicated to by a single PCC (100) > - number of domains (20) Then, should I understand that, in terms of inter-AS PCE, a domain is a = an AS? It is very good for me. I have been supposing an interdomain = environment composed by 200-300 ASes, for some months. having only 20 = domains is great for me, he, he. > - number of path request messages (average of 10/second/PCE) > - handling bursts of requests (burst of 100/second/PCE within a 10- > second interval). > = > But you will note that this does not talk about the connectedness of the = > domains. Neither the number of peer domains, nor the number of = > connections to any peer domain is mentioned. I would expect that these = > numbers would be unchanged from normal operation of (say) ASes in the = > Internet. OK. > = > I would say that some of the numbers listed above show top-end figures = > and one would not necessarily expect, for example, a standard deployment = > to have one PCC communication to 100 PCEs. > Hope that helps. OK. Thank you very much, you have not given me answers for all my = questions but, any way, you have helped me a lot. > Adrian Thank you again, Adrian. Best regards. -- = ------------------------------------------------------------------------ MANUEL DOM=CDNGUEZ DORADO ------------------------------------------------------------------------ Addr.: Laboratorio de Ingenier=EDa Telem=E1tica Escuela Polit=E9cnica de C=E1ceres =C1rea de Ingenier=EDa Telem=E1tica Departamento de Ingenier=EDa de Sistemas Inform=E1ticos y Telem=E1t= icos Universidad de Extremadura Avda. de la Universidad s/n. 10071 - C=E1ceres - SPAIN Phone: +34 607 417 860 Fax..: +34 927 257 202 Email: mdomdor@unex.es Web.:: http://gitaca.unex.es/mdomdor ------------------------------------------------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Jun 12 06:37:59 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA143A6AAA; Thu, 12 Jun 2008 06:37:59 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5444B3A6ABF for ; Thu, 12 Jun 2008 06:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlC+c4qdHRaW for ; Thu, 12 Jun 2008 06:37:57 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 2A12C3A695E for ; Thu, 12 Jun 2008 06:37:55 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m5CDcGV2021765; Thu, 12 Jun 2008 14:38:16 +0100 Received: from your029b8cecfe (reverse.gdsz.cncnet.net [210.21.226.42] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m5CDc8qf021711; Thu, 12 Jun 2008 14:38:14 +0100 Message-ID: <014a01c8cc91$8e468690$d106a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <484FEDF9.7000402@unex.es><010901c8cc27$337ab610$d106a8c0@your029b8cecfe> <4850E7A0.2050801@unex.es> Date: Thu, 12 Jun 2008 14:37:58 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: Re: [Pce] About PCE inte-AS conectivity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Once last thing, Manuel. > Then, should I understand that, in terms of inter-AS PCE, a domain is a > an AS? It is very good for me. I have been supposing an interdomain > environment composed by 200-300 ASes, for some months. having only 20 > domains is great for me, he, he. Yup. >From RFC 4657 Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include Interior Gateway Protocol (IGP) areas, Autonomous Systems (ASs), multiple ASs within a service provider network, or multiple ASs across multiple service provider networks. Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Jun 18 23:23:31 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF063A6875; Wed, 18 Jun 2008 23:23:31 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D3A3A6875 for ; Wed, 18 Jun 2008 23:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GdQvQRmjWlM for ; Wed, 18 Jun 2008 23:23:29 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id F12253A67D0 for ; Wed, 18 Jun 2008 23:23:26 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.47]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 07:24:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 07:24:36 +0100 Message-ID: <0D63518CCAD12D479B4C66FE4572D78D035D6A56@E03MVW2-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concurrent Optimization and More Thread-Index: AcjR1SVOYXa7NpiiQlqiI9RX22M6nA== From: To: X-OriginalArrivalTime: 19 Jun 2008 06:24:15.0898 (UTC) FILETIME=[191317A0:01C8D1D5] Subject: [Pce] Concurrent Optimization and More X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0653485293==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============0653485293== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D1D5.1893557D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D1D5.1893557D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have three basic questions (but I might the correct place in RFCs or drafts for that...); =20 1. How does the protocol for computing a single path works in a hierarchical network (more than one level of PCE's)? 2. What the draft for the concurrent optimization referred to: only inside of a sub-domain or also an inter-domain optimization which requires communication between the PCE's? 3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)? =20 Many thanks, =20 David Amzallag BT ------_=_NextPart_001_01C8D1D5.1893557D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have three basic questions (but I might the = correct=20 place in RFCs or drafts for that...);
 
1. How does the protocol = for computing a single path works in a = hierarchical=20 network (more than one level of PCE's)?
2.=20 What the draft for the = concurrent=20 optimization referred to: only = inside of a=20 sub-domain or also an inter-domain optimization which requires = communication=20 between the PCE's?
3. Can we assume that the = node's demands=20 are splittable (i.e., can be simultaneously satisfied by more than one=20 path)?
 
Many = thanks,
 
David=20 Amzallag
BT

 ------_=_NextPart_001_01C8D1D5.1893557D-- --===============0653485293== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0653485293==-- From pce-bounces@ietf.org Thu Jun 19 02:49:36 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170D628C20A; Thu, 19 Jun 2008 02:49:36 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E232028C20F for ; Thu, 19 Jun 2008 02:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCH9KG-ENtPq for ; Thu, 19 Jun 2008 02:49:31 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by core3.amsl.com (Postfix) with ESMTP id 3F95328C20A for ; Thu, 19 Jun 2008 02:49:31 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so952468ugd.46 for ; Thu, 19 Jun 2008 02:50:19 -0700 (PDT) Received: by 10.210.75.6 with SMTP id x6mr1672174eba.29.1213869018972; Thu, 19 Jun 2008 02:50:18 -0700 (PDT) Received: from Serenity ( [88.97.23.122]) by mx.google.com with ESMTPS id b30sm654964ika.3.2008.06.19.02.50.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Jun 2008 02:50:17 -0700 (PDT) From: "Daniel King" To: References: <0D63518CCAD12D479B4C66FE4572D78D035D6A56@E03MVW2-UKDY.domain1.systemhost.net> In-Reply-To: <0D63518CCAD12D479B4C66FE4572D78D035D6A56@E03MVW2-UKDY.domain1.systemhost.net> Date: Thu, 19 Jun 2008 10:50:25 +0100 Message-ID: <002701c8d1f1$e7aa4b80$b6fee280$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcjR1SVOYXa7NpiiQlqiI9RX22M6nAAG9VTQ Content-Language: en-gb Subject: Re: [Pce] Concurrent Optimization and More X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0514316799==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multipart message in MIME format. --===============0514316799== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C8D1FA.496EB380" Content-Language: en-gb This is a multipart message in MIME format. ------=_NextPart_000_0028_01C8D1FA.496EB380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi David, A few quick responses: >>1. How does the protocol for computing a single path works in a hierarchical network (more than one level of PCE's)? So far this requirement has been out of scope for the current work. There is growing momentum in the application of PCE to multi-layer networks, ASON, and "domain-paths." So this topic will require further thought and discussion. >>2. What the draft for the concurrent optimization referred to: only inside of a sub-domain or also an inter-domain optimization which requires communication between the PCE's? As above. The pce-global-concurrent-optimization draft focuses on single domain optimisation, specifically the PCC-PCE communication needs and protocol extensions to support the concurrent optimisation. Although, the authors do mention that a Global Concurrent Optimization (GCO) is applicable to a Virtual Network Topology (VNT) and multi-layer traffic engineering for new deployments. >>3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)? I may need some further clarity on this question. Do you mean that there may be more than one possible solution to a path computation, or that the solution to the computation may be a set of "parallel" paths with some assumption of load sharing (e.g. inverse multiplexing)? The answer to the first question is yes and is already done, although some work might be required to allow the PCE to supply a choice of paths to the PCC. The answer to the second question is also yes, but (very simple) protocol extensions will be needed to handle this case. Other relevant drafts you may find interesting for this topic include: A Path Computation Element (PCE)-Based Architecture http://www.ietf.org/rfc/rfc4655.txt A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering http://www.ietf.org/rfc/rfc4726.txt A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) http://www.ietf.org/rfc/rfc5152.txt Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-05.txt A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt Br, Dan From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of david.amzallag@bt.com Sent: 19 June 2008 07:25 To: pce@ietf.org Subject: [Pce] Concurrent Optimization and More Hi, I have three basic questions (but I might the correct place in RFCs or drafts for that...); 1. How does the protocol for computing a single path works in a hierarchical network (more than one level of PCE's)? 2. What the draft for the concurrent optimization referred to: only inside of a sub-domain or also an inter-domain optimization which requires communication between the PCE's? 3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)? Many thanks, David Amzallag BT ------=_NextPart_000_0028_01C8D1FA.496EB380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

A few quick responses:

 

>>1. How does the protocol for computing a single path works in a = hierarchical network (more than one level of PCE's)?

 

So far this requirement has been out of scope for the current work. There = is growing momentum in the application of PCE to multi-layer networks, ASON, and = "domain-paths." So this topic will require further thought and = discussion.

 

>>2. What the draft for the concurrent optimization referred to: only inside = of a sub-domain or also an inter-domain optimization which requires = communication between the PCE's?

 

As above. The pce-global-concurrent-optimization draft focuses on single = domain optimisation, specifically the PCC-PCE communication needs and protocol extensions to = support the concurrent optimisation. Although, the authors do mention that a = Global Concurrent Optimization (GCO) is applicable to a Virtual Network = Topology (VNT) and multi-layer traffic engineering for new deployments. =

 

>>3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)?

 

I may need some further clarity on this question. Do you mean that there = may be more than one possible solution to a path computation, or that the = solution to the computation may be a set of "parallel" paths with some = assumption of load sharing (e.g. inverse multiplexing)?

 

The answer to the first question is yes and is already done, although some = work might be required to allow the PCE to supply a choice of paths to the = PCC.

 

The answer to the second question is also yes, but (very simple) protocol extensions will be needed to handle this case.

 

Other relevant drafts you may find interesting for this topic = include:

 

A Path Computation Element (PCE)-Based Architecture

http://www.ietf.org/rfc/rfc4= 655.txt

 

A Framework for Inter-Domain Multiprotocol Label Switching Traffic = Engineering

http://www.ietf.org/rfc/rfc4= 726.txt

 

A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)

http://www.ietf.org/rfc/rfc5= 152.txt

 

Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region = Networks (MLN/MRN)

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln= -eval-05.txt

 

A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute = Shortest Constrained Inter-domain Traffic Engineering Label Switched = Paths

h= ttp://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt

 

Br, Dan

 

 

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = david.amzallag@bt.com
Sent: 19 June 2008 07:25
To: pce@ietf.org
Subject: [Pce] Concurrent Optimization and = More

 

Hi,<= o:p>

 

I have three basic questions (but I might the correct place in RFCs or = drafts for that...);

 

1. How does the protocol for computing a single path works in a = hierarchical network (more than one level of PCE's)?
2. What the draft for the concurrent optimization referred to: only = inside of a sub-domain or also an inter-domain optimization which requires = communication between the PCE's?

3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)?

 

Many thanks,

 

David Amzallag

BT

 =

------=_NextPart_000_0028_01C8D1FA.496EB380-- --===============0514316799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0514316799==-- From pce-bounces@ietf.org Fri Jun 20 00:26:32 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CC63A698E; Fri, 20 Jun 2008 00:26:32 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3549E3A6987 for ; Fri, 20 Jun 2008 00:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cghTSsiR6ePB for ; Fri, 20 Jun 2008 00:26:29 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id F18203A6904 for ; Fri, 20 Jun 2008 00:26:28 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.47]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 08:26:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 08:26:27 +0100 Message-ID: <0D63518CCAD12D479B4C66FE4572D78D035D7082@E03MVW2-UKDY.domain1.systemhost.net> In-Reply-To: <002701c8d1f1$e7aa4b80$b6fee280$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Concurrent Optimization and More Thread-Index: AcjR1SVOYXa7NpiiQlqiI9RX22M6nAAG9VTQABwzIZA= From: To: X-OriginalArrivalTime: 20 Jun 2008 07:26:28.0622 (UTC) FILETIME=[F45D52E0:01C8D2A6] Subject: Re: [Pce] Concurrent Optimization and More X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0618894619==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============0618894619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D2A6.F3DC4D9D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D2A6.F3DC4D9D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, =20 Many thanks for your fast reply. Are you familiar with any "real-time" implementation of few of the PCE ideas? Anyone that implements the distributed approach? =20 Warm regards, =20 David Amzallag, BT ________________________________ From: Daniel King [mailto:dk@danielking.net]=20 Sent: 19 June 2008 12:50 To: pce@ietf.org Subject: RE: [Pce] Concurrent Optimization and More Hi David,=20 =20 A few quick responses: =20 >>1. How does the protocol for computing a single path works in a hierarchical network (more than one level of PCE's)? =20 So far this requirement has been out of scope for the current work. There is growing momentum in the application of PCE to multi-layer networks, ASON, and "domain-paths." So this topic will require further thought and discussion. =20 >>2. What the draft for the concurrent optimization referred to: only inside of a sub-domain or also an inter-domain optimization which requires communication between the PCE's? =20 As above. The pce-global-concurrent-optimization draft focuses on single domain optimisation, specifically the PCC-PCE communication needs and protocol extensions to support the concurrent optimisation. Although, the authors do mention that a Global Concurrent Optimization (GCO) is applicable to a Virtual Network Topology (VNT) and multi-layer traffic engineering for new deployments.=20 =20 >>3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)? =20 I may need some further clarity on this question. Do you mean that there may be more than one possible solution to a path computation, or that the solution to the computation may be a set of "parallel" paths with some assumption of load sharing (e.g. inverse multiplexing)? =20 The answer to the first question is yes and is already done, although some work might be required to allow the PCE to supply a choice of paths to the PCC. =20 The answer to the second question is also yes, but (very simple) protocol extensions will be needed to handle this case. =20 Other relevant drafts you may find interesting for this topic include: =20 A Path Computation Element (PCE)-Based Architecture=20 http://www.ietf.org/rfc/rfc4655.txt =20 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering http://www.ietf.org/rfc/rfc4726.txt =20 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) http://www.ietf.org/rfc/rfc5152.txt =20 Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-05.t xt =20 A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt =20 Br, Dan =20 =20 From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of david.amzallag@bt.com Sent: 19 June 2008 07:25 To: pce@ietf.org Subject: [Pce] Concurrent Optimization and More =20 Hi, =20 I have three basic questions (but I might the correct place in RFCs or drafts for that...); =20 1. How does the protocol for computing a single path works in a hierarchical network (more than one level of PCE's)? 2. What the draft for the concurrent optimization referred to: only inside of a sub-domain or also an inter-domain optimization which requires communication between the PCE's? 3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)? =20 Many thanks, =20 David Amzallag BT =20 ------_=_NextPart_001_01C8D2A6.F3DC4D9D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dan,
 
Many thanks for your fast reply. Are you = familiar with=20 any "real-time" implementation of few of the PCE ideas? Anyone that = implements=20 the distributed approach?
 
Warm regards,
 
David Amzallag,
BT

From: Daniel King = [mailto:dk@danielking.net]=20
Sent: 19 June 2008 12:50
To:=20 pce@ietf.org
Subject: RE: [Pce] Concurrent Optimization and=20 More

Hi David,=20

 

A few quick = responses:

 

>>1. = How does=20 the protocol for computing a single path works in a hierarchical = network=20 (more than one level of PCE's)?

 

So far this = requirement has been out of scope for the current work. There is growing = momentum in the application of PCE to multi-layer networks, ASON, and=20 "domain-paths." So this topic will require further thought and=20 discussion.

 

>>2. = What the=20 draft for the concurrent optimization referred to: only inside of a = sub-domain=20 or also an inter-domain optimization which requires communication = between the=20 PCE's?

 

As above. = The=20 pce-global-concurrent-optimization draft focuses on single domain = optimisation,=20 specifically the PCC-PCE communication needs and protocol extensions to = support=20 the concurrent optimisation. Although, the authors do mention that a = Global=20 Concurrent Optimization (GCO) is applicable to a Virtual Network = Topology (VNT)=20 and multi-layer traffic engineering for new deployments. =

 

>>3. = Can we=20 assume that the node's demands are splittable (i.e., can be = simultaneously=20 satisfied by more than one path)?

 

I may need = some=20 further clarity on this question. Do you mean that there may be more = than one=20 possible solution to a path computation, or that the solution to the = computation=20 may be a set of "parallel" paths with some assumption of load sharing = (e.g.=20 inverse multiplexing)?

 

The answer = to the=20 first question is yes and is already done, although some work might be = required=20 to allow the PCE to supply a choice of paths to the = PCC.

 

The answer = to the=20 second question is also yes, but (very simple) protocol extensions will = be=20 needed to handle this case.

 

Other = relevant drafts=20 you may find interesting for this topic include:

 

A Path = Computation=20 Element (PCE)-Based Architecture

http://www.ietf.org/rfc/rfc4= 655.txt

 

A Framework = for=20 Inter-Domain Multiprotocol Label Switching Traffic=20 Engineering

http://www.ietf.org/rfc/rfc4= 726.txt

 

A = Per-Domain Path=20 Computation Method for Establishing Inter-Domain Traffic Engineering = (TE) Label=20 Switched Paths (LSPs)

http://www.ietf.org/rfc/rfc5= 152.txt

 

Evaluation = of=20 existing GMPLS Protocols against Multi Layer and Multi Region Networks=20 (MLN/MRN)

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln= -eval-05.txt

 

A Backward = Recursive=20 PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained=20 Inter-domain Traffic Engineering Label Switched = Paths

h= ttp://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt

 

Br,=20 Dan

 

 

From:=20 pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of=20 david.amzallag@bt.com
Sent: 19 June 2008 = 07:25
To:=20 pce@ietf.org
Subject: [Pce] Concurrent Optimization and=20 More

 

Hi,

 

I have = three basic=20 questions (but I might the correct place in RFCs or drafts for=20 that...);

 

1. How = does the=20 protocol for computing a single path works in a hierarchical = network (more=20 than one level of PCE's)?
2. What the draft for the concurrent = optimization=20 referred to: only inside of a sub-domain or also an inter-domain = optimization=20 which requires communication between the PCE's?

3. Can we = assume=20 that the node's demands are splittable (i.e., can be simultaneously = satisfied by=20 more than one path)?

 

Many=20 thanks,

 

David=20 Amzallag

BT

 

------_=_NextPart_001_01C8D2A6.F3DC4D9D-- --===============0618894619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0618894619==-- From pce-bounces@ietf.org Fri Jun 20 01:15:43 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D3E3A695A; Fri, 20 Jun 2008 01:15:43 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538443A6904 for ; Fri, 20 Jun 2008 01:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0kPDdBwKruk for ; Fri, 20 Jun 2008 01:15:34 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 945D53A68F4 for ; Fri, 20 Jun 2008 01:15:33 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so396438and.122 for ; Fri, 20 Jun 2008 01:15:34 -0700 (PDT) Received: by 10.100.46.10 with SMTP id t10mr4891602ant.22.1213949733668; Fri, 20 Jun 2008 01:15:33 -0700 (PDT) Received: from Serenity ( [88.97.23.122]) by mx.google.com with ESMTPS id c27sm3727578ana.37.2008.06.20.01.15.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Jun 2008 01:15:32 -0700 (PDT) From: "Daniel King" To: References: <002701c8d1f1$e7aa4b80$b6fee280$@net> <0D63518CCAD12D479B4C66FE4572D78D035D7082@E03MVW2-UKDY.domain1.systemhost.net> In-Reply-To: <0D63518CCAD12D479B4C66FE4572D78D035D7082@E03MVW2-UKDY.domain1.systemhost.net> Date: Fri, 20 Jun 2008 09:15:42 +0100 Message-ID: <002201c8d2ad$d6a0d9a0$83e28ce0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjR1SVOYXa7NpiiQlqiI9RX22M6nAAG9VTQABwzIZAAEgDVcA== Content-Language: en-gb Subject: Re: [Pce] Concurrent Optimization and More X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484297711==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multipart message in MIME format. --===============0484297711== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C8D2B6.386541A0" Content-Language: en-gb This is a multipart message in MIME format. ------=_NextPart_000_0023_01C8D2B6.386541A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi David, Aha ,"real-time". Well as we know real-time is relative. We talked previously about the PCE GCO application. Performing a GCO, via an NMS on a centralized PCE, on a complex network might require 6hrs of computation time. This could be considered real-time and perhaps is an acceptable amount of time to wait for a near-optimal solution. Another scenario might be performing path computation for a local backup path after an existing backup path fails. A local backup path solution could be required within a few seconds and computed via a distributed PCE that has local network knowledge. Both scenarios would require a real-time view (topology, services and resources) of the network at the time of the path computation request. The mechanisms are in place to support these architectures and I am aware of vendors implementing some of these ideas. We should not mention specific vendors on the WG mailing list. I am compiling a list of PCE vendors and implementers at: www.pathcomputationelement.com. Any vendors not currently listed are welcome to contact me and add their name and information. Br, Dan. From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of david.amzallag@bt.com Sent: 20 June 2008 08:26 To: pce@ietf.org Subject: Re: [Pce] Concurrent Optimization and More Dan, Many thanks for your fast reply. Are you familiar with any "real-time" implementation of few of the PCE ideas? Anyone that implements the distributed approach? Warm regards, David Amzallag, BT _____ From: Daniel King [mailto:dk@danielking.net] Sent: 19 June 2008 12:50 To: pce@ietf.org Subject: RE: [Pce] Concurrent Optimization and More Hi David, A few quick responses: >>1. How does the protocol for computing a single path works in a hierarchical network (more than one level of PCE's)? So far this requirement has been out of scope for the current work. There is growing momentum in the application of PCE to multi-layer networks, ASON, and "domain-paths." So this topic will require further thought and discussion. >>2. What the draft for the concurrent optimization referred to: only inside of a sub-domain or also an inter-domain optimization which requires communication between the PCE's? As above. The pce-global-concurrent-optimization draft focuses on single domain optimisation, specifically the PCC-PCE communication needs and protocol extensions to support the concurrent optimisation. Although, the authors do mention that a Global Concurrent Optimization (GCO) is applicable to a Virtual Network Topology (VNT) and multi-layer traffic engineering for new deployments. >>3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)? I may need some further clarity on this question. Do you mean that there may be more than one possible solution to a path computation, or that the solution to the computation may be a set of "parallel" paths with some assumption of load sharing (e.g. inverse multiplexing)? The answer to the first question is yes and is already done, although some work might be required to allow the PCE to supply a choice of paths to the PCC. The answer to the second question is also yes, but (very simple) protocol extensions will be needed to handle this case. Other relevant drafts you may find interesting for this topic include: A Path Computation Element (PCE)-Based Architecture http://www.ietf.org/rfc/rfc4655.txt A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering http://www.ietf.org/rfc/rfc4726.txt A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) http://www.ietf.org/rfc/rfc5152.txt Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-05.txt A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt Br, Dan From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of david.amzallag@bt.com Sent: 19 June 2008 07:25 To: pce@ietf.org Subject: [Pce] Concurrent Optimization and More Hi, I have three basic questions (but I might the correct place in RFCs or drafts for that...); 1. How does the protocol for computing a single path works in a hierarchical network (more than one level of PCE's)? 2. What the draft for the concurrent optimization referred to: only inside of a sub-domain or also an inter-domain optimization which requires communication between the PCE's? 3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)? Many thanks, David Amzallag BT ------=_NextPart_000_0023_01C8D2B6.386541A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

Aha ,“real-time”. Well as we know real-time = is relative. We talked previously about the PCE GCO application. Performing = a GCO, via an NMS on a centralized PCE, on a complex network might require 6hrs = of computation time. This could be considered real-time and perhaps is an acceptable = amount of time to wait for a near-optimal solution. Another scenario might be = performing path computation for a local backup path after an existing backup path = fails. A local backup path solution could be required within a few seconds and = computed via a distributed PCE that has local network knowledge. Both scenarios = would require a real-time view (topology, services and resources) of the = network at the time of the path computation request.  The mechanisms are in = place to support these architectures and I am aware of vendors implementing some = of these ideas.

 

We should not mention specific vendors on the WG mailing = list. I am compiling a list of PCE vendors and implementers at: www.pathcomputationelement= .com. Any vendors not currently listed are welcome to contact me and add their = name and information.

 

Br, Dan.

 

 

From: pce-bounces@ietf.org = [mailto:pce-bounces@ietf.org] On Behalf Of david.amzallag@bt.com
Sent: 20 June 2008 08:26
To: pce@ietf.org
Subject: Re: [Pce] Concurrent Optimization and = More

 

Dan,

 

Many thanks for your fast reply. Are you familiar with any "real-time" implementation of few of the PCE ideas? Anyone = that implements the distributed approach?

 

Warm regards,

 

David Amzallag,

BT

 

From:= Daniel King [mailto:dk@danielking.net]
Sent: 19 June 2008 12:50
To: pce@ietf.org
Subject: RE: [Pce] Concurrent Optimization and More

Hi David,

 

A few quick responses:

 

>>1. How does the protocol for computing a single path works in a = hierarchical network (more than one level of PCE's)?

 

So far this requirement has been out of scope for the current work. There = is growing momentum in the application of PCE to multi-layer networks, = ASON, and "domain-paths." So this topic will require further thought and discussion.

 

>>2. What the draft for the concurrent optimization referred to: only inside = of a sub-domain or also an inter-domain optimization which requires = communication between the PCE's?

 

As above. The pce-global-concurrent-optimization draft focuses on single = domain optimisation, specifically the PCC-PCE communication needs and protocol extensions to support the concurrent optimisation. Although, the authors = do mention that a Global Concurrent Optimization (GCO) is applicable to a = Virtual Network Topology (VNT) and multi-layer traffic engineering for new = deployments.

 

>>3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)?

 

I may need some further clarity on this question. Do you mean that there = may be more than one possible solution to a path computation, or that the = solution to the computation may be a set of "parallel" paths with some = assumption of load sharing (e.g. inverse multiplexing)?

 

The answer to the first question is yes and is already done, although some = work might be required to allow the PCE to supply a choice of paths to the = PCC.

 

The answer to the second question is also yes, but (very simple) protocol extensions will be needed to handle this case.

 

Other relevant drafts you may find interesting for this topic = include:

 

A Path Computation Element (PCE)-Based Architecture

http://www.ietf.org/rfc/rfc4= 655.txt

 

A Framework for Inter-Domain Multiprotocol Label Switching Traffic = Engineering

http://www.ietf.org/rfc/rfc4= 726.txt

 

A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)

http://www.ietf.org/rfc/rfc5= 152.txt

 

Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region = Networks (MLN/MRN)

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln= -eval-05.txt

 

A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute = Shortest Constrained Inter-domain Traffic Engineering Label Switched = Paths

h= ttp://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt

 

Br, Dan

 

 

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = david.amzallag@bt.com
Sent: 19 June 2008 07:25
To: pce@ietf.org
Subject: [Pce] Concurrent Optimization and = More

 

Hi,<= o:p>

 

I have three basic questions (but I might the correct place in RFCs or = drafts for that...);

 

1. How does the protocol for computing a single path works in a = hierarchical network (more than one level of PCE's)?
2. What the draft for the concurrent optimization referred to: only = inside of a sub-domain or also an inter-domain optimization which requires = communication between the PCE's?

3. Can we assume that the node's demands are splittable (i.e., can be simultaneously satisfied by more than one path)?

 

Many thanks,

 

David Amzallag

BT

 =

------=_NextPart_000_0023_01C8D2B6.386541A0-- --===============0484297711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0484297711==-- From pce-bounces@ietf.org Fri Jun 20 03:30:03 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7063A3A6A33; Fri, 20 Jun 2008 03:30:03 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 28D7F3A6A37; Fri, 20 Jun 2008 03:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080620103002.28D7F3A6A37@core3.amsl.com> Date: Fri, 20 Jun 2008 03:30:02 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-manageability-requirements-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Inclusion of Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-04.txt Pages : 12 Date : 2008-06-20 It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-manageability-requirements-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-manageability-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-20031821.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jun 24 10:30:05 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5BB3A691B; Tue, 24 Jun 2008 10:30:05 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F4213A6860; Tue, 24 Jun 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080624173001.8F4213A6860@core3.amsl.com> Date: Tue, 24 Jun 2008 10:30:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-global-concurrent-optimization-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-ietf-pce-global-concurrent-optimization-03.txt Pages : 30 Date : 2008-06-24 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. A GCO may also be applied to some subset of the LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-optimization-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-global-concurrent-optimization-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-24102836.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Tue Jun 24 10:43:57 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B613A68E4; Tue, 24 Jun 2008 10:43:57 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668553A68E4 for ; Tue, 24 Jun 2008 10:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMPfSQFt0h76 for ; Tue, 24 Jun 2008 10:43:23 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 57BB63A67F6 for ; Tue, 24 Jun 2008 10:43:23 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K2Z0067BAKBOL@usaga04-in.huawei.com> for pce@ietf.org; Tue, 24 Jun 2008 12:43:24 -0500 (CDT) Received: from L73682 ([10.124.12.97]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2Z00BIBAK6XW@usaga04-in.huawei.com> for pce@ietf.org; Tue, 24 Jun 2008 12:43:23 -0500 (CDT) Date: Tue, 24 Jun 2008 12:43:18 -0500 From: Young Lee To: 'JP Vasseur' , "'Adrian@OldDog'" Message-id: <000201c8d621$ca7ccae0$610c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_717/YjrYpwRB0aoPO0FZRQ)" Thread-index: AcjWIcl7dyOepOI9Q4i87W9QabE0WA== Cc: pce@ietf.org Subject: [Pce] PCE GCO update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_717/YjrYpwRB0aoPO0FZRQ) Content-type: multipart/alternative; boundary="Boundary_(ID_zdIGGy1PvJXdbdL2xor57w)" --Boundary_(ID_zdIGGy1PvJXdbdL2xor57w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi J-P and Adrian, Here's the update of PCE GCO draft. As per requested in Philadelphia, this is ready for the WG chair's review and the last call. Please note section 9 for IANA considerations and new objects/TLV/Flags have been defined. I'd appreciate your review and look forward to making progress on this work to the next stage. Thanks. I snipped Section 9 below. Thanks. Regards, Young -----------snipped---------------------------------------- 9. IANA Considerations IANA maintains a registry of PCEP parameters. IANA is requested to make allocations from the sub-registries as described in the following sections. 9.1. Request Parameter Bit Flags As described in Section 5.3, two new bit lfags are defined for inclusion in the Flags field of the RP object. IANA is requested to make the following allocations from the "Request Parameter Bit Flags" sub-registry. Bit Name Description Reference 11 D-bit Report the request order [This.I-D] 12 M-bit Make-before-break [This.I-D] 9.2. New PCEP TLV As described in Section 5.4, a new PCEP TLV is defined to indicate the setup and delete order of LSPs in a GCO. IANA is requested to make the following allocation from the "PCEP TLV Types" sub-registry. TLV Type Meaning Reference 5 Order TLV [This.I-D] 9.3. New PCEP Object As descried in Section 5.5, a new PCEP object is defined to carry global constraints. IANA is requested to make the following allocation from the "PCEP Objects" sub-registry. Object Name Reference Class 24 GLOBAL-CONSTRAINTS [This.I-D] Object-Type 1: Global Constraints [This.I-D] 9.4. New PCEP Error Codes As described in Section 5.6, new PCEP error codes are defined for GCO errors. IANA is requested to make allocations from the "PCEP Error Types and Values" sub-registry as set out in the following sections. 9.4.1. New Error-Values for Existing Error-Types Error Type Meaning Reference 5 Policy violation Error-value=5: [This.I-D] Global concurrent optimization not allowed 9.4.2. New Error-Types and Error-Values Error Type Meaning Reference 15 Global Concurrent Optimization Error [This.I-D] Error-value=1: Insufficient memory [This.I-D] Error-value=2: Global concurrent optimization not supported [This.I-D] 9.5. New No-Path Reasons IANA is requested to make the following allocations from the "No-Path Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV in the PCEP NO-PATH object as described in Section 5.7. Bit Number Name Reference 6 No GCO migration path found [This.I-D] 7 No GCO solution found [This.I-D] --Boundary_(ID_zdIGGy1PvJXdbdL2xor57w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi J-P and Adrian, =

 

Here’s the update of PCE GCO draft. As per = requested in Philadelphia, this is ready for the WG chair’s review and the last call. Please = note section 9 for IANA considerations and new objects/TLV/Flags have been = defined. I’d appreciate your review and look forward to making progress on this work = to the next stage. Thanks.

 

I snipped Section 9 below. = Thanks.

 

Regards,

Young

-----------snipped------------------------------------= ----

 

9.  IANA = Considerations

 

   IANA = maintains a registry of PCEP parameters.  IANA is requested = to

   make allocations from the sub-registries as described in = the

   = following sections.

 

9.1.  Request = Parameter Bit Flags

 

   As = described in Section 5.3, two new bit lfags are defined = for

   = inclusion in the Flags field of the RP object.  IANA is requested = to

   make = the following allocations from the "Request Parameter Bit = Flags"

   = sub-registry.

 

 

   Bit      Name    Description          &n= bsp;         Reference

 

   11       D-bit   Report the = request order       = [This.I-D]

   12       M-bit   Make-before-break         &n= bsp;    [This.I-D]

 

 

9.2.  New PCEP = TLV

 

   As = described in Section 5.4, a new PCEP TLV is defined to = indicate

   the = setup and delete order of LSPs in a GCO.  IANA is requested = to

   make = the following allocation from the "PCEP TLV Types" = sub-registry.

 

 

   TLV Type        Meaning           =       Reference

 

   5            =    Order TLV           &nbs= p;   [This.I-D]

 

 

9.3.  New PCEP = Object

 

   As = descried in Section 5.5, a new PCEP object is defined to = carry

   global constraints.  IANA is requested to make the = following

   = allocation from the "PCEP Objects" sub-registry.

 

 

   = Object  Name           &nb= sp;           &nbs= p;                    R= eference

   = Class

 

   24            = ;  GLOBAL-CONSTRAINTS         &= nbsp;            [This.I-D]

           &= nbsp;           Object-Type

           &= nbsp;          1: Global Constraints          &n= bsp;     [This.I-D]

 

9.4.  New PCEP = Error Codes

 

   As = described in Section 5.6, new PCEP error codes are defined for = GCO

   = errors.  IANA is requested to make allocations from the "PCEP = Error

   Types = and Values" sub-registry as set out in the following = sections.

 

9.4.1.  New Error-Values for Existing Error-Types

 

 

   = Error

   Type    Meaning           =             &= nbsp;           &n= bsp;        Reference

 

   5            =    Policy violation

           &= nbsp;           &n= bsp;   Error-value=3D5:         &nb= sp;           [This.I-D]

           &= nbsp;       Global concurrent optimization not allowed

 

 

9.4.2.  New = Error-Types and Error-Values

 

 

   = Error

   Type    = Meaning           =             &= nbsp;           &n= bsp;        Reference

 

   15            = ;  Global Concurrent Optimization Error       [This.I-D]

           &= nbsp;       Error-value=3D1:

           &= nbsp;       Insufficient memory           &= nbsp;            [This.I-D]

           &= nbsp;       Error-value=3D2:

           &= nbsp;       Global concurrent optimization not = supported

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;  [This.I-D]

 

 

9.5.  New = No-Path Reasons

 

   IANA = is requested to make the following allocations from the = "No-Path

   = Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR = TLV

   in the = PCEP NO-PATH object as described in Section 5.7.

 

   = Bit

   Number          Name           &nb= sp;           &nbs= p; Reference

 

   6            =    No GCO migration path found  = [This.I-D]

   7            =    No GCO solution found        = [This.I-D]

 

--Boundary_(ID_zdIGGy1PvJXdbdL2xor57w)-- --Boundary_(ID_717/YjrYpwRB0aoPO0FZRQ) Content-type: text/plain; name=draft-ietf-pce-global-concurrent-optimization-03.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-pce-global-concurrent-optimization-03.txt Network Working Group Y. Lee Internet-Draft Huawei Intended status: Standards Track JL. Le Roux Expires: December 26, 2008 France Telecom D. King Aria Networks E. Oki NTT June 24, 2008 Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization draft-ietf-pce-global-concurrent-optimization-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 26, 2008. Lee, et al. Expires December 26, 2008 [Page 1] Internet-Draft PCE Global Concurrent Optimization June 2008 Abstract The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. A GCO may also be applied to some subset of the LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. Lee, et al. Expires December 26, 2008 [Page 2] Internet-Draft PCE Global Concurrent Optimization June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Applicability of Global Concurrent Optimization (GCO) . . . . 7 3.1. Application of the PCE Architecture . . . . . . . . . . . 7 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 3.3. Greenfield Optimization . . . . . . . . . . . . . . . . . 9 3.3.1. Single-layer Traffic Engineering . . . . . . . . . . . 10 3.3.2. Multi-layer Traffic Engineering . . . . . . . . . . . 10 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol extensions for support of global concurrent optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Global Objective Function (GOF) Specification . . . . . . 15 5.2. Indication of Global Concurrent Optimization Requests . . 16 5.3. Request for the order of LSP . . . . . . . . . . . . . . . 16 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20 6. Manageability Considerations . . . . . . . . . . . . . . . . . 21 6.1. Control of Function and Policy . . . . . . . . . . . . . . 21 6.2. Information and Data Models, e.g. MIB module . . . . . . . 21 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21 6.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 22 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 25 9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 25 9.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 25 9.4. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 26 9.4.1. New Error-Values for Existing Error-Types . . . . . . 26 9.4.2. New Error-Types and Error-Values . . . . . . . . . . . 26 9.5. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Lee, et al. Expires December 26, 2008 [Page 3] Internet-Draft PCE Global Concurrent Optimization June 2008 1. Introduction [RFC4655] defines the Path Computation Element (PCE) based Architecture and explains how a PCE may compute Label Switched Paths (LSP) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks at the request of Path Computation Clients (PCCs). A PCC is shown to be any network component that makes such a request and may be for instance a Label Switching Router (LSR) or a Network Management System (NMS). The PCE, itself, is shown to be located anywhere within the network, and may be within an LSR, an NMS or Operational Support System (OSS), or may be an independent network server. The PCE Communication Protocol (PCEP) is the communication protocol used between PCC and PCE, and may also be used between cooperating PCEs. [RFC4657] sets out generic protocol requirements for PCEP. Additional application-specific requirements for PCEP are defined in separate documents. This document provides a set of requirements and PCEP extensions in support of concurrent path computation applications. A concurrent path computation is a path computation application where a set of TE paths are computed concurrently in order to efficiently utilize network resources. The computation method involved with a concurrent path computation is referred to as global concurrent optimization in this document. Appropriate computation algorithms to perform this type of optimization are out of the scope of this document. The Global Concurrent Optimization (GCO) application is primarily an NMS or a PCE Server based solution. Owing to complex synchronization issues associated with GCO applications, the management based PCE architecture defined in section 5.5 of [RFC4655] is considered as the most suitable usage to support GCO application. This does not preclude other architectural alternatives to support GCO application, but they are NOT RECOMMENDED. For instance, GCO might be enabled by distributed LSRs through complex synchronization mechanisms. However, this approach might suffer from significant synchronization overhead between the PCE and each of the PCCs. It would likely affect the network stability and hence significantly diminish the benefits of deploying PCEs. As new LSPs are added or removed from the network over time, the global network resources become fragmented and the existing placement of LSPs within network no longer provides optimal use of the available capacity. A global concurrent path computation is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs and their respective constraints, and look to re-optimize the entire network to satisfy all constraints for Lee, et al. Expires December 26, 2008 [Page 4] Internet-Draft PCE Global Concurrent Optimization June 2008 all LSPs. Alternatively, the application may consider a subset of the LSPs and/or a subset of the network topology. The need for global concurrent path computation may also arise when network operators need to establish a set of TE LSPs in their network planning process. It is also envisioned that network operators might require global concurrent path computation in the event of catastrophic network failures, where a set of TE LSPs need to be optimally rerouted. The nature of this work promote the use of such systems for offline processing. Online application of this work should only be considered with proven empirical validation. As the PCE has the potential to provide solutions in all path computation solutions in a variety of environments and is a candidate for performing path computations in support of GCO. The main focus of this document is to highlight the PCC-PCE communication needs in support of a concurrent path computation applications and to define protocol extensions to meet those needs. The PCC-PCE requirements addressed herein are specific to the context where the PCE is a specialized PCE that is capable of performing computations in support of GCO. Discovery of such capabilities might be desirable and could be achieved through extensions to the PCE discovery mechanisms [RFC4674], [RFC5058], [RFC5059], but that is out of the scope of this document. It is to be noted that BRPC [BRPC] is a multi-PCE path computation technique used to compute a shortest constrained inter-domain path wheres this ID specifies a technique where a set of path computation requests are bundled and send to a PCE with the objective of "optimizing" the set of computed paths. Lee, et al. Expires December 26, 2008 [Page 5] Internet-Draft PCE Global Concurrent Optimization June 2008 2. Terminology Most of the terminology used in this document is explained in [RFC4655]. A few key terms are repeated here for clarity. PCC: Path Computation Client: Any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: An entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TED: Traffic Engineering Database which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. PCECP: The PCE Communication Protocol: PCECP is the generic abstract idea of a protocol that is used to communicate path computation requests a PCC to a PCE, and to return computed paths from the PCE to the PCC. The PCECP can also be used between cooperating PCEs. PCEP: The PCE communication Protocol: PCEP is the actual protocol that implements the PCECP idea. GCO: Global Concurrent Optimization: A concurrent path computation application where a set of TE paths are computed concurrently in order to efficiently utilize network resources. A GCO path computation is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. A GCO path computation can also provide an optimal way to migrate from an existing set of LSPs to a reoptimized set (Morphing Problem). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These terms are also used in the parts of this document that specify requirements for clarity of specification of those requirements. Lee, et al. Expires December 26, 2008 [Page 6] Internet-Draft PCE Global Concurrent Optimization June 2008 3. Applicability of Global Concurrent Optimization (GCO) This section discusses the PCE architecture to which GCO is applied. It also discusses various application scenarios for which global concurrent path computation may be applied. 3.1. Application of the PCE Architecture Figure 1 shows the PCE-based network architecture as defined in [RFC4655] to which GCO application is applied. It must be observed that the PCC is not necessarily an LSR [RFC4655]. The GCO application is primarily an NMS-based solution in which an NMS plays the function of the PCC. Although Figure 1 shows the PCE as remote from the NMS, it might be collocated with the NMS. Note that in the collocated case there is no need for a standard communication protocol, this can rely on internal APIs. ----------- Application | ----- | Request | | TED | | | | ----- | v | | | ------------- Request/ | v | | PCC | Response| ----- | | (NMS/Server)|<--------+> | PCE | | | | | ----- | ------------- ----------- Service | Request | v ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<---------->| Node | ---------- ---------- Figure 1: PCE-Based Architecture for Global Concurrent Optimization Upon receipt of an application request (e.g., a traffic demand matrix is provided to the NMS by the operator's network planning procedure), the NMS requests a global concurrent path computation from the PCE. The PCE then computes the requested paths concurrently applying some algorithms. When the requested path computation completes, the PCE sends the resulting paths back to the NMS. The NMS then supplies the Lee, et al. Expires December 26, 2008 [Page 7] Internet-Draft PCE Global Concurrent Optimization June 2008 head-end LSRs with a fully computed explicit path for each TE LSP that needs to be established. 3.2. Re-optimization of Existing Networks The need for global concurrent path computation may arise in existing networks. When an existing TE LSP network experiences sub-optimal use of its resources, the need for re-optimization or reconfiguration may arise. The scope of re-optimization and reconfiguration may vary depending on particular situations. The scope of re-optimization may be limited to bandwidth modification to an existing TE LSP. However, it could well be that a set of TE LSPs may need to be re-optimized concurrently. In an extreme case, the TE LSPs may need to be globally re-optimized. In loaded networks, with large size LSPs, a sequential re- optimization may not produce substantial improvements in terms of overall network optimization. The potential for network-wide gains from reoptimization of LSPs sequentially is dependent upon the network usage and size of the LSPs being optimized. However, the key point remains: computing the reoptimized path of one LSP at a time with giving no consideration to the other LSPs in the network could result in sub-optimal use of network resources. This may be far more visible in an optical network with a low ratio of potential LSPs per link, and far less visible in packet networks with micro-flow LSPs. With regards to applicability of GCO in the event of catastrophic failures, there may be a real benefit in computing the paths of the LSPs as a set rather than computing new paths from the head-end LSRs in a distributed manner. It is to be noted, however, that a centralized system will typically suffer from a slower response time than a distributed system. 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) Reconfiguration of the VNT [MLN-REQ] is a typical application scenario where global concurrent path computation may be applicable. Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes, may require a set of existing LSPs to be re-computed. 3.2.2. Traffic Migration When migrating from one set of TE LSPs to a reoptimized set of TE LSPs it is important that the traffic be moved without causing disruption. Various techniques exist in MPLS and GMPLS, such as make-before-break [RFC3209], to establish the new LSPs before tearing down the old LSPs. When multiple LSP routes are changed according to Lee, et al. Expires December 26, 2008 [Page 8] Internet-Draft PCE Global Concurrent Optimization June 2008 the computed results, some of the LSPs may be disrupted due to the resource constraints. In other words, it may prove to be impossible to perform a direct migration from the old LSPs to the new optimal LSPs without disrupting traffic because there are insufficient network resources to support both sets of LSPs when make-before-break is used. However, the PCE may be able to determine an order of LSP rerouting actions so that make-before-break can be performed within the limited resources. It may be the case that the reoptimization is radical. This could mean that it is not possible to apply make-before-break in any order to migrate from the old LSPs to the new LSPs. In this case a migration strategy is required that may necessitate LSPs being rerouted using make-before-break onto temporary paths in order to make space for the full reoptimization. A PCE might indicate the order in which reoptimized LSPs must be established and take over from the old LSPs, and may indicate a series of different temporary paths that must be used. Alternatively, the PCE might perform the global reoptimization as a series of sub-reoptimizations by reoptimizing subsets of the total set of LSPs. The benefit of this multi-step rerouting includes minimization of traffic discruption and optimization gain. However this approach may imply some transient packets desequencing, jitter as well as control plane stress. Note also that during reoptimization, traffic disruption may be allowed for some LSPs carrying low priority services (e.g., Internet traffic) and not allowed for some LSPs carrying mission critical services (e.g., voice traffic). 3.3. Greenfield Optimization Greenfield optimization is a special case of GCO application when there is no LSP setup. Once the LSPs are setup, it is not a greenfield. The need for greenfield arises when network planner will want to make use of computation servers to plan the LSPs that will be provisioned in the network. When a new TE network needs to be provisioned from a green-field perspective, a set of TE LSPs need to be created based on traffic demand, network topology, service constraints, and network resources. Under this scenario, concurrent computation ability is highly desirable, or required, to utilize network resources in an optimal manner and avoid blocking risks. Lee, et al. Expires December 26, 2008 [Page 9] Internet-Draft PCE Global Concurrent Optimization June 2008 3.3.1. Single-layer Traffic Engineering Greenfield optimization can be applied when layer-specific TE LSPs need to be created from a green-field perspective. For example, MPLS-TE network can be established based on layer 3 specific traffic demand, network topology, and network resources. Greenfield optimization for single-layer traffic engineering can be applied to optical transport networks such as SDH/Sonet, Ethernet Transport, WDM, etc. 3.3.2. Multi-layer Traffic Engineering Greenfield optimization is not limited to single-layer traffic engineering. It can also be applied to multi-layer traffic engineering. Both the client and the server layers network resources and topology can be considered simultaneously in setting up a set of TE LSPs that traverse the layer boundary. Lee, et al. Expires December 26, 2008 [Page 10] Internet-Draft PCE Global Concurrent Optimization June 2008 4. PCECP Requirements This section provides the PCECP requirements to support global concurrent path computation applications. The requirements specified here should be regarded as application-specific requirements and are justifiable based on the extensibility clause found in section 6.1.14 of [RFC4657]: The PCECP MUST support the requirements specified in the application-specific requirements documents. The PCECP MUST also allow extensions as more PCE applications will be introduced in the future. It is also to be noted that some of the requirements discussed in this section have already been discussed in the PCECP requirement document [RFC4657]. For example, Section 5.1.16 in [RFC4657] provides a list of generic constraints while Section 5.1.17 in [RFC4657] provides a list of generic objective functions that MUST be supported by the PCECP. While using such generic requirements as the baseline, this section provides application-specific requirements in the context of global concurrent path computation and in a more detailed level than the generic requirements. The PCEP SHOULD support the following capabilities either via creation of new objects and/or modification of existing objects where applicable. o An indicator to convey that the request is for a global concurrent path computation. This indicator is necessary to ensure consistency in applying global objectives and global constraints in all path computations. Note: This requirement is covered by "synchronized path computation" in [RFC4655] and [RFC4657]. However, an explicit indicator to request a global concurrent optimization is a new requirement. o A Global Objective Function (GOF) field in which to specify the global objective function. The global objective function is the overarching objective function to which all individual path computation requests are subjected in order to find a globally optimal solution. Note that this requirement is covered by "synchronized objective functions" in section 5.1.7 [RFC4657]. A list of available global objective functions SHOULD include the following objective functions at the minimum and SHOULD be expandable for future addition: * Minimize the sum of all TE LSP costs (min cost) Lee, et al. Expires December 26, 2008 [Page 11] Internet-Draft PCE Global Concurrent Optimization June 2008 * Evenly allocate the network load to achieve the most uniform link utilization across all links (this can be achieved by the following objective function: minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i. o A Global Constraints (GC) field in which to specify the list of global constraints to which all the requested path computations should be subjected. This list SHOULD include the following constraints at the minimum and SHOULD be expandable for future addition: * Maximum link utilization value -- This value indicates the highest possible link utilization percentage set for each link. (Note: to avoid floating point numbers, the values should be integer values.) * Minimum link utilization value -- This value indicates the lowest possible link utilization percentage set for each link. (Note: same as above) * Overbooking Factor -- The overbooking factor allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. * Maximum number of hops for all the LSPs -- This is the largest number of hops that any LSP can have. Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * Exclusion of links/nodes in all LSP path computation (i.e., all LSPs should not include the specified links/nodes in their paths). Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * An indication should be available in a path computation response that further reoptimization may only become available once existing traffic has been moved to the new LSPs. o A Global Concurrent Vector (GCV) field in which to specify all the individual path computation requests that are subject to concurrent path computation and subject to the global objective function and all of the global constraints. Note that this requirement is entirely fulfilled by the SVEC object in the PCEP specification [PCEP]. Since the SVEC object as defined in [PCEP] allows identifying a set of concurrent path requests, the SVEC can be reused to specify all the individual concurrent path requests Lee, et al. Expires December 26, 2008 [Page 12] Internet-Draft PCE Global Concurrent Optimization June 2008 for a global concurrent optimization. o An indicator field in which to indicate the outcome of the request. When the PCE could not find a feasible solution with the initial request, the reason for failure SHOULD be indicated. This requirement is partially covered by [RFC4657], but not in this level of detail. The following indicators SHOULD be supported at the minimum: * no feasible solution found. Note that this is already covered in [PCEP]. * memory overflow * PCE too busy. Note that this is already covered in [PCEP]. * PCE not capable of concurrent reoptimization * no migration path available * administrative privileges do not allow global reoptimization o In order to minimize disruption associated with bulk path provisioning, the following requirements MUST be supported: * The request message MUST allow requesting the PCE to provide the order in which LSPs should be reoptimized (i.e., the migration path) in order to minimize traffic disruption during the migration. That is the request message MUST allow indicating to the PCE that the set of paths that will be provided in the response message (PCRep) has to be ordered. * In response to the "ordering" request from the PCC, the PCE MUST be able to indicate in the response message (PCRep) the order in which LSPs should be reoptimized so as to minimize traffic disruption. It should indicate for each request the order in which the old LSP should be removed and the order in which the new LSP should be setup. If the removal order is lower than the setup order this means that make-before-break cannot be done for this request. It might also be desirable to have the PCE indicate whether ordering is in fact required or not. * As stated in RFC 4657, the request for a reoptimization MUST support the inclusion of the set of previously computed paths along with their bandwidth. This is to avoid double bandwidth accounting and also this allows running an algorithm that minimizes perturbation and that can compute a migration path Lee, et al. Expires December 26, 2008 [Page 13] Internet-Draft PCE Global Concurrent Optimization June 2008 (LSP setup/removal orders). This is particularly required for stateless PCEs. * During a migration it may not be possible to do a make-before- break for all existing LSPs. The request message must allow indicating for each request whether make-before-break is required (e.g. Voice traffic) or break-before-make is acceptable (e.g. Internet traffic). The response message must allow indicating LSPs for which make-before-break reoptimization is not possible (this will be deduced from the LSP setup and deletion orders). Lee, et al. Expires December 26, 2008 [Page 14] Internet-Draft PCE Global Concurrent Optimization June 2008 5. Protocol extensions for support of global concurrent optimization This section provides protocol extensions for support of global concurrent optimization. Protocol extensions discussed in this section are built on [PCEP]. The format of a PCReq message after incorporating new requirements for support of global concurrent optimization is as follows: ::= [] The is changed as follows: :: = [] [] [] [] Note that three optional objects are added, following the SVEC object: the OF (Objective Function) object, which is defined in [PCE-OF], the GC (Global Constraints) object, which is defined in this document (section 5.5), as well as the eXclude Route Object (XRO) which is defined in [PCE-XRO]. Details of this change will be discussed in the following sections. Note also that when the XRO is global to a SVEC, and F bit is set, it should be allowed to specify multiple RRO objects in the PCReq message. 5.1. Global Objective Function (GOF) Specification The global objective function can be specified in the PCEP Objective Function (OF) object, defined in [PCE-OF]. The OF object includes a 16 bit Objective Function identifier. As per discussed in [PCE-OF], objective function identifier code points are managed by IANA. Two global objective functions defined in [PCE-OF] are used in the context of GCO. Lee, et al. Expires December 26, 2008 [Page 15] Internet-Draft PCE Global Concurrent Optimization June 2008 Function Code Description 5 Minimize the load of the Most Loaded Link (MLL) 6 Minimize Cumulative Cost of a set of paths (MCC) * Note: This can be achieved by the following objective function: minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i.) 5.2. Indication of Global Concurrent Optimization Requests All the path requests in this application should be indicated so that the global objective function and all of the global constraints are applied to each of the requested path computation. This can be indicated implicitly by placing the GCO related objects (GOF, GC or XRO) after the SVEC object. That is, if any of these objects follows the SVEC object in the PCReq message, all of the requested path computations specified in the SVEC object are subject to GOF, GC or XRO. 5.3. Request for the order of LSP In order to minimize disruption associated with bulk path provisioning, the PCC may indicate to the PCE that the response MUST be ordered. That is, the PCE has to include the order in which LSPs MUST be moved so as to minimize traffic disruption. To support such indication a new flag, the D flag, is defined in the RP object as follows: D bit (orDer - 1 bit): when set, in a PCReq message, the requesting PCC requires the PCE to specify in the PCRep message the order in which this particular path request is to be provisioned relative to other requests. To support the determination of whether make-before-break optimization is required, a new flag, the M flag, is defined in the RP object as follows. M bit (Make-before-break - 1 bit): when set, this indicates that a make-before-break reoptimization is required for this request. When M bit is not set, this implies that a break-before-make reoptimization is allowed for this request. Note that M bit can be set only if the R (Reoptimization) flag is set. Lee, et al. Expires December 26, 2008 [Page 16] Internet-Draft PCE Global Concurrent Optimization June 2008 5.4. The Order Response The PCE MUST specify the order number in response to the Order Request made by the PCC in the PCReq message if so requested by the setting of the D bit in the RP object in the PCReq message. To support such ordering indication a new optional TLV, the Order TLV, is defined in the RP object. The Order TLV is an optional TLV in the RP object, that indicates the order in which the old LSP must be removed and the new LSP must be setup during a reoptimization. It is carried in the PCRep message in response to a reoptimization request. The Order TLV SHOULD be included in the RP object in the PCRep message if the D bit is set in the RP object in the PCReq message. The format of the Order TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delete Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The Order TLV in the RP object in the PCRep Message Type: To be defined by IANA (suggested value = 5) Length: Variable Delete Order: 32 bit integer that indicates the order in which the old LSP should be removed Setup Order: 32 bit integer that indicates the order in which the new LSP should be setup The delete order should not be equal to the setup order. If the delete order is higher than the setup order, this means that the reoptimization can be done in a make-before-break manner, else it cannot be done in a make-before-break manner. Lee, et al. Expires December 26, 2008 [Page 17] Internet-Draft PCE Global Concurrent Optimization June 2008 For a new LSP the delete order is not applicable. The value 0 is designated to specify this case. When the value of the delete order is 0, it implies that the resulting LSP is a new LSP. To illustrate, consider a network with two established requests: R1 with path P1 and R2 with path P2. During a reoptimization the PCE may provide the following ordered reply: R1, path P1', remove order 1, setup order 4 R2, path P2', remove order 3, setup order 2 This indicates that the NMS should do the following sequence of tasks: 1: Remove path P1 2: Setup path P2' 3: Remove path P2 4: Setup path P1' That is, R1 is reoptimized in a break-before-make manner and R2 in a make-before-break manner. 5.5. GLOBAL CONSTRAINTS (GC) Object The Global Constraints (GC) Object is used in a PCReq message to specify the necessary global constraints that should be applied to all individual path computations for a global concurrent path optimization request. GLOBAL CONSTRAINT Object-Class is to be assigned by IANA (recommended value=24) GLOBAL CONSTRAINT Object-Type is to be assigned by IANA (recommended value=1) The format of the GC object body that includes the global constraints is as follows: Lee, et al. Expires December 26, 2008 [Page 18] Internet-Draft PCE Global Concurrent Optimization June 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MH | MU | mU | OB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: GC body object format MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop count for all the LSPs. MU (Max Utilization Percentage: 8 bits) : 8 bits integer that indicates the upper bound utilization percentage by which all link should be bound. Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link Capacity mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that indicates the lower bound utilization percentage by which all link should be bound. OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that indicates the overbooking percentage that allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. The value, for example, 10% means that 110 Mbps can be reserved on a 100Mbps link. Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be transmitted as zero and SHOULD be ignored upon receipt. The exclusion of the list of nodes/links from a global path computation can be done by including the XRO object following the GC object in the new SVEC list definition. 5.6. Error Indicator To indicate errors associated with the global concurrent path optimization request, a new Error-Type (14) and subsequent error- values are defined as follows for inclusion in the PCEP-ERROR object: A new Error-Type (15) and subsequent error-values are defined as follows: Lee, et al. Expires December 26, 2008 [Page 19] Internet-Draft PCE Global Concurrent Optimization June 2008 Error-Type=15 and Error-Value=1: if a PCE receives a global concurrent path optimization request and the PCE is not capable of the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP ERROR object (Error-Type=15) and an Error-Value (Error-Value=1). The corresponding global concurrent path optimization request MUST be cancelled. Error-Type=15; Error-Value=2: if a PCE receives a global concurrent path optimization request and the PCE is not capable of global concurrent optimization, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2). The corresponding global concurrent path optimization MUST be cancelled. To indicate an error associated with policy violation, a new error value "global concurrent optimization not allowed" should be added to an existing error code for policy violation (Error-Type=5) as defined in [PCEP]. Error-Type=5; Error-Value=5: if a PCE receives a global concurrent path optimization request which is not compliant with administrative privileges (i.e., the PCE policy does not support global concurrent optimization), the PCE sends a PCErr message with a PCEP-ERROR Object (Error-Type=5) and an Error-Value (Error-Value=5). The corresponding global concurrent path computation MUST be cancelled. 5.7. NO-PATH Indicator To communicate the reason(s) for not being able to find global concurrent path computation, the NO-PATH object can be used in the PCRep message. The format of the NO-PATH object body is defined in [PCEP]. The object may contain a NO-PATH-VECTOR TLV to provide additional information about why a path computation has failed. Two new bit flags are defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object. Bit 6: When set, the PCE indicates that no migration path was found. Bit 7: When set, the PCE indicates no feasible solution was found that meets all the constraints associated with global concurrent path optimization in the PCRep message. Lee, et al. Expires December 26, 2008 [Page 20] Internet-Draft PCE Global Concurrent Optimization June 2008 6. Manageability Considerations Manageability of Global Concurrent Path Computation with PCE must address the following considerations: 6.1. Control of Function and Policy In addition to the parameters already listed in section 8.1 of [PCEP], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCC: o The ability to send a GCO request. In addition to the parameters already listed in section 8.1 of [PCEP], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCE: o The support for Global Concurrent Optimization. o The maximum number of synchronized path requests per request message. o A set of GCO specific policies (authorized sender, request rate limiter, etc). These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in, or may apply to a specific session with a given PCEP peer or a specific group of sessions with a specific group of PCEP peers. 6.2. Information and Data Models, e.g. MIB module Extensions to the PCEP MIB module defined in [PCEP-MIB] should be defined, so as to cover the GCO information introduced in this document. 6.3. Liveness Detection and Monitoring Mechanisms defined in this draft does not imply any new liveness detection and monitoring requirements in addition to those already listed in section 8.3 of [PCEP]. 6.4. Verifying Correct Operation Mechanisms defined in this draft does not imply any new verification requirements in addition to those already listed in section 8.4 of [PCEP] Lee, et al. Expires December 26, 2008 [Page 21] Internet-Draft PCE Global Concurrent Optimization June 2008 6.5. Requirements on Other Protocols and Functional Components The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be used to advertise global concurrent path computation capabilities to PCCs. 6.6. Impact on Network Operation Mechanisms defined in this draft does not imply any new network operation requirements in addition to those already listed in section 8.6 of [PCEP]. Lee, et al. Expires December 26, 2008 [Page 22] Internet-Draft PCE Global Concurrent Optimization June 2008 7. Security Considerations When global re-optimization is applied to an active network, it could be extremely disruptive. Although the real security and policy issues apply at the NMS, if the wrong results are returned to the NMS, the wrong actions may be taken in the network. Therefore, it is very important that the operator issuing the commands has sufficient authority and is authenticated, and that the computation request is subject to appropriate policy. The mechanism defined in [PCEP] to secure a PCEP session can be used to secure global concurrent path computation requests/responses. Lee, et al. Expires December 26, 2008 [Page 23] Internet-Draft PCE Global Concurrent Optimization June 2008 8. Acknowledgements We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So, Lucy Yong and Fabien Verhaeghe for their useful comments and suggestions. Lee, et al. Expires December 26, 2008 [Page 24] Internet-Draft PCE Global Concurrent Optimization June 2008 9. IANA Considerations IANA maintains a registry of PCEP parameters. IANA is requested to make allocations from the sub-registries as described in the following sections. 9.1. Request Parameter Bit Flags As described in Section 5.3, two new bit lfags are defined for inclusion in the Flags field of the RP object. IANA is requested to make the following allocations from the "Request Parameter Bit Flags" sub-registry. Bit Name Description Reference 11 D-bit Report the request order [This.I-D] 12 M-bit Make-before-break [This.I-D] 9.2. New PCEP TLV As described in Section 5.4, a new PCEP TLV is defined to indicate the setup and delete order of LSPs in a GCO. IANA is requested to make the following allocation from the "PCEP TLV Types" sub-registry. TLV Type Meaning Reference 5 Order TLV [This.I-D] 9.3. New PCEP Object As descried in Section 5.5, a new PCEP object is defined to carry global constraints. IANA is requested to make the following allocation from the "PCEP Objects" sub-registry. Object Name Reference Class 24 GLOBAL-CONSTRAINTS [This.I-D] Object-Type 1: Global Constraints [This.I-D] Lee, et al. Expires December 26, 2008 [Page 25] Internet-Draft PCE Global Concurrent Optimization June 2008 9.4. New PCEP Error Codes As described in Section 5.6, new PCEP error codes are defined for GCO errors. IANA is requested to make allocations from the "PCEP Error Types and Values" sub-registry as set out in the following sections. 9.4.1. New Error-Values for Existing Error-Types Error Type Meaning Reference 5 Policy violation Error-value=5: [This.I-D] Global concurrent optimization not allowed 9.4.2. New Error-Types and Error-Values Error Type Meaning Reference 15 Global Concurrent Optimization Error [This.I-D] Error-value=1: Insufficient memory [This.I-D] Error-value=2: Global concurrent optimization not supported [This.I-D] 9.5. New No-Path Reasons IANA is requested to make the following allocations from the "No-Path Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV in the PCEP NO-PATH object as described in Section 5.7. Bit Number Name Reference 6 No GCO migration path found [This.I-D] 7 No GCO solution found [This.I-D] Lee, et al. Expires December 26, 2008 [Page 26] Internet-Draft PCE Global Concurrent Optimization June 2008 10. References 10.1. Normative References [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter- domain Traffic Engineering Label Switched Paths, draft-ietf-pce-brpc-05.txt, work in progress". [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective Function encoding in Path Computation Element communication and discovery protocols, draft-leroux-pce-of, work in progress". [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions, draft-ietf-pce-pcep-xro-00.txt, work in progress". [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1, draft-ietf-pce-pcep, work in progress". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture, RFC 4655, August 2006". [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements, RFC 4657, September 2006". [RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery, RFC 4674, October 2006.". 10.2. Informative References [ISIS-PCED] Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions for Path Computation Element (PCE) Discovery, draft-ietf-pce-disco-proto-isis, work in progress.". [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- Lee, et al. Expires December 26, 2008 [Page 27] Internet-Draft PCE Global Concurrent Optimization June 2008 region and multi-layer networks (MRN/MLN), draft-ietf-ccamp-gmpls-mln-reqs, work in progress". [OSPF-PCED] Le Roux, J. and JP. Vasseur, "OSPF protocol extensions for Path Computation Element (PCE) Discovery, draft-ietf-pce-disco-proto-ospf, work in progress.". [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- based inter-layer MPLS and GMPL traffic engineering, draft-ietf-pce-inter-layer-frwk, work in progress.". [PCEP-MIB] Stephen, E. and K. Koushik, "PCE communication protocol(PCEP) Management Information Base, draft-kkoushik-pce-pcep-mib, work in progress.". Lee, et al. Expires December 26, 2008 [Page 28] Internet-Draft PCE Global Concurrent Optimization June 2008 Authors' Addresses Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 Email: ylee@huawei.com JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE Email: jeanlouis.leroux@orange-ftgroup.com Daniel King Aria Networks 44/45 Market Place Chippenham SN15 3HU United Kingdom Phone: +44 7790 775187 Fax: +44 1249 446530 Email: daniel.king@aria-networks.com Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585 JAPAN Email: oki.eiji@lab.ntt.co.jp Lee, et al. Expires December 26, 2008 [Page 29] Internet-Draft PCE Global Concurrent Optimization June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Lee, et al. Expires December 26, 2008 [Page 30] --Boundary_(ID_717/YjrYpwRB0aoPO0FZRQ) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_717/YjrYpwRB0aoPO0FZRQ)-- From pce-bounces@ietf.org Tue Jun 24 10:57:18 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B473A680E; Tue, 24 Jun 2008 10:57:18 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABFA3A679C for ; Tue, 24 Jun 2008 10:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=1.424, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LueANOjRZFTT for ; Tue, 24 Jun 2008 10:57:16 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 9BDE43A67CE for ; Tue, 24 Jun 2008 10:57:16 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m5OHv3QQ012555; Tue, 24 Jun 2008 18:57:03 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m5OHuxB5012531; Tue, 24 Jun 2008 18:57:03 +0100 Message-ID: <1ddb01c8d623$affcd140$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Young Lee" , "'JP Vasseur'" References: <000201c8d621$ca7ccae0$610c7c0a@china.huawei.com> Date: Tue, 24 Jun 2008 18:56:48 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Thanks. This is now on my list. Can I do it in time for you to update before Dublin? Possibly! A ----- Original Message ----- From: "Young Lee" To: "'JP Vasseur'" ; "'Adrian@OldDog'" Cc: Sent: Tuesday, June 24, 2008 6:43 PM Subject: PCE GCO update > Hi J-P and Adrian, > > > > Here's the update of PCE GCO draft. As per requested in Philadelphia, this > is ready for the WG chair's review and the last call. Please note section > 9 > for IANA considerations and new objects/TLV/Flags have been defined. I'd > appreciate your review and look forward to making progress on this work to > the next stage. Thanks. > > > > I snipped Section 9 below. Thanks. > > > > Regards, > > Young > > -----------snipped---------------------------------------- > > > > 9. IANA Considerations > > > > IANA maintains a registry of PCEP parameters. IANA is requested to > > make allocations from the sub-registries as described in the > > following sections. > > > > 9.1. Request Parameter Bit Flags > > > > As described in Section 5.3, two new bit lfags are defined for > > inclusion in the Flags field of the RP object. IANA is requested to > > make the following allocations from the "Request Parameter Bit Flags" > > sub-registry. > > > > > > Bit Name Description Reference > > > > 11 D-bit Report the request order [This.I-D] > > 12 M-bit Make-before-break [This.I-D] > > > > > > 9.2. New PCEP TLV > > > > As described in Section 5.4, a new PCEP TLV is defined to indicate > > the setup and delete order of LSPs in a GCO. IANA is requested to > > make the following allocation from the "PCEP TLV Types" sub-registry. > > > > > > TLV Type Meaning Reference > > > > 5 Order TLV [This.I-D] > > > > > > 9.3. New PCEP Object > > > > As descried in Section 5.5, a new PCEP object is defined to carry > > global constraints. IANA is requested to make the following > > allocation from the "PCEP Objects" sub-registry. > > > > > > Object Name Reference > > Class > > > > 24 GLOBAL-CONSTRAINTS [This.I-D] > > Object-Type > > 1: Global Constraints [This.I-D] > > > > 9.4. New PCEP Error Codes > > > > As described in Section 5.6, new PCEP error codes are defined for GCO > > errors. IANA is requested to make allocations from the "PCEP Error > > Types and Values" sub-registry as set out in the following sections. > > > > 9.4.1. New Error-Values for Existing Error-Types > > > > > > Error > > Type Meaning Reference > > > > 5 Policy violation > > Error-value=5: [This.I-D] > > Global concurrent optimization not allowed > > > > > > 9.4.2. New Error-Types and Error-Values > > > > > > Error > > Type Meaning Reference > > > > 15 Global Concurrent Optimization Error [This.I-D] > > Error-value=1: > > Insufficient memory [This.I-D] > > Error-value=2: > > Global concurrent optimization not supported > > [This.I-D] > > > > > > 9.5. New No-Path Reasons > > > > IANA is requested to make the following allocations from the "No-Path > > Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV > > in the PCEP NO-PATH object as described in Section 5.7. > > > > Bit > > Number Name Reference > > > > 6 No GCO migration path found [This.I-D] > > 7 No GCO solution found [This.I-D] > > > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Jun 24 11:30:04 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14F33A68D3; Tue, 24 Jun 2008 11:30:04 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0A8DE3A6815; Tue, 24 Jun 2008 11:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Mime-Version: 1.0 Message-Id: <20080624183002.0A8DE3A6815@core3.amsl.com> Date: Tue, 24 Jun 2008 11:30:02 -0700 (PDT) Cc: pce@ietf.org, jpv@cisco.com Subject: [Pce] WG Action: RECHARTER: Path Computation Element (pce) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org The charter of the Path Computation Element (pce) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Path Computation Element (pce) ================================ Last Modified: 2008-06-20 Current Status: Active Working Group Chair(s): JP Vasseur [jpv@cisco.com] Adrian Farrel [adrian@olddog.co.uk] Routing Area Director(s): Ross Callon [rcallon@juniper.net] David Ward [dward@cisco.com] Routing Area Advisor: Ross Callon [rcallon@juniper.net] Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single Domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Done Submit first draft of PCE architecture document Done Submit first draft of PCE discovery requirements and protocol extensions documents Done Submit first draft of the PCE communication protocol requirements Done Submit first draft of the definition of objective metrics Done Submit first draft of the PCE communication protocol specification Done Submit PCE architecture specification to the IESG to be considered as Informational RFC Done Submit first draft of the MIB module for the PCE protocol Done Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Jun 2008 First draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Jun 2008 Submit first draft of the PCE P2MP communication requirements Jul 2008 Submit first draft of the PCE P2MP PCEP protocol extensions Sep 2008 Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Nov 2008 Submit applicability statement to the IESG as informational RFC Dec 2008 Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Feb 2009 Submit applicability and metrics documents to the IESG Feb 2009 Submit the PCE MIB Internet-Draft to the IESG for consideration as Proposed Standard Feb 2009 Evaluate WG progress, recharter or close _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Jun 25 02:24:31 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34CA3A68D5; Wed, 25 Jun 2008 02:24:31 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E553A68D5 for ; Wed, 25 Jun 2008 02:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVrn-YBZh9aj for ; Wed, 25 Jun 2008 02:24:29 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by core3.amsl.com (Postfix) with ESMTP id CE0893A6859 for ; Wed, 25 Jun 2008 02:24:26 -0700 (PDT) Received: from [10.30.2.169] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 43225183; Wed, 25 Jun 2008 11:27:04 +0200 Message-ID: <042a01c8d6a5$3fa9a710$a9021e0a@Platini> From: "Filippo Cugini" To: "Young Lee" References: <000201c8d621$ca7ccae0$610c7c0a@china.huawei.com> Date: Wed, 25 Jun 2008 11:24:20 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621429982==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============1621429982== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0427_01C8D6B6.030C5170" This is a multi-part message in MIME format. ------=_NextPart_000_0427_01C8D6B6.030C5170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Young, 1) in case of stateful PCE, is it mandatory to include the full list of = RROs in the PCReq message? 2) In section 2, Terminology, GCO is defined to consider only the entire = network, while in the rest of the document also network subsets are = allowed.=20 Is the use of "Global" associated to both the cases of entire network = and network subsets or is it just related to the entire network? Thank you Filippo ----- Original Message -----=20 From: Young Lee=20 To: 'JP Vasseur' ; 'Adrian@OldDog'=20 Cc: pce@ietf.org=20 Sent: Tuesday, June 24, 2008 7:43 PM Subject: [Pce] PCE GCO update Hi J-P and Adrian,=20 =20 Here's the update of PCE GCO draft. As per requested in Philadelphia, = this is ready for the WG chair's review and the last call. Please note = section 9 for IANA considerations and new objects/TLV/Flags have been = defined. I'd appreciate your review and look forward to making progress = on this work to the next stage. Thanks.=20 =20 I snipped Section 9 below. Thanks. =20 Regards, Young -----------snipped---------------------------------------- =20 9. IANA Considerations =20 IANA maintains a registry of PCEP parameters. IANA is requested to make allocations from the sub-registries as described in the following sections. =20 9.1. Request Parameter Bit Flags =20 As described in Section 5.3, two new bit lfags are defined for inclusion in the Flags field of the RP object. IANA is requested = to make the following allocations from the "Request Parameter Bit = Flags" sub-registry. =20 =20 Bit Name Description Reference =20 11 D-bit Report the request order [This.I-D] 12 M-bit Make-before-break [This.I-D] =20 =20 9.2. New PCEP TLV =20 As described in Section 5.4, a new PCEP TLV is defined to indicate the setup and delete order of LSPs in a GCO. IANA is requested to make the following allocation from the "PCEP TLV Types" = sub-registry. =20 =20 TLV Type Meaning Reference =20 5 Order TLV [This.I-D] =20 =20 9.3. New PCEP Object =20 As descried in Section 5.5, a new PCEP object is defined to carry global constraints. IANA is requested to make the following allocation from the "PCEP Objects" sub-registry. =20 =20 Object Name Reference Class =20 24 GLOBAL-CONSTRAINTS [This.I-D] Object-Type 1: Global Constraints [This.I-D] =20 9.4. New PCEP Error Codes =20 As described in Section 5.6, new PCEP error codes are defined for = GCO errors. IANA is requested to make allocations from the "PCEP Error Types and Values" sub-registry as set out in the following = sections. =20 9.4.1. New Error-Values for Existing Error-Types =20 =20 Error Type Meaning = Reference =20 5 Policy violation Error-value=3D5: = [This.I-D] Global concurrent optimization not allowed =20 =20 9.4.2. New Error-Types and Error-Values =20 =20 Error Type Meaning = Reference =20 15 Global Concurrent Optimization Error = [This.I-D] Error-value=3D1: Insufficient memory = [This.I-D] Error-value=3D2: Global concurrent optimization not supported = [This.I-D] =20 =20 9.5. New No-Path Reasons =20 IANA is requested to make the following allocations from the = "No-Path Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR = TLV in the PCEP NO-PATH object as described in Section 5.7. =20 Bit Number Name Reference =20 6 No GCO migration path found [This.I-D] 7 No GCO solution found [This.I-D] =20 -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0427_01C8D6B6.030C5170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Young,
 
1) in case of stateful PCE, is it = mandatory to=20 include the full list of RROs in the PCReq message?
 
2) In section 2, Terminology, GCO is = defined to=20 consider only the entire network, while in the rest of the document also = network=20 subsets are allowed.
Is the use of "Global" associated to = both the cases=20 of entire network and network subsets or is it just related to the = entire=20 network?
 
Thank you
  Filippo
 
 
----- Original Message -----
From:=20 Young = Lee
To: 'JP Vasseur' ; 'Adrian@OldDog'=20
Sent: Tuesday, June 24, 2008 = 7:43=20 PM
Subject: [Pce] PCE GCO = update

Hi J-P and Adrian,=20

 

Here=92s the update of = PCE GCO=20 draft. As per requested in Philadelphia, this is ready for the = WG=20 chair=92s review and the last call. Please note section 9 for IANA=20 considerations and new objects/TLV/Flags have been defined. I=92d = appreciate=20 your review and look forward to making progress on this work to the = next=20 stage. Thanks.

 

I snipped Section 9 = below.=20 Thanks.

 

Regards,

Young

-----------snipped----------------------------------------

 

9.  IANA=20 Considerations

 

   = IANA=20 maintains a registry of PCEP parameters.  IANA is requested=20 to

   = make=20 allocations from the sub-registries as described in=20 the

   = following=20 sections.

 

9.1.  = Request=20 Parameter Bit Flags

 

   As = described=20 in Section 5.3, two new bit lfags are defined = for

   = inclusion in=20 the Flags field of the RP object.  IANA is requested=20 to

   = make the=20 following allocations from the "Request Parameter Bit=20 Flags"

  =20 sub-registry.

 

 

  =20 Bit      Name   =20 = Description          &n= bsp;        =20 Reference

 

  =20 11       D-bit   Report the = request=20 order      =20 [This.I-D]

  =20 12       M-bit  =20 = Make-before-break         &n= bsp;   =20 [This.I-D]

 

 

9.2.  New = PCEP=20 TLV

 

   As = described=20 in Section 5.4, a new PCEP TLV is defined to=20 indicate

   the = setup and=20 delete order of LSPs in a GCO.  IANA is requested=20 to

   = make the=20 following allocation from the "PCEP TLV Types"=20 sub-registry.

 

 

   TLV = Type       =20 = Meaning           =      =20 Reference

 

  =20 = 5            =   =20 Order=20 = TLV           &nbs= p;  =20 [This.I-D]

 

 

9.3.  New = PCEP=20 Object

 

   As = descried=20 in Section 5.5, a new PCEP object is defined to=20 carry

   = global=20 constraints.  IANA is requested to make the=20 following

   = allocation=20 from the "PCEP Objects" sub-registry.

 

 

   = Object =20 = Name           &nb= sp;           &nbs= p;       =20 =             R= eference

  =20 Class

 

  =20 = 24            = ; =20 = GLOBAL-CONSTRAINTS         &= nbsp;           =20 [This.I-D]

           &= nbsp;          =20 Object-Type

           &= nbsp;         =20 1: Global=20 = Constraints          &n= bsp;    =20 [This.I-D]

 

9.4.  New = PCEP Error=20 Codes

 

   As = described=20 in Section 5.6, new PCEP error codes are defined for=20 GCO

   = errors. =20 IANA is requested to make allocations from the "PCEP=20 Error

   = Types and=20 Values" sub-registry as set out in the following=20 sections.

 

9.4.1.  New = Error-Values for Existing Error-Types

 

 

  =20 Error

  =20 Type   =20 = Meaning           =             &= nbsp;           &n= bsp; =20 =       Reference

 

  =20 = 5            =   =20 Policy violation

           &= nbsp;           &n= bsp;  =20 = Error-value=3D5:         &nb= sp;          =20 [This.I-D]

           &= nbsp;      =20 Global concurrent optimization not = allowed

 

 

9.4.2.  New = Error-Types and Error-Values

 

 

  =20 Error

  =20 Type   =20 = Meaning           =             &= nbsp;           &n= bsp;       =20 Reference

 

  =20 = 15            = ; =20 Global Concurrent Optimization = Error      =20 [This.I-D]

           &= nbsp;      =20 Error-value=3D1:

           &= nbsp;      =20 Insufficient=20 = memory           &= nbsp;           =20 [This.I-D]

           &= nbsp;      =20 Error-value=3D2:

           &= nbsp;      =20 Global concurrent optimization not = supported

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; =20 [This.I-D]

 

 

9.5.  New = No-Path=20 Reasons

 

   = IANA is=20 requested to make the following allocations from the=20 "No-Path

   = Reasons"=20 sub-registry for bit flags carried in the NO-PATH-VECTOR=20 TLV

   in = the PCEP=20 NO-PATH object as described in Section = 5.7.

 

  =20 Bit

  =20 Number         =20 = Name           &nb= sp;           &nbs= p;=20 Reference

 

  =20 = 6            =   =20 No GCO migration path found  = [This.I-D]

  =20 = 7            =   =20 No GCO solution found       =20 [This.I-D]

 

_______________________________________________
Pce mailing=20 = list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
------=_NextPart_000_0427_01C8D6B6.030C5170-- --===============1621429982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1621429982==-- From pce-bounces@ietf.org Wed Jun 25 10:06:23 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBFC3A68CC; Wed, 25 Jun 2008 10:06:23 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D643328B797 for ; Wed, 25 Jun 2008 10:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v16hWjlXkQCB for ; Wed, 25 Jun 2008 10:06:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C912C3A68CC for ; Wed, 25 Jun 2008 10:06:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,703,1204520400"; d="scan'208,217";a="12219796" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jun 2008 13:06:22 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5PH6MQZ001633 for ; Wed, 25 Jun 2008 13:06:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5PH6Mm0026928 for ; Wed, 25 Jun 2008 17:06:22 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 13:06:22 -0400 Received: from 10.21.70.104 ([10.21.70.104]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Jun 2008 17:06:22 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 25 Jun 2008 19:06:21 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: New Charter Thread-Index: AcjW5cpNLN9QGIlt40+DrgR6xjXJyA== Mime-version: 1.0 X-OriginalArrivalTime: 25 Jun 2008 17:06:22.0610 (UTC) FILETIME=[CB434F20:01C8D6E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=847; t=1214413582; x=1215277582; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20Charter |Sender:=20 |To:=20; bh=VKeX9bA7EhO9diHsGmhxEL8B7TMZAca/hFBIXCrMj8M=; b=kXM8RdcNL/N6Y8fdeg+f6Q+sgfj1mFccmO+DezfCYASjIraV1iyCiDvetw Sj0fK4aHRGVDcnwehim728d/a3PtWckTRXhBy+3mlKG6C5knfkB0vOWOVSBP 6uSs7uko3T; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Pce] New Charter X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500035324==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1500035324== Content-type: multipart/alternative; boundary="B_3297265581_4899338" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3297265581_4899338 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Our charter has been updated: http://www.ietf.org/html.charters/pce-charter.html Thanks. JP. --B_3297265581_4899338 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable New Charter Dear WG,

Our charter has been updated: http://www.ietf.org/html.charters/pce-charter.html

Thanks.

JP. --B_3297265581_4899338-- --===============1500035324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1500035324==-- From pce-bounces@ietf.org Wed Jun 25 13:14:12 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55EF3A6ADF; Wed, 25 Jun 2008 13:14:12 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EB63A6A6B for ; Wed, 25 Jun 2008 13:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpiyMuOqGxTF for ; Wed, 25 Jun 2008 13:14:04 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D42A13A6ADC for ; Wed, 25 Jun 2008 13:14:03 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3100BF1C7H86@usaga04-in.huawei.com> for pce@ietf.org; Wed, 25 Jun 2008 15:14:05 -0500 (CDT) Received: from L73682 ([10.124.12.97]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3100DBAC7DH0@usaga04-in.huawei.com> for pce@ietf.org; Wed, 25 Jun 2008 15:14:05 -0500 (CDT) Date: Wed, 25 Jun 2008 15:14:01 -0500 From: Young Lee In-reply-to: <042a01c8d6a5$3fa9a710$a9021e0a@Platini> To: 'Filippo Cugini' Message-id: <002301c8d700$026f9ca0$610c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjWqhl1TavQUQVdQv61zo1AnkX16gAUDnHQ References: <000201c8d621$ca7ccae0$610c7c0a@china.huawei.com> <042a01c8d6a5$3fa9a710$a9021e0a@Platini> Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1129715583==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============1129715583== Content-type: multipart/alternative; boundary="Boundary_(ID_UUf5Cin1XUx8V8td+ur+6w)" This is a multi-part message in MIME format. --Boundary_(ID_UUf5Cin1XUx8V8td+ur+6w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Filippo, Please see inline for my comment. Thanks. Young _____ From: Filippo Cugini [mailto:filippo.cugini@cnit.it] Sent: Wednesday, June 25, 2008 4:24 AM To: Young Lee Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update Hi Young, 1) in case of stateful PCE, is it mandatory to include the full list of RROs in the PCReq message? Young>> I am not sure of your definition of stateful PCE. If you mean stateful PCE to be the PCE that keeps the state of the active LSPs at the PCE, this is beyond the scope of PCEP in IETF. Nonetheless, if this is what you mean by stateful PCE, I am not sure why you need to send the full list of RROs in the PCReq message since the PCE keeps such information with stateful PCE. When you want to do re-optimization with stateless PCE, you need to send the full list of RROs of the LSPs to be re-optimized in the PC Req message. This way PCE needs not maintain the state of LSPs at the PCE level. 2) In section 2, Terminology, GCO is defined to consider only the entire network, while in the rest of the document also network subsets are allowed. Is the use of "Global" associated to both the cases of entire network and network subsets or is it just related to the entire network? Young>> Although GCO considers the entire network in general case, there are applications of GCO where only a subset of TE LSPs can be re-optimized. This has a protocol support. I believe you are quoting the statement in the Introduction, "Alternatively, the application may consider a subset of the LSPs and/or a subset of the network topology." I may have to delete the last clause. This can be achieved, but we don't have ways to limit the whole topology into a subset in the current PCEP for GCO. Are you aware of any good application for this case? Thank you Filippo ----- Original Message ----- From: Young Lee To: 'JP Vasseur' ; 'Adrian@OldDog' Cc: pce@ietf.org Sent: Tuesday, June 24, 2008 7:43 PM Subject: [Pce] PCE GCO update Hi J-P and Adrian, Here's the update of PCE GCO draft. As per requested in Philadelphia, this is ready for the WG chair's review and the last call. Please note section 9 for IANA considerations and new objects/TLV/Flags have been defined. I'd appreciate your review and look forward to making progress on this work to the next stage. Thanks. I snipped Section 9 below. Thanks. Regards, Young -----------snipped---------------------------------------- 9. IANA Considerations IANA maintains a registry of PCEP parameters. IANA is requested to make allocations from the sub-registries as described in the following sections. 9.1. Request Parameter Bit Flags As described in Section 5.3, two new bit lfags are defined for inclusion in the Flags field of the RP object. IANA is requested to make the following allocations from the "Request Parameter Bit Flags" sub-registry. Bit Name Description Reference 11 D-bit Report the request order [This.I-D] 12 M-bit Make-before-break [This.I-D] 9.2. New PCEP TLV As described in Section 5.4, a new PCEP TLV is defined to indicate the setup and delete order of LSPs in a GCO. IANA is requested to make the following allocation from the "PCEP TLV Types" sub-registry. TLV Type Meaning Reference 5 Order TLV [This.I-D] 9.3. New PCEP Object As descried in Section 5.5, a new PCEP object is defined to carry global constraints. IANA is requested to make the following allocation from the "PCEP Objects" sub-registry. Object Name Reference Class 24 GLOBAL-CONSTRAINTS [This.I-D] Object-Type 1: Global Constraints [This.I-D] 9.4. New PCEP Error Codes As described in Section 5.6, new PCEP error codes are defined for GCO errors. IANA is requested to make allocations from the "PCEP Error Types and Values" sub-registry as set out in the following sections. 9.4.1. New Error-Values for Existing Error-Types Error Type Meaning Reference 5 Policy violation Error-value=5: [This.I-D] Global concurrent optimization not allowed 9.4.2. New Error-Types and Error-Values Error Type Meaning Reference 15 Global Concurrent Optimization Error [This.I-D] Error-value=1: Insufficient memory [This.I-D] Error-value=2: Global concurrent optimization not supported [This.I-D] 9.5. New No-Path Reasons IANA is requested to make the following allocations from the "No-Path Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV in the PCEP NO-PATH object as described in Section 5.7. Bit Number Name Reference 6 No GCO migration path found [This.I-D] 7 No GCO solution found [This.I-D] _____ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_UUf5Cin1XUx8V8td+ur+6w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Filippo,

 

Please see inline for my comment. = Thanks.

 

Young

 

From: = Filippo Cugini [mailto:filippo.cugini@cnit.it]
Sent: Wednesday, June 25, = 2008 4:24 AM
To: Young Lee
Cc: pce@ietf.org
Subject: Re: [Pce] PCE = GCO update

 

Hi = Young,

 

1) in case of stateful PCE, is it mandatory to = include the full list of RROs in the PCReq message?

 

Young>> I am not sure of your = definition of stateful PCE. If you mean stateful PCE to be the PCE that keeps the = state of the active LSPs at the PCE, this is beyond the scope of PCEP in IETF. = Nonetheless, if this is what you mean by stateful PCE, I am not sure why you need to = send the full list of RROs in the PCReq message since the PCE keeps such = information with stateful PCE.  When you want to do re-optimization with = stateless PCE, you need to send the full list of RROs of the LSPs to be = re-optimized in the PC Req message. This way PCE needs not maintain the state of LSPs at = the PCE level.

 

2) In section 2, Terminology, GCO is defined to = consider only the entire network, while in the rest of the document also network = subsets are allowed.

Is the use of "Global" associated to both = the cases of entire network and network subsets or is it just related to the = entire network?

 

Young>> Although GCO = considers the entire network in general case, there are applications of GCO where only = a subset of TE LSPs can be re-optimized. This has a protocol support. I believe = you are quoting the statement in the Introduction, “Alternatively, the application may consider a subset of = the LSPs and/or a subset of the network topology.” I may have to = delete the last clause. This can be achieved, but we don’t have ways to limit = the whole topology into a subset in the current PCEP for GCO. Are you aware = of any good application for this case?

 

 

Thank you

  Filippo

 

 

----- Original Message ----- =

From: Young Lee =

Cc: pce@ietf.org =

Sent: = Tuesday, June 24, 2008 7:43 PM

Subject: [Pce] = PCE GCO update

 

Hi J-P and Adrian,

 

Here’s the update of PCE GCO draft. As per = requested in Philadelphia, this is ready for the WG chair’s review and the last call. Please = note section 9 for IANA considerations and new objects/TLV/Flags have been = defined. I’d appreciate your review and look forward to making progress on = this work to the next stage. Thanks.

 

I snipped Section 9 below. = Thanks.

 

Regards,

Young

-----------snipped------------------------------------= ----

 

9.  IANA = Considerations

 

   IANA maintains a registry of = PCEP parameters.  IANA is requested to

   make allocations from the sub-registries as described in the

   following = sections.

 

9.1.  Request Parameter Bit = Flags

 

   As described in Section 5.3, two = new bit lfags are defined for

   inclusion in the Flags field of = the RP object.  IANA is requested to

   make the following allocations = from the "Request Parameter Bit Flags"

   = sub-registry.

 

 

   = Bit      Name    Description          &n= bsp;         Reference

 

   = 11       D-bit   Report the request = order       [This.I-D]

   = 12       M-bit   Make-before-break         &n= bsp;    [This.I-D]

 

 

9.2.  New PCEP = TLV

 

   As described in Section 5.4, a = new PCEP TLV is defined to indicate

   the setup and delete order of = LSPs in a GCO.  IANA is requested to

   make the following allocation = from the "PCEP TLV Types" sub-registry.

 

 

   TLV Type        Meaning           =       Reference

 

   = 5            =    Order TLV           &nbs= p;   [This.I-D]

 

 

9.3.  New PCEP = Object

 

   As descried in Section 5.5, a = new PCEP object is defined to carry

   global constraints.  IANA = is requested to make the following

   allocation from the "PCEP Objects" sub-registry.

 

 

   Object  Name           &nb= sp;           &nbs= p;                    R= eference

   = Class

 

   24            = ;  GLOBAL-CONSTRAINTS         &= nbsp;            [This.I-D]

           &= nbsp;           Object-Type

           &= nbsp;          1: Global Constraints          &n= bsp;     [This.I-D]

 

9.4.  New PCEP Error = Codes

 

   As described in Section 5.6, new = PCEP error codes are defined for GCO

   errors.  IANA is requested = to make allocations from the "PCEP Error

   Types and Values" = sub-registry as set out in the following sections.

 

9.4.1.  New Error-Values for Existing Error-Types

 

 

   = Error

   Type    Meaning           =             &= nbsp;           &n= bsp;        Reference

 

   5            =    Policy violation

           &= nbsp;           &n= bsp;   Error-value=3D5:         &nb= sp;           [This.I-D]

           &= nbsp;       Global concurrent optimization not allowed

 

 

9.4.2.  New Error-Types and = Error-Values

 

 

   = Error

   Type    Meaning           =             &= nbsp;           &n= bsp;        Reference

 

   15            = ;  Global Concurrent Optimization Error       [This.I-D]

           &= nbsp;       Error-value=3D1:

           &= nbsp;       Insufficient memory           &= nbsp;            [This.I-D]

           &= nbsp;       Error-value=3D2:

           &= nbsp;       Global concurrent optimization not = supported

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;  [This.I-D]

 

 

9.5.  New No-Path = Reasons

 

   IANA is requested to make the = following allocations from the "No-Path

   Reasons" sub-registry for = bit flags carried in the NO-PATH-VECTOR TLV

   in the PCEP NO-PATH object as = described in Section 5.7.

 

   Bit

   Number          Name           &nb= sp;           &nbs= p; Reference

 

   6            =    No GCO migration path found  = [This.I-D]

   7            =    No GCO solution found        = [This.I-D]

 

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

--Boundary_(ID_UUf5Cin1XUx8V8td+ur+6w)-- --===============1129715583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1129715583==-- From pce-bounces@ietf.org Thu Jun 26 03:54:12 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B273A6983; Thu, 26 Jun 2008 03:54:12 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232BF3A6983 for ; Thu, 26 Jun 2008 03:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3MF3NDOVTC1 for ; Thu, 26 Jun 2008 03:54:05 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by core3.amsl.com (Postfix) with ESMTP id 975C23A6811 for ; Thu, 26 Jun 2008 03:54:03 -0700 (PDT) Received: from [10.30.2.169] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 43251542; Thu, 26 Jun 2008 12:26:33 +0200 Message-ID: <002901c8d776$ba826680$a9021e0a@Platini> From: "Filippo Cugini" To: "Young Lee" References: <000201c8d621$ca7ccae0$610c7c0a@china.huawei.com> <042a01c8d6a5$3fa9a710$a9021e0a@Platini> <002301c8d700$026f9ca0$610c7c0a@china.huawei.com> Date: Thu, 26 Jun 2008 12:23:51 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0735066835==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============0735066835== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C8D787.7DEF9830" This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C8D787.7DEF9830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, please see in-line.=20 1) in case of stateful PCE, is it mandatory to include the full list of = RROs in the PCReq message? =20 Young>> I am not sure of your definition of stateful PCE. If you mean = stateful PCE to be the PCE that keeps the state of the active LSPs at = the PCE, this is beyond the scope of PCEP in IETF. Nonetheless, if this = is what you mean by stateful PCE, I am not sure why you need to send the = full list of RROs in the PCReq message since the PCE keeps such = information with stateful PCE. When you want to do re-optimization with = stateless PCE, you need to send the full list of RROs of the LSPs to be = re-optimized in the PC Req message. This way PCE needs not maintain the = state of LSPs at the PCE level. =20 Filippo>> agree that in case of Stateful PCE (yes, the one that keeps = the state of active LSPs) there is no need to send the full list, = however, in draft-ietf-pce-pcep-12.txt, section 7.4.1 and .2, it is = reported that in case of re-optimization, PCReq messages MUST include = RROs.=20 =20 2) In section 2, Terminology, GCO is defined to consider only the entire = network, while in the rest of the document also network subsets are = allowed.=20 Is the use of "Global" associated to both the cases of entire network = and network subsets or is it just related to the entire network? =20 Young>> Although GCO considers the entire network in general case, there = are applications of GCO where only a subset of TE LSPs can be = re-optimized. This has a protocol support. I believe you are quoting the = statement in the Introduction, "Alternatively, the application may = consider a subset of the LSPs and/or a subset of the network topology." = I may have to delete the last clause. This can be achieved, but we don't = have ways to limit the whole topology into a subset in the current PCEP = for GCO. Are you aware of any good application for this case?=20 =20 Filippo>> Yes, exactly that statement in the introduction which should = become consistent with the rest of the document.=20 To restrict the computation to a network subset, a possible solution = could be the use of IRO object, e.g. specifying the IP prefix or AS = number (don't know how to indicate Area ID). Typo: in section 4, "section 6.1.14 of [RFC4657]" -> "section 5.1.14 = of.." Thanks Filippo ------=_NextPart_000_0026_01C8D787.7DEF9830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
please see in-line.
 

1) in case of stateful = PCE, is it=20 mandatory to include the full list of RROs in the PCReq=20 message?

 

Young>> = I am not=20 sure of your definition of stateful PCE. If you mean stateful PCE to be = the PCE=20 that keeps the state of the active LSPs at the PCE, this is beyond the = scope of=20 PCEP in IETF. = Nonetheless, if=20 this is what you mean by stateful PCE, I am not sure why you need to = send the=20 full list of RROs in the PCReq message since the PCE keeps such = information with=20 stateful PCE. When you want to do re-optimization with stateless PCE, = you need=20 to send the full list of RROs of the LSPs to be re-optimized in the PC = Req=20 message. This way PCE needs not maintain the state of LSPs at the PCE=20 level.   

 

Filippo>> agree that in case of Stateful PCE (yes, = the one=20 that keeps the state of active LSPs) there is no need to send the full=20 list, however, in draft-ietf-pce-pcep-12.txt, section 7.4.1 and .2, = it is=20 reported that in case of re-optimization, PCReq messages MUST = include RROs.=20

 

 

2) In section 2, = Terminology, GCO is=20 defined to consider only the entire network, while in the rest of the = document=20 also network subsets are allowed.

Is the use of "Global" = associated to=20 both the cases of entire network and network subsets or is it just = related to=20 the entire network?

 

Young>> = Although=20 GCO considers the entire network in general case, there are applications = of GCO=20 where only a subset of TE LSPs can be re-optimized. This has a protocol = support.=20 I believe you are quoting the statement in the Introduction,=20 =93Alternatively, the = application may consider a subset of=20 the LSPs and/or a = subset of=20 the network topology.=94 I may have to delete the last clause. This can = be=20 achieved, but we don=92t have ways to limit the whole topology into a = subset in=20 the current PCEP for GCO. Are you aware of any good application for this = case?=20

 

Filippo>> Yes, exactly that statement in the = introduction=20 which should become consistent with the rest of the document.=20

To=20 restrict the computation to a network subset, a possible solution could = be the=20 use of IRO object, e.g. specifying the IP prefix or AS number = (don't know=20 how to indicate Area = ID).

 

Typo: in section 4, "section 6.1.14 of [RFC4657]" -> = "section=20 5.1.14 of.."

 

Thanks

 =20 Filippo

 

 

------=_NextPart_000_0026_01C8D787.7DEF9830-- --===============0735066835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0735066835==-- From pce-bounces@ietf.org Thu Jun 26 08:40:03 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D5F28C149; Thu, 26 Jun 2008 08:40:03 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AE128C144 for ; Thu, 26 Jun 2008 08:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+6W6oReKGzb for ; Thu, 26 Jun 2008 08:39:53 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 1ADB83A67D0 for ; Thu, 26 Jun 2008 08:39:53 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3200EWWU6J3C@usaga04-in.huawei.com> for pce@ietf.org; Thu, 26 Jun 2008 10:39:56 -0500 (CDT) Received: from L73682 ([10.124.12.97]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3200JOIU6CCV@usaga04-in.huawei.com> for pce@ietf.org; Thu, 26 Jun 2008 10:39:55 -0500 (CDT) Date: Thu, 26 Jun 2008 10:39:48 -0500 From: Young Lee In-reply-to: <002901c8d776$ba826680$a9021e0a@Platini> To: 'Filippo Cugini' Message-id: <001e01c8d7a2$de5f9920$610c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjXds1EQLYEnfnAS3uMvVJRC6Mv8QAKQQjw References: <000201c8d621$ca7ccae0$610c7c0a@china.huawei.com> <042a01c8d6a5$3fa9a710$a9021e0a@Platini> <002301c8d700$026f9ca0$610c7c0a@china.huawei.com> <002901c8d776$ba826680$a9021e0a@Platini> Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1076720689==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============1076720689== Content-type: multipart/alternative; boundary="Boundary_(ID_j+J7pKrzP15k8j1gdFrcAg)" This is a multi-part message in MIME format. --Boundary_(ID_j+J7pKrzP15k8j1gdFrcAg) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Filippo, The reason for the RRO inclusion in PCReq in draft-ietf-pce-pcep-12.txt is because the PCE is stateless. As far as I know, all the PCE drafts and RFCs assume that PCE is stateless. Thanks for your review on the latest GCO draft, I will make some corrections to make it consistent. Regards, Young _____ From: Filippo Cugini [mailto:filippo.cugini@cnit.it] Sent: Thursday, June 26, 2008 5:24 AM To: Young Lee Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update Hi, please see in-line. 1) in case of stateful PCE, is it mandatory to include the full list of RROs in the PCReq message? Young>> I am not sure of your definition of stateful PCE. If you mean stateful PCE to be the PCE that keeps the state of the active LSPs at the PCE, this is beyond the scope of PCEP in IETF. Nonetheless, if this is what you mean by stateful PCE, I am not sure why you need to send the full list of RROs in the PCReq message since the PCE keeps such information with stateful PCE. When you want to do re-optimization with stateless PCE, you need to send the full list of RROs of the LSPs to be re-optimized in the PC Req message. This way PCE needs not maintain the state of LSPs at the PCE level. Filippo>> agree that in case of Stateful PCE (yes, the one that keeps the state of active LSPs) there is no need to send the full list, however, in draft-ietf-pce-pcep-12.txt, section 7.4.1 and .2, it is reported that in case of re-optimization, PCReq messages MUST include RROs. 2) In section 2, Terminology, GCO is defined to consider only the entire network, while in the rest of the document also network subsets are allowed. Is the use of "Global" associated to both the cases of entire network and network subsets or is it just related to the entire network? Young>> Although GCO considers the entire network in general case, there are applications of GCO where only a subset of TE LSPs can be re-optimized. This has a protocol support. I believe you are quoting the statement in the Introduction, "Alternatively, the application may consider a subset of the LSPs and/or a subset of the network topology." I may have to delete the last clause. This can be achieved, but we don't have ways to limit the whole topology into a subset in the current PCEP for GCO. Are you aware of any good application for this case? Filippo>> Yes, exactly that statement in the introduction which should become consistent with the rest of the document. To restrict the computation to a network subset, a possible solution could be the use of IRO object, e.g. specifying theIP prefix or AS number (don't know how to indicate Area ID). Typo: in section 4, "section 6.1.14 of [RFC4657]" -> "section 5.1.14 of.." Thanks Filippo --Boundary_(ID_j+J7pKrzP15k8j1gdFrcAg) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable

Hi Filippo, =

 

The reason for the RRO inclusion in = PCReq in draft-ietf-pce-pcep-12.txt is because the PCE is stateless. As far as = I know, all the PCE drafts and RFCs assume that PCE is stateless. Thanks = for your review on the latest GCO draft, I will make some corrections to make it consistent.

 

Regards,

Young

 

From: = Filippo Cugini [mailto:filippo.cugini@cnit.it]
Sent: Thursday, June 26, = 2008 5:24 AM
To: Young Lee
Cc: pce@ietf.org
Subject: Re: [Pce] PCE = GCO update

 

Hi,=

please see in-line.

 

 

1) in case of stateful PCE, is it mandatory to = include the full list of RROs in the PCReq message?

 

Young>> I am not sure of your definition of stateful PCE. If you mean stateful PCE to be the PCE that = keeps the state of the active LSPs at the PCE, this is beyond the scope of = PCEP in IETF. Nonetheless, if this is what you mean by stateful PCE, I am not = sure why you need to send the full list of RROs in the PCReq message since the PCE = keeps such information with stateful PCE. When you want to do re-optimization = with stateless PCE, you need to send the full list of RROs of the LSPs to be re-optimized in the PC Req message. This way PCE needs not maintain the = state of LSPs at the PCE level.   

 

Filippo>> agree that in case = of Stateful PCE (yes, the one that keeps the state of active LSPs) there is = no need to send the full list, however, in draft-ietf-pce-pcep-12.txt, section 7.4.1 and .2, it is reported that in case of re-optimization, = PCReq messages MUST include RROs.

 

 

2) In section 2, Terminology, GCO is defined to = consider only the entire network, while in the rest of the document also network = subsets are allowed.

Is the use of "Global" associated to both = the cases of entire network and network subsets or is it just related to the = entire network?

 

Young>> Although GCO = considers the entire network in general case, there are applications of GCO where only = a subset of TE LSPs can be re-optimized. This has a protocol support. I believe = you are quoting the statement in the Introduction, “Alternatively, the application may consider a subset of = the LSPs and/or a subset of the network topology.” I may have to = delete the last clause. This can be achieved, but we don’t have ways to limit = the whole topology into a subset in the current PCEP for GCO. Are you aware = of any good application for this case?

 

Filippo>> Yes, exactly that statement in the introduction which should become consistent with the = rest of the document.

To restrict the computation to a = network subset, a possible solution could be the use of IRO object, e.g. = specifying theIP prefix or AS number (don't know how to indicate Area = ID).

 

Typo: in section 4, "section = 6.1.14 of [RFC4657]" -> "section 5.1.14 = of.."

 

Thanks

Filippo

=

 

 

 

--Boundary_(ID_j+J7pKrzP15k8j1gdFrcAg)-- --===============1076720689== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1076720689==-- From pce-bounces@ietf.org Fri Jun 27 05:50:32 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D733A68EF; Fri, 27 Jun 2008 05:50:32 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70CA3A68B3 for ; Fri, 27 Jun 2008 05:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOgbHOhHleBz for ; Fri, 27 Jun 2008 05:50:31 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CE6C83A67F1 for ; Fri, 27 Jun 2008 05:50:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,715,1204520400"; d="scan'208,217";a="12448800" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Jun 2008 08:50:34 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5RCoYAc000892 for ; Fri, 27 Jun 2008 08:50:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5RCoYQJ020482 for ; Fri, 27 Jun 2008 12:50:34 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 08:50:34 -0400 Received: from 10.21.78.247 ([10.21.78.247]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Jun 2008 12:50:34 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 27 Jun 2008 14:50:33 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: PCE WG Meeting in Dublin Thread-Index: AcjYVGMCByywYPqAXUemQUD437HJqA== Mime-version: 1.0 X-OriginalArrivalTime: 27 Jun 2008 12:50:34.0667 (UTC) FILETIME=[64008FB0:01C8D854] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=815; t=1214571034; x=1215435034; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20PCE=20WG=20Meeting=20in=20Dublin |Sender:=20 |To:=20; bh=jmmea8el5beHVctQNsmIrC3rZS3HzqzZzHGkJx7dL0s=; b=cAJxrbGC8ONq29VFb/Q4Pipw0NFZ59/2cQ5PDQTz9NZxuJKM9jaRcK04ew w1Rjc1DGj4nB8pgwq6LsSRPXvy90mNlf/0sDSew5Nn0o/ZZObLglT8VNbo4O 90GG8wvITQ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Pce] PCE WG Meeting in Dublin X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0983294944==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0983294944== Content-type: multipart/alternative; boundary="B_3297423033_13634178" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3297423033_13634178 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Please let us know if you would like to request a slot for the PCE WG in Dublin. Thanks JP and Adrian. --B_3297423033_13634178 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable PCE WG Meeting in Dublin Dear WG,

Please let us know if you would like to request a slot for the PCE WG in Du= blin.

Thanks

JP and Adrian. --B_3297423033_13634178-- --===============0983294944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0983294944==-- From pce-bounces@ietf.org Sun Jun 29 15:59:49 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717BF3A6A60; Sun, 29 Jun 2008 15:59:49 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE083A6A60 for ; Sun, 29 Jun 2008 15:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRHDfa37mGty for ; Sun, 29 Jun 2008 15:59:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 3478B3A6A2D for ; Sun, 29 Jun 2008 15:59:44 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m5TMxbsd022850; Sun, 29 Jun 2008 23:59:39 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m5TMxZCQ022840; Sun, 29 Jun 2008 23:59:36 +0100 Message-ID: <047901c8da3b$cae0b9b0$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Young Lee" , "'JP Vasseur'" References: <000201c8d621$ca7ccae0$610c7c0a@china.huawei.com> Date: Sun, 29 Jun 2008 23:59:27 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: Re: [Pce] PCE GCO update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Young, Here is my review as promised... Cheers, Adrian ==== idnits (http://tools.ietf.org/tools/idnits/) gives the following errors and warnings... == Missing Reference: 'RFC5058' is mentioned on line 186, but not defined == Missing Reference: 'RFC5059' is mentioned on line 186, but not defined == Missing Reference: 'ISIS PCED' is mentioned on line 858, but not defined == Missing Reference: 'OSPF PCED' is mentioned on line 858, but not defined == Unused Reference: 'ISIS-PCED' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'OSPF-PCED' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'PCE-MLN' is defined on line 1023, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pce-brpc-05 -- Possible downref: Normative reference to a draft: ref. 'PCE-OF' (No intended status found in state file of draft-leroux-pce-of) == Outdated reference: A later version (-05) exists of draft-ietf-pce-pcep-xro-00 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 ** Downref: Normative reference to an Informational RFC: RFC 4674 == Outdated reference: draft-ietf-pce-disco-proto-isis has been published as RFC 5089 == Outdated reference: draft-ietf-pce-disco-proto-ospf has been published as RFC 5088 ==== Philosophy... Please add to the Abstract *and* Introduction some comment like... While GCO is applicable to any simultaneous request for multiple LSPs (for example, a request for end-to-end protection), it is not invisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of LSPs (churn) is not advised because of the likelihood that LSPs would change before they could be gloablly reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. I hope that this sort of text is not in oposition to your intentions. I believe it will go a long way toward calming some of the concerns about this document. the distinction I am trying to draw is in the applicability of global optimization and global reoptimization. ==== Abstract The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. Suggest you add... In this context a PCC may be a Label Switching Router (LSR), an Network management Station (NMS), or another PCE. ==== Section 1 para 1 s/(LSP)/(LSPs)/ ==== Section 1 I would suggest reversing the order of paragraphs 5 and 6. As currently presented, it appears that the reoptimization issue is a larger usage than the provisioning/planning use. However, as per my suggested text for the Abstract and Introduction, the provisioning/planning use can be applied in any network, while reoptimization may not be appropriate in some networks. You might also re-order sections 3.2 and 3.3 for the same reasons. ==== Philosophy... Is "Global" causing problems in discussions? The word implies that *all* LSPs must be concurrently optimized. As in plain from this I-D, you allow global, but you also allow a subset or batch dropping down to just two LSPs as the extreme minimum case. I know that GCO rolls off the tongue nicely, but is it too late to change this to just "concurrent optimization"? ==== Section 1 final paragraph s/BRPC/Backward Recursive Path Computation (BRPC)/ ==== Section 3.1 s/protocol, this/protocol; this/ ==== Section 3.1 This is the first section to mention "algorithms". I suggest you add something like. Various algorithms and computation techniques have been proposed to perform this function. Specification of such algorithms or techniques is outside the scope of this document. ==== Section 3.2 You use the term "sequential re-optimization". Could you introduce the term or explain it. ==== Section 3.2 s/with giving no/without giving any/ ==== Section 3.2 You have With regards to applicability of GCO in the event of catastrophic failures, there may be a real benefit in computing the paths of the LSPs as a set rather than computing new paths from the head-end LSRs in a distributed manner. It is to be noted, however, that a centralized system will typically suffer from a slower response time than a distributed system. You may want to give some comment on the cost/benefit of this. ==== Section 3.2.1 It might be good to reference draft-ietf-pce-inter-layer-frwk as this is a PCE working group draft with a wider discussion of VNT. ==== Section 3.2.2 first paragraph I understand the point you are making, but it could be more clearly made. You have: However, the PCE may be able to determine an order of LSP rerouting actions so that make-before-break can be performed within the limited resources. What about... However, a PCE may be able to determine a sequence of make-before- break replacement of individual LSPs or small sets of LSPs so that the full set of LSPs can be migrated without any disruption. ==== Section 3.3 OLD Greenfield optimization is a special case of GCO application when there is no LSP setup. Once the LSPs are setup, it is not a greenfield. The need for greenfield arises when network planner will want to make use of computation servers to plan the LSPs that will be provisioned in the network. NEW Greenfield optimization is a special case of GCO application when there are no LSPs already set up in the network. The need for greenfield optimization arises when network planner wants to make use of a computation server to plan the LSPs that will be provisioned in the network. ==== Section 3.3 s/green-field/greenfield/ s/a set of TE LSPs need/a set of TE LSPs needs/ ==== Section 3.3 OLD Under this scenario, concurrent computation ability is highly desirable, or required, to utilize network resources in an optimal manner and avoid blocking risks. NEW In this scenario, the ability to perform concurrent computation is desirable, or required, to utilize network resources in an optimal manner and avoid blocking. ==== Section 3.3.1 s/green-field/greenfield/ ==== Section 3.3.1 OLD For example, MPLS-TE network can be established based on layer 3 specific traffic demand, network topology, and network resources. NEW For example, an MPLS-TE network can be planned based on layer 3 traffic demands, the network topology, and available network resources. ==== Section 3.3.2 Add a reference to draft-ietf-pce-inter-layer-frwk ==== Section 4 Please reconcile the two objective functions you have defined with the three (numbers 4, 5, and 6) defined in draft-ietf-pce-of. A forward reference to section 5.1 might help. ==== Backward compatibility I would like to see some discussion of what happens if a PCE doesn't support GCO. How will it treat a request and will it be graceful? Note that error 15/2 doesn't do it because a legacy PCE does not know to send this error. ==== Section 4 s/When the PCE could not find a feasible/When the PCE cannot find a feasible/ ==== Section 4 It might also be desirable to have the PCE indicate whether ordering is in fact required or not. Is that "might" actually "MAY"? ==== Section 4 s/The request message must allow/The request message MUST allow/ ==== Section 5 Please capitalise the section heading ==== Section 5 I'm a little confused as to which is the normative document for defining the placement of in the . This document of draft-ietf-pce-of? ==== Section 5 final paragraph s/should/SHOULD/ s/RRO object/Reported Route Object (RRO)/ ==== Section 5.1 final paragraph s/i.)/i./ ==== Section 5.3 Please capitalise the section heading ==== Section 5.4 The delete order should not be equal to the setup order. Is that "SHOULD"? ==== Section 5.4 s/To illustrate,/To illustrate this,/ ==== Section 5.4 two established requests Hmmm. LSPs can be established, not requests. ==== Section 5.5 Please be consitent between GLOBAL CONSTRAINTS Object Global Constraints Object GLOBAL CONSTRAINT Object ==== Section 5.5 I *really* don't like the full 32 bits of Reserved field. This is highly unusual. At the very least you must justify it. By preference you should remove it. ==== Section 5.6 s/is not capable of the request/is not capable of processing the request/ ==== Section 5.6 For a couple of errors, you have... The corresponding global concurrent path optimization request MUST be cancelled. This is an error from the PCE, right? So what does "MUST be cancelled" mean? Do you mean: The PCE stops processing the request. ==== Sections 6.4 and 6.6 s/does not/do not/ ==== ----- Original Message ----- From: "Young Lee" To: "'JP Vasseur'" ; "'Adrian@OldDog'" Cc: Sent: Tuesday, June 24, 2008 6:43 PM Subject: PCE GCO update > Hi J-P and Adrian, > > > > Here's the update of PCE GCO draft. As per requested in Philadelphia, this > is ready for the WG chair's review and the last call. Please note section > 9 > for IANA considerations and new objects/TLV/Flags have been defined. I'd > appreciate your review and look forward to making progress on this work to > the next stage. Thanks. > > > > I snipped Section 9 below. Thanks. > > > > Regards, > > Young > > -----------snipped---------------------------------------- > > > > 9. IANA Considerations > > > > IANA maintains a registry of PCEP parameters. IANA is requested to > > make allocations from the sub-registries as described in the > > following sections. > > > > 9.1. Request Parameter Bit Flags > > > > As described in Section 5.3, two new bit lfags are defined for > > inclusion in the Flags field of the RP object. IANA is requested to > > make the following allocations from the "Request Parameter Bit Flags" > > sub-registry. > > > > > > Bit Name Description Reference > > > > 11 D-bit Report the request order [This.I-D] > > 12 M-bit Make-before-break [This.I-D] > > > > > > 9.2. New PCEP TLV > > > > As described in Section 5.4, a new PCEP TLV is defined to indicate > > the setup and delete order of LSPs in a GCO. IANA is requested to > > make the following allocation from the "PCEP TLV Types" sub-registry. > > > > > > TLV Type Meaning Reference > > > > 5 Order TLV [This.I-D] > > > > > > 9.3. New PCEP Object > > > > As descried in Section 5.5, a new PCEP object is defined to carry > > global constraints. IANA is requested to make the following > > allocation from the "PCEP Objects" sub-registry. > > > > > > Object Name Reference > > Class > > > > 24 GLOBAL-CONSTRAINTS [This.I-D] > > Object-Type > > 1: Global Constraints [This.I-D] > > > > 9.4. New PCEP Error Codes > > > > As described in Section 5.6, new PCEP error codes are defined for GCO > > errors. IANA is requested to make allocations from the "PCEP Error > > Types and Values" sub-registry as set out in the following sections. > > > > 9.4.1. New Error-Values for Existing Error-Types > > > > > > Error > > Type Meaning Reference > > > > 5 Policy violation > > Error-value=5: [This.I-D] > > Global concurrent optimization not allowed > > > > > > 9.4.2. New Error-Types and Error-Values > > > > > > Error > > Type Meaning Reference > > > > 15 Global Concurrent Optimization Error [This.I-D] > > Error-value=1: > > Insufficient memory [This.I-D] > > Error-value=2: > > Global concurrent optimization not supported > > [This.I-D] > > > > > > 9.5. New No-Path Reasons > > > > IANA is requested to make the following allocations from the "No-Path > > Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV > > in the PCEP NO-PATH object as described in Section 5.7. > > > > Bit > > Number Name Reference > > > > 6 No GCO migration path found [This.I-D] > > 7 No GCO solution found [This.I-D] > > > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jun 30 10:52:48 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064B83A6AF8; Mon, 30 Jun 2008 10:52:48 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8C5993A68B2; Mon, 30 Jun 2008 10:52:45 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080630175245.8C5993A68B2@core3.amsl.com> Date: Mon, 30 Jun 2008 10:52:45 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-pcep-xro (Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-xro-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15918&rfc_flag=0 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jun 30 15:15:02 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE11A3A6AE2; Mon, 30 Jun 2008 15:15:02 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2DDB73A6AFB; Mon, 30 Jun 2008 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080630221501.2DDB73A6AFB@core3.amsl.com> Date: Mon, 30 Jun 2008 15:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-ext-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, J. Le Roux, A. Farrel Filename : draft-ietf-pce-inter-layer-ext-01.txt Pages : 13 Date : 2008-6-30 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-ext-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-30150409.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart--