From pce-bounces@lists.ietf.org Mon May 01 16:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FafTp-0008AV-V1; Mon, 01 May 2006 16:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FafTo-00089p-2A; Mon, 01 May 2006 16:58:52 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FafTm-0005Gn-R9; Mon, 01 May 2006 16:58:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k41KwfBX019286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 20:58:41 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FafTd-0002Ps-4k; Mon, 01 May 2006 16:58:41 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 01 May 2006 16:58:41 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'A Path Computation Element (PCE) Based Architecture' to Informational RFC X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org The IESG has approved the following document: - 'A Path Computation Element (PCE) Based Architecture ' as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-05.txt Technical Summary This document specifies the architecture for a Path Computation Element (PCE)-based model to address the problem of path computation in large, multi-domain, multi-region or multi-layer networks. This document describes a set of building blocks for the PCE architecture from which solutions may be constructed. Working Group Summary The WG had a consensus on progressing this document. Protocol Quality Alex Zinin Reviewed this document for the IESG. Note to RFC Editor There are a few nits that should be fixed prior to publication: Nit1>> Section 6.8, third paragraph, Second sentence: However, in a single centralized PCE environment, a stateful PCE is almost a simple matter of remembering all of the TE LSPs the PCE has computed, if it can also be known that the TE LSPs were actually set up, and when they were torn down. This should read: However, in a single centralized PCE environment, a stateful PCE is almost a simple matter of remembering all of the TE LSPs the PCE has computed, that the TE LSPs were actually set up (if this can be known), and when they were torn down. Nit2>> From section 6.8, (I think the seventh paragraph, at the bottom of page 23): A limited form of statefulness might be applied within an otherwise stateful PCE. This should read: A limited form of statefulness might be applied within an otherwise stateless PCE. Nit3>> Section 10, first paragraph, second sentence: There is unlikely to be any impact on intra-domain security, but... This should read: The impact may be less likely to be an issue in the case of intra-domain use of PCE, but ... _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon May 01 19:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fahsx-00067S-SH; Mon, 01 May 2006 19:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fahsw-00067N-ST for pce@ietf.org; Mon, 01 May 2006 19:32:58 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fahss-000419-Ew for pce@ietf.org; Mon, 01 May 2006 19:32:58 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FahsV-0003s9-00 for pce@ietf.org; Tue, 02 May 2006 00:32:31 +0100 Received: from youref3aa80866 ([217.158.132.149] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 00:33:11 +0100 Message-ID: <01cd01c66d78$559159d0$020210ac@youref3aa80866> From: "Adrian Farrel" To: "JP Vasseur" , "LE ROUX Jean-Louis RD-CORE-LAN" References: <4CA3EE07-6890-452C-AE6B-BD8EA4128412@cisco.com> Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for theCPSID. Date: Mon, 1 May 2006 17:51:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 01 May 2006 23:33:12.0734 (UTC) FILETIME=[9CE3ABE0:01C66D77] X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ccamp@ops.ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, Sorry that I haven't been following this too closely. Jean Louis made a couple of interesting points... >>PCE WG members: thanks to provide your feedback on whether: >>(1) You think that there is a need for such solution, > >Yes definitely, confidentiality is a key requirements in an inter-provider >context. > >>(2) You would prefer one solution (which one and why ?) >>(3) You think that there is a need for both > >Answer to (2) and (3): > >It seems to me that we should end-up with a single solution so as to ease >interworking. Of course, interworking is important and options are generally a Bad Thing (TM), but if the different solutions are beneficial in different environments then we can easily specify support for both options as mandatory. There will, in any case, be a policy decision at an domain border router to say how (and if) to process and encryption/path key. So, for me, the question is whether there are different environments under which each of the options is preferable. > IMO in an inter-AS MPLS-TE environment without PCEs, the paths > will be loose anyway, so there will not be any confidentiality issue. I am not sure. The point we are trying to make is that, in order to determine a viable (not to mention optimal) end-to-end path, it will have been necessary to compute the entire path. This may have been achieved privately by independent (albeit cooperating) PCEs. In this case I think we are agreed that the full path would not be passed back to the ingress PCC for signaling, and so loose hops or strict abstract nodes would be used. But the question is what to do with the computed information so that it is not necessary to recompute when the signaling message enters the domain. One option, as you suggest, is to send it out to the domain border routers in anticipation of a signaling message (and potentially use a key to unlock it), a second option is to retain the information on the PCE and look it up using a key. The third option is to encrypt the path. It seems to me that the first option requires the second to handle races, memory over-load, etc. So, in fact, the first option is an implementation optimization (but we may still need to make protocol changes to ensure that it is supported). And my question reduces to: Are there any circmstances under which ERO encryption is of value to us? > If have some concerns regarding the cost of encryption, particularly for > large paths (we need to think about future P2MP applications with a > large number of hops...). I am not so sure that the encryption of an ERO is so significant using today's technology. Indeed, one might equally argue that the cost of distributing a large number of paths for multiple destinations to several domain entry points could also be high. > By the way, encryption approaches are really vulnerable > to DoS attacks. This sounds really important. What you mean is presumably that we could waste a lot of CPU decrypting an ERO that is bogus. But why is this more of a problem than receiving a bogus LSP setup request that causes us to do extra computation? Or a Path message with a bogus path key that causes us to consult the local PCE for a non-existent path? > Hence I would strongly favor the PKS solution. The optimization > suggested, which consists of sending the computed path segment > to the LSR in an unsolicited manner, just after the computation, > sounds relevant and should be further investigated. I think this is a valid application, but I would not want to see it made *the* standard technique since it gives me scaling worries for the future. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 04 16:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkOo-0004pT-4q; Thu, 04 May 2006 16:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkOm-0004pO-VV for pce@ietf.org; Thu, 04 May 2006 16:26:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbkOk-0005LF-CK for pce@ietf.org; Thu, 04 May 2006 16:26:08 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 May 2006 16:26:06 -0400 X-IronPort-AV: i="4.05,89,1146456000"; d="scan'208,217"; a="87916677:sNHT54904836" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k44KQ5TL017894; Thu, 4 May 2006 16:26:05 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 16:26:05 -0400 Received: from [161.44.71.221] ([161.44.71.221]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 16:26:04 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) References: Message-Id: <37080E54-B829-4669-9E78-7F7DAD7D3562@cisco.com> From: JP Vasseur Date: Thu, 4 May 2006 16:26:03 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 20:26:04.0774 (UTC) FILETIME=[F7BE3060:01C66FB8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com Subject: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1841492653==" Errors-To: pce-bounces@lists.ietf.org --===============1841492653== Content-Type: multipart/alternative; boundary=Apple-Mail-125-963439238 --Apple-Mail-125-963439238 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, As agreed during our last WG meeting in Dallas (see the discussion with Adrian, acting as CCAMP co-chair), we moved that ID in PCE WG. We took that opportunity to make several changes based on the comments that we received so far. So new text has been added for clarification, we reworded some sections and more importantly, we removed the specification of the VSPT object and replaced it by a 1- bit new flag in the RP object defined in PCEP. Comments very welcome. JP, Raymond, Nabil and Jean-Louis. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: May 4, 2006 3:50:01 PM EDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Backward Recursive PCE-based Computation > (BRPC) procedure to compute shortest inter- > domain Traffic Engineering Label Switched > Paths > Author(s) : J. Vasseur, et al. > Filename : draft-vasseur-pce-brpc-00.txt > Pages : 14 > Date : 2006-5-4 > > This document specifies a Path Computation Element (PCE)-based > procedure to compute inter-domain constrained shortest Traffic > Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. In this > document a domain is referred to as a collection of network > elements > within a common sphere of address management or path computational > responsibility such as IGP areas and Autonomous Systems. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-vasseur-pce-brpc-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-5-4145941.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-125-963439238 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear WG,

As agreed during our last = WG meeting in Dallas (see the discussion with Adrian, acting as CCAMP = co-chair), we moved that ID in PCE WG. We took that opportunity to make = several changes based on the comments that we received so far. So new = text has been added for clarification, we reworded some sections and = more importantly, we removed the specification of the VSPT object and = replaced it by a 1-bit new flag in the RP object defined in = PCEP.

Comments = very welcome.

JP, Raymond, Nabil and = Jean-Louis.

Begin forwarded message:

Date: May 4, 2006 3:50:01 PM = EDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-vasseur-pce-brpc-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts directories.


Title : A Backward Recursive PCE-based = Computation=A0
=A0=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (BRPC) procedure to compute = shortest inter-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 domain Traffic Engineering Label Switched = Paths
Author(s) : J. = Vasseur, et al.
Filename : = draft-vasseur-pce-brpc-00.txt
= Pages = = : 14
Date : 2006-5-4

=A0=A0 This document specifies a = Path Computation Element (PCE)-based
=A0=A0 procedure to compute = inter-domain constrained shortest Traffic
=A0=A0 Engineering (TE) Label = Switched Paths (LSPs) in Multiprotocol Label
=A0=A0 = Switching (MPLS) and Generalized MPLS (GMPLS) networks.=A0 In this
=A0=A0 = document a domain is referred to as a collection of network = elements
=A0=A0 within a common sphere of = address management or path computational
=A0=A0 responsibility such as IGP = areas and Autonomous Systems.



A URL = for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt

To = remove yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of the message. =A0
to = change your subscription settings.


Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" = and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get = draft-vasseur-pce-brpc-00.txt".

A list of Internet-Drafts = directories can be found in

Internet-Drafts can also be obtained by = e-mail.

Send a message to:
In the body type:
"FILE = /internet-drafts/draft-vasseur-pce-brpc-00.txt".

NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

= =
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

=

= --Apple-Mail-125-963439238-- --===============1841492653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1841492653==-- From pce-bounces@lists.ietf.org Fri May 05 16:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc71S-0007cz-5T; Fri, 05 May 2006 16:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc71R-0007cY-HM for pce@ietf.org; Fri, 05 May 2006 16:35:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc71R-0000KC-6S for pce@ietf.org; Fri, 05 May 2006 16:35:33 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fc71Q-0003He-EW; Fri, 05 May 2006 20:35:32 +0000 Message-ID: <445BB718.5020008@psg.com> Date: Fri, 05 May 2006 22:35:36 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt References: <37080E54-B829-4669-9E78-7F7DAD7D3562@cisco.com> In-Reply-To: <37080E54-B829-4669-9E78-7F7DAD7D3562@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org jp - not sure to really understand what you mean "we moved that ID in PCE WG" from the minutes (IETF 65): "Next steps: - More discussion on the list - Is there a need for OAM/MIB to troubleshot procedure - Adopt as WG document?" thanks to clarify ? - d. JP Vasseur wrote: > Dear WG, > > As agreed during our last WG meeting in Dallas (see the discussion with > Adrian, acting as CCAMP co-chair), we moved that ID in PCE WG. We took > that opportunity to make several changes based on the comments that we > received so far. So new text has been added for clarification, we > reworded some sections and more importantly, we removed the > specification of the VSPT object and replaced it by a 1- bit new flag in > the RP object defined in PCEP. > > Comments very welcome. > > JP, Raymond, Nabil and Jean-Louis. > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: May 4, 2006 3:50:01 PM EDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : A Backward Recursive PCE-based Computation >> (BRPC) procedure to compute shortest inter- >> domain Traffic Engineering Label Switched >> Paths >> Author(s) : J. Vasseur, et al. >> Filename : draft-vasseur-pce-brpc-00.txt >> Pages : 14 >> Date : 2006-5-4 >> >> This document specifies a Path Computation Element (PCE)-based >> procedure to compute inter-domain constrained shortest Traffic >> Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label >> Switching (MPLS) and Generalized MPLS (GMPLS) networks. In this >> document a domain is referred to as a collection of network elements >> within a common sphere of address management or path computational >> responsibility such as IGP areas and Autonomous Systems. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-vasseur-pce-brpc-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-5-4145941.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 05 17:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc8BN-0007si-9o; Fri, 05 May 2006 17:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc8BL-0007sd-FL for pce@ietf.org; Fri, 05 May 2006 17:49:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc8BJ-0003HO-3w for pce@ietf.org; Fri, 05 May 2006 17:49:51 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 May 2006 17:49:49 -0400 X-IronPort-AV: i="4.05,93,1146456000"; d="scan'208"; a="88000929:sNHT33409872" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k45LnmvF025678; Fri, 5 May 2006 17:49:48 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 May 2006 17:49:47 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 May 2006 17:49:46 -0400 In-Reply-To: <445BB718.5020008@psg.com> References: <37080E54-B829-4669-9E78-7F7DAD7D3562@cisco.com> <445BB718.5020008@psg.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CB3A9AE-5816-4CC2-BD1F-53A87024C169@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt Date: Fri, 5 May 2006 17:49:45 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 05 May 2006 21:49:47.0118 (UTC) FILETIME=[D3B4D0E0:01C6708D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, On May 5, 2006, at 4:35 PM, dimitri papadimitriou wrote: > jp - > > not sure to really understand what you mean "we moved that ID in > PCE WG" > The draft was originally named draft-XXX-ccamp and targeted to be discussed in CCAMP. Since the procedure is PCE-specific (although it applies to Inter-domain that belongs to CCAMP), it was decided to discuss this ID in the PCE WG with a review of CCAMP. > from the minutes (IETF 65): > > "Next steps: > > - More discussion on the list Yes, hence my email seeking for comments. > - Is there a need for OAM/MIB to troubleshot procedure Still an open question ... Do you have opinion on this ? > - Adopt as WG document?" > Thanks. JP. > thanks to clarify ? > - d. > > JP Vasseur wrote: > >> Dear WG, >> As agreed during our last WG meeting in Dallas (see the >> discussion with Adrian, acting as CCAMP co-chair), we moved that >> ID in PCE WG. We took that opportunity to make several changes >> based on the comments that we received so far. So new text has >> been added for clarification, we reworded some sections and more >> importantly, we removed the specification of the VSPT object and >> replaced it by a 1- bit new flag in the RP object defined in PCEP. >> Comments very welcome. >> JP, Raymond, Nabil and Jean-Louis. >> Begin forwarded message: >>> From: Internet-Drafts@ietf.org >>> Date: May 4, 2006 3:50:01 PM EDT >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet- >>> Drafts directories. >>> >>> >>> Title : A Backward Recursive PCE-based Computation >>> (BRPC) procedure to compute shortest inter- >>> domain Traffic Engineering Label >>> Switched Paths >>> Author(s) : J. Vasseur, et al. >>> Filename : draft-vasseur-pce-brpc-00.txt >>> Pages : 14 >>> Date : 2006-5-4 >>> This document specifies a Path Computation Element (PCE)- >>> based >>> procedure to compute inter-domain constrained shortest Traffic >>> Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol >>> Label >>> Switching (MPLS) and Generalized MPLS (GMPLS) networks. In this >>> document a domain is referred to as a collection of network >>> elements >>> within a common sphere of address management or path >>> computational >>> responsibility such as IGP areas and Autonomous Systems. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>> announce >>> to change your subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with >>> the username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-vasseur-pce-brpc-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt". >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> Below is the data which will enable a MIME >>> compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2006-5-4145941.I-D@ietf.org> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 09 09:54:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSfA-0005ls-Oa; Tue, 09 May 2006 09:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSf9-0005ln-5b for pce@ietf.org; Tue, 09 May 2006 09:54:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdSf7-0001sB-B5 for pce@ietf.org; Tue, 09 May 2006 09:54:07 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 May 2006 09:54:05 -0400 X-IronPort-AV: i="4.05,106,1146456000"; d="scan'208,217"; a="88181306:sNHT60130832" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k49Ds4TL025546; Tue, 9 May 2006 09:54:04 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 09:54:04 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 09:54:03 -0400 In-Reply-To: <70BC84B185C3EE448EDB7AB8956D3B0E01ACF593@xmb-sjc-234.amer.cisco.com> References: <70BC84B185C3EE448EDB7AB8956D3B0E01ACF593@xmb-sjc-234.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: From: JP Vasseur Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt Date: Tue, 9 May 2006 09:54:00 -0400 To: Dean Cheng ((dcheng)) X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 09 May 2006 13:54:03.0323 (UTC) FILETIME=[07EE58B0:01C67370] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1896065604==" Errors-To: pce-bounces@lists.ietf.org --===============1896065604== Content-Type: multipart/alternative; boundary=Apple-Mail-35--775567205 --Apple-Mail-35--775567205 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Dean, Many thanks for your comments. Replies/Discussion in line, - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple domains. DC2 - This is practically true but if not, the BRPC procedure can still be used. JP>> Yes, but we want to clarify the fact BRPC does not require any topology or resource information distribution across domains. We'll reword to clarify. - While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. DC3 - This may also be relaxed as an assumption. These constraints may be globally or locally (thus may need mapping) defined, but in either case, the BRPC procedure may be applied. JP>> Well at least not for the cost metric that must be consistent to compute the shortest inter-domain constrained path. You're right that other metrics apply to the general inter-domain case and are not specific to BRPC. - Each AS can be made of several IGP areas. The path computation procedure described in this document applies to the case of a single AS made of multiple IGP areas, multiples ASs made of a single IGP area or any combination of the above. For the sake of simplicity, each AS will be considered to be comprised of a single area in this document. The case of an Inter-AS TE LSP spanning multiple ASs where some of those ASs are themselves made of multiple IGP areas can be easily derived from this case by applying the BRPC procedure described in this document, recursively. DC4 - The BRPC procedure in general can be applied to any network partitions in the context of (G-)MPLS networks, and so this paragraph could be moved to the Intruduction, and at least not a hard assumption. JP>> Agree. - The domain path (set of domains traversed to reach the destination domain) is either administratively pre-determined or discovered by some means (outside of the scope of this document). DC5 - What does this mean ? Thought the domain path is calculated by the BRPC procedure. JP>> nope, the BRPC computes the optimal (shortest) path between a source S in Domain A to destination D in Domain B, along a determined domain path (can be pre-determined or discovered during the BRPC procedure). But, BRPC does not attempt to discover all the domain- path, compute for each domain path the best path and return the absolute best path. DC10 Thr BRPC procedure may return x number of path segments where x equals the number of equal cost paths (ECMP), where two parameters may be configurable based on carriers policy. The first is the max number for x, and the second is the approximates of these paths (costs are exactly the same or close enough). JP> Do you see a strong reason for limiting x ? The second requirement might indeed be interesting. WG, any feed-back on this ? DC11 - It could be reworded to say: After accommodating local policy that may be associated with domains that a LSP may traverse, if any, the BRPC would guarantee the optimality of inter-domain paths end-to-end. JP> Not quite sure to see your point here ? Thanks for your comments. JP. On May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote: > Dear Authors, > > I've got some quick feedback please see the attached (lines inserted > starting with DC). > > Cheers, > Dean > > From: Jean Philippe Vasseur (jvasseur) > Sent: Thursday, May 04, 2006 1:26 PM > To: pce@ietf.org > Cc: raymond_zhang@bt.infonet.com; nabil.n.bitar@verizon.com > Subject: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt > > Dear WG, > > As agreed during our last WG meeting in Dallas (see the discussion > with Adrian, acting as CCAMP co-chair), we moved that ID in PCE WG. > We took that opportunity to make several changes based on the > comments that we received so far. So new text has been added for > clarification, we reworded some sections and more importantly, we > removed the specification of the VSPT object and replaced it by a 1- > bit new flag in the RP object defined in PCEP. > > Comments very welcome. > > JP, Raymond, Nabil and Jean-Louis. > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: May 4, 2006 3:50:01 PM EDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : A Backward Recursive PCE-based Computation >> (BRPC) procedure to compute shortest inter- >> domain Traffic Engineering Label >> Switched Paths >> Author(s) : J. Vasseur, et al. >> Filename : draft-vasseur-pce-brpc-00.txt >> Pages : 14 >> Date : 2006-5-4 >> >> This document specifies a Path Computation Element (PCE)-based >> procedure to compute inter-domain constrained shortest Traffic >> Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol >> Label >> Switching (MPLS) and Generalized MPLS (GMPLS) networks. In this >> document a domain is referred to as a collection of network >> elements >> within a common sphere of address management or path computational >> responsibility such as IGP areas and Autonomous Systems. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with >> the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-vasseur-pce-brpc-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-5-4145941.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > --Apple-Mail-35--775567205 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Dean,

Many thanks for your = comments. Replies/Discussion in line,

- No topology or resource = information is distributed between domains
=A0=A0 (as mandated = per [RFC4105] and [RFC4216]), which is critical to
=A0=A0 = preserve IGP/BGP scalability and confidentiality in the case of = TE
=A0=A0 LSPs spanning multiple domains.

DC2 - This is practically = true but if not, the BRPC procedure can
=A0 =A0 =A0 still be = used.

JP>> Yes, but we want = to clarify the fact BRPC does not require any topology or resource = information distribution across domains. We'll reword to = clarify.

- = While certain constraints like bandwidth can be used across
=A0=A0= different domains, certain other TE constraints like = resource
=A0 =A0affinity, color, metric, etc. as listed in = [RFC2702] could be
=A0=A0 translated at domain boundaries.=A0 = If required, it is assumed that, at
=A0=A0 the domain boundary = LSRs, there will exist some sort of local mapping
=A0=A0 based = on offline policy agreement, in order to translate such
=A0=A0 = constraints across domain boundaries during the inter-PCE
=A0=A0= communication process.

DC3 - This may also be = relaxed as an assumption. These constraints
=A0 =A0 =A0 may be = globally or locally (thus may need mapping) defined,
=A0 =A0 =A0= but in either case, the BRPC procedure may be applied.

JP>> Well at least = not for the cost metric that must be consistent to compute the shortest = inter-domain constrained path. You're right that other metrics apply to = the general inter-domain case and are not specific to = BRPC.

- Each = AS can be made of several IGP areas.=A0 The path = computation
=A0=A0 procedure described in this document = applies to the case of a single
=A0=A0 AS made of multiple IGP = areas, multiples ASs made of a single IGP
=A0=A0 area or any = combination of the above.=A0 For the sake of simplicity,
=A0=A0 = each AS will be considered to be comprised of a single area in = this
=A0=A0 document.=A0 The case of an Inter-AS TE LSP = spanning multiple ASs where
=A0=A0 some of those ASs are = themselves made of multiple IGP areas can be
=A0=A0 easily = derived from this case by applying the BRPC procedure
=A0=A0 = described in this document, recursively.

DC4 - The BRPC procedure in = general can be applied to any network
=A0 =A0 =A0 partitions = in the context of (G-)MPLS networks, and so this
=A0 =A0 =A0 = paragraph could be moved to the Intruduction, and at least
=A0 = =A0 =A0 not a hard assumption.

JP>> = Agree.

- The = domain path (set of domains traversed to reach the = destination
=A0=A0 domain) is either administratively = pre-determined or discovered by
=A0=A0 some means (outside of = the scope of this document).

DC5 - What does this mean ? = Thought the domain path is calculated by
=A0 =A0 =A0 the BRPC = procedure.

JP>> nope, the BRPC = computes the optimal (shortest) path between a source S in Domain A to = destination D in Domain B, along a determined domain path (can be = pre-determined or discovered during the BRPC procedure). But, BRPC does = not attempt to discover all the domain-path, compute for each domain = path the best path and return the absolute best path.

DC10 Thr BRPC procedure may = return x number of path segments where x equals
=A0 =A0=A0 the = number of equal cost paths (ECMP), where two parameters may = be
=A0 =A0=A0 configurable based on carriers policy. The first = is the max number for
=A0 =A0=A0 x, and the second is the = approximates of these paths (costs are
=A0 =A0=A0 exactly the = same or close enough).

JP> Do you see a strong = reason for limiting x ?
The second requirement might indeed be = interesting.=A0
WG, any feed-back on this ?

DC11 - It could be reworded = to say: After accommodating local policy
=A0 =A0 =A0=A0 that = may be associated with domains that a LSP may traverse,
=A0 =A0= =A0=A0 if any, the BRPC would guarantee the optimality of inter-domain =
=A0 =A0 =A0=A0 paths end-to-end.

JP> Not quite sure to = see your point here ?

Thanks for your = comments.

JP.

O= n May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote:

Dear Authors,
=A0
I've got some quick feedback please see the attached (lines = inserted
starting = with DC).
=A0
Cheers,
Dean

From: Jean Philippe Vasseur (jvasseur) =
Sent: Thursday, May 04, 2006 1:26 PM
To: pce@ietf.org
Cc: raymond_zhang@bt.infonet.com<= /A>; nabil.n.bitar@verizon.comSubject: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt =

Dear WG,

As agreed during our last = WG meeting in Dallas (see the discussion with Adrian, acting as CCAMP = co-chair), we moved that ID in PCE WG. We took that opportunity to = make several changes based on the comments that we received so far. So = new text has been added for clarification, we reworded some sections = and more importantly, we removed the specification of the VSPT object = and replaced it by a 1-bit new flag in the RP object defined in = PCEP.

=
Comments very welcome.

JP, Raymond, Nabil and = Jean-Louis.

Begin forwarded message:

Date: May 4, 2006 3:50:01 PM = EDT
To: i-d-announce@ietf.org
Subject: I-D = ACTION:draft-vasseur-pce-brpc-00.txt=A0

=
A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title : A Backward Recursive PCE-based Computation=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 (BRPC) procedure to compute shortest = inter-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 domain Traffic Engineering Label Switched = Paths
Author(s) : J. Vasseur, et al.
Filename : draft-vasseur-pce-brpc-00.txt
Pages : 14
Date : = 2006-5-4

=A0=A0 This = document specifies a Path Computation Element (PCE)-based
=A0=A0 = procedure to compute inter-domain constrained shortest = Traffic
=A0=A0 Engineering (TE) Label = Switched Paths (LSPs) in Multiprotocol Label
=A0=A0 = Switching (MPLS) and Generalized MPLS (GMPLS) networks.=A0 In this
=A0=A0 = document a domain is referred to as a collection of network = elements
=A0=A0 within a common sphere = of address management or path computational
=A0=A0 = responsibility such as IGP areas and Autonomous Systems.
=



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of the message. =A0
to change your subscription settings.


Internet-Drafts are also available by anonymous = FTP. Login with the username
"anonymous" and a password of your e-mail address. After = logging in,
type "cd = internet-drafts" and then
"get = draft-vasseur-pce-brpc-00.txt".

A list of = Internet-Drafts directories can be found in


Internet-Drafts can also = be obtained by e-mail.

Send a message = to:
In the body type:
"FILE = /internet-drafts/draft-vasseur-pce-brpc-00.txt".

NOTE: = The mail server at ietf.org can return the document in
=
MIME-encoded form by using the "mpack" = utility.=A0 To use = this
feature, insert the command "ENCODING = mime" before the "FILE"
command.=A0 To decode the response(s), = you will need "munpack" or
a = MIME-compliant mail reader.=A0 = Different MIME-compliant mail readers
exhibit different behavior, especially when dealing = with
"multipart" MIME messages (i.e. = documents which have been split
up = into multiple messages), so check your local documentation on
=
how to manipulate these = messages.


Below is the data which will enable a MIME = compliant mail reader
implementation = to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain

=
_______________________________________________
I-D-Announce mailing list
 =

<draft-vasseur-pce-brpc-00DC.txt>

= --Apple-Mail-35--775567205-- --===============1896065604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1896065604==-- From pce-bounces@lists.ietf.org Tue May 09 12:18:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUuz-0001gC-OQ; Tue, 09 May 2006 12:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUuy-0001g7-Uu for pce@ietf.org; Tue, 09 May 2006 12:18:36 -0400 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdUux-0000gJ-Tr for pce@ietf.org; Tue, 09 May 2006 12:18:36 -0400 Received: from ib (unknown [172.16.24.125]) by jera.movaz.com (Postfix) with SMTP id AFDADABA8; Tue, 9 May 2006 12:18:34 -0400 (EDT) Message-ID: <013001c67384$2f3aae50$7d1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" , "Dean Cheng ((dcheng))" References: <70BC84B185C3EE448EDB7AB8956D3B0E01ACF593@xmb-sjc-234.amer.cisco.com> Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt Date: Tue, 9 May 2006 12:18:18 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.3 (/) X-Scan-Signature: 39f167824961b0285404677daacd7806 Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0884217114==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0884217114== Content-Type: multipart/alternative; boundary="----=_NextPart_000_012D_01C67362.A7F52D10" This is a multi-part message in MIME format. ------=_NextPart_000_012D_01C67362.A7F52D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, I have a question for you. Correct me if I am wrong, but my = understanding is that path segments for each of the domains are computed = independently from each other. Hence the loops are possible. What is the = protection against the loops? Note that just excluding links of = previous segments won't do, because the path computation failure after = the exclusions does not necessarily mean that end-to-end path does not = exist: the loop might not occur if one or more previous segments would = take different (albeit longer) paths, Thanks, Igor ----- Original Message -----=20 From: JP Vasseur=20 To: Dean Cheng ((dcheng))=20 Cc: raymond_zhang@bt.infonet.com ; nabil.n.bitar@verizon.com ; = pce@ietf.org=20 Sent: Tuesday, May 09, 2006 9:54 AM Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt=20 Hi Dean, Many thanks for your comments. Replies/Discussion in line, - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple domains. DC2 - This is practically true but if not, the BRPC procedure can still be used. JP>> Yes, but we want to clarify the fact BRPC does not require any = topology or resource information distribution across domains. We'll = reword to clarify. - While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, = at the domain boundary LSRs, there will exist some sort of local = mapping based on offline policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. DC3 - This may also be relaxed as an assumption. These constraints may be globally or locally (thus may need mapping) defined, but in either case, the BRPC procedure may be applied. JP>> Well at least not for the cost metric that must be consistent to = compute the shortest inter-domain constrained path. You're right that = other metrics apply to the general inter-domain case and are not = specific to BRPC. - Each AS can be made of several IGP areas. The path computation procedure described in this document applies to the case of a = single AS made of multiple IGP areas, multiples ASs made of a single IGP area or any combination of the above. For the sake of simplicity, each AS will be considered to be comprised of a single area in this document. The case of an Inter-AS TE LSP spanning multiple ASs = where some of those ASs are themselves made of multiple IGP areas can be easily derived from this case by applying the BRPC procedure described in this document, recursively. DC4 - The BRPC procedure in general can be applied to any network partitions in the context of (G-)MPLS networks, and so this=20 paragraph could be moved to the Intruduction, and at least not a hard assumption. JP>> Agree. - The domain path (set of domains traversed to reach the destination domain) is either administratively pre-determined or discovered by some means (outside of the scope of this document). DC5 - What does this mean ? Thought the domain path is calculated by the BRPC procedure. JP>> nope, the BRPC computes the optimal (shortest) path between a = source S in Domain A to destination D in Domain B, along a determined = domain path (can be pre-determined or discovered during the BRPC = procedure). But, BRPC does not attempt to discover all the domain-path, = compute for each domain path the best path and return the absolute best = path. DC10 Thr BRPC procedure may return x number of path segments where x = equals the number of equal cost paths (ECMP), where two parameters may = be configurable based on carriers policy. The first is the max = number for x, and the second is the approximates of these paths (costs are=20 exactly the same or close enough). JP> Do you see a strong reason for limiting x ? The second requirement might indeed be interesting.=20 WG, any feed-back on this ? DC11 - It could be reworded to say: After accommodating local policy that may be associated with domains that a LSP may traverse,=20 if any, the BRPC would guarantee the optimality of inter-domain = paths end-to-end. JP> Not quite sure to see your point here ? Thanks for your comments. JP. On May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote: Dear Authors, I've got some quick feedback please see the attached (lines inserted starting with DC). Cheers, Dean -------------------------------------------------------------------------= - From: Jean Philippe Vasseur (jvasseur)=20 Sent: Thursday, May 04, 2006 1:26 PM To: pce@ietf.org Cc: raymond_zhang@bt.infonet.com; nabil.n.bitar@verizon.com Subject: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt=20 Dear WG,=20 As agreed during our last WG meeting in Dallas (see the discussion = with Adrian, acting as CCAMP co-chair), we moved that ID in PCE WG. We = took that opportunity to make several changes based on the comments that = we received so far. So new text has been added for clarification, we = reworded some sections and more importantly, we removed the = specification of the VSPT object and replaced it by a 1-bit new flag in = the RP object defined in PCEP. Comments very welcome. JP, Raymond, Nabil and Jean-Louis. Begin forwarded message: From: Internet-Drafts@ietf.org Date: May 4, 2006 3:50:01 PM EDT To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line = Internet-Drafts directories. Title : A Backward Recursive PCE-based Computation=20 (BRPC) procedure to compute shortest = inter- domain Traffic Engineering Label = Switched Paths Author(s) : J. Vasseur, et al. Filename : draft-vasseur-pce-brpc-00.txt Pages : 14 Date : 2006-5-4 This document specifies a Path Computation Element = (PCE)-based procedure to compute inter-domain constrained shortest = Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol = Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. In = this document a domain is referred to as a collection of network = elements within a common sphere of address management or path = computational responsibility such as IGP areas and Autonomous Systems. A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt To remove yourself from the I-D Announcement list, send a = message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the = body of the message. =20 You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with = the username "anonymous" and a password of your e-mail address. After logging = in, type "cd internet-drafts" and then "get draft-vasseur-pce-brpc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail = readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of = the Internet-Draft. Content-Type: text/plain Content-ID: <2006-5-4145941.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_012D_01C67362.A7F52D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP,
 
I have a question for you. Correct me = if I am=20 wrong, but my understanding is that path segments for each of the = domains are=20 computed independently from each other. Hence the loops are possible. = What is=20 the protection against the loops?  Note that just excluding links = of=20 previous segments won't do, because the path computation  failure = after the=20 exclusions does not necessarily mean that end-to-end path does not = exist: the=20 loop might not occur if one or more previous segments would take = different=20 (albeit longer) paths,
 
Thanks,
Igor
 
 
----- Original Message -----
From:=20 JP = Vasseur=20
Sent: Tuesday, May 09, 2006 = 9:54 AM
Subject: Re: [Pce] Fwd: I-D=20 ACTION:draft-vasseur-pce-brpc-00.txt

Hi Dean,

Many thanks for your comments. Replies/Discussion in line,

- No topology or resource information is distributed between=20 domains
   (as mandated per [RFC4105] and [RFC4216]), which is = critical=20 to
   preserve IGP/BGP scalability and confidentiality in = the case=20 of TE
   LSPs spanning multiple domains.

DC2 - This is practically true but if not, the BRPC procedure = can
      still be used.

JP>> Yes, but we want to clarify the fact BRPC does not = require any=20 topology or resource information distribution across domains. We'll = reword to=20 clarify.

- While certain constraints like bandwidth can be used = across
   different domains, certain other TE constraints like = resource
   affinity, color, metric, etc. as listed in [RFC2702] = could=20 be
   translated at domain boundaries.  If required, = it is=20 assumed that, at
   the domain boundary LSRs, there will exist some sort = of=20 local mapping
   based on offline policy agreement, in order to = translate=20 such
   constraints across domain boundaries during the=20 inter-PCE
   communication process.

DC3 - This may also be relaxed as an assumption. These = constraints
      may be globally or locally (thus may need = mapping)=20 defined,
      but in either case, the BRPC procedure may = be=20 applied.

JP>> Well at least not for the cost metric that must be = consistent=20 to compute the shortest inter-domain constrained path. You're right = that other=20 metrics apply to the general inter-domain case and are not specific to = BRPC.

- Each AS can be made of several IGP areas.  The path=20 computation
   procedure described in this document applies to the = case of=20 a single
   AS made of multiple IGP areas, multiples ASs made of = a=20 single IGP
   area or any combination of the above.  For the = sake of=20 simplicity,
   each AS will be considered to be comprised of a = single area=20 in this
   document.  The case of an Inter-AS TE LSP = spanning=20 multiple ASs where
   some of those ASs are themselves made of multiple = IGP areas=20 can be
   easily derived from this case by applying the BRPC=20 procedure
   described in this document, recursively.

DC4 - The BRPC procedure in general can be applied to any = network
      partitions in the context of (G-)MPLS = networks, and=20 so this
      paragraph could be moved to the = Intruduction, and at=20 least
      not a hard assumption.

JP>> Agree.

- The domain path (set of domains traversed to reach the=20 destination
   domain) is either administratively pre-determined or = discovered by
   some means (outside of the scope of this = document).

DC5 - What does this mean ? Thought the domain path is calculated = by
      the BRPC procedure.

JP>> nope, the BRPC computes the optimal (shortest) path = between a=20 source S in Domain A to destination D in Domain B, along a determined = domain=20 path (can be pre-determined or discovered during the BRPC procedure). = But,=20 BRPC does not attempt to discover all the domain-path, compute for = each domain=20 path the best path and return the absolute best path.

DC10 Thr BRPC procedure may return x number of path segments = where x=20 equals
     the number of equal cost paths (ECMP), where = two=20 parameters may be
     configurable based on carriers policy. The = first is=20 the max number for
     x, and the second is the approximates of = these paths=20 (costs are
     exactly the same or close enough).

JP> Do you see a strong reason for limiting x ?
The second requirement might indeed be interesting. 
WG, any feed-back on this ?

DC11 - It could be reworded to say: After accommodating local=20 policy
       that may be associated with domains = that a LSP=20 may traverse,
       if any, the BRPC would guarantee the=20 optimality of inter-domain
       paths end-to-end.

JP> Not quite sure to see your point here ?

Thanks for your comments.

JP.

On May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote:

Dear Authors,
 
I've got some quick feedback please see the attached (lines = inserted
starting with DC).
 
Cheers,
Dean

From: Jean Philippe Vasseur = (jvasseur)=20
Sent: Thursday, May 04, 2006 1:26 PM
To: pce@ietf.org
Cc: raymond_zhang@bt.infonet.com= ;=20 nabil.n.bitar@verizon.comSubject:=20 [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt =

Dear WG,=20

As agreed during our last WG meeting in Dallas (see the = discussion=20 with Adrian, acting as CCAMP co-chair), we moved that ID in PCE = WG. We=20 took that opportunity to make several changes based on the = comments that=20 we received so far. So new text has been added for clarification, = we=20 reworded some sections and more importantly, we removed the = specification=20 of the VSPT object and replaced it by a 1-bit new flag in the RP = object=20 defined in PCEP.

Comments very welcome.

JP, Raymond, Nabil and Jean-Louis.

Begin forwarded message:

From: Internet-Drafts@ietf.org
Date: May 4, = 2006 3:50:01=20 PM EDT
To: i-d-announce@ietf.org
Subject: I-D=20 ACTION:draft-vasseur-pce-brpc-00.txt 
Reply-To: internet-drafts@ietf.org

A New Internet-Draft is available = from the=20 on-line Internet-Drafts directories.


Title : A Backward Recursive = PCE-based=20 Computation 
  =20                   =  =20   (BRPC) procedure to compute shortest inter-
   =20                   =  =20   domain Traffic Engineering Label Switched = Paths
Author(s) : J. Vasseur, et al.
Filename : = draft-vasseur-pce-brpc-00.txt
Pages : 14
Date : 2006-5-4

  =20 This document specifies a Path Computation Element=20 (PCE)-based
  =20 procedure to compute inter-domain constrained shortest=20 Traffic
  =20 Engineering (TE) Label Switched Paths (LSPs) in = Multiprotocol=20 Label
  =20 Switching (MPLS) and Generalized MPLS (GMPLS) = networks.  In this
  =20 document a domain is referred to as a collection of = network=20 elements
  =20 within a common sphere of address management or path=20 computational
  =20 responsibility such as IGP areas and Autonomous = Systems.



A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt

To remove yourself from the I-D = Announcement=20 list, send a message to 
i-d-announce-request@ietf.o= rg=20 with the word unsubscribe in the body of the message.  
You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce 
to change your subscription = settings.


Internet-Drafts are also available by = anonymous=20 FTP. Login with the username
"anonymous" and a password of your = e-mail=20 address. After logging in,
type "cd internet-drafts" and = then
"get=20 draft-vasseur-pce-brpc-00.txt".

A list of Internet-Drafts directories = can be=20 found in
http://www.ietf.org/shadow.html<= /A> 
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt


Internet-Drafts can also be obtained = by=20 e-mail.

Send a message to:
mailserv@ietf.org.
In the body type:
"FILE=20 /internet-drafts/draft-vasseur-pce-brpc-00.txt".

NOTE: The mail server at ietf.org = can return=20 the document in
MIME-encoded form by using the = "mpack"=20 utility.  To use = this
feature, insert the command = "ENCODING=20 mime" before the "FILE"
command.  To decode the = response(s), you=20 will need "munpack" or
a MIME-compliant mail = reader.  Different = MIME-compliant mail=20 readers
exhibit different behavior, = especially=20 when dealing with
"multipart" MIME messages = (i.e.=20 documents which have been split
up into multiple messages), so = check=20 your local documentation on
how to manipulate these = messages.


Below is the data which will enable a = MIME=20 compliant mail reader
implementation to automatically = retrieve the=20 ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2006-5-4145941.I-D@ietf.org>

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1= .ietf.org/mailman/listinfo/i-d-announce

<= /DIV>
=
<draft-vasseur-pce-brpc-00DC.txt>

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_012D_01C67362.A7F52D10-- --===============0884217114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0884217114==-- From pce-bounces@lists.ietf.org Wed May 10 09:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdow8-0007dH-B3; Wed, 10 May 2006 09:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdody-0000o7-3U for pce@ietf.org; Wed, 10 May 2006 09:22:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdodw-0005Ig-Js for pce@ietf.org; Wed, 10 May 2006 09:22:22 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 May 2006 06:22:20 -0700 X-IronPort-AV: i="4.05,109,1146466800"; d="scan'208,217"; a="1803707478:sNHT106693952" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4ADMIYk028444; Wed, 10 May 2006 06:22:19 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 May 2006 09:22:12 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 May 2006 09:22:10 -0400 In-Reply-To: <013001c67384$2f3aae50$7d1810ac@movaz.com> References: <70BC84B185C3EE448EDB7AB8956D3B0E01ACF593@xmb-sjc-234.amer.cisco.com> <013001c67384$2f3aae50$7d1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Message-Id: <6D6FDD64-0590-4A56-84A2-E008361AA82B@cisco.com> From: JP Vasseur Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt Date: Wed, 10 May 2006 09:22:08 -0400 To: Igor Bryskin X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 10 May 2006 13:22:10.0638 (UTC) FILETIME=[BE4B86E0:01C67434] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1d80f558f165fa9af6247527f0cff882 X-Mailman-Approved-At: Wed, 10 May 2006 09:41:06 -0400 Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1722112544==" Errors-To: pce-bounces@lists.ietf.org --===============1722112544== Content-Type: multipart/alternative; boundary=Apple-Mail-43--691079959 --Apple-Mail-43--691079959 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Igor, On May 9, 2006, at 12:18 PM, Igor Bryskin wrote: > Hi JP, > > I have a question for you. Correct me if I am wrong, but my > understanding is that path segments for each of the domains are > computed independently from each other. Hence the loops are > possible. What is the protection against the loops? Note that just > excluding links of previous segments won't do, because the path > computation failure after the exclusions does not necessarily mean > that end-to-end path does not exist: the loop might not occur if > one or more previous segments would take different (albeit longer) > paths, As pointed out in the ID, the domain-path is not determined by the BRPC procedure: the aim of BRPC is to find the optimal (shortest) path across a determined set of domains. So in the case of Inter-AS (since in the vast majority of the cases for the IGP case, topology are tree-based), it is the responsibility of the domain path computation module to avoid loops. Two simple ways to implement this: (1) Manual configuration of the domain path on the head-end (in which case, the user should make sure of the absence of loop) (2) Rely on BGP to find your way to the destination AS. If you want to find all possible domain paths, use BRPC for each of them so as to compute to absolute best path, there are many ways to achieve this (out of the scope of this ID). Another important point here: we discussed the ability to record to set of traversed PCE and there will be a procedure defined to detect and break loops, should it happen. Hope that this answers your question. JP. > > Thanks, > Igor > > > ----- Original Message ----- > From: JP Vasseur > To: Dean Cheng ((dcheng)) > Cc: raymond_zhang@bt.infonet.com ; nabil.n.bitar@verizon.com ; > pce@ietf.org > Sent: Tuesday, May 09, 2006 9:54 AM > Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt > > Hi Dean, > > Many thanks for your comments. Replies/Discussion in line, > > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > > DC2 - This is practically true but if not, the BRPC procedure can > still be used. > > JP>> Yes, but we want to clarify the fact BRPC does not require any > topology or resource information distribution across domains. We'll > reword to clarify. > > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed > that, at > the domain boundary LSRs, there will exist some sort of local > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > > DC3 - This may also be relaxed as an assumption. These constraints > may be globally or locally (thus may need mapping) defined, > but in either case, the BRPC procedure may be applied. > > JP>> Well at least not for the cost metric that must be consistent > to compute the shortest inter-domain constrained path. You're right > that other metrics apply to the general inter-domain case and are > not specific to BRPC. > > - Each AS can be made of several IGP areas. The path computation > procedure described in this document applies to the case of a > single > AS made of multiple IGP areas, multiples ASs made of a single IGP > area or any combination of the above. For the sake of simplicity, > each AS will be considered to be comprised of a single area in this > document. The case of an Inter-AS TE LSP spanning multiple ASs > where > some of those ASs are themselves made of multiple IGP areas can be > easily derived from this case by applying the BRPC procedure > described in this document, recursively. > > DC4 - The BRPC procedure in general can be applied to any network > partitions in the context of (G-)MPLS networks, and so this > paragraph could be moved to the Intruduction, and at least > not a hard assumption. > > JP>> Agree. > > - The domain path (set of domains traversed to reach the destination > domain) is either administratively pre-determined or discovered by > some means (outside of the scope of this document). > > DC5 - What does this mean ? Thought the domain path is calculated by > the BRPC procedure. > > JP>> nope, the BRPC computes the optimal (shortest) path between a > source S in Domain A to destination D in Domain B, along a > determined domain path (can be pre-determined or discovered during > the BRPC procedure). But, BRPC does not attempt to discover all the > domain-path, compute for each domain path the best path and return > the absolute best path. > > DC10 Thr BRPC procedure may return x number of path segments where > x equals > the number of equal cost paths (ECMP), where two parameters > may be > configurable based on carriers policy. The first is the max > number for > x, and the second is the approximates of these paths (costs are > exactly the same or close enough). > > JP> Do you see a strong reason for limiting x ? > The second requirement might indeed be interesting. > WG, any feed-back on this ? > > DC11 - It could be reworded to say: After accommodating local policy > that may be associated with domains that a LSP may traverse, > if any, the BRPC would guarantee the optimality of inter-domain > paths end-to-end. > > JP> Not quite sure to see your point here ? > > Thanks for your comments. > > JP. > > On May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote: > >> Dear Authors, >> >> I've got some quick feedback please see the attached (lines inserted >> starting with DC). >> >> Cheers, >> Dean >> >> From: Jean Philippe Vasseur (jvasseur) >> Sent: Thursday, May 04, 2006 1:26 PM >> To: pce@ietf.org >> Cc: raymond_zhang@bt.infonet.com; nabil.n.bitar@verizon.com >> Subject: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt >> >> Dear WG, >> >> As agreed during our last WG meeting in Dallas (see the discussion >> with Adrian, acting as CCAMP co-chair), we moved that ID in PCE >> WG. We took that opportunity to make several changes based on the >> comments that we received so far. So new text has been added for >> clarification, we reworded some sections and more importantly, we >> removed the specification of the VSPT object and replaced it by a >> 1-bit new flag in the RP object defined in PCEP. >> >> Comments very welcome. >> >> JP, Raymond, Nabil and Jean-Louis. >> >> Begin forwarded message: >> >>> From: Internet-Drafts@ietf.org >>> Date: May 4, 2006 3:50:01 PM EDT >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet- >>> Drafts directories. >>> >>> >>> Title : A Backward Recursive PCE-based Computation >>> (BRPC) procedure to compute shortest inter- >>> domain Traffic Engineering Label >>> Switched Paths >>> Author(s) : J. Vasseur, et al. >>> Filename : draft-vasseur-pce-brpc-00.txt >>> Pages : 14 >>> Date : 2006-5-4 >>> >>> This document specifies a Path Computation Element (PCE)-based >>> procedure to compute inter-domain constrained shortest Traffic >>> Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol >>> Label >>> Switching (MPLS) and Generalized MPLS (GMPLS) networks. In this >>> document a domain is referred to as a collection of network >>> elements >>> within a common sphere of address management or path >>> computational >>> responsibility such as IGP areas and Autonomous Systems. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>> announce >>> to change your subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with >>> the username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-vasseur-pce-brpc-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2006-5-4145941.I-D@ietf.org> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-43--691079959 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Igor,

On = May 9, 2006, at 12:18 PM, Igor Bryskin wrote:

Hi = JP,
=A0
I have a question for you. Correct me if I am wrong, but my = understanding is that path segments for each of the domains are computed = independently from each other. Hence the loops are possible. What is the = protection against the loops? =A0Note that just excluding links of = previous segments won't do, because the path computation=A0 failure = after the exclusions does not necessarily mean that end-to-end path does = not exist: the loop might not occur if one or more previous segments = would take different (albeit longer) = paths,

As pointed out in the ID, = the domain-path is not determined by the BRPC procedure: the aim of BRPC = is to find the optimal (shortest) path across a determined set of = domains. So in the case of Inter-AS (since in the vast majority of the = cases for the IGP case, topology are tree-based), it is = the=A0responsibility of the domain path computation module to avoid = loops. Two simple ways to implement this: (1) Manual configuration of = the domain path on the head-end (in which case, the user should make = sure of the absence of loop) (2) Rely on BGP to find your way to the = destination AS. If you want to find all possible domain paths, use BRPC = for each of them so as to compute to absolute best path, there are many = ways to achieve this (out of the scope of this ID). Another important = point here: we discussed the ability to record to set of traversed PCE = and there will be a procedure defined to detect and break loops, should = it happen.

Hope= that this answers your question.

JP.

=A0
Thanks,
Igor
=A0
=A0
----- Original = Message -----
Sent: Tuesday, May 09, 2006 9:54 AM
Subject: Re: [Pce] Fwd: I-D = ACTION:draft-vasseur-pce-brpc-00.txt

Hi = Dean,

Many thanks = for your comments. Replies/Discussion in line,

- No topology or resource = information is distributed between domains
=A0=A0 (as mandated = per [RFC4105] and [RFC4216]), which is critical to
=A0=A0 = preserve IGP/BGP scalability and confidentiality in the case of = TE
=A0=A0 LSPs spanning multiple domains.

DC2 - This is practically = true but if not, the BRPC procedure can
=A0 =A0 =A0 still be = used.

JP>> Yes, but we want = to clarify the fact BRPC does not require any topology or resource = information distribution across domains. We'll reword to = clarify.

- = While certain constraints like bandwidth can be used across
=A0=A0= different domains, certain other TE constraints like = resource
=A0 =A0affinity, color, metric, etc. as listed in = [RFC2702] could be
=A0=A0 translated at domain boundaries.=A0 = If required, it is assumed that, at
=A0=A0 the domain boundary = LSRs, there will exist some sort of local mapping
=A0=A0 based = on offline policy agreement, in order to translate such
=A0=A0 = constraints across domain boundaries during the inter-PCE
=A0=A0= communication process.

DC3 - This may also be = relaxed as an assumption. These constraints
=A0 =A0 =A0 may be = globally or locally (thus may need mapping) defined,
=A0 =A0 =A0= but in either case, the BRPC procedure may be applied.

JP>> Well at least = not for the cost metric that must be consistent to compute the shortest = inter-domain constrained path. You're right that other metrics apply to = the general inter-domain case and are not specific to = BRPC.

- Each = AS can be made of several IGP areas.=A0 The path = computation
=A0=A0 procedure described in this document = applies to the case of a single
=A0=A0 AS made of multiple IGP = areas, multiples ASs made of a single IGP
=A0=A0 area or any = combination of the above.=A0 For the sake of simplicity,
=A0=A0 = each AS will be considered to be comprised of a single area in = this
=A0=A0 document.=A0 The case of an Inter-AS TE LSP = spanning multiple ASs where
=A0=A0 some of those ASs are = themselves made of multiple IGP areas can be
=A0=A0 easily = derived from this case by applying the BRPC procedure
=A0=A0 = described in this document, recursively.

DC4 - The BRPC procedure in = general can be applied to any network
=A0 =A0 =A0 partitions = in the context of (G-)MPLS networks, and so this
=A0 =A0 =A0 = paragraph could be moved to the Intruduction, and at least
=A0 = =A0 =A0 not a hard assumption.

JP>> = Agree.

- The = domain path (set of domains traversed to reach the = destination
=A0=A0 domain) is either administratively = pre-determined or discovered by
=A0=A0 some means (outside of = the scope of this document).

DC5 - What does this mean ? = Thought the domain path is calculated by
=A0 =A0 =A0 the BRPC = procedure.

JP>> nope, the BRPC = computes the optimal (shortest) path between a source S in Domain A to = destination D in Domain B, along a determined domain path (can be = pre-determined or discovered during the BRPC procedure). But, BRPC does = not attempt to discover all the domain-path, compute for each domain = path the best path and return the absolute best path.

DC10 Thr BRPC procedure may = return x number of path segments where x equals
=A0 =A0=A0 the = number of equal cost paths (ECMP), where two parameters may = be
=A0 =A0=A0 configurable based on carriers policy. The first = is the max number for
=A0 =A0=A0 x, and the second is the = approximates of these paths (costs are
=A0 =A0=A0 exactly the = same or close enough).

JP> Do you see a strong = reason for limiting x ?
The second requirement might indeed be = interesting.=A0
WG, any feed-back on this ?

DC11 - It could be reworded = to say: After accommodating local policy
=A0 =A0 =A0=A0 that = may be associated with domains that a LSP may traverse,
=A0 =A0 = =A0=A0 if any, the BRPC would guarantee the optimality of = inter-domain
=A0 =A0 =A0=A0 paths end-to-end.

JP> Not quite sure to = see your point here ?

Thanks for your = comments.

JP.

O= n May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote:

Dear Authors,
=A0
I've got some quick feedback please see the attached = (lines inserted
=A0
Cheers,
Jean Philippe Vasseur (jvasseur)
Sent: Thursday, May = 04, 2006 1:26 PM
To: ; nabil.n.bitar@verizon.com
[Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt =

Dear WG,
As agreed during our last WG meeting in Dallas (see = the discussion with Adrian, acting as CCAMP co-chair), we moved that ID = in PCE WG. We took that opportunity to make several changes based on the = comments that we received so far. So new text has been added for = clarification, we reworded some sections and more importantly, we = removed the specification of the VSPT object and replaced it by a 1-bit = new flag in the RP object defined in PCEP.


JP, Raymond, Nabil and Jean-Louis.
From: Internet-Drafts@ietf.org
Date: = May 4, 2006 3:50:01 PM = EDT
Subject: = I-D = ACTION:draft-vasseur-pce-brpc-00.txtinternet-drafts@ietf.org

A New Internet-Draft is available from the on-line = Internet-Drafts directories.


Title : A Backward Recursive PCE-based = Computation=A0=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (BRPC) = procedure to compute shortest inter-
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domain = Traffic Engineering Label Switched Paths
: J. = Vasseur, et al.
Filename : draft-vasseur-pce-brpc-00.txt
Pages : 14
: 2006-5-4

=A0=A0 = This document specifies a Path Computation Element = (PCE)-based
=A0=A0 = procedure to compute inter-domain constrained shortest = Traffic
=A0=A0 Engineering = (TE) Label Switched Paths (LSPs) in Multiprotocol Label
=A0=A0 Switching = (MPLS) and Generalized MPLS (GMPLS) networks.=A0 In = this
=A0=A0 document a = domain is referred to as a collection of network = elements
=A0=A0 within a = common sphere of address management or path = computational
=A0=A0 = responsibility such as IGP areas and Autonomous = Systems.



A URL for = this Internet-Draft is:




or =


In the body type:
"FILE = /internet-drafts/draft-vasseur-pce-brpc-00.txt".

The mail = server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.=A0 To use = this
feature, insert the command "ENCODING mime" before the = "FILE"
command.=A0 To decode = the response(s), you will need "munpack" or
a MIME-compliant mail reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been = split
up into multiple messages), so check your local = documentation on
how to manipulate these = messages.


Below is the data which will enable a MIME compliant = mail reader
Content-Type: text/plain
Content-ID: <>



= --Apple-Mail-43--691079959-- --===============1722112544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1722112544==-- From pce-bounces@lists.ietf.org Thu May 11 10:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCCf-0007an-1a; Thu, 11 May 2006 10:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCCd-0007WM-4T for pce@ietf.org; Thu, 11 May 2006 10:31:43 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCCb-0004Ab-KL for pce@ietf.org; Thu, 11 May 2006 10:31:43 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FeCCX-0000Id-00 for pce@ietf.org; Thu, 11 May 2006 15:31:37 +0100 Received: from your029b8cecfe ([217.158.132.76] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 15:32:17 +0100 Message-ID: <018701c67507$841be7c0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Jim Jones" Date: Thu, 11 May 2006 15:30:46 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 11 May 2006 14:32:17.0953 (UTC) FILETIME=[B4769910:01C67507] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Bill Fenner , Ross Callon , pce@ietf.org Subject: [Pce] Your communication about closer ties with the PCE Working Group X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org To: Jim Jones, OIF TC Chair From: Adrian Farrel and JP Vasseur, IETF PCE Co-Chairs Cc: Bill Fenner and Ross Callon, IETF Routing Area Directors Subject: Your communication about closer ties with the PCE Working Group Dear Jim, Thank you for your interest in the work of the PCE working group and for expressing an interest in cooperation between your Forum and the working group. Many apologies for the delay in responding that is largely caused by my pressure of work and hardware failures. The PCE working group is still at a relatively early stage, and while it has specified an architecture and some protocol requirements its protocols are as yet immature. We feel, therefore, that it would be premature to instigate a liaison relationship to develop interoperable products and services. However, we would very much appreciate the opinions of all participants in the OIF with regard to our work. The latest versions of our Internet-Drafts can be found at the PCE working group charter page http://www.ietf.org/html.charters/pce-charter.html and can be downloaded without charge simply by clicking on the links. Opinions and questions on the work are welcomed on the PCE mailing list. The mailing list is open to everyone without charge or membership requirements. Instructions for signing up to the mailing list can be found on the charter page. Best regards, Adrian Farrel and JP Vasseur IETF PCE Working Group Co-Chairs > ====== > > To: Adrian Farrel and J.P. Vasseur, IETF PCE WG Co-Chairs > From: Jim Jones, OIF TC Chair > Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors > Subject: Proposal to establish a liaison to IETF PCE WG > > Dear Adrian and JP, > > The OIF is interested in initiating a cooperative liaison with the PCE WG, > WG in the spirit of fostering cooperation for achieving interoperability > of intelligent optical networks. > > The mission of the Optical Internetworking Forum (OIF) is to foster the > development and deployment of interoperable products and services for > data switching and routing using optical networking technologies. > > To date OIF has had issued Interoperability Agreements (IAs) in the > areas of physical link layer interoperability and network control plane > interoperability. OIF has also been successful with multiple > interoperability demonstrations using OIF IAs and ITU-T > Recommendations as the basis for the interoperability demonstrations. > > We would like to propose that Richard Bradford of Cisco act as liaison > between the two organizations. > > Best regards, > Jim Jones > OIF Technical Committee Chair _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun May 14 15:58:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfMiN-0001vF-EU; Sun, 14 May 2006 15:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfMiF-0001uk-VJ for pce@ietf.org; Sun, 14 May 2006 15:57:11 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfMiE-0002wN-EJ for pce@ietf.org; Sun, 14 May 2006 15:57:11 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FfMiJ-0005Y7-00 for pce@ietf.org; Sun, 14 May 2006 20:57:15 +0100 Received: from your029b8cecfe ([217.158.132.55] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 May 2006 20:56:53 +0100 Message-ID: <023f01c67790$7312dd90$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Sun, 14 May 2006 20:42:10 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 14 May 2006 19:56:53.0900 (UTC) FILETIME=[8C4584C0:01C67790] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [Pce] Liaison Statement received from ITU-T Study Group 15 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, We received the following liaison statement from Study Group 15 of the ITU-T. The liaison can be seen in the IETF repository at https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=219 with the attachment visible at https://datatracker.ietf.org/documents/LIAISON/file312.doc The liaison is for information, and so no response is expected from us. If anyone has questions or issues that they would like the ITU-T to clarify then we can generate a liaison - please talk to the chairs. I think it might be nice for us to send a response to encourage them on their way and to ask them to send us a copy of the work when it is more stable and to give us time to comment before they consent it into a Recommendation. if no-one objects, I will draft something. Cheers, Adrian > Title: Draft new G.7715.2 on remote path query > Submission Date: 2006-05-05 > URL of the IETF Web page: > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=219 > > From: Greg Jones(ITU-T SG 15) > To: IETF PCE WG(Adrian Farrel , JP Vasseur > ) > Cc: Ross Callon > Bill Fenner > Scott Bradner > Yoichi Maeda > pce@ietf.org > Reponse Contact: tsbsg15@itu.int; greg.jones@itu.int > Technical Contact: Hing-Kam Lam > Purpose: For information > Body: > We would like to inform the IETF PCE Working Group that Q14/15 has > commenced on the work of a draft new Recommendation G.7715.2 on > remote path query. This follows from the recent inclusion of the > path query capability in the ASON architecture (G.8080). > > A contribution that proposes an outline and some initial text for > the new Recommendation was received at the April 22-27, 2006 > Interim meeting. The contribution was accepted by the meeting as > the initial base text of G.7715.2 and will be further developed. > The next meeting of Q14/15 has been planned for June 26-30, 2006 > in Darmstadt, Germany. > > Attached for your information is the accepted initial base text. > Please note that the comments made at the meeting on the > contribution are not reflected yet in the attached contribution. > > An electronic copy of this liaison statement is available at: > ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html > > Attachment(s): > Draft new G.7715 on remote path query - This liaison in WinWord > with draft embedded > (https://datatracker.ietf.org/documents/LIAISON/file312.doc) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 19 05:58:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1kg-0007hh-BY; Fri, 19 May 2006 05:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1kf-0007hc-LK for pce@ietf.org; Fri, 19 May 2006 05:58:33 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh1kd-000155-2m for pce@ietf.org; Fri, 19 May 2006 05:58:33 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fh1kb-00070A-00 for pce@ietf.org; Fri, 19 May 2006 10:58:29 +0100 Received: from your029b8cecfe ([217.158.132.70] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 10:58:19 +0100 Message-ID: <098e01c67b2a$bbd1a780$36849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 19 May 2006 09:19:54 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 19 May 2006 09:58:19.0973 (UTC) FILETIME=[C1F7E750:01C67B2A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: [Pce] Fw: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org FYI ----- Original Message ----- From: To: Sent: Friday, May 19, 2006 5:00 AM Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 19 15:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAz6-0006nj-Jz; Fri, 19 May 2006 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAz3-0006n9-UQ; Fri, 19 May 2006 15:50:01 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAz3-0007tA-KD; Fri, 19 May 2006 15:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4JJo11I018981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FhAz3-000323-Ec; Fri, 19 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 19 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-05.txt Pages : 21 Date : 2006-5-19 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-comm-protocol-gen-reqs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-19144217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-comm-protocol-gen-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-19144217.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri May 19 15:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAzF-0006pj-Ff; Fri, 19 May 2006 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAz6-0006nh-38; Fri, 19 May 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAz3-0007tC-NQ; Fri, 19 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4JJo1et027422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FhAz3-00032N-HB; Fri, 19 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 19 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.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 : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-04.txt Pages : 15 Date : 2006-5-19 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-19144732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-discovery-reqs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-discovery-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-19144732.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Sat May 20 02:58:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhLOc-0000Ut-Sl; Sat, 20 May 2006 02:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhLOb-0000So-6C for pce@ietf.org; Sat, 20 May 2006 02:57:05 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhLOa-0003oB-Mm for pce@ietf.org; Sat, 20 May 2006 02:57:05 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4K6v1MI024238 for ; Sat, 20 May 2006 08:57:01 +0200 In-Reply-To: To: pce@ietf.org Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sat, 20 May 2006 08:57:04 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/20/2006 08:57:00, Serialize complete at 05/20/2006 08:57:00 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org folks, looking at this draft could editors tell us what they mean in section 6.1.16 by "Note that the absence of a constraint in this list does not mean that the constraint must not be supported." same comment for section 6.1.17 in 6.2.2 it is mentioned "PCECP messages MUST be able to carry transparent policy information." ... not sure to understand the role of the term "transparent" in this sentence thanks, - d. Internet-Drafts@ietf.org 19/05/2006 21:50 To: i-d-announce@ietf.org cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-05.txt 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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-05.txt Pages : 21 Date : 2006-5-19 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-comm-protocol-gen-reqs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-05.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat May 20 05:15:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhNXz-0002GK-Dp; Sat, 20 May 2006 05:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhNXy-0002Fm-7b for pce@ietf.org; Sat, 20 May 2006 05:14:54 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhNXx-0003GV-PL for pce@ietf.org; Sat, 20 May 2006 05:14:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 May 2006 11:14:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-05.txt Date: Sat, 20 May 2006 11:15:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-05.txt Thread-Index: AcZ72vnLMO3rPJ6DTRiEgS2/zLXcZAAEgoqQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 20 May 2006 09:14:48.0688 (UTC) FILETIME=[D7EF2F00:01C67BED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Please see inline,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : samedi 20 mai 2006 08:57 > =C0 : pce@ietf.org > Objet : Re: [Pce] I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-05.txt >=20 > folks, looking at this draft could editors tell us what they=20 > mean in section 6.1.16 by >=20 > "Note that the absence of a constraint in this list does not=20 > mean that the constraint must not be supported." This is not an exhaustive list. The absence of a constraint C does not = mean that the request message must not include C. >=20 > same comment for section 6.1.17 >=20 > in 6.2.2 it is mentioned "PCECP messages MUST be able to=20 > carry transparent=20 >=20 > policy information." ... not sure to understand the role of=20 > the term "transparent" > in this sentence =3D Opaque The information is not processed by PCEP. This is to be used by a PDP... Thanks, JL >=20 > thanks, > - d. >=20 >=20 >=20 >=20 >=20 > Internet-Drafts@ietf.org > 19/05/2006 21:50 > =20 > To: i-d-announce@ietf.org > cc: pce@ietf.org > Subject: [Pce] I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Path Computation Element=20 > Working Group of the IETF. >=20 > Title : PCE Communication=20 > Protocol Generic Requirements > Author(s) : J. Le Roux, J. Ash > Filename :=20 > draft-ietf-pce-comm-protocol-gen-reqs-05.txt > Pages : 21 > Date : 2006-5-19 > =20 > The PCE model is described in the "PCE Architecture" document and > facilitates path computation requests from Path Computation Clients > (PCCs) to Path Computation Elements (PCEs). This document=20 > specifies > generic requirements for a communication protocol between PCCs and > PCEs, and also between PCEs where cooperation between PCEs is > desirable. Subsequent documents will specify application-specific > requirements for the PCE communication protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protoc > ol-gen-reqs-05.txt >=20 >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-pce-comm-protocol-gen-reqs-05.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-05.txt". > =20 > NOTE: The mail server at ietf.org can return the=20 > document in > MIME-encoded form by using the "mpack"=20 > utility. To use=20 > this > feature, insert the command "ENCODING mime"=20 > before the=20 > "FILE" > command. To decode the response(s), you will need=20 > "munpack" or > a MIME-compliant mail reader. Different=20 > MIME-compliant=20 > mail readers > exhibit different behavior, especially when=20 > dealing with > "multipart" MIME messages (i.e. documents=20 > which have been=20 > split > up into multiple messages), so check your local=20 > documentation on > how to manipulate these messages. > =20 > =20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-pce-co > mm-protocol-gen-reqs-05.txt > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon May 22 15:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGPn-0002T7-4V; Mon, 22 May 2006 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGPi-0002Rf-Uc; Mon, 22 May 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiGPh-0000xw-PB; Mon, 22 May 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4MJo1et029037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FiGPh-00032f-Hg; Mon, 22 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 22 May 2006 15:50:01 -0400 X-Spam-Score: 0.6 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-06.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-06.txt Pages : 21 Date : 2006-5-22 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed May 24 11:18:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiv7o-0000Rn-IP; Wed, 24 May 2006 11:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiv7n-0000Rh-Dn for pce@ietf.org; Wed, 24 May 2006 11:18:15 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiv7h-0004J9-9n for pce@ietf.org; Wed, 24 May 2006 11:18:15 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZR00LZ8Z6C5R@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 08:03:49 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZR00258Z62EG@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 08:03:48 -0700 (PDT) Date: Wed, 24 May 2006 10:06:46 -0500 From: Lucy Yong To: 'Adrian Farrel' Message-id: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: pce@ietf.org Subject: [Pce] Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0648336528==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0648336528== Content-type: multipart/alternative; boundary="Boundary_(ID_tc9iF2JADOupI7/LBcy11w)" This is a multi-part message in MIME format. --Boundary_(ID_tc9iF2JADOupI7/LBcy11w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Adrian, The draft layouts the basic PCE architecture and expresses the motivation for a PCE-based architecture. It is a good document. Beyond these motivation facts, I think we should have another incentive for a PCE-based architecture. Today, a control plane based switching architecture assumes a user-network model or client-server model. A LSP is initiated at an end user point (client), then network establishes the LSP thru. the control plane instantly. PCE reserves that concept too. Thus all connection paths are based on instant requests from end users. In carrier reality world, it is hard to see that transport service will be offered this way only, especially for a large bandwidth and permanent bandwidth request. Typically, carrier has a service order reservation system, it allows customer to book a bandwidth ahead (pending order), carrier will do traffic engineering based on the pending order and will excuse the order when the time arrives. A path computer engine has a capability of taking a consideration about future pending orders while it computes a path. The architecture is pretty close to the PCE-based architecture except a lot of manual operation. I think PCE should consider this as its application too and revise the basic architecture to include this functionality. Here is the recommendation for the PCE-based architecture: --------------- | --------- | Routing ---------- | | | | Protocol | | | | TED |<-+----------+-> | | | | | | | | --------- | | | | | | | | | | Input | | | | v | | | ---------- Response | --------- | | | | |Request | | | | | Adjacent | | SORD |<--------> | | PCE | | | Node | | |Input | | | | | | ---------- | --------- | | | ^ | ^ | | | | | |Request | | | | | |Response| | | Service Order | v | | | | --------- | | | Service | | | | Signaling| | Request | |Signaling| | Protocol | | ------+->| Engine |<-+----------+-> | | | | | | | | --------- | ---------- --------------- Here, SORD is the service order reservation database, it contains all service order requests in terms of ingress and egress points, bandwidth, service type, time period for the request, etc. When PCE computes a path, it could get input from SORD to indicate if there are some network resource is already blocked out. When a booking order in SORD is ready to kick off, SORD will send request to PCE for the path computation, then PCE will send a service request to signaling engine to establish the LSP. It is clarified that not all pending orders in SORD need to reserve the bandwidth ahead, carrier could have some policies in SORD to manage which order need to reserve the bandwidth ahead and which is not. Be glad to hear your and other people comment on this suggestion. Regards, Lucy Yong Huawei Technologies, U.S. --Boundary_(ID_tc9iF2JADOupI7/LBcy11w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Adrian,

 

The draft layouts the basic PCE architecture and expresses the motivation for a PCE-based architecture. It is a good document.

 Beyond these motivation facts, I think we should have another incentive for a PCE-based architecture.

 

Today, a control plane based switching architecture assumes a user-network model or client-server model. A LSP is initiated at an end user point (client), then network establishes the LSP thru. the control plane instantly. PCE reserves that concept too. Thus all connection paths are based on instant requests from end users.

 

In carrier reality world, it is hard to see that transport service will be offered this way only, especially for a large bandwidth and permanent bandwidth request. Typically, carrier has a service order reservation system, it allows customer to book a bandwidth ahead (pending order), carrier will do traffic engineering based on the pending order and will excuse the order when the time arrives. A path computer engine has a capability of taking a consideration about future pending orders while it computes a path. The architecture is pretty close to the PCE-based architecture except a lot of manual operation. I think PCE should consider this as its application too and revise the basic architecture to include this functionality.

 

Here is the recommendation for the PCE-based architecture:

 

                       ---------------
                      |   ---------   | Routing   ----------
                      |  |         |  | Protocol |          |
                      |  |   TED   |<-+----------+->        |
                      |  |         |  |          |          |
                      |   ---------   |          |          |
                      |      |        |          |          |
                      |      | Input  |          |          |
                      |      v        |          |          |
 ---------- Response  |   ---------   |          |          |
|          |Request   |  |         |  |          | Adjacent |
|  SORD    |ß----à   |  |   PCE   |  |          |   Node   |
|          |Input     |  |         |  |          |          |
 ----------           |   ---------   |          |          |
      ^               |      ^        |          |          |
      |               |      |Request |          |          |
      |               |      |Response|          |          |
   Service Order      |      v        |          |          |
                      |   ---------   |          |          |
             Service  |  |         |  | Signaling|          |
             Request  |  |Signaling|  | Protocol |          |
                ------+->| Engine  |<-+----------+->        |
                      |  |         |  |          |          |
                      |   ---------   |           ----------
                       ---------------
 

Here, SORD is the service order reservation database, it contains all service order requests in terms of ingress and egress points, bandwidth, service type, time period for the request, etc. When PCE computes a path, it could get input from SORD to indicate if there are some network resource is already blocked out. When a booking order in SORD is ready to kick off, SORD will send request to PCE for the path computation, then PCE will send a service request to signaling engine to establish the LSP.

 

It is clarified that not all pending orders in SORD need to reserve the bandwidth ahead, carrier could have some policies in SORD to manage which order need to reserve the bandwidth ahead and which is not.

 

Be glad to hear your and other people comment on this suggestion.

 

Regards,

Lucy Yong

Huawei Technologies, U.S.

 

 

--Boundary_(ID_tc9iF2JADOupI7/LBcy11w)-- --===============0648336528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0648336528==-- From pce-bounces@lists.ietf.org Wed May 24 12:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivnF-0000ou-PT; Wed, 24 May 2006 12:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivnF-0000op-36 for pce@ietf.org; Wed, 24 May 2006 12:01:05 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FivnC-0006Vs-JP for pce@ietf.org; Wed, 24 May 2006 12:01:05 -0400 Received: from localhost (imp-4-2.polymtl.ca [132.207.4.77]) by smtp.polymtl.ca (8.13.6/8.13.6) with ESMTP id k4OG0j5r004246; Wed, 24 May 2006 12:00:45 -0400 Received: from 132.207.176.236 ([132.207.176.236]) by www.imp.polymtl.ca (IMP) with HTTP for ; Wed, 24 May 2006 12:00:44 -0400 Message-ID: <1148486444.4474832ce7904@www.imp.polymtl.ca> Date: Wed, 24 May 2006 12:00:44 -0400 From: Meral Shirazipour To: Lucy Yong Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 References: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> In-Reply-To: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 132.207.176.236 X-Poly-FromMTA: (imp-4-2.polymtl.ca [132.207.4.77]) at Wed, 24 May 2006 16:00:44 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.polymtl.ca id k4OG0j5r004246 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: "pce@ietf.org" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Lucy, I agree with what you say here. This is a fact to consider especially = if the PCE architecture is to be adapted later on for inter-AS TE in the =91Inte= rnet=92. What you say here is important if we consider the Internet peering models. Regards, Meral Shirazipour Selon Lucy Yong : > Adrian, > > > > The draft layouts the basic PCE architecture and expresses the motivati= on > for a PCE-based architecture. It is a good document. > > Beyond these motivation facts, I think we should have another incentiv= e for > a PCE-based architecture. > > > > Today, a control plane based switching architecture assumes a user-netw= ork > model or client-server model. A LSP is initiated at an end user point > (client), then network establishes the LSP thru. the control plane > instantly. PCE reserves that concept too. Thus all connection paths are > based on instant requests from end users. > > > > In carrier reality world, it is hard to see that transport service will= be > offered this way only, especially for a large bandwidth and permanent > bandwidth request. Typically, carrier has a service order reservation > system, it allows customer to book a bandwidth ahead (pending order), > carrier will do traffic engineering based on the pending order and will > excuse the order when the time arrives. A path computer engine has a > capability of taking a consideration about future pending orders while = it > computes a path. The architecture is pretty close to the PCE-based > architecture except a lot of manual operation. I think PCE should consi= der > this as its application too and revise the basic architecture to includ= e > this functionality. > > > > Here is the recommendation for the PCE-based architecture: > > > > --------------- > | --------- | Routing ---------- > | | | | Protocol | | > | | TED |<-+----------+-> | > | | | | | | > | --------- | | | > | | | | | > | | Input | | | > | v | | | > ---------- Response | --------- | | | > | |Request | | | | | Adjacent | > | SORD |<--------> | | PCE | | | Node | > | |Input | | | | | | > ---------- | --------- | | | > ^ | ^ | | | > | | |Request | | | > | | |Response| | | > Service Order | v | | | > | --------- | | | > Service | | | | Signaling| | > Request | |Signaling| | Protocol | | > ------+->| Engine |<-+----------+-> | > | | | | | | > | --------- | ---------- > --------------- > > > Here, SORD is the service order reservation database, it contains all > service order requests in terms of ingress and egress points, bandwidth= , > service type, time period for the request, etc. When PCE computes a pat= h, it > could get input from SORD to indicate if there are some network resourc= e is > already blocked out. When a booking order in SORD is ready to kick off,= SORD > will send request to PCE for the path computation, then PCE will send a > service request to signaling engine to establish the LSP. > > > > It is clarified that not all pending orders in SORD need to reserve the > bandwidth ahead, carrier could have some policies in SORD to manage whi= ch > order need to reserve the bandwidth ahead and which is not. > > > > Be glad to hear your and other people comment on this suggestion. > > > > Regards, > > Lucy Yong > > Huawei Technologies, U.S. > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 12:07:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivtS-000319-N5; Wed, 24 May 2006 12:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivtS-000314-12 for pce@ietf.org; Wed, 24 May 2006 12:07:30 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FivtP-0006tG-0Q for pce@ietf.org; Wed, 24 May 2006 12:07:30 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fivt6-0003DZ-00 for pce@ietf.org; Wed, 24 May 2006 17:07:08 +0100 Received: from your029b8cecfe ([217.158.132.49] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 17:07:02 +0100 Message-ID: <031601c67f4c$13b35640$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Lucy Yong" References: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> Date: Wed, 24 May 2006 17:02:25 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 May 2006 16:07:03.0207 (UTC) FILETIME=[18824370:01C67F4C] X-Spam-Score: 0.1 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df Cc: pce@ietf.org Subject: [Pce] Re: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1534153504==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1534153504== Content-Type: multipart/alternative; boundary="----=_NextPart_000_030C_01C67F53.D4CE2290" This is a multi-part message in MIME format. ------=_NextPart_000_030C_01C67F53.D4CE2290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lucy, > The draft layouts the basic PCE architecture and expresses the = motivation > for a PCE-based architecture. It is a good document. Thanks. > Beyond these motivation facts, I think we should have another = incentive for > a PCE-based architecture. >=20 > Today, a control plane based switching architecture assumes a = user-network > model or client-server model. A LSP is initiated at an end user point > (client), then network establishes the LSP thru. the control plane > instantly. PCE reserves that concept too. Thus all connection paths = are > based on instant requests from end users. I think it is true that PCE supports this model, but I don't think it is = the case that the assumptions you state are universal. 1. The user-network model and the client-server model are examples of = how one might use a control plane-based switching network, but they are = not the only examples. 2. To say that all connection paths are based on instant requests from = end users slightly misses the point of PCE. PCE performs computations = based on requests from an external entity (the PCC), and PCE operates on = a TED. There is nothing that says that the TED must be a representation = of the network at only one instant of time, and there is nothing that = says that the computation request must demand a computation "now". > In carrier reality world, it is hard to see that transport service = will be > offered this way only, especially for a large bandwidth and permanent > bandwidth request. Hmmm. This may be why I disagreed with your assumptions! :-) > Typically, carrier has a service order reservation > system, it allows customer to book a bandwidth ahead (pending order), > carrier will do traffic engineering based on the pending order and = will > excuse the order when the time arrives. Yes, this is another valid model. But it is also not the only valid = model and many transport networks are operated today on a much more = flexible approach. > A path computer engine has a > capability of taking a consideration about future pending orders while = it > computes a path. I am unsure whether what you say matches reality perfectly. That is, when a pending future order is entered into the system, the = reservation is made. This means that the TED reflects the results of the = order/computation/fulfilment cycle, and that computations are still = prefomred on demand (i.e. "now"). The difference is that the = provisioning (fulfilment) is some time in the future. In this case, it seems unlikely that you would feed your TED from the = routing protocols, but rather from inventory discovery and from the = service ordering/fulfilment process. Figure 5 in the architecture shows = this model. > The architecture is pretty close to the PCE-based > architecture except a lot of manual operation. I think PCE should = consider > this as its application too and revise the basic architecture to = include > this functionality.=20 There is nothing (IMHO) in the current architecture that prohibits = either the management plane use of PCE, or the inclusion of a time = dimension in the TED and the computaiton requests. > Here is the recommendation for the PCE-based architecture: >=20 > --------------- > | --------- | Routing ---------- > | | | | Protocol | | > | | TED |<-+----------+-> | > | | | | | | > | --------- | | | > | | | | | > | | Input | | | > | v | | | > ---------- Response | --------- | | | > | |Request | | | | | Adjacent | > | SORD |<------->| | PCE | | | Node | > | |Input | | | | | | > ---------- | --------- | | | > ^ | ^ | | | > | | |Request | | | > | | |Response| | | > Service Order | v | | | > | --------- | | | > Service | | | | Signaling| | > Request | |Signaling| | Protocol | | > ------+->| Engine |<-+----------+-> | > | | | | | | > | --------- | ---------- > --------------- > > Here, SORD is the service order reservation database, it contains all > service order requests in terms of ingress and egress points, = bandwidth, > service type, time period for the request, etc. When PCE computes a = path, it > could get input from SORD to indicate if there are some network = resource is > already blocked out. When a booking order in SORD is ready to kick = off, SORD > will send request to PCE for the path computation, then PCE will send = a > service request to signaling engine to establish the LSP.=20 This would be hugely inefficient, wouldn't it? Since PCE cannot guess which resources might be blocked out for future = requests, it would have to make this query for every computation. = Further, if PCE only made the query for resources that satisfied the = computation, it might have to make repeated recomputations, so it would = be more efficient for it to retrieve information about every future = blocking.=20 So, in fact, it makes more sense for SORD to feed the information into = the TED and allow PCE to operate on the full database. But consider: How does SORD know which resources will be reserved and = when? Presumably, it has consulted PCE as well. > It is clarified that not all pending orders in SORD need to reserve = the > bandwidth ahead, carrier could have some policies in SORD to manage = which > order need to reserve the bandwidth ahead and which is not. >=20 > Be glad to hear your and other people comment on this suggestion. If you wanted to work on some issue like "Applicability of PCE to = time-scoped service requests" this might be of interest to people. It = was raised in the early days of PCE and of L1VPN, but did not attract = significant interest. I think that the feeling at the time was that it = was out of scope for PCE, but formed part of a management system. = However, it might be that there would be value in enhancing the PCE = protocol to carry time delimiters for computation requests. Note that the PCE working group is interested in applications of PCE and = the protocols involved, but is not so interested in abstract functional = components that are beyond the scope of the working group. Regards, Adrian ------=_NextPart_000_030C_01C67F53.D4CE2290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Lucy,
 
> The draft layouts the basic PCE = architecture=20 and expresses the motivation
> for a PCE-based architecture. It is = a good=20 document.
 
Thanks.

> Beyond these motivation = facts, I=20 think we should have another incentive for
> a PCE-based=20 architecture.
>
> Today, a control plane based switching=20 architecture assumes a user-network
> model or client-server = model. A LSP=20 is initiated at an end user point
> (client), then network = establishes the=20 LSP thru. the control plane
> instantly. PCE reserves that concept = too.=20 Thus all connection paths are
> based on instant requests from end = users.
 
I think it is true that PCE supports = this model,=20 but I don't think it is the case that the assumptions you state are=20 universal.
 
1. The user-network model and the = client-server=20 model are examples of how one might use a control plane-based switching = network,=20 but they are not the only examples.
 
2. To say that all connection paths are = based on=20 instant requests from end users slightly misses the point of PCE. PCE = performs=20 computations based on requests from an external entity (the PCC), and = PCE=20 operates on a TED. There is nothing that says that the TED must be a=20 representation of the network at only one instant of time, and there is = nothing=20 that says that the computation request must demand a computation=20 "now".

> In carrier reality world, it = is hard to=20 see that transport service will be
> offered this way only, = especially for=20 a large bandwidth and permanent
> bandwidth request.
 
Hmmm. This may be why I disagreed with = your=20 assumptions! :-)
 
> Typically, carrier has a = service order=20 reservation
> system, it allows customer to book a bandwidth ahead = (pending order),
> carrier will do traffic engineering based on = the=20 pending order and will
> excuse the order when the time=20 arrives.
 
Yes, this is another valid model. But = it is also=20 not the only valid model and many transport networks are operated today = on a=20 much more flexible approach.
 
> A path computer engine has = a
>=20 capability of taking a consideration about future pending orders while=20 it
> computes a path.
 
I am unsure whether what you say = matches reality=20 perfectly.
 
That is, when a pending future order is = entered=20 into the system, the reservation is made. This means that the TED = reflects the=20 results of the order/computation/fulfilment cycle, and that computations = are=20 still prefomred on demand (i.e. "now"). The difference is that the = provisioning=20 (fulfilment) is some time in the future.
 
In this case, it seems unlikely that = you would feed=20 your TED from the routing protocols, but rather from inventory discovery = and=20 from the service ordering/fulfilment process. Figure 5 in the = architecture shows=20 this model.
 
> The architecture is pretty = close to the=20 PCE-based
> architecture except a lot of manual operation. I think = PCE=20 should consider
> this as its application too and revise the basic = architecture to include
> this functionality.
 
There is nothing (IMHO) in the current = architecture=20 that prohibits either the management plane use of PCE, or the inclusion = of a=20 time dimension in the TED and the computaiton requests.
 
> Here, SORD is the service order = reservation=20 database, it contains all
> service order requests in terms of = ingress and=20 egress points, bandwidth,
> service type, time period for the = request,=20 etc. When PCE computes a path, it
> could get input from SORD to = indicate=20 if there are some network resource is
> already blocked out. When = a=20 booking order in SORD is ready to kick off, SORD
> will send = request to=20 PCE for the path computation, then PCE will send a
> service = request to=20 signaling engine to establish the LSP.
 
This would be hugely inefficient, = wouldn't=20 it?
Since PCE cannot guess which resources = might be=20 blocked out for future requests, it would have to make this query for = every=20 computation. Further, if PCE only made the query for resources that = satisfied=20 the computation, it might have to make repeated recomputations, so it = would be=20 more efficient for it to retrieve information about every future = blocking.=20
So, in fact, it makes more sense for = SORD to feed=20 the information into the TED and allow PCE to operate on the full=20 database.
 
But consider: How does SORD know which = resources=20 will be reserved and when? Presumably, it has consulted PCE as=20 well.
 
> It is clarified that not all pending orders in SORD need to = reserve=20 the
> bandwidth ahead, carrier could have some policies in SORD to = manage=20 which
> order need to reserve the bandwidth ahead and which is=20 not.
>
> Be glad to hear your and other people comment on = this=20 suggestion.
If you wanted to work on some issue like "Applicability of PCE to=20 time-scoped service requests" this might be of interest to people. It = was raised=20 in the early days of PCE and of L1VPN, but did not attract significant = interest.=20 I think that the feeling at the time was that it was out of scope for = PCE, but=20 formed part of a management system. However, it might be that there = would be=20 value in enhancing the PCE protocol to carry time delimiters for = computation=20 requests.
 
Note that the PCE working group is interested in applications of = PCE and=20 the protocols involved, but is not so interested in abstract functional=20 components that are beyond the scope of the working group.
 
Regards,
Adrian
------=_NextPart_000_030C_01C67F53.D4CE2290-- --===============1534153504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1534153504==-- From pce-bounces@lists.ietf.org Wed May 24 12:12:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivxs-00069a-Ce; Wed, 24 May 2006 12:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivxp-000674-DA for pce@ietf.org; Wed, 24 May 2006 12:12:01 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fivxo-00075Z-4Q for pce@ietf.org; Wed, 24 May 2006 12:12:01 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fivxk-0003rz-00 for pce@ietf.org; Wed, 24 May 2006 17:11:56 +0100 Received: from your029b8cecfe ([217.158.132.49] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 17:11:57 +0100 Message-ID: <031c01c67f4c$c1b31960$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Meral Shirazipour" , "Lucy Yong" References: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> <1148486444.4474832ce7904@www.imp.polymtl.ca> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Date: Wed, 24 May 2006 17:10:51 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 May 2006 16:11:58.0022 (UTC) FILETIME=[C83B7660:01C67F4C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Begging your pardon, Meral, but I'm a bit confused. > I agree with what you say here. This is a fact to consider especially if > the > PCE architecture is to be adapted later on for inter-AS TE in the > 'Internet'. > What you say here is important if we consider the Internet peering models. The architecture is already intended to be "adapted" for that purpose. Have a quick read through the first few sections and you'll see ample discussion of inter-AS. Lucy's email seems to me to be about the time-based reservation of resources. This doesn't seem to me to be outside the scope of the current architecture, but one might want to write down how PCE is used for that purpose as an informational draft. Personally, I would find Lucy's suggestion of a distinct component and database that was consulted for each computation request a costly idea, and would prefer to see this type of function rolled into a single database. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 12:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivyu-0006Uf-EZ; Wed, 24 May 2006 12:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivyt-0006UQ-5h for pce@ietf.org; Wed, 24 May 2006 12:13:07 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fivyq-0007Af-Jo for pce@ietf.org; Wed, 24 May 2006 12:13:07 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4OGBqmg018632; Wed, 24 May 2006 18:11:52 +0200 In-Reply-To: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> To: Lucy Yong Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 24 May 2006 18:11:45 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/24/2006 18:11:51, Serialize complete at 05/24/2006 18:11:51 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org i have one specific comment ... what i see progressively is that work item = enters into the document of specific "architectures" ... while the role of the working group is to - per charter - The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating=20 PCEs note: LSR =3D Label Switching Router i start to have some concerns in building around a PC (functional) element = a global network architecture with all related transactional user request=20 and so forth... so i have a suggestion - summarize the message around=20 section 5 and close this section by detailing areas of standardization=20 Lucy Yong 24/05/2006 17:06 =20 To: "'Adrian Farrel'" cc: pce@ietf.org Subject: [Pce] Comments about=20 draft-ietf-pce-architecture-05 Adrian, =20 The draft layouts the basic PCE architecture and expresses the motivation=20 for a PCE-based architecture. It is a good document. Beyond these motivation facts, I think we should have another incentive=20 for a PCE-based architecture. =20 Today, a control plane based switching architecture assumes a user-network = model or client-server model. A LSP is initiated at an end user point=20 (client), then network establishes the LSP thru. the control plane=20 instantly. PCE reserves that concept too. Thus all connection paths are=20 based on instant requests from end users. =20 In carrier reality world, it is hard to see that transport service will be = offered this way only, especially for a large bandwidth and permanent=20 bandwidth request. Typically, carrier has a service order reservation=20 system, it allows customer to book a bandwidth ahead (pending order),=20 carrier will do traffic engineering based on the pending order and will=20 excuse the order when the time arrives. A path computer engine has a=20 capability of taking a consideration about future pending orders while it=20 computes a path. The architecture is pretty close to the PCE-based=20 architecture except a lot of manual operation. I think PCE should consider = this as its application too and revise the basic architecture to include=20 this functionality.=20 =20 Here is the recommendation for the PCE-based architecture: =20 --------------- | --------- | Routing ---------- | | | | Protocol | | | | TED |<-+----------+-> | | | | | | | | --------- | | | | | | | | | | Input | | | | v | | | ---------- Response | --------- | | | | |Request | | | | | Adjacent | | SORD |=DF----=E0 | | PCE | | | Node | | |Input | | | | | | ---------- | --------- | | | ^ | ^ | | | | | |Request | | | | | |Response| | | Service Order | v | | | | --------- | | | Service | | | | Signaling| | Request | |Signaling| | Protocol | | ------+->| Engine |<-+----------+-> | | | | | | | | --------- | ---------- --------------- =20 Here, SORD is the service order reservation database, it contains all=20 service order requests in terms of ingress and egress points, bandwidth,=20 service type, time period for the request, etc. When PCE computes a path,=20 it could get input from SORD to indicate if there are some network=20 resource is already blocked out. When a booking order in SORD is ready to=20 kick off, SORD will send request to PCE for the path computation, then PCE = will send a service request to signaling engine to establish the LSP.=20 =20 It is clarified that not all pending orders in SORD need to reserve the=20 bandwidth ahead, carrier could have some policies in SORD to manage which=20 order need to reserve the bandwidth ahead and which is not. =20 Be glad to hear your and other people comment on this suggestion. =20 Regards, Lucy Yong Huawei Technologies, U.S. =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 12:47:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwW1-000429-IG; Wed, 24 May 2006 12:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwW0-00041z-0c for pce@ietf.org; Wed, 24 May 2006 12:47:20 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiwVx-0000q8-Lz for pce@ietf.org; Wed, 24 May 2006 12:47:19 -0400 Received: from localhost (imp-4-1.polymtl.ca [132.207.4.76]) by smtp.polymtl.ca (8.13.6/8.13.6) with ESMTP id k4OGkghX019931; Wed, 24 May 2006 12:46:44 -0400 Received: from 132.207.176.236 ([132.207.176.236]) by www.imp.polymtl.ca (IMP) with HTTP for ; Wed, 24 May 2006 12:46:42 -0400 Message-ID: <1148489202.44748df25e812@www.imp.polymtl.ca> Date: Wed, 24 May 2006 12:46:42 -0400 From: Meral Shirazipour To: Adrian Farrel Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 References: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> <1148486444.4474832ce7904@www.imp.polymtl.ca> <031c01c67f4c$c1b31960$0a23fea9@your029b8cecfe> In-Reply-To: <031c01c67f4c$c1b31960$0a23fea9@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 132.207.176.236 X-Poly-FromMTA: (imp-4-1.polymtl.ca [132.207.4.76]) at Wed, 24 May 2006 16:46:42 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.polymtl.ca id k4OGkghX019931 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "pce@ietf.org" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear Adrian, I apologize for the lack of clarity in my previous comment. I think Lu= cy has a point. But I do not think the draft needs to me modified. My comment on =93the applicability of the PCE architecture in the Interne= t at large=94 comes from the following lines in the Description of Working Gro= up. (http://www.ietf.org/html.charters/pce-charter.html). I was referring to: =93The 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.=94 This said, I think if our ultimate goal is to do inter-AS TE and path optimization in a PCE-based architecture, we must consider TED updating i= ssues and PCE signaling responsiveness while we are still at the definition sta= ge of the architecture and signaling protocols. Best regards, Meral Shirazipour _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 13:08:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiwqn-00039P-OH; Wed, 24 May 2006 13:08:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiwqm-00039J-24 for pce@ietf.org; Wed, 24 May 2006 13:08:48 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiwqk-0001pH-PW for pce@ietf.org; Wed, 24 May 2006 13:08:48 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS00L004TD5R@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 10:05:38 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS007S44T81V@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 10:05:37 -0700 (PDT) Date: Wed, 24 May 2006 12:08:40 -0500 From: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: <031c01c67f4c$c1b31960$0a23fea9@your029b8cecfe> To: 'Adrian Farrel' , 'Meral Shirazipour' Message-id: <003101c67f54$b519b8a0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org All, Thank you for all the comments. PCE should support time-base reservation in the general and leave as an option for carrier to implement or not. If we exclude this functionality, it is hard to see the full automatic network because there are quite these kinds of service demands and carrier also encourages the pre-order so they can proactively engineer the network. I'll be glad to write an informational draft to explain the possible mechanism and protocols. Weather the function should be maintained in the same database or separated databases, it would be better to see after clarifying the functionality of each element first, and then decide the solution. The service reservation database mentioned here has a lot of information that PCE does not need and has no responsibility to maintain them. Maybe some cache mechanism could be used. Welcome anyone to provide the input on the informational draft. Best Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 11:11 AM To: Meral Shirazipour; Lucy Yong Cc: pce@ietf.org Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Begging your pardon, Meral, but I'm a bit confused. > I agree with what you say here. This is a fact to consider especially if > the > PCE architecture is to be adapted later on for inter-AS TE in the > 'Internet'. > What you say here is important if we consider the Internet peering models. The architecture is already intended to be "adapted" for that purpose. Have a quick read through the first few sections and you'll see ample discussion of inter-AS. Lucy's email seems to me to be about the time-based reservation of resources. This doesn't seem to me to be outside the scope of the current architecture, but one might want to write down how PCE is used for that purpose as an informational draft. Personally, I would find Lucy's suggestion of a distinct component and database that was consulted for each computation request a costly idea, and would prefer to see this type of function rolled into a single database. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 13:26:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fix7Y-0002kg-4r; Wed, 24 May 2006 13:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fix7W-0002kb-S9 for pce@ietf.org; Wed, 24 May 2006 13:26:06 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fix7U-0002XC-C3 for pce@ietf.org; Wed, 24 May 2006 13:26:06 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4OHPYHr012045; Wed, 24 May 2006 19:25:34 +0200 In-Reply-To: <003101c67f54$b519b8a0$d4087c0a@china.huawei.com> To: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 24 May 2006 19:25:27 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/24/2006 19:25:34, Serialize complete at 05/24/2006 19:25:34 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org the question is why "time constraint" should be taken into account during path computation that would justify incorporation into the communication between LSR-PCE/PCE-PCE elements scheduling of LSPs - themselves - is outside the scope of the comm process between LSR-PCE/PCE-PCE elements, it is even outside the scope of the PCE (since not a resource manager of some sort) Lucy Yong 24/05/2006 19:08 To: "'Adrian Farrel'" , "'Meral Shirazipour'" cc: pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 All, Thank you for all the comments. PCE should support time-base reservation in the general and leave as an option for carrier to implement or not. If we exclude this functionality, it is hard to see the full automatic network because there are quite these kinds of service demands and carrier also encourages the pre-order so they can proactively engineer the network. I'll be glad to write an informational draft to explain the possible mechanism and protocols. Weather the function should be maintained in the same database or separated databases, it would be better to see after clarifying the functionality of each element first, and then decide the solution. The service reservation database mentioned here has a lot of information that PCE does not need and has no responsibility to maintain them. Maybe some cache mechanism could be used. Welcome anyone to provide the input on the informational draft. Best Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 11:11 AM To: Meral Shirazipour; Lucy Yong Cc: pce@ietf.org Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Begging your pardon, Meral, but I'm a bit confused. > I agree with what you say here. This is a fact to consider especially if > the > PCE architecture is to be adapted later on for inter-AS TE in the > 'Internet'. > What you say here is important if we consider the Internet peering models. The architecture is already intended to be "adapted" for that purpose. Have a quick read through the first few sections and you'll see ample discussion of inter-AS. Lucy's email seems to me to be about the time-based reservation of resources. This doesn't seem to me to be outside the scope of the current architecture, but one might want to write down how PCE is used for that purpose as an informational draft. Personally, I would find Lucy's suggestion of a distinct component and database that was consulted for each computation request a costly idea, and would prefer to see this type of function rolled into a single database. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 13:26:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fix7t-0002mS-CD; Wed, 24 May 2006 13:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fix7s-0002mN-MX for pce@ietf.org; Wed, 24 May 2006 13:26:28 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fix7r-0002bG-Ct for pce@ietf.org; Wed, 24 May 2006 13:26:28 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS00J4K5MU83@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 10:23:18 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS006VM5MKYO@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 10:23:18 -0700 (PDT) Date: Wed, 24 May 2006 12:26:16 -0500 From: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: <1148489202.44748df25e812@www.imp.polymtl.ca> To: 'Meral Shirazipour' , 'Adrian Farrel' Message-id: <003201c67f57$2da49180$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Meral, PCE group is formed recently. If this is out of charter scope, it may be added on if this is really valuable function. As Adrian mentions that the basic architecture scope already 'adapt' this functionality, but seems it is clear how PCE performs this function yet. We are researching some advanced intelligent network to accomplish intelligent automatic LSP establish and tear down. If the reservation functionality is scoped out because of network size, I don't think that is proper. See more below. Regards, Lucy -----Original Message----- From: Meral Shirazipour [mailto:meral.shirazipour@polymtl.ca] Sent: Wednesday, May 24, 2006 11:47 AM To: Adrian Farrel Cc: Lucy Yong; pce@ietf.org Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Dear Adrian, I apologize for the lack of clarity in my previous comment. I think Lucy has a point. But I do not think the draft needs to me modified. My comment on "the applicability of the PCE architecture in the Internet at large" comes from the following lines in the Description of Working Group. (http://www.ietf.org/html.charters/pce-charter.html). I was referring to: "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." This said, I think if our ultimate goal is to do inter-AS TE and path optimization in a PCE-based architecture, we must consider TED updating issues and PCE signaling responsiveness while we are still at the definition stage of the architecture and signaling protocols. Lucy: I don't see the conflict here. WG should study all these issues. However, these should not prevent from studying time-based reservation either, especially in the architecture design stage. Best regards, Meral Shirazipour _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 13:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixEc-0006AW-Lw; Wed, 24 May 2006 13:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixEb-00066p-Tg for pce@ietf.org; Wed, 24 May 2006 13:33:25 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FixEa-000370-Iw for pce@ietf.org; Wed, 24 May 2006 13:33:25 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS00JH15YC83@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 10:30:12 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS002GC5Y6V5@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 10:30:11 -0700 (PDT) Date: Wed, 24 May 2006 12:33:15 -0500 From: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: To: Dimitri.Papadimitriou@alcatel.be Message-id: <003301c67f58$243e9a90$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dimitri, Because for some important reservations, carrier want to reserve the specific path for many purposes such as better optimization, request length period, service guarantee, etc. Why should PCE WG limits the scope between LSR-PCE/PCE-PCE elements? We are defining the architecture now. Adrian has mentioned that it is in PCE scope. Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Wednesday, May 24, 2006 12:25 PM To: Lucy Yong Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 the question is why "time constraint" should be taken into account during path computation that would justify incorporation into the communication between LSR-PCE/PCE-PCE elements scheduling of LSPs - themselves - is outside the scope of the comm process between LSR-PCE/PCE-PCE elements, it is even outside the scope of the PCE (since not a resource manager of some sort) Lucy Yong 24/05/2006 19:08 To: "'Adrian Farrel'" , "'Meral Shirazipour'" cc: pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 All, Thank you for all the comments. PCE should support time-base reservation in the general and leave as an option for carrier to implement or not. If we exclude this functionality, it is hard to see the full automatic network because there are quite these kinds of service demands and carrier also encourages the pre-order so they can proactively engineer the network. I'll be glad to write an informational draft to explain the possible mechanism and protocols. Weather the function should be maintained in the same database or separated databases, it would be better to see after clarifying the functionality of each element first, and then decide the solution. The service reservation database mentioned here has a lot of information that PCE does not need and has no responsibility to maintain them. Maybe some cache mechanism could be used. Welcome anyone to provide the input on the informational draft. Best Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 11:11 AM To: Meral Shirazipour; Lucy Yong Cc: pce@ietf.org Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Begging your pardon, Meral, but I'm a bit confused. > I agree with what you say here. This is a fact to consider especially if > the > PCE architecture is to be adapted later on for inter-AS TE in the > 'Internet'. > What you say here is important if we consider the Internet peering models. The architecture is already intended to be "adapted" for that purpose. Have a quick read through the first few sections and you'll see ample discussion of inter-AS. Lucy's email seems to me to be about the time-based reservation of resources. This doesn't seem to me to be outside the scope of the current architecture, but one might want to write down how PCE is used for that purpose as an informational draft. Personally, I would find Lucy's suggestion of a distinct component and database that was consulted for each computation request a costly idea, and would prefer to see this type of function rolled into a single database. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 13:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixUK-0004cK-FS; Wed, 24 May 2006 13:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixUJ-0004cE-H5 for pce@ietf.org; Wed, 24 May 2006 13:49:39 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FixUH-0004Nz-V1 for pce@ietf.org; Wed, 24 May 2006 13:49:39 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4OHnWlc018565; Wed, 24 May 2006 19:49:32 +0200 In-Reply-To: <003301c67f58$243e9a90$d4087c0a@china.huawei.com> To: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 24 May 2006 19:49:24 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/24/2006 19:49:31, Serialize complete at 05/24/2006 19:49:31 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org lucy - take a look at section 6.16, if there is a need to consider - as you wrote - that "PCE should support time-base reservation in the general and leave as an option for carrier to implement or not." i would like to hear from operators specific rationales to incorporate as part of the communication protocol / PCE processing any time constraint now more fundamentally and as stated the role of the group is to define IP communication protocols not network architectures of some sort - reason for the suggestion made on section 5 adrian mentions what is that inter-AS PCE is in scope, he forgot probably to mention to you that the primary concerns of the work ongoing here is driven by four major concerns: scalability, performance, robustness and resiliency from this perspective any time constraint is going to seriously impact all these base objectives Lucy Yong 24/05/2006 19:33 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "'Adrian Farrel'" , "'Meral Shirazipour'" , pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 Dimitri, Because for some important reservations, carrier want to reserve the specific path for many purposes such as better optimization, request length period, service guarantee, etc. Why should PCE WG limits the scope between LSR-PCE/PCE-PCE elements? We are defining the architecture now. Adrian has mentioned that it is in PCE scope. Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Wednesday, May 24, 2006 12:25 PM To: Lucy Yong Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 the question is why "time constraint" should be taken into account during path computation that would justify incorporation into the communication between LSR-PCE/PCE-PCE elements scheduling of LSPs - themselves - is outside the scope of the comm process between LSR-PCE/PCE-PCE elements, it is even outside the scope of the PCE (since not a resource manager of some sort) Lucy Yong 24/05/2006 19:08 To: "'Adrian Farrel'" , "'Meral Shirazipour'" cc: pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 All, Thank you for all the comments. PCE should support time-base reservation in the general and leave as an option for carrier to implement or not. If we exclude this functionality, it is hard to see the full automatic network because there are quite these kinds of service demands and carrier also encourages the pre-order so they can proactively engineer the network. I'll be glad to write an informational draft to explain the possible mechanism and protocols. Weather the function should be maintained in the same database or separated databases, it would be better to see after clarifying the functionality of each element first, and then decide the solution. The service reservation database mentioned here has a lot of information that PCE does not need and has no responsibility to maintain them. Maybe some cache mechanism could be used. Welcome anyone to provide the input on the informational draft. Best Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 11:11 AM To: Meral Shirazipour; Lucy Yong Cc: pce@ietf.org Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Begging your pardon, Meral, but I'm a bit confused. > I agree with what you say here. This is a fact to consider especially if > the > PCE architecture is to be adapted later on for inter-AS TE in the > 'Internet'. > What you say here is important if we consider the Internet peering models. The architecture is already intended to be "adapted" for that purpose. Have a quick read through the first few sections and you'll see ample discussion of inter-AS. Lucy's email seems to me to be about the time-based reservation of resources. This doesn't seem to me to be outside the scope of the current architecture, but one might want to write down how PCE is used for that purpose as an informational draft. Personally, I would find Lucy's suggestion of a distinct component and database that was consulted for each computation request a costly idea, and would prefer to see this type of function rolled into a single database. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 15:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiyg5-0000db-F9; Wed, 24 May 2006 15:05:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiyg3-0000dJ-Ry for pce@ietf.org; Wed, 24 May 2006 15:05:51 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiyg2-0000J3-S9 for pce@ietf.org; Wed, 24 May 2006 15:05:51 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS00J4K9PS83@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 11:51:28 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS002TC9PHEG@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 11:51:28 -0700 (PDT) Date: Wed, 24 May 2006 13:54:25 -0500 From: Lucy Yong In-reply-to: <031601c67f4c$13b35640$0a23fea9@your029b8cecfe> To: 'Adrian Farrel' Message-id: <003401c67f63$7da39440$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 885bdbbd21ade8122610f36a666788c5 Cc: pce@ietf.org Subject: [Pce] RE: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2078715529==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2078715529== Content-type: multipart/alternative; boundary="Boundary_(ID_UY9I/MqCeWWUBR7roUW4+g)" This is a multi-part message in MIME format. --Boundary_(ID_UY9I/MqCeWWUBR7roUW4+g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Adrian, First of all, highly appreciate your all great comments. See my comment below. Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 11:02 AM To: Lucy Yong Cc: pce@ietf.org Subject: Re: Comments about draft-ietf-pce-architecture-05 Hi Lucy, > The draft layouts the basic PCE architecture and expresses the motivation > for a PCE-based architecture. It is a good document. Thanks. > Beyond these motivation facts, I think we should have another incentive for > a PCE-based architecture. > > Today, a control plane based switching architecture assumes a user-network > model or client-server model. A LSP is initiated at an end user point > (client), then network establishes the LSP thru. the control plane > instantly. PCE reserves that concept too. Thus all connection paths are > based on instant requests from end users. I think it is true that PCE supports this model, but I don't think it is the case that the assumptions you state are universal. 1. The user-network model and the client-server model are examples of how one might use a control plane-based switching network, but they are not the only examples. Accept this comment. 2. To say that all connection paths are based on instant requests from end users slightly misses the point of PCE. PCE performs computations based on requests from an external entity (the PCC), and PCE operates on a TED. There is nothing that says that the TED must be a representation of the network at only one instant of time, and there is nothing that says that the computation request must demand a computation "now". OK PCE does specify an instant request from end-user or NMS. TED defined in the draft contains the topology and resource information of the domain. It is very unclear if it can sever bandwidth reservation purpose or not. In addition, TED is not excluded to reside within network, which is hard to use this purpose. > In carrier reality world, it is hard to see that transport service will be > offered this way only, especially for a large bandwidth and permanent > bandwidth request. Hmmm. This may be why I disagreed with your assumptions! :-) Maybe my words here are not clear to you. I means that it is hard to see that transport service will be only offered in the way that an end user sends a signal request at ingress point at the time that a bandwidth needed. > Typically, carrier has a service order reservation > system, it allows customer to book a bandwidth ahead (pending order), > carrier will do traffic engineering based on the pending order and will > excuse the order when the time arrives. Yes, this is another valid model. But it is also not the only valid model and many transport networks are operated today on a much more flexible approach. I agree. Does the architecture need to enable other approaches? > A path computer engine has a > capability of taking a consideration about future pending orders while it > computes a path. I am unsure whether what you say matches reality perfectly. That is, when a pending future order is entered into the system, the reservation is made. This means that the TED reflects the results of the order/computation/fulfilment cycle, and that computations are still prefomred on demand (i.e. "now"). The difference is that the provisioning (fulfilment) is some time in the future. In this case, it seems unlikely that you would feed your TED from the routing protocols, but rather from inventory discovery and from the service ordering/fulfilment process. Figure 5 in the architecture shows this model. That is the goal to feed TED from the routing protocols and let PCE use TED information and SORD information to compute the path. I think resource inventory should come from network instead of human entering. Figure 5 show NMS initiating the service request, but does not show the reservation capability. You mention that the architecture does not prohibit time-based reservation. But it does not explicitly support that either. It is hard to see through it. If this is a valid function, could we explicitly specify it instead of "imply it"? Maybe insert section 5.6 to illustrate this model. That is my suggestion to expand the architecture including this scenario. This adds value for the PCE. > The architecture is pretty close to the PCE-based > architecture except a lot of manual operation. I think PCE should consider > this as its application too and revise the basic architecture to include > this functionality. There is nothing (IMHO) in the current architecture that prohibits either the management plane use of PCE, or the inclusion of a time dimension in the TED and the computaiton requests. It seems that current TED definition does not serve this function. > Here is the recommendation for the PCE-based architecture: > > --------------- > | --------- | Routing ---------- > | | | | Protocol | | > | | TED |<-+----------+-> | > | | | | | | > | --------- | | | > | | | | | > | | Input | | | > | v | | | > ---------- Response | --------- | | | > | |Request | | | | | Adjacent | > | SORD |<------->| | PCE | | | Node | > | |Input | | | | | | > ---------- | --------- | | | > ^ | ^ | | | > | | |Request | | | > | | |Response| | | > Service Order | v | | | > | --------- | | | > Service | | | | Signaling| | > Request | |Signaling| | Protocol | | > ------+->| Engine |<-+----------+-> | > | | | | | | > | --------- | ---------- > --------------- > > Here, SORD is the service order reservation database, it contains all > service order requests in terms of ingress and egress points, bandwidth, > service type, time period for the request, etc. When PCE computes a path, it > could get input from SORD to indicate if there are some network resource is > already blocked out. When a booking order in SORD is ready to kick off, SORD > will send request to PCE for the path computation, then PCE will send a > service request to signaling engine to establish the LSP. This would be hugely inefficient, wouldn't it? Since PCE cannot guess which resources might be blocked out for future requests, it would have to make this query for every computation. Further, if PCE only made the query for resources that satisfied the computation, it might have to make repeated recomputations, so it would be more efficient for it to retrieve information about every future blocking. So, in fact, it makes more sense for SORD to feed the information into the TED and allow PCE to operate on the full database. But consider: How does SORD know which resources will be reserved and when? Presumably, it has consulted PCE as well. > It is clarified that not all pending orders in SORD need to reserve the > bandwidth ahead, carrier could have some policies in SORD to manage which > order need to reserve the bandwidth ahead and which is not. > > Be glad to hear your and other people comment on this suggestion. If you wanted to work on some issue like "Applicability of PCE to time-scoped service requests" this might be of interest to people. It was raised in the early days of PCE and of L1VPN, but did not attract significant interest. I think that the feeling at the time was that it was out of scope for PCE, but formed part of a management system. However, it might be that there would be value in enhancing the PCE protocol to carry time delimiters for computation requests. Note that the PCE working group is interested in applications of PCE and the protocols involved, but is not so interested in abstract functional components that are beyond the scope of the working group. Regards, Adrian --Boundary_(ID_UY9I/MqCeWWUBR7roUW4+g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Adrian,

 

First of all, highly appreciate your all great comments. See my comment below.

 

Regards,

Lucy

 

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, May 24, 2006 11:02 AM
To: Lucy Yong
Cc: pce@ietf.org
Subject: Re: Comments about draft-ietf-pce-architecture-05

 

Hi Lucy,

 

> The draft layouts the basic PCE architecture and expresses the motivation
> for a PCE-based architecture. It is a good document.

 

Thanks.


> Beyond these motivation facts, I think we should have another incentive for
> a PCE-based architecture.
>
> Today, a control plane based switching architecture assumes a user-network
> model or client-server model. A LSP is initiated at an end user point
> (client), then network establishes the LSP thru. the control plane
> instantly. PCE reserves that concept too. Thus all connection paths are
> based on instant requests from end users.

 

I think it is true that PCE supports this model, but I don't think it is the case that the assumptions you state are universal.

 

1.       The user-network model and the client-server model are examples of how one might use a control plane-based switching network, but they are not the only examples.

Accept this comment.

 

2. To say that all connection paths are based on instant requests from end users slightly misses the point of PCE. PCE performs computations based on requests from an external entity (the PCC), and PCE operates on a TED. There is nothing that says that the TED must be a representation of the network at only one instant of time, and there is nothing that says that the computation request must demand a computation "now".

OK PCE does specify an instant request from end-user or NMS. TED defined in the draft contains the topology and resource information of the domain. It is very unclear if it can sever bandwidth reservation purpose or not. In addition, TED is not excluded to reside within network, which is hard to use this purpose.


> In carrier reality world, it is hard to see that transport service will be
> offered this way only, especially for a large bandwidth and permanent
> bandwidth request.

 

Hmmm. This may be why I disagreed with your assumptions! :-)

 

Maybe my words here are not clear to you. I means that it is hard to see that transport service will be only offered in the way that an end user sends a signal request at ingress point at the time that a bandwidth needed.

 

> Typically, carrier has a service order reservation
> system, it allows customer to book a bandwidth ahead (pending order),
> carrier will do traffic engineering based on the pending order and will
> excuse the order when the time arrives.

 

Yes, this is another valid model. But it is also not the only valid model and many transport networks are operated today on a much more flexible approach.

 I agree. Does the architecture need to enable other approaches?

 

> A path computer engine has a
> capability of taking a consideration about future pending orders while it
> computes a path.

 

I am unsure whether what you say matches reality perfectly.

 

That is, when a pending future order is entered into the system, the reservation is made. This means that the TED reflects the results of the order/computation/fulfilment cycle, and that computations are still prefomred on demand (i.e. "now"). The difference is that the provisioning (fulfilment) is some time in the future.

 

In this case, it seems unlikely that you would feed your TED from the routing protocols, but rather from inventory discovery and from the service ordering/fulfilment process. Figure 5 in the architecture shows this model.

 

 That is the goal to feed TED from the routing protocols and let PCE use TED information and SORD information to compute the path. I think resource inventory should come from network instead of human entering.  Figure 5 show NMS initiating the service request, but does not show the reservation capability.

 

You mention that the architecture does not prohibit time-based reservation. But it does not explicitly support that either. It is hard to see through it. If this is a valid function, could we explicitly specify it instead of “imply it”? Maybe insert section 5.6 to illustrate this model.

That is my suggestion to expand the architecture including this scenario. This adds value for the PCE.

 

 

> The architecture is pretty close to the PCE-based
> architecture except a lot of manual operation. I think PCE should consider
> this as its application too and revise the basic architecture to include
> this functionality.

 

There is nothing (IMHO) in the current architecture that prohibits either the management plane use of PCE, or the inclusion of a time dimension in the TED and the computaiton requests.

 

            It seems that current TED definition does not serve this function.

 

> Here is the recommendation for the PCE-based architecture:
>
>                       ---------------
>                      |   ---------   | Routing   ----------
>                      |  |         |  | Protocol |          |
>                      |  |   TED   |<-+----------+->        |
>                      |  |         |  |          |          |
>                      |   ---------   |          |          |
>                      |      |        |          |          |
>                      |      | Input  |          |          |
>                      |      v        |          |          |
>  ---------- Response |   ---------   |          |          |
> |          |Request  |  |         |  |          | Adjacent |
> |  SORD    |<------->|  |   PCE   |  |          |   Node   |
> |          |Input    |  |         |  |          |          |
>  ----------          |   ---------   |          |          |
>      ^               |      ^        |          |          |
>      |               |      |Request |          |          |
>      |               |      |Response|          |          |
>   Service Order      |      v        |          |          |
>                      |   ---------   |          |          |
>             Service  |  |         |  | Signaling|          |
>             Request  |  |Signaling|  | Protocol |          |
>                ------+->| Engine  |<-+----------+->        |
>                      |  |         |  |          |          |
>                      |   ---------   |           ----------
>                       ---------------
>

> Here, SORD is the service order reservation database, it contains all
> service order requests in terms of ingress and egress points, bandwidth,
> service type, time period for the request, etc. When PCE computes a path, it
> could get input from SORD to indicate if there are some network resource is
> already blocked out. When a booking order in SORD is ready to kick off, SORD
> will send request to PCE for the path computation, then PCE will send a
> service request to signaling engine to establish the LSP.

 

This would be hugely inefficient, wouldn't it?

Since PCE cannot guess which resources might be blocked out for future requests, it would have to make this query for every computation. Further, if PCE only made the query for resources that satisfied the computation, it might have to make repeated recomputations, so it would be more efficient for it to retrieve information about every future blocking.

So, in fact, it makes more sense for SORD to feed the information into the TED and allow PCE to operate on the full database.

 

But consider: How does SORD know which resources will be reserved and when? Presumably, it has consulted PCE as well.

 

> It is clarified that not all pending orders in SORD need to reserve the
> bandwidth ahead, carrier could have some policies in SORD to manage which
> order need to reserve the bandwidth ahead and which is not.
>
> Be glad to hear your and other people comment on this suggestion.

If you wanted to work on some issue like "Applicability of PCE to time-scoped service requests" this might be of interest to people. It was raised in the early days of PCE and of L1VPN, but did not attract significant interest. I think that the feeling at the time was that it was out of scope for PCE, but formed part of a management system. However, it might be that there would be value in enhancing the PCE protocol to carry time delimiters for computation requests.

 

Note that the PCE working group is interested in applications of PCE and the protocols involved, but is not so interested in abstract functional components that are beyond the scope of the working group.

 

Regards,

Adrian

--Boundary_(ID_UY9I/MqCeWWUBR7roUW4+g)-- --===============2078715529== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2078715529==-- From pce-bounces@lists.ietf.org Wed May 24 15:11:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiyl7-0001oz-TZ; Wed, 24 May 2006 15:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiyl7-0001ou-EU for pce@ietf.org; Wed, 24 May 2006 15:11:05 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiyl5-0000VL-VV for pce@ietf.org; Wed, 24 May 2006 15:11:05 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS00JTRAGT83@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 12:07:42 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS007F1AGJCF@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 12:07:41 -0700 (PDT) Date: Wed, 24 May 2006 14:10:38 -0500 From: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: To: Dimitri.Papadimitriou@alcatel.be Message-id: <003e01c67f65$c2567bf0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Thank you for the comments. It is understood that the group goal is to study IP communication protocols not network architecture. However, they can not be completely separated. Before we are clear about the architecture and its components, we can't really specify the protocol, do we? The suggestion here is to add another architecture scenario which enables to support time-based reservation. I don't see this impact the protocol study. It simply adds a value for PCE based architecture. If we only study the protocols between LSR-PCE and PCE-PCE, adding this scenario does not add addition work at all. I don't see how this scenario impacts the scalability, performance, robustness and resiliency at all. If it is, it is scared what we are doing here. Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Wednesday, May 24, 2006 12:49 PM To: Lucy Yong Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 lucy - take a look at section 6.16, if there is a need to consider - as you wrote - that "PCE should support time-base reservation in the general and leave as an option for carrier to implement or not." i would like to hear from operators specific rationales to incorporate as part of the communication protocol / PCE processing any time constraint now more fundamentally and as stated the role of the group is to define IP communication protocols not network architectures of some sort - reason for the suggestion made on section 5 adrian mentions what is that inter-AS PCE is in scope, he forgot probably to mention to you that the primary concerns of the work ongoing here is driven by four major concerns: scalability, performance, robustness and resiliency from this perspective any time constraint is going to seriously impact all these base objectives Lucy Yong 24/05/2006 19:33 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "'Adrian Farrel'" , "'Meral Shirazipour'" , pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 Dimitri, Because for some important reservations, carrier want to reserve the specific path for many purposes such as better optimization, request length period, service guarantee, etc. Why should PCE WG limits the scope between LSR-PCE/PCE-PCE elements? We are defining the architecture now. Adrian has mentioned that it is in PCE scope. Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Wednesday, May 24, 2006 12:25 PM To: Lucy Yong Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 the question is why "time constraint" should be taken into account during path computation that would justify incorporation into the communication between LSR-PCE/PCE-PCE elements scheduling of LSPs - themselves - is outside the scope of the comm process between LSR-PCE/PCE-PCE elements, it is even outside the scope of the PCE (since not a resource manager of some sort) Lucy Yong 24/05/2006 19:08 To: "'Adrian Farrel'" , "'Meral Shirazipour'" cc: pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 All, Thank you for all the comments. PCE should support time-base reservation in the general and leave as an option for carrier to implement or not. If we exclude this functionality, it is hard to see the full automatic network because there are quite these kinds of service demands and carrier also encourages the pre-order so they can proactively engineer the network. I'll be glad to write an informational draft to explain the possible mechanism and protocols. Weather the function should be maintained in the same database or separated databases, it would be better to see after clarifying the functionality of each element first, and then decide the solution. The service reservation database mentioned here has a lot of information that PCE does not need and has no responsibility to maintain them. Maybe some cache mechanism could be used. Welcome anyone to provide the input on the informational draft. Best Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 11:11 AM To: Meral Shirazipour; Lucy Yong Cc: pce@ietf.org Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Begging your pardon, Meral, but I'm a bit confused. > I agree with what you say here. This is a fact to consider especially if > the > PCE architecture is to be adapted later on for inter-AS TE in the > 'Internet'. > What you say here is important if we consider the Internet peering models. The architecture is already intended to be "adapted" for that purpose. Have a quick read through the first few sections and you'll see ample discussion of inter-AS. Lucy's email seems to me to be about the time-based reservation of resources. This doesn't seem to me to be outside the scope of the current architecture, but one might want to write down how PCE is used for that purpose as an informational draft. Personally, I would find Lucy's suggestion of a distinct component and database that was consulted for each computation request a costly idea, and would prefer to see this type of function rolled into a single database. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 15:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyyU-0008IZ-Ve; Wed, 24 May 2006 15:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyyU-0008IU-AB for pce@ietf.org; Wed, 24 May 2006 15:24:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiyyT-0001Cd-9o for pce@ietf.org; Wed, 24 May 2006 15:24:54 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 12:24:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,169,1146466800"; d="scan'208,217"; a="28845353:sNHT53147140" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4OJOpvF027453; Wed, 24 May 2006 15:24:51 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:24:51 -0400 Received: from [161.44.71.181] ([161.44.71.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:24:51 -0400 In-Reply-To: <003401c67f63$7da39440$d4087c0a@china.huawei.com> References: <003401c67f63$7da39440$d4087c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: Comments about draft-ietf-pce-architecture-05 Date: Wed, 24 May 2006 15:24:48 -0400 To: Lucy Yong X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 24 May 2006 19:24:51.0094 (UTC) FILETIME=[BA521B60:01C67F67] X-Spam-Score: 0.0 (/) X-Scan-Signature: afddcc4f0dbd876d4009dc71857c6cc6 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075865971==" Errors-To: pce-bounces@lists.ietf.org --===============0075865971== Content-Type: multipart/alternative; boundary=Apple-Mail-45-540280793 --Apple-Mail-45-540280793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Lucy, Comments in line, On May 24, 2006, at 2:54 PM, Lucy Yong wrote: > Hi Adrian, > > > First of all, highly appreciate your all great comments. See my =20 > comment below. > > > Regards, > > Lucy > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 11:02 AM > To: Lucy Yong > Cc: pce@ietf.org > Subject: Re: Comments about draft-ietf-pce-architecture-05 > > > Hi Lucy, > > > > The draft layouts the basic PCE architecture and expresses the =20 > motivation > > for a PCE-based architecture. It is a good document. > > > Thanks. > > > > Beyond these motivation facts, I think we should have another =20 > incentive for > > a PCE-based architecture. > > > > Today, a control plane based switching architecture assumes a =20 > user-network > > model or client-server model. A LSP is initiated at an end user =20 > point > > (client), then network establishes the LSP thru. the control plane > > instantly. PCE reserves that concept too. Thus all connection =20 > paths are > > based on instant requests from end users. > > > I think it is true that PCE supports this model, but I don't think =20 > it is the case that the assumptions you state are universal. > > > 1. The user-network model and the client-server model are =20 > examples of how one might use a control plane-based switching =20 > network, but they are not the only examples. > > Accept this comment. > > > 2. To say that all connection paths are based on instant requests =20 > from end users slightly misses the point of PCE. PCE performs =20 > computations based on requests from an external entity (the PCC), =20 > and PCE operates on a TED. There is nothing that says that the TED =20 > must be a representation of the network at only one instant of =20 > time, and there is nothing that says that the computation request =20 > must demand a computation "now". As already pointed out by Adrian, the PCE does not preclude this =20 "instant per-user" model ... but from a realistic point of view, it =20 is unlikely to be the most common application case. You may want to =20 have a closer look at several of the requirement documents that do =20 describe various applications contexts such as Inter-area, Inter-AS =20 and Inter-layer MPLS TE. Such applications will likely be described =20 in more details in future applicability statement. The PCE Architecture ID specifies the components, their interaction =20 in term of protocols and so on. If you want to use it in a per-user =20 real-time fashion, this is not precluded but again I would express =20 some serious concerns about the scalability. > OK PCE does specify an instant request from end-user or NMS. Not sure what you mean by "instant" request. The trigger for a path =20 computation request are out of the standardization scope. > TED defined in the draft contains the topology and resource =20 > information of the domain. Note that we do not change the definition of the TED. > It is very unclear if it can sever bandwidth reservation purpose or =20= > not. The PCE does not *reserve* bandwidth, but computes paths for TE LSP. =20 Bandwidth reservation is performed by RSVP-TE (RFC 3209). > In addition, TED is not excluded to reside within network, which is =20= > hard to use this purpose. > > > > In carrier reality world, it is hard to see that transport =20 > service will be > > offered this way only, especially for a large bandwidth and =20 > permanent > > bandwidth request. > > > Hmmm. This may be why I disagreed with your assumptions! :-) > > > Maybe my words here are not clear to you. I means that it is hard =20 > to see that transport service will be only offered in the way that =20 > an end user sends a signal request at ingress point at the time =20 > that a bandwidth needed. There is no such assumption in the architecture. > > > > Typically, carrier has a service order reservation > > system, it allows customer to book a bandwidth ahead (pending =20 > order), > > carrier will do traffic engineering based on the pending order =20 > and will > > excuse the order when the time arrives. > > > Yes, this is another valid model. But it is also not the only valid =20= > model and many transport networks are operated today on a much more =20= > flexible approach. > > I agree. Does the architecture need to enable other approaches? > > It does. > > A path computer engine has a > > capability of taking a consideration about future pending orders =20 > while it > > computes a path. > > > I am unsure whether what you say matches reality perfectly. > > > That is, when a pending future order is entered into the system, =20 > the reservation is made. This means that the TED reflects the =20 > results of the order/computation/fulfilment cycle, and that =20 > computations are still prefomred on demand (i.e. "now"). The =20 > difference is that the provisioning (fulfilment) is some time in =20 > the future. > > > In this case, it seems unlikely that you would feed your TED from =20 > the routing protocols, but rather from inventory discovery and from =20= > the service ordering/fulfilment process. Figure 5 in the =20 > architecture shows this model. > > > That is the goal to feed TED from the routing protocols and let =20 > PCE use TED information and SORD information to compute the path. I =20= > think resource inventory should come from network instead of human =20 > entering. Figure 5 show NMS initiating the service request, but =20 > does not show the reservation capability. > > > You mention that the architecture does not prohibit time-based =20 > reservation. But it does not explicitly support that either. It is =20 > hard to see through it. If this is a valid function, could we =20 > explicitly specify it instead of =93imply it=94? Maybe insert section =20= > 5.6 to illustrate this model. > > That is my suggestion to expand the architecture including this =20 > scenario. This adds value for the PCE. So you might want to consider producing an applicability statement ID =20= but this does not require any change to the architecture document. > > > > The architecture is pretty close to the PCE-based > > architecture except a lot of manual operation. I think PCE should =20= > consider > > this as its application too and revise the basic architecture to =20 > include > > this functionality. > > > There is nothing (IMHO) in the current architecture that prohibits =20 > either the management plane use of PCE, or the inclusion of a time =20 > dimension in the TED and the computaiton requests. > > > It seems that current TED definition does not serve =20 > this function. > > > > Here is the recommendation for the PCE-based architecture: > > > > --------------- > > | --------- | Routing ---------- > > | | | | Protocol | | > > | | TED |<-+----------+-> | > > | | | | | | > > | --------- | | | > > | | | | | > > | | Input | | | > > | v | | | > > ---------- Response | --------- | | | > > | |Request | | | | | Adjacent | > > | SORD |<------->| | PCE | | | Node | > > | |Input | | | | | | > > ---------- | --------- | | | > > ^ | ^ | | | > > | | |Request | | | > > | | |Response| | | > > Service Order | v | | | > > | --------- | | | > > Service | | | | Signaling| | > > Request | |Signaling| | Protocol | | > > ------+->| Engine |<-+----------+-> | > > | | | | | | > > | --------- | ---------- > > --------------- > > > > > Here, SORD is the service order reservation database, it contains =20= > all > > service order requests in terms of ingress and egress points, =20 > bandwidth, > > service type, time period for the request, etc. When PCE computes =20= > a path, it > > could get input from SORD to indicate if there are some network =20 > resource is > > already blocked out. When a booking order in SORD is ready to =20 > kick off, SORD > > will send request to PCE for the path computation, then PCE will =20 > send a > > service request to signaling engine to establish the LSP. > > > This would be hugely inefficient, wouldn't it? > > Since PCE cannot guess which resources might be blocked out for =20 > future requests, it would have to make this query for every =20 > computation. Further, if PCE only made the query for resources that =20= > satisfied the computation, it might have to make repeated =20 > recomputations, so it would be more efficient for it to retrieve =20 > information about every future blocking. > > So, in fact, it makes more sense for SORD to feed the information =20 > into the TED and allow PCE to operate on the full database. > > > But consider: How does SORD know which resources will be reserved =20 > and when? Presumably, it has consulted PCE as well. > > > > It is clarified that not all pending orders in SORD need to =20 > reserve the > > bandwidth ahead, carrier could have some policies in SORD to =20 > manage which > > order need to reserve the bandwidth ahead and which is not. > > > > Be glad to hear your and other people comment on this suggestion. > > If you wanted to work on some issue like "Applicability of PCE to =20 > time-scoped service requests" this might be of interest to people. =20 > It was raised in the early days of PCE and of L1VPN, but did not =20 > attract significant interest. I think that the feeling at the time =20 > was that it was out of scope for PCE, but formed part of a =20 > management system. However, it might be that there would be value =20 > in enhancing the PCE protocol to carry time delimiters for =20 > computation requests. > > > Note that the PCE working group is interested in applications of =20 > PCE and the protocols involved, but is not so interested in =20 > abstract functional components that are beyond the scope of the =20 > working group. In full sync with Adrian. JP. > > Regards, > > Adrian > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-45-540280793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Lucy,

Comments in = line,
> Here is the recommendation for the = PCE-based=20 architecture:
>
>          &nbs= p;           =20 ---------------
>        &n= bsp;           &nb= sp;=20 |   ---------   | Routing  =20 ----------
>         &= nbsp;           =20 |  |         |  | = Protocol=20 |         =20 |
>          &nbs= p;          =20 |  |   TED  =20 |<-+----------+->       =20 |
>          &nbs= p;          =20 |  |         | =20 |         =20 |         =20 |
>          &nbs= p;          =20 |   ---------  =20 |         =20 |         =20 |
>          &nbs= p;          =20 |      = |       =20 |         =20 |         =20 |
>          &nbs= p;          =20 |      | Input =20 |         =20 |         =20 |
>          &nbs= p;          =20 |      = v       =20 |         =20 |          |
>=20  ---------- Response |   ---------  =20 |         =20 |          |
>=20 |          |Request  = | =20 |         | =20 |          | Adjacent = |
>=20 |  SORD    |<------->|  |  =20 PCE   |  = |         =20 |   Node   |
>=20 |          = |Input   =20 |  |         | =20 |         =20 |          |
> =20 ----------          = |  =20 ---------   = |         =20 |         =20 |
>     =20 ^            =   =20 |      = ^       =20 |         =20 |         =20 |
>     =20 |            =   =20 |      |Request=20 |         =20 |         =20 |
>     =20 |            =   =20 |     =20 |Response|         =20 |          = |
>  =20 Service Order      = |     =20 v       =20 |         =20 |         =20 |
>          &nbs= p;          =20 |   ---------  =20 |         =20 |         =20 |
>          &nbs= p; =20 Service  |  |         = | =20 | Signaling|         =20 |
>          &nbs= p; =20 Request  |  |Signaling|  | Protocol=20 |         =20 |
>          &nbs= p;    =20 ------+->| Engine =20 |<-+----------+->       =20 |
>          &nbs= p;          =20 |  |         | =20 |         =20 |         =20 |
>          &nbs= p;          =20 |   ---------  =20 |          =20 ----------
>         &= nbsp;           &n= bsp;=20 ---------------
>

On May 24, 2006, at 2:54 PM, Lucy Yong = wrote:

Hi = Adrian,

=A0

First of all, highly appreciate = your all great comments. See my comment = below.

=A0

Regards,

Lucy

=A0

-----Original = Message-----
From: = Adrian Farrel [mailto:adrian@olddog.co.uk]
= Sent: Wednesday, May 24, = 2006 11:02 AM
To: = Lucy Yong
Cc: pce@ietf.org
Subject: Re: Comments about = draft-ietf-pce-architecture-05

=A0

Hi Lucy,

=
=A0

> = The draft layouts the basic PCE architecture and expresses the = motivation
> for a PCE-based architecture. It is a good = document.

=A0

Thanks.

=


= >=A0Beyond these = motivation facts, I think we should have another incentive for
> = a PCE-based architecture.
>
> Today, a control plane = based switching architecture assumes a user-network
> model or = client-server model. A LSP is initiated at an end user point
> = (client), then network establishes the LSP thru. the control plane
= > instantly. PCE reserves that concept too. Thus all connection paths = are
> based on instant requests from end users.

=
=A0

I = think it is true that PCE supports this model, but I don't think it is = the case that the assumptions you state are universal.

=
=A0

1.=A0=A0=A0=A0=A0=A0 The user-network model and the client-server = model are examples of how one might use a control plane-based switching = network, but they are not the only examples.

Accept this = comment.

=A0

2. To = say that all connection paths are based on instant requests from end = users slightly misses the point of PCE. PCE performs computations based = on requests from an external entity (the PCC), and PCE operates on a = TED. There is nothing that says that the TED must be a representation of = the network at only one instant of time, and there is nothing that says = that the computation request must demand a computation = "now".

As already pointed out = by Adrian, the PCE does not preclude this "instant per-user" model ... = but from a realistic point of view, it is unlikely to be the most common = application case. You may want to have a closer look at several of the = requirement documents that do describe various applications contexts = such as Inter-area, Inter-AS and Inter-layer MPLS TE. Such applications = will likely be described in more details in future applicability = statement.=A0

The PCE Architecture ID = specifies the components, their interaction in term of protocols and so = on. If you want to use it in a per-user real-time fashion, this is not = precluded but again I would express some serious concerns about the = scalability.

OK PCE does = specify an instant request from end-user or = NMS.

Not sure what you = mean by "instant" request. The trigger for a path computation request = are out of the standardization scope.

TED defined in the draft contains = the topology and resource information of the = domain.

Note that we do = not change the definition of the TED.

It is very unclear if it can sever = bandwidth reservation purpose or not. =

The PCE does not = *reserve* bandwidth, but computes paths for TE LSP. Bandwidth = reservation is performed by RSVP-TE (RFC 3209).

In addition, TED is not excluded to = reside within network, which is hard to use this purpose. =


> In carrier reality world, it is hard to see that transport = service will be
> offered this way only, especially for a large = bandwidth and permanent
> bandwidth request.

=
=A0

Hmmm. = This may be why I disagreed with your assumptions! = :-)

=A0

Maybe my words here are not clear = to you. I means that it is hard to see that transport service will be = only offered in the way that an end user sends a signal request at = ingress point at the time that a bandwidth = needed.

There is no such = assumption in the architecture.

=

=A0

>=A0Typically, carrier = has a service order reservation
> system, it allows customer to = book a bandwidth ahead (pending order),
> carrier will do traffic = engineering based on the pending order and will
> excuse the = order when the time arrives.

=A0

Yes, = this is another valid model. But it is also not the only valid model and = many transport networks are operated today on a much more flexible = approach.

=A0I agree. Does the architecture need to enable other = approaches?

=A0

It does.

>=A0A= path computer engine has a
> capability of taking a = consideration about future pending orders while it
> computes a = path.

=A0

I am = unsure whether what you say matches reality perfectly.

=
=A0

That = is, when a pending future order is entered into the system, the = reservation is made. This means that the TED reflects the results of the = order/computation/fulfilment cycle, and that computations are still = prefomred on demand (i.e. "now"). The difference is that the = provisioning (fulfilment) is some time in the future.

=
=A0

In = this case, it seems unlikely that you would feed your TED from the = routing protocols, but rather from inventory discovery and from the = service ordering/fulfilment process. Figure 5 in the architecture shows = this model.

=A0

=A0That is the goal to feed TED = from the routing protocols and let PCE use TED information and SORD = information to compute the path. I think resource inventory should come = from network instead of human entering. =A0Figure 5 show NMS initiating = the service request, but does not show the reservation = capability.

=A0

You mention that the architecture = does not prohibit time-based reservation. But it does not explicitly = support that either. It is hard to see through it. If this is a valid = function, could we explicitly specify it instead of =93imply it=94? = Maybe insert section 5.6 to illustrate this model.

That is my = suggestion to expand the architecture including this scenario. This adds = value for the PCE.

So you = might want to consider producing an applicability statement ID but this = does not require any change to the architecture = document.

=A0
=A0

>=A0T= he architecture is pretty close to the PCE-based
> architecture = except a lot of manual operation. I think PCE should consider
> = this as its application too and revise the basic architecture to = include
> this functionality.

=A0

There = is nothing (IMHO) in the current architecture that prohibits either the = management plane use of PCE, or the inclusion of a time dimension in the = TED and the computaiton requests.

=A0

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 It seems that current TED definition does not serve this = function.

=A0

> = Here is the recommendation for the PCE-based architecture:
>
= >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 ---------------
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |=A0=A0 ---------=A0=A0 | Routing=A0=A0 = ----------
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | Protocol |=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0 |=A0=A0 TED=A0=A0 |<-+----------+->=A0=A0=A0=A0=A0=A0=A0= |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 ---------=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
= >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0 | Input=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |=A0=A0=A0=A0=A0 v=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
> =A0---------- Response |=A0=A0= ---------=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0= |
> |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |Request=A0 |=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Adjacent |
> |=A0 = SORD=A0=A0=A0 |<------->|=A0 |=A0=A0 PCE=A0=A0 |=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0 Node=A0=A0 |
> |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |Input=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>=A0 ----------=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0 ---------=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>=A0=A0=A0=A0=A0 ^=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 ^=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
= >=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= =A0=A0 |Request |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |
>=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0 |Response|=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |
>=A0=A0 Service Order=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 = v=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0 ---------=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Service=A0 = |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | Signaling|=A0=A0=A0=A0=A0=A0=A0=A0=A0= |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Request=A0 |=A0 = |Signaling|=A0 | Protocol |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
= >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ------+->| Engine=A0 = |<-+----------+->=A0=A0=A0=A0=A0=A0=A0 |
= >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0 ---------=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ----------
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 ---------------
>

> Here, SORD is the = service order reservation database, it contains all
> service = order requests in terms of ingress and egress points, bandwidth,
= > service type, time period for the request, etc. When PCE computes a = path, it
> could get input from SORD to indicate if there are = some network resource is
> already blocked out. When a booking = order in SORD is ready to kick off, SORD
> will send request to = PCE for the path computation, then PCE will send a
> service = request to signaling engine to establish the LSP.

=
=A0

This = would be hugely inefficient, wouldn't it?

=

Since = PCE cannot guess which resources might be blocked out for future = requests, it would have to make this query for every computation. = Further, if PCE only made the query for resources that satisfied the = computation, it might have to make repeated recomputations, so it would = be more efficient for it to=A0retrieve information about every future = blocking.

So, in fact, it makes more = sense for SORD to feed the information into the TED and allow PCE to = operate on the full database.

=A0

But = consider: How does SORD know which resources will be reserved and when? = Presumably, it has consulted PCE as well.

=
=A0

> = It is clarified that not all pending orders in SORD need to reserve = the
> bandwidth ahead, carrier could have some policies in SORD = to manage which
> order need to reserve the bandwidth ahead and = which is not.
>
> Be glad to hear your and other people = comment on this suggestion.

If you = wanted to work on some issue like "Applicability of PCE to time-scoped = service requests" this might be of interest to people. It was raised in = the early days of PCE and of L1VPN, but did not attract significant = interest. I think that the feeling at the time was that it was out of = scope for PCE, but formed part of a management system. However, it might = be that there would be value in enhancing the PCE protocol to carry time = delimiters for computation requests.

=A0

Note = that the PCE working group is interested in applications of PCE and the = protocols involved, but is not so interested in abstract functional = components that are beyond the scope of the working = group.

In full sync with = Adrian.

JP.

=A0

Regards,

=

Adrian

=
Pce mailing list
=

= --Apple-Mail-45-540280793-- --===============0075865971== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0075865971==-- From pce-bounces@lists.ietf.org Wed May 24 15:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiz4z-00037d-Ui; Wed, 24 May 2006 15:31:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiz4y-00037S-81 for pce@ietf.org; Wed, 24 May 2006 15:31:36 -0400 Received: from mail.lopsys.com ([12.47.115.93] helo=mailsrv01.vasw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiz4x-00020n-Qf for pce@ietf.org; Wed, 24 May 2006 15:31:36 -0400 Received: from NETPTORAB (net-torab.vasw [192.168.254.48]) by mailsrv01.vasw (8.13.1/8.13.1) with ESMTP id k4OJTJ5Z002675; Wed, 24 May 2006 15:29:19 -0400 From: "Payam Torab" To: "'Lucy Yong'" , Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 Date: Wed, 24 May 2006 15:31:17 -0400 Organization: Lambda OpticalSystems Message-ID: <010301c67f68$a0ef4700$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <003e01c67f65$c2567bf0$d4087c0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Lucy- What do you mean by "architecture scenario" below? I don't see any = conflict between the current PCE architecture, and adding an element of time to = path computation. You can certainly add time constraints to TED, as well as computation algorithms and support scheduling if you wish. You mention "It seems that current TED definition does not serve this function (scheduling)" - How is TED definition blocking you from = scheduling? Thanks, Payam Torab > -----Original Message----- > From: Lucy Yong [mailto:lucyyong@huawei.com]=20 > Sent: Wednesday, May 24, 2006 3:11 PM > To: Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >=20 >=20 > Hi Dimitri, >=20 > Thank you for the comments. It is understood that the group=20 > goal is to study IP communication protocols not network=20 > architecture. However, they can not be completely separated.=20 > Before we are clear about the architecture and its=20 > components, we can't really specify the protocol, do we? The=20 > suggestion here is to add another architecture scenario which=20 > enables to support time-based reservation. I don't see this=20 > impact the protocol study. It simply adds a value for PCE=20 > based architecture. If we only study the protocols between=20 > LSR-PCE and PCE-PCE, adding this scenario does not add=20 > addition work at all. I don't see how this scenario impacts=20 > the scalability, performance, robustness and resiliency at=20 > all. If it is, it is scared what we are doing here. >=20 > Regards, > Lucy >=20 >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Sent: Wednesday, May 24, 2006 12:49 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >=20 > lucy -=20 >=20 > take a look at=20 > col-gen-reqs-0 > 6.txt>=20 > section 6.16, >=20 > if there is a need to consider - as you wrote - that "PCE=20 > should support=20 > time-base reservation in the general=20 > and leave as an option for carrier to implement or not." i=20 > would like to=20 > hear from operators specific rationales=20 > to incorporate as part of the communication protocol / PCE=20 > processing any=20 > time constraint >=20 > now more fundamentally and as stated the role of the group is=20 > to define IP=20 > communication protocols not network > architectures of some sort - reason for the suggestion made=20 > on section 5 >=20 > adrian mentions what is that inter-AS PCE is in scope, he=20 > forgot probably=20 > to mention to you that the primary=20 > concerns of the work ongoing here is driven by four major concerns:=20 > scalability, performance, robustness and > resiliency from this perspective any time constraint is going=20 > to seriously=20 > impact all these base objectives >=20 >=20 >=20 >=20 >=20 > Lucy Yong > 24/05/2006 19:33 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "'Adrian Farrel'" , "'Meral=20 > Shirazipour'" , pce@ietf.org > Subject: RE: [Pce] Comments about=20 > draft-ietf-pce-architecture-05 >=20 >=20 > Dimitri, >=20 > Because for some important reservations, carrier want to=20 > reserve the specific path for many purposes such as better=20 > optimization, request=20 > length > period, service guarantee, etc. >=20 > Why should PCE WG limits the scope between LSR-PCE/PCE-PCE=20 > elements? We=20 > are > defining the architecture now. >=20 > Adrian has mentioned that it is in PCE scope. >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Sent: Wednesday, May 24, 2006 12:25 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >=20 > the question is why "time constraint" should be taken into=20 > account during path computation that would justify=20 > incorporation into the communication between LSR-PCE/PCE-PCE elements=20 >=20 > scheduling of LSPs - themselves - is outside the scope of the=20 > comm process between LSR-PCE/PCE-PCE elements, it is even=20 > outside the scope of the PCE (since not a resource manager of=20 > some sort) >=20 >=20 >=20 >=20 >=20 > Lucy Yong > 24/05/2006 19:08 > =20 > To: "'Adrian Farrel'" , "'Meral=20 > Shirazipour'" > cc: pce@ietf.org > Subject: RE: [Pce] Comments about=20 > draft-ietf-pce-architecture-05 >=20 >=20 > All, >=20 > Thank you for all the comments. > PCE should support time-base reservation in the general and=20 > leave as an option for carrier to implement or not. If we=20 > exclude this functionality,=20 > it > is hard to see the full automatic network because there are=20 > quite these kinds of service demands and carrier also=20 > encourages the pre-order so they can proactively engineer the=20 > network. I'll be glad to write an informational draft to=20 > explain the possible mechanism and protocols. Weather the=20 > function should be maintained in the same database or=20 > separated databases, it would be better to see after=20 > clarifying the functionality of each element first, and then=20 > decide the solution. The service reservation database=20 > mentioned here has a lot of information that PCE does not=20 > need and has no responsibility to maintain them. Maybe some=20 > cache mechanism could be used. Welcome anyone to provide the=20 > input on the informational draft. >=20 > Best Regards, > Lucy >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Wednesday, May 24, 2006 11:11 AM > To: Meral Shirazipour; Lucy Yong > Cc: pce@ietf.org > Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >=20 > Begging your pardon, Meral, but I'm a bit confused. >=20 > > I agree with what you say here. This is a fact to consider=20 > > especially > if >=20 > > the > > PCE architecture is to be adapted later on for inter-AS TE in the > > 'Internet'. > > What you say here is important if we consider the Internet peering=20 > models. >=20 > The architecture is already intended to be "adapted" for that=20 > purpose.=20 > Have=20 > a quick read through the first few sections and you'll see ample=20 > discussion=20 > of inter-AS. >=20 > Lucy's email seems to me to be about the time-based reservation of=20 > resources. This doesn't seem to me to be outside the scope of=20 > the current=20 > architecture, but one might want to write down how PCE is=20 > used for that=20 > purpose as an informational draft. >=20 > Personally, I would find Lucy's suggestion of a distinct=20 > component and=20 > database that was consulted for each computation request a=20 > costly idea,=20 > and=20 > would prefer to see this type of function rolled into a=20 > single database. >=20 > Adrian >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 15:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiz89-0003q8-5g; Wed, 24 May 2006 15:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiz87-0003nO-Di for pce@ietf.org; Wed, 24 May 2006 15:34:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiz84-0002VH-PS for pce@ietf.org; Wed, 24 May 2006 15:34:51 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 12:34:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,169,1146466800"; d="scan'208"; a="28846635:sNHT25357396" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4OJYkvL000009; Wed, 24 May 2006 15:34:47 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:34:36 -0400 Received: from [161.44.71.181] ([161.44.71.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:34:35 -0400 In-Reply-To: <003e01c67f65$c2567bf0$d4087c0a@china.huawei.com> References: <003e01c67f65$c2567bf0$d4087c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Date: Wed, 24 May 2006 15:34:33 -0400 To: Lucy Yong X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 24 May 2006 19:34:36.0000 (UTC) FILETIME=[16F3AE00:01C67F69] X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Lucy, On May 24, 2006, at 3:10 PM, Lucy Yong wrote: > Hi Dimitri, > > Thank you for the comments. It is understood that the group goal is > to study > IP communication protocols not network architecture. However, they > can not > be completely separated. Before we are clear about the architecture > and its > components, we can't really specify the protocol, do we? > The suggestion here is to add another architecture scenario which > enables to > support time-based reservation. But again there's nothing that prevents you from applying your application using the defined PCE architecture. I think that you made some assumptions about the applicability of the PCE architecture that are not valid. Hope that these emails have clarified this. > I don't see this impact the protocol study. > It simply adds a value for PCE based architecture. > If we only study the protocols between LSR-PCE and PCE-PCE, adding > this > scenario does not add addition work at all. Note that there is one communication protocol between PCC-PCE and PCE- PCE. > I don't see how this scenario > impacts the scalability, performance, robustness and resiliency at > all. I personally think that it does, as pointed out by Dimitri. In summary: (1) The Architecture ID does not preclude the scenario that you describe, (2) We are very welcome to document such application model in an applicability ID to gather input from the list. Thanks. JP. > If > it is, it is scared what we are doing here. > > Regards, > Lucy > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, May 24, 2006 12:49 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > lucy - > > take a look at > gen-reqs-0 > 6.txt> > section 6.16, > > if there is a need to consider - as you wrote - that "PCE should > support > time-base reservation in the general > and leave as an option for carrier to implement or not." i would > like to > hear from operators specific rationales > to incorporate as part of the communication protocol / PCE > processing any > time constraint > > now more fundamentally and as stated the role of the group is to > define IP > communication protocols not network > architectures of some sort - reason for the suggestion made on > section 5 > > adrian mentions what is that inter-AS PCE is in scope, he forgot > probably > to mention to you that the primary > concerns of the work ongoing here is driven by four major concerns: > scalability, performance, robustness and > resiliency from this perspective any time constraint is going to > seriously > impact all these base objectives > > > > > > Lucy Yong > 24/05/2006 19:33 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "'Adrian Farrel'" , "'Meral > Shirazipour'" , pce@ietf.org > Subject: RE: [Pce] Comments about > draft-ietf-pce-architecture-05 > > > Dimitri, > > Because for some important reservations, carrier want to reserve the > specific path for many purposes such as better optimization, request > length > period, service guarantee, etc. > > Why should PCE WG limits the scope between LSR-PCE/PCE-PCE > elements? We > are > defining the architecture now. > > Adrian has mentioned that it is in PCE scope. > > Regards, > Lucy > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, May 24, 2006 12:25 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > the question is why "time constraint" should be taken into account > during path computation that would justify incorporation into the > communication between LSR-PCE/PCE-PCE elements > > scheduling of LSPs - themselves - is outside the scope of the comm > process between LSR-PCE/PCE-PCE elements, it is even outside the > scope of the PCE (since not a resource manager of some sort) > > > > > > Lucy Yong > 24/05/2006 19:08 > > To: "'Adrian Farrel'" , "'Meral > Shirazipour'" > cc: pce@ietf.org > Subject: RE: [Pce] Comments about > draft-ietf-pce-architecture-05 > > > All, > > Thank you for all the comments. > PCE should support time-base reservation in the general and leave > as an > option for carrier to implement or not. If we exclude this > functionality, > it > is hard to see the full automatic network because there are quite > these > kinds of service demands and carrier also encourages the pre-order > so they > can proactively engineer the network. > I'll be glad to write an informational draft to explain the possible > mechanism and protocols. Weather the function should be maintained > in the > same database or separated databases, it would be better to see after > clarifying the functionality of each element first, and then decide > the > solution. The service reservation database mentioned here has a lot of > information that PCE does not need and has no responsibility to > maintain > them. > Maybe some cache mechanism could be used. > Welcome anyone to provide the input on the informational draft. > > Best Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 11:11 AM > To: Meral Shirazipour; Lucy Yong > Cc: pce@ietf.org > Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > > Begging your pardon, Meral, but I'm a bit confused. > >> I agree with what you say here. This is a fact to consider >> especially > if > >> the >> PCE architecture is to be adapted later on for inter-AS TE in the >> 'Internet'. >> What you say here is important if we consider the Internet peering > models. > > The architecture is already intended to be "adapted" for that purpose. > Have > a quick read through the first few sections and you'll see ample > discussion > of inter-AS. > > Lucy's email seems to me to be about the time-based reservation of > resources. This doesn't seem to me to be outside the scope of the > current > architecture, but one might want to write down how PCE is used for > that > purpose as an informational draft. > > Personally, I would find Lucy's suggestion of a distinct component and > database that was consulted for each computation request a costly > idea, > and > would prefer to see this type of function rolled into a single > database. > > Adrian > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 15:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizNW-0004wv-O1; Wed, 24 May 2006 15:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizNT-0004gO-VH for pce@ietf.org; Wed, 24 May 2006 15:50:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FizNR-0003H4-AB for pce@ietf.org; Wed, 24 May 2006 15:50:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2006 15:50:41 -0400 X-IronPort-AV: i="4.05,169,1146456000"; d="scan'208,217"; a="89385316:sNHT49365312" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4OJodTL016102; Wed, 24 May 2006 15:50:41 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:50:38 -0400 Received: from [161.44.71.181] ([161.44.71.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:50:38 -0400 In-Reply-To: <1148489202.44748df25e812@www.imp.polymtl.ca> References: <000901c67f43$b0bc3aa0$d4087c0a@china.huawei.com> <1148486444.4474832ce7904@www.imp.polymtl.ca> <031c01c67f4c$c1b31960$0a23fea9@your029b8cecfe> <1148489202.44748df25e812@www.imp.polymtl.ca> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <49EA58C4-1BF5-45E3-8707-884EE0B1AB2B@cisco.com> From: JP Vasseur Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Date: Wed, 24 May 2006 15:50:36 -0400 To: Meral Shirazipour X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 24 May 2006 19:50:38.0457 (UTC) FILETIME=[549EF690:01C67F6B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: "pce@ietf.org" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0290007786==" Errors-To: pce-bounces@lists.ietf.org --===============0290007786== Content-Type: multipart/alternative; boundary=Apple-Mail-48-541827907 --Apple-Mail-48-541827907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Meral, On May 24, 2006, at 12:46 PM, Meral Shirazipour wrote: > Dear Adrian, > I apologize for the lack of clarity in my previous comment. I =20 > think Lucy has > a point. But I do not think the draft needs to me modified. > My comment on =93the applicability of the PCE architecture in the =20 > Internet at > large=94 comes from the following lines in the Description of Working =20= > Group. > (http://www.ietf.org/html.charters/pce-charter.html). > > I was referring to: > =93The 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 =20 > 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.=94 > > This said, I think if our ultimate goal is to do inter-AS TE and path > optimization in a PCE-based architecture, we must consider TED =20 > updating issues > and PCE signaling responsiveness while we are still at the =20 > definition stage of > the architecture and signaling protocols. Both items are indeed important. TED update: do you see any reason to change the way the TED is =20 updated by the IGP in a PCE context ? Note that so called "distributed CSPF approach" is a specific =20 instantiation of the PCE (LSR and PCE co-resident). PCEP communication responsiveness: this is an key metric indeed that =20 is been considered during the protocol design (in line with the =20 requirement IDs). Note also that there's a WG item related to =20 "Objective metrics" for which several expressed some interest. We can =20= expect some work to be done in this area and you're obviously very =20 welcome to contribute. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Thanks. JP. > > Best regards, > Meral Shirazipour > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-48-541827907 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Meral,

On = May 24, 2006, at 12:46 PM, Meral Shirazipour wrote:

Dear Adrian,
=A0=A0 I apologize for the lack = of clarity in my previous comment. I think Lucy has
a point. But I do not think the draft needs to me = modified.
My comment on =93the = applicability of the PCE architecture in the Internet at
large=94 comes from the following lines in the = Description of Working Group.

I was = referring to:
=93The PCE WG will work on = application of this model within a single
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
Internet is not thought to be = possible, and the PCE WG will not spend
energy = on that topic.=94

This said, I think if our ultimate goal is to do = inter-AS TE and path
optimization in a PCE-based = architecture, we must consider TED updating issues
and PCE signaling responsiveness while we are still = at the definition stage of
the = architecture and signaling protocols.

Both items are indeed = important.

TED = update: do you see any reason to change the way the TED is updated by = the IGP in a PCE context ?
Note that so called "distributed = CSPF approach" is a specific instantiation of the PCE (LSR and PCE = co-resident).

PCEP communication = responsiveness: this is an key metric indeed that is been considered = during the protocol design (in line with the requirement IDs). Note also = that there's a WG item related to "Objective metrics" for which several = expressed some interest. We can expect some work to be done in this area = and you're obviously very welcome to contribute.

- Definition of = objective metrics to evaluate various criteria such = as
the measurement = of path quality, response time, robustness = and
scalability of = path computation models.

Thanks.

JP.


Best regards,
=A0 Meral Shirazipour



Pce mailing list
=

= --Apple-Mail-48-541827907-- --===============0290007786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0290007786==-- From pce-bounces@lists.ietf.org Wed May 24 16:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0Ha-0000ly-2b; Wed, 24 May 2006 16:48:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0HZ-0000lt-Ip for pce@ietf.org; Wed, 24 May 2006 16:48:41 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0HZ-0007h7-2b for pce@ietf.org; Wed, 24 May 2006 16:48:41 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS00JXAEZW83@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 13:45:33 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS006NNEZRYO@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 13:45:32 -0700 (PDT) Date: Wed, 24 May 2006 15:48:34 -0500 From: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: <010301c67f68$a0ef4700$30fea8c0@NETPTORAB> To: 'Payam Torab' , Dimitri.Papadimitriou@alcatel.be Message-id: <005a01c67f73$6d571cf0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Payam, The draft specifies five architecture scenarios. Suggest adding one for time-based reservation. Giving the definition of TED, I don't see it can serve that function properly. TED contains topology and resource information from network. It may be embedded in NE. It is good to have a place to hold real network information and another place hold all reservations. You can flexibly apply policy to manage which bandwidth need to reserve ahead and which is only a book. It is hard to see the implementation done in TED. Lucy -----Original Message----- From: Payam Torab [mailto:ptorab@lopsys.com] Sent: Wednesday, May 24, 2006 2:31 PM To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be Cc: pce@ietf.org Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 Lucy- What do you mean by "architecture scenario" below? I don't see any conflict between the current PCE architecture, and adding an element of time to path computation. You can certainly add time constraints to TED, as well as computation algorithms and support scheduling if you wish. You mention "It seems that current TED definition does not serve this function (scheduling)" - How is TED definition blocking you from scheduling? Thanks, Payam Torab > -----Original Message----- > From: Lucy Yong [mailto:lucyyong@huawei.com] > Sent: Wednesday, May 24, 2006 3:11 PM > To: Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > Hi Dimitri, > > Thank you for the comments. It is understood that the group > goal is to study IP communication protocols not network > architecture. However, they can not be completely separated. > Before we are clear about the architecture and its > components, we can't really specify the protocol, do we? The > suggestion here is to add another architecture scenario which > enables to support time-based reservation. I don't see this > impact the protocol study. It simply adds a value for PCE > based architecture. If we only study the protocols between > LSR-PCE and PCE-PCE, adding this scenario does not add > addition work at all. I don't see how this scenario impacts > the scalability, performance, robustness and resiliency at > all. If it is, it is scared what we are doing here. > > Regards, > Lucy > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, May 24, 2006 12:49 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > lucy - > > take a look at > col-gen-reqs-0 > 6.txt> > section 6.16, > > if there is a need to consider - as you wrote - that "PCE > should support > time-base reservation in the general > and leave as an option for carrier to implement or not." i > would like to > hear from operators specific rationales > to incorporate as part of the communication protocol / PCE > processing any > time constraint > > now more fundamentally and as stated the role of the group is > to define IP > communication protocols not network > architectures of some sort - reason for the suggestion made > on section 5 > > adrian mentions what is that inter-AS PCE is in scope, he > forgot probably > to mention to you that the primary > concerns of the work ongoing here is driven by four major concerns: > scalability, performance, robustness and > resiliency from this perspective any time constraint is going > to seriously > impact all these base objectives > > > > > > Lucy Yong > 24/05/2006 19:33 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "'Adrian Farrel'" , "'Meral > Shirazipour'" , pce@ietf.org > Subject: RE: [Pce] Comments about > draft-ietf-pce-architecture-05 > > > Dimitri, > > Because for some important reservations, carrier want to > reserve the specific path for many purposes such as better > optimization, request > length > period, service guarantee, etc. > > Why should PCE WG limits the scope between LSR-PCE/PCE-PCE > elements? We > are > defining the architecture now. > > Adrian has mentioned that it is in PCE scope. > > Regards, > Lucy > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, May 24, 2006 12:25 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > the question is why "time constraint" should be taken into > account during path computation that would justify > incorporation into the communication between LSR-PCE/PCE-PCE elements > > scheduling of LSPs - themselves - is outside the scope of the > comm process between LSR-PCE/PCE-PCE elements, it is even > outside the scope of the PCE (since not a resource manager of > some sort) > > > > > > Lucy Yong > 24/05/2006 19:08 > > To: "'Adrian Farrel'" , "'Meral > Shirazipour'" > cc: pce@ietf.org > Subject: RE: [Pce] Comments about > draft-ietf-pce-architecture-05 > > > All, > > Thank you for all the comments. > PCE should support time-base reservation in the general and > leave as an option for carrier to implement or not. If we > exclude this functionality, > it > is hard to see the full automatic network because there are > quite these kinds of service demands and carrier also > encourages the pre-order so they can proactively engineer the > network. I'll be glad to write an informational draft to > explain the possible mechanism and protocols. Weather the > function should be maintained in the same database or > separated databases, it would be better to see after > clarifying the functionality of each element first, and then > decide the solution. The service reservation database > mentioned here has a lot of information that PCE does not > need and has no responsibility to maintain them. Maybe some > cache mechanism could be used. Welcome anyone to provide the > input on the informational draft. > > Best Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 11:11 AM > To: Meral Shirazipour; Lucy Yong > Cc: pce@ietf.org > Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > > Begging your pardon, Meral, but I'm a bit confused. > > > I agree with what you say here. This is a fact to consider > > especially > if > > > the > > PCE architecture is to be adapted later on for inter-AS TE in the > > 'Internet'. > > What you say here is important if we consider the Internet peering > models. > > The architecture is already intended to be "adapted" for that > purpose. > Have > a quick read through the first few sections and you'll see ample > discussion > of inter-AS. > > Lucy's email seems to me to be about the time-based reservation of > resources. This doesn't seem to me to be outside the scope of > the current > architecture, but one might want to write down how PCE is > used for that > purpose as an informational draft. > > Personally, I would find Lucy's suggestion of a distinct > component and > database that was consulted for each computation request a > costly idea, > and > would prefer to see this type of function rolled into a > single database. > > Adrian > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 17:07:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0Zb-00064i-Ml; Wed, 24 May 2006 17:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0Za-00064W-AD for pce@ietf.org; Wed, 24 May 2006 17:07:18 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0ZZ-0000s7-QH for pce@ietf.org; Wed, 24 May 2006 17:07:18 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS000TJFLR1D@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 13:58:40 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS007YTFLM1V@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 13:58:39 -0700 (PDT) Date: Wed, 24 May 2006 16:01:41 -0500 From: Lucy Yong Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: To: 'JP Vasseur' Message-id: <005d01c67f75$42a68bb0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org JP, I did not say the architecture prevent from time-based reservation. To be clarify here. Actually, I see that the architecture could be explicitly extended to support the application and be mentioned as one value for PCE based implementation compared to current router based implementation. The gap is you think that should be done in the TED and is out of scope of PCE. I think that, as we promote this basic architecture, it is good to mention the architecture also enable this kind of application and provide possible architecture scenario. Again, this does not impact the protocol implementation scoped here. Lucy -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Wednesday, May 24, 2006 2:35 PM To: Lucy Yong Cc: Dimitri.Papadimitriou@alcatel.be; pce@ietf.org Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 Hi Lucy, On May 24, 2006, at 3:10 PM, Lucy Yong wrote: > Hi Dimitri, > > Thank you for the comments. It is understood that the group goal is > to study > IP communication protocols not network architecture. However, they > can not > be completely separated. Before we are clear about the architecture > and its > components, we can't really specify the protocol, do we? > The suggestion here is to add another architecture scenario which > enables to > support time-based reservation. But again there's nothing that prevents you from applying your application using the defined PCE architecture. I think that you made some assumptions about the applicability of the PCE architecture that are not valid. Hope that these emails have clarified this. > I don't see this impact the protocol study. > It simply adds a value for PCE based architecture. > If we only study the protocols between LSR-PCE and PCE-PCE, adding > this > scenario does not add addition work at all. Note that there is one communication protocol between PCC-PCE and PCE- PCE. > I don't see how this scenario > impacts the scalability, performance, robustness and resiliency at > all. I personally think that it does, as pointed out by Dimitri. In summary: (1) The Architecture ID does not preclude the scenario that you describe, (2) We are very welcome to document such application model in an applicability ID to gather input from the list. Thanks. JP. > If > it is, it is scared what we are doing here. > > Regards, > Lucy > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, May 24, 2006 12:49 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > lucy - > > take a look at > gen-reqs-0 > 6.txt> > section 6.16, > > if there is a need to consider - as you wrote - that "PCE should > support > time-base reservation in the general > and leave as an option for carrier to implement or not." i would > like to > hear from operators specific rationales > to incorporate as part of the communication protocol / PCE > processing any > time constraint > > now more fundamentally and as stated the role of the group is to > define IP > communication protocols not network > architectures of some sort - reason for the suggestion made on > section 5 > > adrian mentions what is that inter-AS PCE is in scope, he forgot > probably > to mention to you that the primary > concerns of the work ongoing here is driven by four major concerns: > scalability, performance, robustness and > resiliency from this perspective any time constraint is going to > seriously > impact all these base objectives > > > > > > Lucy Yong > 24/05/2006 19:33 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "'Adrian Farrel'" , "'Meral > Shirazipour'" , pce@ietf.org > Subject: RE: [Pce] Comments about > draft-ietf-pce-architecture-05 > > > Dimitri, > > Because for some important reservations, carrier want to reserve the > specific path for many purposes such as better optimization, request > length > period, service guarantee, etc. > > Why should PCE WG limits the scope between LSR-PCE/PCE-PCE > elements? We > are > defining the architecture now. > > Adrian has mentioned that it is in PCE scope. > > Regards, > Lucy > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, May 24, 2006 12:25 PM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > the question is why "time constraint" should be taken into account > during path computation that would justify incorporation into the > communication between LSR-PCE/PCE-PCE elements > > scheduling of LSPs - themselves - is outside the scope of the comm > process between LSR-PCE/PCE-PCE elements, it is even outside the > scope of the PCE (since not a resource manager of some sort) > > > > > > Lucy Yong > 24/05/2006 19:08 > > To: "'Adrian Farrel'" , "'Meral > Shirazipour'" > cc: pce@ietf.org > Subject: RE: [Pce] Comments about > draft-ietf-pce-architecture-05 > > > All, > > Thank you for all the comments. > PCE should support time-base reservation in the general and leave > as an > option for carrier to implement or not. If we exclude this > functionality, > it > is hard to see the full automatic network because there are quite > these > kinds of service demands and carrier also encourages the pre-order > so they > can proactively engineer the network. > I'll be glad to write an informational draft to explain the possible > mechanism and protocols. Weather the function should be maintained > in the > same database or separated databases, it would be better to see after > clarifying the functionality of each element first, and then decide > the > solution. The service reservation database mentioned here has a lot of > information that PCE does not need and has no responsibility to > maintain > them. > Maybe some cache mechanism could be used. > Welcome anyone to provide the input on the informational draft. > > Best Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 11:11 AM > To: Meral Shirazipour; Lucy Yong > Cc: pce@ietf.org > Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > > Begging your pardon, Meral, but I'm a bit confused. > >> I agree with what you say here. This is a fact to consider >> especially > if > >> the >> PCE architecture is to be adapted later on for inter-AS TE in the >> 'Internet'. >> What you say here is important if we consider the Internet peering > models. > > The architecture is already intended to be "adapted" for that purpose. > Have > a quick read through the first few sections and you'll see ample > discussion > of inter-AS. > > Lucy's email seems to me to be about the time-based reservation of > resources. This doesn't seem to me to be outside the scope of the > current > architecture, but one might want to write down how PCE is used for > that > purpose as an informational draft. > > Personally, I would find Lucy's suggestion of a distinct component and > database that was consulted for each computation request a costly > idea, > and > would prefer to see this type of function rolled into a single > database. > > Adrian > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 17:19:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0kv-0003RO-9E; Wed, 24 May 2006 17:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0ku-0003RJ-LO for pce@ietf.org; Wed, 24 May 2006 17:19:00 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0kt-0001XW-Ns for pce@ietf.org; Wed, 24 May 2006 17:19:00 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS000AHGED1D@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 14:15:49 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS006T3GE0IU@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 14:15:49 -0700 (PDT) Date: Wed, 24 May 2006 16:18:44 -0500 From: Lucy Yong In-reply-to: <031601c67f4c$13b35640$0a23fea9@your029b8cecfe> To: 'Adrian Farrel' Message-id: <005e01c67f77$a6b8ea10$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f8267f77ca4545e62c57802503816d5 Cc: pce@ietf.org Subject: [Pce] RE: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0328658776==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0328658776== Content-type: multipart/alternative; boundary="Boundary_(ID_UM3U85og8rZY9993p0E24w)" This is a multi-part message in MIME format. --Boundary_(ID_UM3U85og8rZY9993p0E24w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Adrian, Sorry I did not read the entire message in the previous response. Here are comments for last few response. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 11:02 AM To: Lucy Yong Cc: pce@ietf.org Subject: Re: Comments about draft-ietf-pce-architecture-05 Hi Lucy, > The draft layouts the basic PCE architecture and expresses the motivation > for a PCE-based architecture. It is a good document. Thanks. > Beyond these motivation facts, I think we should have another incentive for > a PCE-based architecture. > > Today, a control plane based switching architecture assumes a user-network > model or client-server model. A LSP is initiated at an end user point > (client), then network establishes the LSP thru. the control plane > instantly. PCE reserves that concept too. Thus all connection paths are > based on instant requests from end users. I think it is true that PCE supports this model, but I don't think it is the case that the assumptions you state are universal. 1. The user-network model and the client-server model are examples of how one might use a control plane-based switching network, but they are not the only examples. 2. To say that all connection paths are based on instant requests from end users slightly misses the point of PCE. PCE performs computations based on requests from an external entity (the PCC), and PCE operates on a TED. There is nothing that says that the TED must be a representation of the network at only one instant of time, and there is nothing that says that the computation request must demand a computation "now". > In carrier reality world, it is hard to see that transport service will be > offered this way only, especially for a large bandwidth and permanent > bandwidth request. Hmmm. This may be why I disagreed with your assumptions! :-) > Typically, carrier has a service order reservation > system, it allows customer to book a bandwidth ahead (pending order), > carrier will do traffic engineering based on the pending order and will > excuse the order when the time arrives. Yes, this is another valid model. But it is also not the only valid model and many transport networks are operated today on a much more flexible approach. > A path computer engine has a > capability of taking a consideration about future pending orders while it > computes a path. I am unsure whether what you say matches reality perfectly. That is, when a pending future order is entered into the system, the reservation is made. This means that the TED reflects the results of the order/computation/fulfilment cycle, and that computations are still prefomred on demand (i.e. "now"). The difference is that the provisioning (fulfilment) is some time in the future. In this case, it seems unlikely that you would feed your TED from the routing protocols, but rather from inventory discovery and from the service ordering/fulfilment process. Figure 5 in the architecture shows this model. > The architecture is pretty close to the PCE-based > architecture except a lot of manual operation. I think PCE should consider > this as its application too and revise the basic architecture to include > this functionality. There is nothing (IMHO) in the current architecture that prohibits either the management plane use of PCE, or the inclusion of a time dimension in the TED and the computaiton requests. > Here is the recommendation for the PCE-based architecture: > > --------------- > | --------- | Routing ---------- > | | | | Protocol | | > | | TED |<-+----------+-> | > | | | | | | > | --------- | | | > | | | | | > | | Input | | | > | v | | | > ---------- Response | --------- | | | > | |Request | | | | | Adjacent | > | SORD |<------->| | PCE | | | Node | > | |Input | | | | | | > ---------- | --------- | | | > ^ | ^ | | | > | | |Request | | | > | | |Response| | | > Service Order | v | | | > | --------- | | | > Service | | | | Signaling| | > Request | |Signaling| | Protocol | | > ------+->| Engine |<-+----------+-> | > | | | | | | > | --------- | ---------- > --------------- > > Here, SORD is the service order reservation database, it contains all > service order requests in terms of ingress and egress points, bandwidth, > service type, time period for the request, etc. When PCE computes a path, it > could get input from SORD to indicate if there are some network resource is > already blocked out. When a booking order in SORD is ready to kick off, SORD > will send request to PCE for the path computation, then PCE will send a > service request to signaling engine to establish the LSP. This would be hugely inefficient, wouldn't it? Since PCE cannot guess which resources might be blocked out for future requests, it would have to make this query for every computation. Further, if PCE only made the query for resources that satisfied the computation, it might have to make repeated recomputations, so it would be more efficient for it to retrieve information about every future blocking. So, in fact, it makes more sense for SORD to feed the information into the TED and allow PCE to operate on the full database. But consider: How does SORD know which resources will be reserved and when? Presumably, it has consulted PCE as well. Good point. Thus, even the result is saved in TED, it still needs to consulted PCE. > It is clarified that not all pending orders in SORD need to reserve the > bandwidth ahead, carrier could have some policies in SORD to manage which > order need to reserve the bandwidth ahead and which is not. > > Be glad to hear your and other people comment on this suggestion. If you wanted to work on some issue like "Applicability of PCE to time-scoped service requests" this might be of interest to people. It was raised in the early days of PCE and of L1VPN, but did not attract significant interest. I think that the feeling at the time was that it was out of scope for PCE, but formed part of a management system. However, it might be that there would be value in enhancing the PCE protocol to carry time delimiters for computation requests. Note that the PCE working group is interested in applications of PCE and the protocols involved, but is not so interested in abstract functional components that are beyond the scope of the working group. Thank you for the suggestion. Well understand the group interest now. We will think about the protocol enhancement. Regards, Adrian --Boundary_(ID_UM3U85og8rZY9993p0E24w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Adrian,

 

Sorry I did not read the entire message in the previous response.

Here are comments for last few response.

 

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, May 24, 2006 11:02 AM
To: Lucy Yong
Cc: pce@ietf.org
Subject: Re: Comments about draft-ietf-pce-architecture-05

 

Hi Lucy,

 

> The draft layouts the basic PCE architecture and expresses the motivation
> for a PCE-based architecture. It is a good document.

 

Thanks.


> Beyond these motivation facts, I think we should have another incentive for
> a PCE-based architecture.
>
> Today, a control plane based switching architecture assumes a user-network
> model or client-server model. A LSP is initiated at an end user point
> (client), then network establishes the LSP thru. the control plane
> instantly. PCE reserves that concept too. Thus all connection paths are
> based on instant requests from end users.

 

I think it is true that PCE supports this model, but I don't think it is the case that the assumptions you state are universal.

 

1. The user-network model and the client-server model are examples of how one might use a control plane-based switching network, but they are not the only examples.

 

2. To say that all connection paths are based on instant requests from end users slightly misses the point of PCE. PCE performs computations based on requests from an external entity (the PCC), and PCE operates on a TED. There is nothing that says that the TED must be a representation of the network at only one instant of time, and there is nothing that says that the computation request must demand a computation "now".


> In carrier reality world, it is hard to see that transport service will be
> offered this way only, especially for a large bandwidth and permanent
> bandwidth request.

 

Hmmm. This may be why I disagreed with your assumptions! :-)

 

> Typically, carrier has a service order reservation
> system, it allows customer to book a bandwidth ahead (pending order),
> carrier will do traffic engineering based on the pending order and will
> excuse the order when the time arrives.

 

Yes, this is another valid model. But it is also not the only valid model and many transport networks are operated today on a much more flexible approach.

 

> A path computer engine has a
> capability of taking a consideration about future pending orders while it
> computes a path.

 

I am unsure whether what you say matches reality perfectly.

 

That is, when a pending future order is entered into the system, the reservation is made. This means that the TED reflects the results of the order/computation/fulfilment cycle, and that computations are still prefomred on demand (i.e. "now"). The difference is that the provisioning (fulfilment) is some time in the future.

 

In this case, it seems unlikely that you would feed your TED from the routing protocols, but rather from inventory discovery and from the service ordering/fulfilment process. Figure 5 in the architecture shows this model.

 

> The architecture is pretty close to the PCE-based
> architecture except a lot of manual operation. I think PCE should consider
> this as its application too and revise the basic architecture to include
> this functionality.

 

There is nothing (IMHO) in the current architecture that prohibits either the management plane use of PCE, or the inclusion of a time dimension in the TED and the computaiton requests.

 

> Here is the recommendation for the PCE-based architecture:
>
>                       ---------------
>                      |   ---------   | Routing   ----------
>                      |  |         |  | Protocol |          |
>                      |  |   TED   |<-+----------+->        |
>                      |  |         |  |          |          |
>                      |   ---------   |          |          |
>                      |      |        |          |          |
>                      |      | Input  |          |          |
>                      |      v        |          |          |
>  ---------- Response |   ---------   |          |          |
> |          |Request  |  |         |  |          | Adjacent |
> |  SORD    |<------->|  |   PCE   |  |          |   Node   |
> |          |Input    |  |         |  |          |          |
>  ----------          |   ---------   |          |          |
>      ^               |      ^        |          |          |
>      |               |      |Request |          |          |
>      |               |      |Response|          |          |
>   Service Order      |      v        |          |          |
>                      |   ---------   |          |          |
>             Service  |  |         |  | Signaling|          |
>             Request  |  |Signaling|  | Protocol |          |
>                ------+->| Engine  |<-+----------+->        |
>                      |  |         |  |          |          |
>                      |   ---------   |           ----------
>                       ---------------
>

> Here, SORD is the service order reservation database, it contains all
> service order requests in terms of ingress and egress points, bandwidth,
> service type, time period for the request, etc. When PCE computes a path, it
> could get input from SORD to indicate if there are some network resource is
> already blocked out. When a booking order in SORD is ready to kick off, SORD
> will send request to PCE for the path computation, then PCE will send a
> service request to signaling engine to establish the LSP.

 

This would be hugely inefficient, wouldn't it?

Since PCE cannot guess which resources might be blocked out for future requests, it would have to make this query for every computation. Further, if PCE only made the query for resources that satisfied the computation, it might have to make repeated recomputations, so it would be more efficient for it to retrieve information about every future blocking.

So, in fact, it makes more sense for SORD to feed the information into the TED and allow PCE to operate on the full database.

 

But consider: How does SORD know which resources will be reserved and when? Presumably, it has consulted PCE as well.

 

Good point. Thus, even the result is saved in TED, it still needs to consulted PCE.

 

> It is clarified that not all pending orders in SORD need to reserve the
> bandwidth ahead, carrier could have some policies in SORD to manage which
> order need to reserve the bandwidth ahead and which is not.
>
> Be glad to hear your and other people comment on this suggestion.

If you wanted to work on some issue like "Applicability of PCE to time-scoped service requests" this might be of interest to people. It was raised in the early days of PCE and of L1VPN, but did not attract significant interest. I think that the feeling at the time was that it was out of scope for PCE, but formed part of a management system. However, it might be that there would be value in enhancing the PCE protocol to carry time delimiters for computation requests.

 

Note that the PCE working group is interested in applications of PCE and the protocols involved, but is not so interested in abstract functional components that are beyond the scope of the working group.

 

Thank you for the suggestion. Well understand the group interest now. We will think about the protocol enhancement.

 

 

Regards,

Adrian

--Boundary_(ID_UM3U85og8rZY9993p0E24w)-- --===============0328658776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0328658776==-- From pce-bounces@lists.ietf.org Wed May 24 17:39:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj14U-00048d-Mn; Wed, 24 May 2006 17:39:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj14T-00048Y-5p for pce@ietf.org; Wed, 24 May 2006 17:39:13 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj14S-0002kE-GS for pce@ietf.org; Wed, 24 May 2006 17:39:13 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fj14N-0005D1-00 for pce@ietf.org; Wed, 24 May 2006 22:39:07 +0100 Received: from your029b8cecfe ([217.158.132.122] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 22:39:08 +0100 Message-ID: <03f901c67f7a$791254e0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Lucy Yong" , "'Payam Torab'" , References: <005a01c67f73$6d571cf0$d4087c0a@china.huawei.com> Subject: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Date: Wed, 24 May 2006 22:34:04 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 May 2006 21:39:09.0485 (UTC) FILETIME=[7D7EFDD0:01C67F7A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Lucy, I think that some of the confusion may be coming from the definition of TED. In the architecture I-D we have 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. and also ...a PCE would be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request. This gives us the somewhat circular definition that the TED is the database on which PCE operates to compute TE paths. You might think that this TED is exactly the database of TE information advertised by an IGP, and that would be an entirely reasonable implementation, but the architecture and definitions deliberately allow the TED to be supplemented from other sources, or even created entirely from other sources. Regards, Adrian ----- Original Message ----- From: "Lucy Yong" To: "'Payam Torab'" ; Cc: Sent: Wednesday, May 24, 2006 9:48 PM Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > Payam, > > The draft specifies five architecture scenarios. Suggest adding one for > time-based reservation. Giving the definition of TED, I don't see it can > serve that function properly. > TED contains topology and resource information from network. It may be > embedded in NE. It is good to have a place to hold real network > information > and another place hold all reservations. You can flexibly apply policy to > manage which bandwidth need to reserve ahead and which is only a book. It > is > hard to see the implementation done in TED. > > Lucy > > -----Original Message----- > From: Payam Torab [mailto:ptorab@lopsys.com] > Sent: Wednesday, May 24, 2006 2:31 PM > To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > Lucy- > > What do you mean by "architecture scenario" below? I don't see any > conflict > between the current PCE architecture, and adding an element of time to > path > computation. You can certainly add time constraints to TED, as well as > computation algorithms and support scheduling if you wish. > > You mention "It seems that current TED definition does not serve this > function (scheduling)" - How is TED definition blocking you from > scheduling? > > Thanks, > Payam Torab > >> -----Original Message----- >> From: Lucy Yong [mailto:lucyyong@huawei.com] >> Sent: Wednesday, May 24, 2006 3:11 PM >> To: Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> >> Hi Dimitri, >> >> Thank you for the comments. It is understood that the group >> goal is to study IP communication protocols not network >> architecture. However, they can not be completely separated. >> Before we are clear about the architecture and its >> components, we can't really specify the protocol, do we? The >> suggestion here is to add another architecture scenario which >> enables to support time-based reservation. I don't see this >> impact the protocol study. It simply adds a value for PCE >> based architecture. If we only study the protocols between >> LSR-PCE and PCE-PCE, adding this scenario does not add >> addition work at all. I don't see how this scenario impacts >> the scalability, performance, robustness and resiliency at >> all. If it is, it is scared what we are doing here. >> >> Regards, >> Lucy >> >> >> -----Original Message----- >> From: Dimitri.Papadimitriou@alcatel.be >> [mailto:Dimitri.Papadimitriou@alcatel.be] >> Sent: Wednesday, May 24, 2006 12:49 PM >> To: Lucy Yong >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> lucy - >> >> take a look at >> > col-gen-reqs-0 >> 6.txt> >> section 6.16, >> >> if there is a need to consider - as you wrote - that "PCE >> should support >> time-base reservation in the general >> and leave as an option for carrier to implement or not." i >> would like to >> hear from operators specific rationales >> to incorporate as part of the communication protocol / PCE >> processing any >> time constraint >> >> now more fundamentally and as stated the role of the group is >> to define IP >> communication protocols not network >> architectures of some sort - reason for the suggestion made >> on section 5 >> >> adrian mentions what is that inter-AS PCE is in scope, he >> forgot probably >> to mention to you that the primary >> concerns of the work ongoing here is driven by four major concerns: >> scalability, performance, robustness and >> resiliency from this perspective any time constraint is going >> to seriously >> impact all these base objectives >> >> >> >> >> >> Lucy Yong >> 24/05/2006 19:33 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: "'Adrian Farrel'" , "'Meral >> Shirazipour'" , pce@ietf.org >> Subject: RE: [Pce] Comments about >> draft-ietf-pce-architecture-05 >> >> >> Dimitri, >> >> Because for some important reservations, carrier want to >> reserve the specific path for many purposes such as better >> optimization, request >> length >> period, service guarantee, etc. >> >> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >> elements? We >> are >> defining the architecture now. >> >> Adrian has mentioned that it is in PCE scope. >> >> Regards, >> Lucy >> >> -----Original Message----- >> From: Dimitri.Papadimitriou@alcatel.be >> [mailto:Dimitri.Papadimitriou@alcatel.be] >> Sent: Wednesday, May 24, 2006 12:25 PM >> To: Lucy Yong >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> the question is why "time constraint" should be taken into >> account during path computation that would justify >> incorporation into the communication between LSR-PCE/PCE-PCE elements >> >> scheduling of LSPs - themselves - is outside the scope of the >> comm process between LSR-PCE/PCE-PCE elements, it is even >> outside the scope of the PCE (since not a resource manager of >> some sort) >> >> >> >> >> >> Lucy Yong >> 24/05/2006 19:08 >> >> To: "'Adrian Farrel'" , "'Meral >> Shirazipour'" >> cc: pce@ietf.org >> Subject: RE: [Pce] Comments about >> draft-ietf-pce-architecture-05 >> >> >> All, >> >> Thank you for all the comments. >> PCE should support time-base reservation in the general and >> leave as an option for carrier to implement or not. If we >> exclude this functionality, >> it >> is hard to see the full automatic network because there are >> quite these kinds of service demands and carrier also >> encourages the pre-order so they can proactively engineer the >> network. I'll be glad to write an informational draft to >> explain the possible mechanism and protocols. Weather the >> function should be maintained in the same database or >> separated databases, it would be better to see after >> clarifying the functionality of each element first, and then >> decide the solution. The service reservation database >> mentioned here has a lot of information that PCE does not >> need and has no responsibility to maintain them. Maybe some >> cache mechanism could be used. Welcome anyone to provide the >> input on the informational draft. >> >> Best Regards, >> Lucy >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Wednesday, May 24, 2006 11:11 AM >> To: Meral Shirazipour; Lucy Yong >> Cc: pce@ietf.org >> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Begging your pardon, Meral, but I'm a bit confused. >> >> > I agree with what you say here. This is a fact to consider >> > especially >> if >> >> > the >> > PCE architecture is to be adapted later on for inter-AS TE in the >> > 'Internet'. >> > What you say here is important if we consider the Internet peering >> models. >> >> The architecture is already intended to be "adapted" for that >> purpose. >> Have >> a quick read through the first few sections and you'll see ample >> discussion >> of inter-AS. >> >> Lucy's email seems to me to be about the time-based reservation of >> resources. This doesn't seem to me to be outside the scope of >> the current >> architecture, but one might want to write down how PCE is >> used for that >> purpose as an informational draft. >> >> Personally, I would find Lucy's suggestion of a distinct >> component and >> database that was consulted for each computation request a >> costly idea, >> and >> would prefer to see this type of function rolled into a >> single database. >> >> Adrian >> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 17:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj19h-00022O-5C; Wed, 24 May 2006 17:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj19g-00022J-NU for pce@ietf.org; Wed, 24 May 2006 17:44:36 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj19e-000382-9G for pce@ietf.org; Wed, 24 May 2006 17:44:36 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fj19w-0002ZQ-00 for pce@ietf.org; Wed, 24 May 2006 22:44:52 +0100 Received: from your029b8cecfe ([217.158.132.122] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 22:44:27 +0100 Message-ID: <040d01c67f7b$368a3510$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Lucy Yong" , "'Meral Shirazipour'" References: <003101c67f54$b519b8a0$d4087c0a@china.huawei.com> Date: Wed, 24 May 2006 22:41:01 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 May 2006 21:44:27.0675 (UTC) FILETIME=[3B26EEB0:01C67F7B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: pce@ietf.org Subject: [Pce] Informational I-D for timebased LSPs Was: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Lucy, Just to clarify: If you plan to propose a change in the architecture, we will (of course) discuss this with you. But I would not expect the working group to be very sympathetic having just completed work on the architecture, taken it through working group last call, and negotiated through a rather thorough IESG review. If you plan to write an informational I-D to show the requirements for time-based path computation, to show how the existing architecture meets the needs, and to propose requirements for extensions to existing protocols, this would be fine. From a working group perspective, this is getting a little ahead of ourselves (we have to complete the basic work first, and I hope you will contribute to advance this work), but it is a worthwhile activity to start if: - you want to prove that it can be done with the existing tools - you are willing to watch your draft progress slowly until other pieces of work have been done. It is possible that as you progress with the second option you may find yourself drawn to the first option. In this case i would suggest that you step back from the solutions work and focus only on the requirements work. Then you can consult with others in the working group about how to meet your requirements using the existing toolset. Regards, Adrian ----- Original Message ----- From: "Lucy Yong" To: "'Adrian Farrel'" ; "'Meral Shirazipour'" Cc: Sent: Wednesday, May 24, 2006 6:08 PM Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > All, > > Thank you for all the comments. > PCE should support time-base reservation in the general and leave as an > option for carrier to implement or not. If we exclude this functionality, > it > is hard to see the full automatic network because there are quite these > kinds of service demands and carrier also encourages the pre-order so they > can proactively engineer the network. > I'll be glad to write an informational draft to explain the possible > mechanism and protocols. Weather the function should be maintained in the > same database or separated databases, it would be better to see after > clarifying the functionality of each element first, and then decide the > solution. The service reservation database mentioned here has a lot of > information that PCE does not need and has no responsibility to maintain > them. > Maybe some cache mechanism could be used. > Welcome anyone to provide the input on the informational draft. > > Best Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 11:11 AM > To: Meral Shirazipour; Lucy Yong > Cc: pce@ietf.org > Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > > Begging your pardon, Meral, but I'm a bit confused. > >> I agree with what you say here. This is a fact to consider especially >> if > >> the >> PCE architecture is to be adapted later on for inter-AS TE in the >> 'Internet'. >> What you say here is important if we consider the Internet peering >> models. > > The architecture is already intended to be "adapted" for that purpose. > Have > a quick read through the first few sections and you'll see ample > discussion > of inter-AS. > > Lucy's email seems to me to be about the time-based reservation of > resources. This doesn't seem to me to be outside the scope of the current > architecture, but one might want to write down how PCE is used for that > purpose as an informational draft. > > Personally, I would find Lucy's suggestion of a distinct component and > database that was consulted for each computation request a costly idea, > and > would prefer to see this type of function rolled into a single database. > > Adrian > > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 17:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1Jp-0007kd-Lo; Wed, 24 May 2006 17:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1Jo-0007kY-2q for pce@ietf.org; Wed, 24 May 2006 17:55:04 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj1Jm-0003w0-IN for pce@ietf.org; Wed, 24 May 2006 17:55:04 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fj1K8-0003Dr-00 for pce@ietf.org; Wed, 24 May 2006 22:55:24 +0100 Received: from your029b8cecfe ([217.158.132.122] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 22:54:59 +0100 Message-ID: <041901c67f7c$afdff480$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Lucy Yong" References: <003401c67f63$7da39440$d4087c0a@china.huawei.com> Date: Wed, 24 May 2006 22:54:14 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 May 2006 21:55:00.0253 (UTC) FILETIME=[B432ACD0:01C67F7C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: pce@ietf.org Subject: [Pce] Re: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Lucy, Sorry that I am a bit behind in this discussion. others may have jumped in on some of these points already. >>> Today, a control plane based switching architecture assumes a >>> user-network >>> model or client-server model. A LSP is initiated at an end user point >>> (client), then network establishes the LSP thru. the control plane >>> instantly. PCE reserves that concept too. Thus all connection paths are >>> based on instant requests from end users. >> >> I think it is true that PCE supports this model, but I don't think it is >> the >> case that the assumptions you state are universal. >> >> 1. The user-network model and the client-server model are examples >> of >> how one might use a control plane-based switching network, but they are >> not >> the only examples. > > Accept this comment. > >> 2. To say that all connection paths are based on instant requests from >> end >> users slightly misses the point of PCE. PCE performs computations based >> on >> requests from an external entity (the PCC), and PCE operates on a TED. >> There >> is nothing that says that the TED must be a representation of the network >> at >> only one instant of time, and there is nothing that says that the >> computation request must demand a computation "now". > > OK PCE does specify an instant request from end-user or NMS. TED defined > in > the draft contains the topology and resource information of the domain. It > is very unclear if it can sever bandwidth reservation purpose or not. In > addition, TED is not excluded to reside within network, which is hard to > use > this purpose. That is clear. There are several architectural models defined. Not all models are applicable to all usage scenarios. Part of the purpose of an applicability statement is to define which models should be used for a particular application. >>> In carrier reality world, it is hard to see that transport service will >>> be >>> offered this way only, especially for a large bandwidth and permanent >>> bandwidth request. >> >> Hmmm. This may be why I disagreed with your assumptions! :-) > > Maybe my words here are not clear to you. I means that it is hard to see > that transport service will be only offered in the way that an end user > sends a signal request at ingress point at the time that a bandwidth > needed. Ah, *that* meaning of "instant" :-) OK. Yes. Sometimes services will be planned ahead of time. This was certainly in our minds as we wrote the architecture. >>> Typically, carrier has a service order reservation >>> system, it allows customer to book a bandwidth ahead (pending order), >>> carrier will do traffic engineering based on the pending order and will >>> excuse the order when the time arrives. >> >> Yes, this is another valid model. But it is also not the only valid model >> and many transport networks are operated today on a much more flexible >> approach. > > I agree. Does the architecture need to enable other approaches? The architecture has to enable a variety of realistic approaches. It does not need to document how they are achieved. That is the role of applicbility statements. >>> A path computer engine has a >>> capability of taking a consideration about future pending orders while >>> it >>> computes a path. >> >> I am unsure whether what you say matches reality perfectly. > >> That is, when a pending future order is entered into the system, the >> reservation is made. This means that the TED reflects the results of the >> order/computation/fulfilment cycle, and that computations are still >> prefomred on demand (i.e. "now"). The difference is that the provisioning >> (fulfilment) is some time in the future. >> >> In this case, it seems unlikely that you would feed your TED from the >> routing protocols, but rather from inventory discovery and from the >> service >> ordering/fulfilment process. Figure 5 in the architecture shows this >> model. > > That is the goal to feed TED from the routing protocols and let PCE use > TED > information and SORD information to compute the path. I think resource > inventory should come from network instead of human entering. Figure 5 > show > NMS initiating the service request, but does not show the reservation > capability. Whose goal do you describe? You are already describing a time-based TED in which resources that are free in the network are actually reserved at some point in the future. I think our problem is the definition of TED. See my mail on this subject. > You mention that the architecture does not prohibit time-based > reservation. > But it does not explicitly support that either. It is hard to see through > it. If this is a valid function, could we explicitly specify it instead of > "imply it"? Maybe insert section 5.6 to illustrate this model. It is not the architecture's job to explicitly support everything you might want to do. In fact, it would be a long document if it tried to do that. it is an architecture not a complete functional specification to cover all eventualities. Again, in order to show the applicability of the architecture to a scenario, we write applicability I-Ds. > That is my suggestion to expand the architecture including this scenario. I understand your suggestion. I do not see the need. Perhaps the working group will disagree with me. > This adds value for the PCE. :-) Will that mean that chairs get paid more? >>> The architecture is pretty close to the PCE-based >>> architecture except a lot of manual operation. I think PCE should >>> consider >>> this as its application too and revise the basic architecture to include >>> this functionality. >> >> There is nothing (IMHO) in the current architecture that prohibits either >> the management plane use of PCE, or the inclusion of a time dimension in >> the >> TED and the computaiton requests. > > It seems that current TED definition does not serve this function. Please show me the definition to which you refer. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 17:58:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1NS-0008I4-0Q; Wed, 24 May 2006 17:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1NR-0008Hz-FQ for pce@ietf.org; Wed, 24 May 2006 17:58:49 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj1NQ-0004C7-25 for pce@ietf.org; Wed, 24 May 2006 17:58:49 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fj1NL-0006WC-00 for pce@ietf.org; Wed, 24 May 2006 22:58:43 +0100 Received: from your029b8cecfe ([217.158.132.122] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 22:58:45 +0100 Message-ID: <041c01c67f7d$368da590$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Lucy Yong" References: <005e01c67f77$a6b8ea10$d4087c0a@china.huawei.com> Date: Wed, 24 May 2006 22:58:31 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 May 2006 21:58:46.0176 (UTC) FILETIME=[3ADBCA00:01C67F7D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pce@ietf.org Subject: [Pce] Re: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org No problem. Thanks for continuing to discuss this. >>> Here is the recommendation for the PCE-based architecture: >>> >>> --------------- >>> | --------- | Routing ---------- >>> | | | | Protocol | | >>> | | TED |<-+----------+-> | >>> | | | | | | >>> | --------- | | | >>> | | | | | >>> | | Input | | | >>> | v | | | >>> ---------- Response | --------- | | | >>> | |Request | | | | | Adjacent | >>> | SORD |<------->| | PCE | | | Node | >>> | |Input | | | | | | >>> ---------- | --------- | | | >>> ^ | ^ | | | >>> | | |Request | | | >>> | | |Response| | | >>> Service Order | v | | | >>> | --------- | | | >>> Service | | | | Signaling| | >>> Request | |Signaling| | Protocol | | >>> ------+->| Engine |<-+----------+-> | >>> | | | | | | >>> | --------- | ---------- >>> --------------- >>> >>> Here, SORD is the service order reservation database, it contains all >>> service order requests in terms of ingress and egress points, bandwidth, >>> service type, time period for the request, etc. When PCE computes a >>> path, >>> it could get input from SORD to indicate if there are some network >>> resource is already blocked out. When a booking order in SORD is >>> ready to kick off, SORD >>> will send request to PCE for the path computation, then PCE will send a >>> service request to signaling engine to establish the LSP. >> >> This would be hugely inefficient, wouldn't it? >> >> Since PCE cannot guess which resources might be blocked out for future >> requests, it would have to make this query for every computation. >> Further, >> if PCE only made the query for resources that satisfied the computation, >> it >> might have to make repeated recomputations, so it would be more efficient >> for it to retrieve information about every future blocking. >> >> So, in fact, it makes more sense for SORD to feed the information into >> the >> TED and allow PCE to operate on the full database. >> >> But consider: How does SORD know which resources will be reserved and >> when? >> Presumably, it has consulted PCE as well. > > Good point. Thus, even the result is saved in TED, it still needs to > consulted PCE. Yes. Your SORD becomes just another regular PCC. in fact, it is probably part of the NMS/OSS. >> If you wanted to work on some issue like "Applicability of PCE to >> time-scoped service requests" this might be of interest to people. It was >> raised in the early days of PCE and of L1VPN, but did not attract >> significant interest. I think that the feeling at the time was that it >> was >> out of scope for PCE, but formed part of a management system. However, it >> might be that there would be value in enhancing the PCE protocol to carry >> time delimiters for computation requests. >> >> Note that the PCE working group is interested in applications of PCE and >> the >> protocols involved, but is not so interested in abstract functional >> components that are beyond the scope of the working group. > > Thank you for the suggestion. Well understand the group interest now. We > will think about the protocol enhancement. OK. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 18:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1qG-0000Fe-Qj; Wed, 24 May 2006 18:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1qF-0000FZ-0G for pce@ietf.org; Wed, 24 May 2006 18:28:35 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj1qC-0005rj-Cp for pce@ietf.org; Wed, 24 May 2006 18:28:34 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS0004KINC1D@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 15:04:25 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS0034LIN2JH@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 15:04:24 -0700 (PDT) Date: Wed, 24 May 2006 17:07:21 -0500 From: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: <03f901c67f7a$791254e0$0a23fea9@your029b8cecfe> To: 'Adrian Farrel' , 'Payam Torab' , Dimitri.Papadimitriou@alcatel.be Message-id: <006801c67f7e$71e90020$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, Great explanation. Thanks. Since PCE is the only path computation engine, any path reservation needs to go through it even the result could be saved in TED. I understand the TED may be fed by IGP extensions or potentially by other means. This other could be the reservation system. However, the reservation system only has ingress and egress information, it does not have travel path information, TED can not compute the path either. Therefore, it needs to go through the PCE. No need to another path computation engine. Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 4:34 PM To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be Cc: pce@ietf.org Subject: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi Lucy, I think that some of the confusion may be coming from the definition of TED. In the architecture I-D we have 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. and also ...a PCE would be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request. This gives us the somewhat circular definition that the TED is the database on which PCE operates to compute TE paths. You might think that this TED is exactly the database of TE information advertised by an IGP, and that would be an entirely reasonable implementation, but the architecture and definitions deliberately allow the TED to be supplemented from other sources, or even created entirely from other sources. Regards, Adrian ----- Original Message ----- From: "Lucy Yong" To: "'Payam Torab'" ; Cc: Sent: Wednesday, May 24, 2006 9:48 PM Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > Payam, > > The draft specifies five architecture scenarios. Suggest adding one for > time-based reservation. Giving the definition of TED, I don't see it can > serve that function properly. > TED contains topology and resource information from network. It may be > embedded in NE. It is good to have a place to hold real network > information > and another place hold all reservations. You can flexibly apply policy to > manage which bandwidth need to reserve ahead and which is only a book. It > is > hard to see the implementation done in TED. > > Lucy > > -----Original Message----- > From: Payam Torab [mailto:ptorab@lopsys.com] > Sent: Wednesday, May 24, 2006 2:31 PM > To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > Lucy- > > What do you mean by "architecture scenario" below? I don't see any > conflict > between the current PCE architecture, and adding an element of time to > path > computation. You can certainly add time constraints to TED, as well as > computation algorithms and support scheduling if you wish. > > You mention "It seems that current TED definition does not serve this > function (scheduling)" - How is TED definition blocking you from > scheduling? > > Thanks, > Payam Torab > >> -----Original Message----- >> From: Lucy Yong [mailto:lucyyong@huawei.com] >> Sent: Wednesday, May 24, 2006 3:11 PM >> To: Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> >> Hi Dimitri, >> >> Thank you for the comments. It is understood that the group >> goal is to study IP communication protocols not network >> architecture. However, they can not be completely separated. >> Before we are clear about the architecture and its >> components, we can't really specify the protocol, do we? The >> suggestion here is to add another architecture scenario which >> enables to support time-based reservation. I don't see this >> impact the protocol study. It simply adds a value for PCE >> based architecture. If we only study the protocols between >> LSR-PCE and PCE-PCE, adding this scenario does not add >> addition work at all. I don't see how this scenario impacts >> the scalability, performance, robustness and resiliency at >> all. If it is, it is scared what we are doing here. >> >> Regards, >> Lucy >> >> >> -----Original Message----- >> From: Dimitri.Papadimitriou@alcatel.be >> [mailto:Dimitri.Papadimitriou@alcatel.be] >> Sent: Wednesday, May 24, 2006 12:49 PM >> To: Lucy Yong >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> lucy - >> >> take a look at >> > col-gen-reqs-0 >> 6.txt> >> section 6.16, >> >> if there is a need to consider - as you wrote - that "PCE >> should support >> time-base reservation in the general >> and leave as an option for carrier to implement or not." i >> would like to >> hear from operators specific rationales >> to incorporate as part of the communication protocol / PCE >> processing any >> time constraint >> >> now more fundamentally and as stated the role of the group is >> to define IP >> communication protocols not network >> architectures of some sort - reason for the suggestion made >> on section 5 >> >> adrian mentions what is that inter-AS PCE is in scope, he >> forgot probably >> to mention to you that the primary >> concerns of the work ongoing here is driven by four major concerns: >> scalability, performance, robustness and >> resiliency from this perspective any time constraint is going >> to seriously >> impact all these base objectives >> >> >> >> >> >> Lucy Yong >> 24/05/2006 19:33 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: "'Adrian Farrel'" , "'Meral >> Shirazipour'" , pce@ietf.org >> Subject: RE: [Pce] Comments about >> draft-ietf-pce-architecture-05 >> >> >> Dimitri, >> >> Because for some important reservations, carrier want to >> reserve the specific path for many purposes such as better >> optimization, request >> length >> period, service guarantee, etc. >> >> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >> elements? We >> are >> defining the architecture now. >> >> Adrian has mentioned that it is in PCE scope. >> >> Regards, >> Lucy >> >> -----Original Message----- >> From: Dimitri.Papadimitriou@alcatel.be >> [mailto:Dimitri.Papadimitriou@alcatel.be] >> Sent: Wednesday, May 24, 2006 12:25 PM >> To: Lucy Yong >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> the question is why "time constraint" should be taken into >> account during path computation that would justify >> incorporation into the communication between LSR-PCE/PCE-PCE elements >> >> scheduling of LSPs - themselves - is outside the scope of the >> comm process between LSR-PCE/PCE-PCE elements, it is even >> outside the scope of the PCE (since not a resource manager of >> some sort) >> >> >> >> >> >> Lucy Yong >> 24/05/2006 19:08 >> >> To: "'Adrian Farrel'" , "'Meral >> Shirazipour'" >> cc: pce@ietf.org >> Subject: RE: [Pce] Comments about >> draft-ietf-pce-architecture-05 >> >> >> All, >> >> Thank you for all the comments. >> PCE should support time-base reservation in the general and >> leave as an option for carrier to implement or not. If we >> exclude this functionality, >> it >> is hard to see the full automatic network because there are >> quite these kinds of service demands and carrier also >> encourages the pre-order so they can proactively engineer the >> network. I'll be glad to write an informational draft to >> explain the possible mechanism and protocols. Weather the >> function should be maintained in the same database or >> separated databases, it would be better to see after >> clarifying the functionality of each element first, and then >> decide the solution. The service reservation database >> mentioned here has a lot of information that PCE does not >> need and has no responsibility to maintain them. Maybe some >> cache mechanism could be used. Welcome anyone to provide the >> input on the informational draft. >> >> Best Regards, >> Lucy >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Wednesday, May 24, 2006 11:11 AM >> To: Meral Shirazipour; Lucy Yong >> Cc: pce@ietf.org >> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Begging your pardon, Meral, but I'm a bit confused. >> >> > I agree with what you say here. This is a fact to consider >> > especially >> if >> >> > the >> > PCE architecture is to be adapted later on for inter-AS TE in the >> > 'Internet'. >> > What you say here is important if we consider the Internet peering >> models. >> >> The architecture is already intended to be "adapted" for that >> purpose. >> Have >> a quick read through the first few sections and you'll see ample >> discussion >> of inter-AS. >> >> Lucy's email seems to me to be about the time-based reservation of >> resources. This doesn't seem to me to be outside the scope of >> the current >> architecture, but one might want to write down how PCE is >> used for that >> purpose as an informational draft. >> >> Personally, I would find Lucy's suggestion of a distinct >> component and >> database that was consulted for each computation request a >> costly idea, >> and >> would prefer to see this type of function rolled into a >> single database. >> >> Adrian >> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 24 18:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj269-0001aJ-8W; Wed, 24 May 2006 18:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj268-0001YS-0Y for pce@ietf.org; Wed, 24 May 2006 18:45:00 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj266-0006p6-Gc for pce@ietf.org; Wed, 24 May 2006 18:44:59 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZS0003KKDQ1D@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 15:41:50 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZS0030NKDGJH@usaga01-in.huawei.com> for pce@ietf.org; Wed, 24 May 2006 15:41:50 -0700 (PDT) Date: Wed, 24 May 2006 17:44:47 -0500 From: Lucy Yong In-reply-to: <040d01c67f7b$368a3510$0a23fea9@your029b8cecfe> To: 'Adrian Farrel' , 'Meral Shirazipour' Message-id: <006901c67f83$ac9b9ac0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: pce@ietf.org Subject: [Pce] RE: Informational I-D for timebased LSPs Was: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Adrian, Thank you for a kind advice. My purpose is to suggest PCE based architecture could support time-based reservation, which has a great value for a label switched service. (As the chair, you deserve a high pay!) You clearly see this function in existing architecture model while that is not clear to me (sorry I am not that clever). My point is: does this worth to explicitly mention in the document even this may not be the main implementation area for the group? Don't know if the time is the issue or not. I am new for this group and just read this document published recently. Maybe a lot of discussions have been done before. Then, sorry about that late noise. I would like to provide some informational draft about time-based computation. However, as you mentioned, that will be back to the architecture model again, which model to use. Thank you for the suggestion, starting from the requirement might be a smart starting point. Please continually advise. Best Regards, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, May 24, 2006 4:41 PM To: Lucy Yong; 'Meral Shirazipour' Cc: pce@ietf.org Subject: Informational I-D for timebased LSPs Was: Comments about draft-ietf-pce-architecture-05 Lucy, Just to clarify: If you plan to propose a change in the architecture, we will (of course) discuss this with you. But I would not expect the working group to be very sympathetic having just completed work on the architecture, taken it through working group last call, and negotiated through a rather thorough IESG review. If you plan to write an informational I-D to show the requirements for time-based path computation, to show how the existing architecture meets the needs, and to propose requirements for extensions to existing protocols, this would be fine. From a working group perspective, this is getting a little ahead of ourselves (we have to complete the basic work first, and I hope you will contribute to advance this work), but it is a worthwhile activity to start if: - you want to prove that it can be done with the existing tools - you are willing to watch your draft progress slowly until other pieces of work have been done. It is possible that as you progress with the second option you may find yourself drawn to the first option. In this case i would suggest that you step back from the solutions work and focus only on the requirements work. Then you can consult with others in the working group about how to meet your requirements using the existing toolset. Regards, Adrian ----- Original Message ----- From: "Lucy Yong" To: "'Adrian Farrel'" ; "'Meral Shirazipour'" Cc: Sent: Wednesday, May 24, 2006 6:08 PM Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > All, > > Thank you for all the comments. > PCE should support time-base reservation in the general and leave as an > option for carrier to implement or not. If we exclude this functionality, > it > is hard to see the full automatic network because there are quite these > kinds of service demands and carrier also encourages the pre-order so they > can proactively engineer the network. > I'll be glad to write an informational draft to explain the possible > mechanism and protocols. Weather the function should be maintained in the > same database or separated databases, it would be better to see after > clarifying the functionality of each element first, and then decide the > solution. The service reservation database mentioned here has a lot of > information that PCE does not need and has no responsibility to maintain > them. > Maybe some cache mechanism could be used. > Welcome anyone to provide the input on the informational draft. > > Best Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 11:11 AM > To: Meral Shirazipour; Lucy Yong > Cc: pce@ietf.org > Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > > Begging your pardon, Meral, but I'm a bit confused. > >> I agree with what you say here. This is a fact to consider especially >> if > >> the >> PCE architecture is to be adapted later on for inter-AS TE in the >> 'Internet'. >> What you say here is important if we consider the Internet peering >> models. > > The architecture is already intended to be "adapted" for that purpose. > Have > a quick read through the first few sections and you'll see ample > discussion > of inter-AS. > > Lucy's email seems to me to be about the time-based reservation of > resources. This doesn't seem to me to be outside the scope of the current > architecture, but one might want to write down how PCE is used for that > purpose as an informational draft. > > Personally, I would find Lucy's suggestion of a distinct component and > database that was consulted for each computation request a costly idea, > and > would prefer to see this type of function rolled into a single database. > > Adrian > > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 07:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjDoZ-0007QA-Bj; Thu, 25 May 2006 07:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjDoY-0007Q0-1F for pce@ietf.org; Thu, 25 May 2006 07:15:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjDoX-000701-CO for pce@ietf.org; Thu, 25 May 2006 07:15:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2006 07:15:37 -0400 X-IronPort-AV: i="4.05,171,1146456000"; d="scan'208"; a="89433008:sNHT37512480" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4PBFZTL014748; Thu, 25 May 2006 07:15:36 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 07:15:35 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 07:15:34 -0400 In-Reply-To: <006801c67f7e$71e90020$d4087c0a@china.huawei.com> References: <006801c67f7e$71e90020$d4087c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D29E2CF-4FC0-4106-B3B9-BC1AB89D5DA4@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Date: Thu, 25 May 2006 07:15:30 -0400 To: Lucy Yong X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 25 May 2006 11:15:34.0931 (UTC) FILETIME=[8B18DE30:01C67FEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: pce@ietf.org, Dimitri.Papadimitriou@alcatel.be X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Lucy, On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > Hi Adrian, > > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation > needs to > go through it even the result could be saved in TED. Yes, although I would suggest you to be cautious here since there would be dangerous side-effect especially in situations where the PCE is not used by all nodes to compute TE LSP paths. > I understand the TED > may be fed by IGP extensions or potentially by other means. This > other could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, > TED can > not compute the path either. Therefore, it needs to go through the > PCE. No > need to another path computation engine. It looks like you use a different terminology than in the IETF documents related to MPLS TE: -> By "reservation system" do you mean "Control plane used to establish the TE LSP (RSVP-TE)" ? -> TED never compute paths ... this is the topology database used to compute path Thanks. JP. > > Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > I think that some of the confusion may be coming from the > definition of TED. > > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE > LSP > service request. > > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that > this TED is > exactly the database of TE information advertised by an IGP, and > that would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. > > Regards, > Adrian > > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> Payam, >> >> The draft specifies five architecture scenarios. Suggest adding >> one for >> time-based reservation. Giving the definition of TED, I don't see >> it can >> serve that function properly. >> TED contains topology and resource information from network. It >> may be >> embedded in NE. It is good to have a place to hold real network >> information >> and another place hold all reservations. You can flexibly apply >> policy to >> manage which bandwidth need to reserve ahead and which is only a >> book. It >> is >> hard to see the implementation done in TED. >> >> Lucy >> >> -----Original Message----- >> From: Payam Torab [mailto:ptorab@lopsys.com] >> Sent: Wednesday, May 24, 2006 2:31 PM >> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Lucy- >> >> What do you mean by "architecture scenario" below? I don't see any >> conflict >> between the current PCE architecture, and adding an element of >> time to >> path >> computation. You can certainly add time constraints to TED, as >> well as >> computation algorithms and support scheduling if you wish. >> >> You mention "It seems that current TED definition does not serve this >> function (scheduling)" - How is TED definition blocking you from >> scheduling? >> >> Thanks, >> Payam Torab >> >>> -----Original Message----- >>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>> Sent: Wednesday, May 24, 2006 3:11 PM >>> To: Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> >>> Hi Dimitri, >>> >>> Thank you for the comments. It is understood that the group >>> goal is to study IP communication protocols not network >>> architecture. However, they can not be completely separated. >>> Before we are clear about the architecture and its >>> components, we can't really specify the protocol, do we? The >>> suggestion here is to add another architecture scenario which >>> enables to support time-based reservation. I don't see this >>> impact the protocol study. It simply adds a value for PCE >>> based architecture. If we only study the protocols between >>> LSR-PCE and PCE-PCE, adding this scenario does not add >>> addition work at all. I don't see how this scenario impacts > >>> the scalability, performance, robustness and resiliency at >>> all. If it is, it is scared what we are doing here. >>> >>> Regards, >>> Lucy >>> >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:49 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> lucy - >>> >>> take a look at >>> >> col-gen-reqs-0 >>> 6.txt> >>> section 6.16, >>> >>> if there is a need to consider - as you wrote - that "PCE >>> should support >>> time-base reservation in the general >>> and leave as an option for carrier to implement or not." i >>> would like to >>> hear from operators specific rationales >>> to incorporate as part of the communication protocol / PCE >>> processing any >>> time constraint >>> >>> now more fundamentally and as stated the role of the group is >>> to define IP >>> communication protocols not network >>> architectures of some sort - reason for the suggestion made >>> on section 5 >>> >>> adrian mentions what is that inter-AS PCE is in scope, he >>> forgot probably >>> to mention to you that the primary >>> concerns of the work ongoing here is driven by four major concerns: >>> scalability, performance, robustness and >>> resiliency from this perspective any time constraint is going >>> to seriously >>> impact all these base objectives >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:33 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" , pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> Dimitri, >>> >>> Because for some important reservations, carrier want to >>> reserve the specific path for many purposes such as better >>> optimization, request >>> length >>> period, service guarantee, etc. >>> >>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>> elements? We >>> are >>> defining the architecture now. >>> >>> Adrian has mentioned that it is in PCE scope. >>> >>> Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:25 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> the question is why "time constraint" should be taken into >>> account during path computation that would justify >>> incorporation into the communication between LSR-PCE/PCE-PCE >>> elements >>> >>> scheduling of LSPs - themselves - is outside the scope of the >>> comm process between LSR-PCE/PCE-PCE elements, it is even >>> outside the scope of the PCE (since not a resource manager of >>> some sort) >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:08 >>> >>> To: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" >>> cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> All, >>> >>> Thank you for all the comments. >>> PCE should support time-base reservation in the general and >>> leave as an option for carrier to implement or not. If we >>> exclude this functionality, >>> it >>> is hard to see the full automatic network because there are >>> quite these kinds of service demands and carrier also >>> encourages the pre-order so they can proactively engineer the >>> network. I'll be glad to write an informational draft to >>> explain the possible mechanism and protocols. Weather the >>> function should be maintained in the same database or >>> separated databases, it would be better to see after >>> clarifying the functionality of each element first, and then >>> decide the solution. The service reservation database >>> mentioned here has a lot of information that PCE does not >>> need and has no responsibility to maintain them. Maybe some >>> cache mechanism could be used. Welcome anyone to provide the >>> input on the informational draft. >>> >>> Best Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Wednesday, May 24, 2006 11:11 AM >>> To: Meral Shirazipour; Lucy Yong >>> Cc: pce@ietf.org >>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Begging your pardon, Meral, but I'm a bit confused. >>> >>>> I agree with what you say here. This is a fact to consider >>>> especially >>> if >>> >>>> the >>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>> 'Internet'. >>>> What you say here is important if we consider the Internet peering >>> models. >>> >>> The architecture is already intended to be "adapted" for that >>> purpose. >>> Have >>> a quick read through the first few sections and you'll see ample >>> discussion >>> of inter-AS. >>> >>> Lucy's email seems to me to be about the time-based reservation of >>> resources. This doesn't seem to me to be outside the scope of >>> the current >>> architecture, but one might want to write down how PCE is >>> used for that >>> purpose as an informational draft. >>> >>> Personally, I would find Lucy's suggestion of a distinct >>> component and >>> database that was consulted for each computation request a >>> costly idea, >>> and >>> would prefer to see this type of function rolled into a >>> single database. >>> >>> Adrian >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 10:00:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGNY-0006Mi-UO; Thu, 25 May 2006 09:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGNW-0006MX-Ui for pce@ietf.org; Thu, 25 May 2006 09:59:54 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGNW-0003hA-BF for pce@ietf.org; Thu, 25 May 2006 09:59:54 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZT00CRPQOF0Z@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 06:55:28 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZT00HAKQO3X3@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 06:55:27 -0700 (PDT) Date: Thu, 25 May 2006 08:58:24 -0500 From: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 In-reply-to: <3D29E2CF-4FC0-4106-B3B9-BC1AB89D5DA4@cisco.com> To: 'JP Vasseur' Message-id: <000001c68003$4ee78210$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec Cc: pce@ietf.org, Dimitri.Papadimitriou@alcatel.be X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi JP, Thank you for a good catch. See me response below. Regards, Lucy -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, May 25, 2006 6:16 AM To: Lucy Yong Cc: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be; pce@ietf.org Subject: Re: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi Lucy, On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > Hi Adrian, > > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation > needs to > go through it even the result could be saved in TED. Yes, although I would suggest you to be cautious here since there would be dangerous side-effect especially in situations where the PCE is not used by all nodes to compute TE LSP paths. [Lucy] Agree. I do not assume that either. PCE could be centralized or partial distributed. > I understand the TED > may be fed by IGP extensions or potentially by other means. This > other could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, > TED can > not compute the path either. Therefore, it needs to go through the > PCE. No > need to another path computation engine. It looks like you use a different terminology than in the IETF documents related to MPLS TE: -> By "reservation system" do you mean "Control plane used to establish the TE LSP (RSVP-TE)" ? -> TED never compute paths ... this is the topology database used to compute path [Lucy]: Sorry, use the wrong term. It should be inventory system. Inventory system is manually maintained resource system. With PCE based architecture, we only want one place to compute the path, that is the PCE. Therefore, no matter where the time-based reserved resource is stored, PCE should be the place to compute the path. Maybe someone could illustrate how the basic architecture model could accomplish this task. :) Thanks. JP. > > Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > I think that some of the confusion may be coming from the > definition of TED. > > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE > LSP > service request. > > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that > this TED is > exactly the database of TE information advertised by an IGP, and > that would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. > > Regards, > Adrian > > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> Payam, >> >> The draft specifies five architecture scenarios. Suggest adding >> one for >> time-based reservation. Giving the definition of TED, I don't see >> it can >> serve that function properly. >> TED contains topology and resource information from network. It >> may be >> embedded in NE. It is good to have a place to hold real network >> information >> and another place hold all reservations. You can flexibly apply >> policy to >> manage which bandwidth need to reserve ahead and which is only a >> book. It >> is >> hard to see the implementation done in TED. >> >> Lucy >> >> -----Original Message----- >> From: Payam Torab [mailto:ptorab@lopsys.com] >> Sent: Wednesday, May 24, 2006 2:31 PM >> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Lucy- >> >> What do you mean by "architecture scenario" below? I don't see any >> conflict >> between the current PCE architecture, and adding an element of >> time to >> path >> computation. You can certainly add time constraints to TED, as >> well as >> computation algorithms and support scheduling if you wish. >> >> You mention "It seems that current TED definition does not serve this >> function (scheduling)" - How is TED definition blocking you from >> scheduling? >> >> Thanks, >> Payam Torab >> >>> -----Original Message----- >>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>> Sent: Wednesday, May 24, 2006 3:11 PM >>> To: Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> >>> Hi Dimitri, >>> >>> Thank you for the comments. It is understood that the group >>> goal is to study IP communication protocols not network >>> architecture. However, they can not be completely separated. >>> Before we are clear about the architecture and its >>> components, we can't really specify the protocol, do we? The >>> suggestion here is to add another architecture scenario which >>> enables to support time-based reservation. I don't see this >>> impact the protocol study. It simply adds a value for PCE >>> based architecture. If we only study the protocols between >>> LSR-PCE and PCE-PCE, adding this scenario does not add >>> addition work at all. I don't see how this scenario impacts > >>> the scalability, performance, robustness and resiliency at >>> all. If it is, it is scared what we are doing here. >>> >>> Regards, >>> Lucy >>> >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:49 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> lucy - >>> >>> take a look at >>> >> col-gen-reqs-0 >>> 6.txt> >>> section 6.16, >>> >>> if there is a need to consider - as you wrote - that "PCE >>> should support >>> time-base reservation in the general >>> and leave as an option for carrier to implement or not." i >>> would like to >>> hear from operators specific rationales >>> to incorporate as part of the communication protocol / PCE >>> processing any >>> time constraint >>> >>> now more fundamentally and as stated the role of the group is >>> to define IP >>> communication protocols not network >>> architectures of some sort - reason for the suggestion made >>> on section 5 >>> >>> adrian mentions what is that inter-AS PCE is in scope, he >>> forgot probably >>> to mention to you that the primary >>> concerns of the work ongoing here is driven by four major concerns: >>> scalability, performance, robustness and >>> resiliency from this perspective any time constraint is going >>> to seriously >>> impact all these base objectives >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:33 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" , pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> Dimitri, >>> >>> Because for some important reservations, carrier want to >>> reserve the specific path for many purposes such as better >>> optimization, request >>> length >>> period, service guarantee, etc. >>> >>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>> elements? We >>> are >>> defining the architecture now. >>> >>> Adrian has mentioned that it is in PCE scope. >>> >>> Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:25 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> the question is why "time constraint" should be taken into >>> account during path computation that would justify >>> incorporation into the communication between LSR-PCE/PCE-PCE >>> elements >>> >>> scheduling of LSPs - themselves - is outside the scope of the >>> comm process between LSR-PCE/PCE-PCE elements, it is even >>> outside the scope of the PCE (since not a resource manager of >>> some sort) >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:08 >>> >>> To: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" >>> cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> All, >>> >>> Thank you for all the comments. >>> PCE should support time-base reservation in the general and >>> leave as an option for carrier to implement or not. If we >>> exclude this functionality, >>> it >>> is hard to see the full automatic network because there are >>> quite these kinds of service demands and carrier also >>> encourages the pre-order so they can proactively engineer the >>> network. I'll be glad to write an informational draft to >>> explain the possible mechanism and protocols. Weather the >>> function should be maintained in the same database or >>> separated databases, it would be better to see after >>> clarifying the functionality of each element first, and then >>> decide the solution. The service reservation database >>> mentioned here has a lot of information that PCE does not >>> need and has no responsibility to maintain them. Maybe some >>> cache mechanism could be used. Welcome anyone to provide the >>> input on the informational draft. >>> >>> Best Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Wednesday, May 24, 2006 11:11 AM >>> To: Meral Shirazipour; Lucy Yong >>> Cc: pce@ietf.org >>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Begging your pardon, Meral, but I'm a bit confused. >>> >>>> I agree with what you say here. This is a fact to consider >>>> especially >>> if >>> >>>> the >>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>> 'Internet'. >>>> What you say here is important if we consider the Internet peering >>> models. >>> >>> The architecture is already intended to be "adapted" for that >>> purpose. >>> Have >>> a quick read through the first few sections and you'll see ample >>> discussion >>> of inter-AS. >>> >>> Lucy's email seems to me to be about the time-based reservation of >>> resources. This doesn't seem to me to be outside the scope of >>> the current >>> architecture, but one might want to write down how PCE is >>> used for that >>> purpose as an informational draft. >>> >>> Personally, I would find Lucy's suggestion of a distinct >>> component and >>> database that was consulted for each computation request a >>> costly idea, >>> and >>> would prefer to see this type of function rolled into a >>> single database. >>> >>> Adrian >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 10:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHBf-0000sq-8Y; Thu, 25 May 2006 10:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHBd-0000se-W9 for pce@ietf.org; Thu, 25 May 2006 10:51:42 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHBd-0008GE-2k for pce@ietf.org; Thu, 25 May 2006 10:51:41 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4PEodtn016275; Thu, 25 May 2006 16:50:39 +0200 In-Reply-To: <000001c68003$4ee78210$d4087c0a@china.huawei.com> To: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 25 May 2006 16:50:29 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/25/2006 16:50:39, Serialize complete at 05/25/2006 16:50:39 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 439b8e44c906b144bce6744ebb966e60 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org lucy - this side discussion on TED is diverting from the (real) issue behind the initial proposal that has started this thread there is first a need to determine whether there is an interest behind this feature i.e. whether this would be addressing a real concern, and i have not seen anything similar in all the requirements document and discussion we had since so far now, assuming such requirement would pop up (i would be keen to see which applications we're speaking about here) there is a second phase that consists in assessing whether the PCE communication/entity is appropriate for processing such kind of information (side note: PCE does not perform any resource admission control nor performs any sort of resource reservation) and the impact this would have on the PCE mechanisms assumed since so far this because time based reservation / time constraint implies - network time synchronization for each resource reservation and for each LSP - the PCE that will have to take this constraint into account will also have to maintain (or obtain as information) for each reservation and for each LSP the time elapsed in order to be able to provide with the suitable answer to subsequent request (in brief, a computation will not have only to rely on the PRESENT state of the network resource reservation but also on PAST and FUTURE reservation) note: there is a side-effect on the signaling protocol mechanism as this breaks the idempotent behaviour of RSVP (for inst.) - PCEs will need to synchronize around that information during Path computation requests involving more than one PCE - PCE becomes trigger for setting up and tearing down LSP (or at least is involved in this decision process) when reservation time elapses and the signaling controller fails performing this action - Preemption will become a required mechanism (based on the LSP priority) you would have to perform actions that are also impacting network stability - etc. at the end and more specifically the "pce architecture" document is not dealing with any kind of specific usage of the functional (and informational) element that are proposed but on the other side someone proposing a specific application has imho to demonstrate that the documented mechanisms will support this specific application, and i fail to see real rationales for the time being thanks, - dimitri. Lucy Yong 25/05/2006 15:58 To: "'JP Vasseur'" cc: pce@ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: RE: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi JP, Thank you for a good catch. See me response below. Regards, Lucy -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, May 25, 2006 6:16 AM To: Lucy Yong Cc: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be; pce@ietf.org Subject: Re: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi Lucy, On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > Hi Adrian, > > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation > needs to > go through it even the result could be saved in TED. Yes, although I would suggest you to be cautious here since there would be dangerous side-effect especially in situations where the PCE is not used by all nodes to compute TE LSP paths. [Lucy] Agree. I do not assume that either. PCE could be centralized or partial distributed. > I understand the TED > may be fed by IGP extensions or potentially by other means. This > other could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, > TED can > not compute the path either. Therefore, it needs to go through the > PCE. No > need to another path computation engine. It looks like you use a different terminology than in the IETF documents related to MPLS TE: -> By "reservation system" do you mean "Control plane used to establish the TE LSP (RSVP-TE)" ? -> TED never compute paths ... this is the topology database used to compute path [Lucy]: Sorry, use the wrong term. It should be inventory system. Inventory system is manually maintained resource system. With PCE based architecture, we only want one place to compute the path, that is the PCE. Therefore, no matter where the time-based reserved resource is stored, PCE should be the place to compute the path. Maybe someone could illustrate how the basic architecture model could accomplish this task. :) Thanks. JP. > > Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > I think that some of the confusion may be coming from the > definition of TED. > > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE > LSP > service request. > > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that > this TED is > exactly the database of TE information advertised by an IGP, and > that would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. > > Regards, > Adrian > > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> Payam, >> >> The draft specifies five architecture scenarios. Suggest adding >> one for >> time-based reservation. Giving the definition of TED, I don't see >> it can >> serve that function properly. >> TED contains topology and resource information from network. It >> may be >> embedded in NE. It is good to have a place to hold real network >> information >> and another place hold all reservations. You can flexibly apply >> policy to >> manage which bandwidth need to reserve ahead and which is only a >> book. It >> is >> hard to see the implementation done in TED. >> >> Lucy >> >> -----Original Message----- >> From: Payam Torab [mailto:ptorab@lopsys.com] >> Sent: Wednesday, May 24, 2006 2:31 PM >> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Lucy- >> >> What do you mean by "architecture scenario" below? I don't see any >> conflict >> between the current PCE architecture, and adding an element of >> time to >> path >> computation. You can certainly add time constraints to TED, as >> well as >> computation algorithms and support scheduling if you wish. >> >> You mention "It seems that current TED definition does not serve this >> function (scheduling)" - How is TED definition blocking you from >> scheduling? >> >> Thanks, >> Payam Torab >> >>> -----Original Message----- >>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>> Sent: Wednesday, May 24, 2006 3:11 PM >>> To: Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> >>> Hi Dimitri, >>> >>> Thank you for the comments. It is understood that the group >>> goal is to study IP communication protocols not network >>> architecture. However, they can not be completely separated. >>> Before we are clear about the architecture and its >>> components, we can't really specify the protocol, do we? The >>> suggestion here is to add another architecture scenario which >>> enables to support time-based reservation. I don't see this >>> impact the protocol study. It simply adds a value for PCE >>> based architecture. If we only study the protocols between >>> LSR-PCE and PCE-PCE, adding this scenario does not add >>> addition work at all. I don't see how this scenario impacts > >>> the scalability, performance, robustness and resiliency at >>> all. If it is, it is scared what we are doing here. >>> >>> Regards, >>> Lucy >>> >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:49 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> lucy - >>> >>> take a look at >>> >> col-gen-reqs-0 >>> 6.txt> >>> section 6.16, >>> >>> if there is a need to consider - as you wrote - that "PCE >>> should support >>> time-base reservation in the general >>> and leave as an option for carrier to implement or not." i >>> would like to >>> hear from operators specific rationales >>> to incorporate as part of the communication protocol / PCE >>> processing any >>> time constraint >>> >>> now more fundamentally and as stated the role of the group is >>> to define IP >>> communication protocols not network >>> architectures of some sort - reason for the suggestion made >>> on section 5 >>> >>> adrian mentions what is that inter-AS PCE is in scope, he >>> forgot probably >>> to mention to you that the primary >>> concerns of the work ongoing here is driven by four major concerns: >>> scalability, performance, robustness and >>> resiliency from this perspective any time constraint is going >>> to seriously >>> impact all these base objectives >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:33 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" , pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> Dimitri, >>> >>> Because for some important reservations, carrier want to >>> reserve the specific path for many purposes such as better >>> optimization, request >>> length >>> period, service guarantee, etc. >>> >>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>> elements? We >>> are >>> defining the architecture now. >>> >>> Adrian has mentioned that it is in PCE scope. >>> >>> Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:25 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> the question is why "time constraint" should be taken into >>> account during path computation that would justify >>> incorporation into the communication between LSR-PCE/PCE-PCE >>> elements >>> >>> scheduling of LSPs - themselves - is outside the scope of the >>> comm process between LSR-PCE/PCE-PCE elements, it is even >>> outside the scope of the PCE (since not a resource manager of >>> some sort) >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:08 >>> >>> To: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" >>> cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> All, >>> >>> Thank you for all the comments. >>> PCE should support time-base reservation in the general and >>> leave as an option for carrier to implement or not. If we >>> exclude this functionality, >>> it >>> is hard to see the full automatic network because there are >>> quite these kinds of service demands and carrier also >>> encourages the pre-order so they can proactively engineer the >>> network. I'll be glad to write an informational draft to >>> explain the possible mechanism and protocols. Weather the >>> function should be maintained in the same database or >>> separated databases, it would be better to see after >>> clarifying the functionality of each element first, and then >>> decide the solution. The service reservation database >>> mentioned here has a lot of information that PCE does not >>> need and has no responsibility to maintain them. Maybe some >>> cache mechanism could be used. Welcome anyone to provide the >>> input on the informational draft. >>> >>> Best Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Wednesday, May 24, 2006 11:11 AM >>> To: Meral Shirazipour; Lucy Yong >>> Cc: pce@ietf.org >>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Begging your pardon, Meral, but I'm a bit confused. >>> >>>> I agree with what you say here. This is a fact to consider >>>> especially >>> if >>> >>>> the >>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>> 'Internet'. >>>> What you say here is important if we consider the Internet peering >>> models. >>> >>> The architecture is already intended to be "adapted" for that >>> purpose. >>> Have >>> a quick read through the first few sections and you'll see ample >>> discussion >>> of inter-AS. >>> >>> Lucy's email seems to me to be about the time-based reservation of >>> resources. This doesn't seem to me to be outside the scope of >>> the current >>> architecture, but one might want to write down how PCE is >>> used for that >>> purpose as an informational draft. >>> >>> Personally, I would find Lucy's suggestion of a distinct >>> component and >>> database that was consulted for each computation request a >>> costly idea, >>> and >>> would prefer to see this type of function rolled into a >>> single database. >>> >>> Adrian >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 11:03:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHMz-00077U-Ek; Thu, 25 May 2006 11:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHMx-00077N-Vf for pce@ietf.org; Thu, 25 May 2006 11:03:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHMx-0000na-Dw for pce@ietf.org; Thu, 25 May 2006 11:03:23 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2006 11:03:23 -0400 X-IronPort-AV: i="4.05,173,1146456000"; d="scan'208"; a="89455613:sNHT36847592" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4PF3MvF004678; Thu, 25 May 2006 11:03:22 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 11:03:22 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 11:03:21 -0400 In-Reply-To: <000001c68003$4ee78210$d4087c0a@china.huawei.com> References: <000001c68003$4ee78210$d4087c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6446D04D-471B-43BF-B450-88BD85E89FDC@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Date: Thu, 25 May 2006 11:03:19 -0400 To: Lucy Yong X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 25 May 2006 15:03:21.0486 (UTC) FILETIME=[5CFFAAE0:01C6800C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: pce@ietf.org, Dimitri.Papadimitriou@alcatel.be X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Lucy, On May 25, 2006, at 9:58 AM, Lucy Yong wrote: > Hi JP, > > Thank you for a good catch. See me response below. > > Regards, > Lucy > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, May 25, 2006 6:16 AM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be; > pce@ietf.org > Subject: Re: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > >> Hi Adrian, >> >> Great explanation. Thanks. >> Since PCE is the only path computation engine, any path reservation >> needs to >> go through it even the result could be saved in TED. > > Yes, although I would suggest you to be cautious here since there > would be dangerous side-effect especially in situations where the PCE > is not used by all nodes to compute TE LSP paths. > > [Lucy] Agree. I do not assume that either. PCE could be centralized or > partial distributed. Again be cautious with the word "distributed"; this has been discussed on the list. You can refer to the definition provided in the document. > >> I understand the TED >> may be fed by IGP extensions or potentially by other means. This >> other could >> be the reservation system. However, the reservation system only has >> ingress >> and egress information, it does not have travel path information, >> TED can >> not compute the path either. Therefore, it needs to go through the >> PCE. No >> need to another path computation engine. > > It looks like you use a different terminology than in the IETF > documents related to MPLS TE: > -> By "reservation system" do you mean "Control plane used to > establish the TE LSP (RSVP-TE)" ? > -> TED never compute paths ... this is the topology database used to > compute path > > [Lucy]: Sorry, use the wrong term. It should be inventory system. > Inventory > system is manually maintained resource system. With PCE based > architecture, > we only want one place to compute the path, that is the PCE. > Therefore, no > matter where the time-based reserved resource is stored, PCE should > be the > place to compute the path. Maybe someone could illustrate how the > basic > architecture model could accomplish this task. :) Right. Note that our charter is limited to the PCE. Inventory system, NMS, ... are outside of our scope. Thanks. JP. > > Thanks. > > JP. > >> >> Regards, >> Lucy >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Wednesday, May 24, 2006 4:34 PM >> To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: What is the TED? Was: [Pce] Comments about >> draft-ietf-pce-architecture-05 >> >> Hi Lucy, >> >> I think that some of the confusion may be coming from the >> definition of TED. >> >> In the architecture I-D we have >> 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. >> and also >> ...a PCE would >> be able to compute the path of a TE LSP by operating on the TED >> and >> considering bandwidth and other constraints applicable to the TE >> LSP >> service request. >> >> This gives us the somewhat circular definition that the TED is the >> database >> on which PCE operates to compute TE paths. You might think that >> this TED is >> exactly the database of TE information advertised by an IGP, and >> that would >> be an entirely reasonable implementation, but the architecture and >> definitions deliberately allow the TED to be supplemented from other >> sources, or even created entirely from other sources. >> >> Regards, >> Adrian >> >> ----- Original Message ----- >> From: "Lucy Yong" >> To: "'Payam Torab'" ; >> >> Cc: >> Sent: Wednesday, May 24, 2006 9:48 PM >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> >>> Payam, >>> >>> The draft specifies five architecture scenarios. Suggest adding >>> one for >>> time-based reservation. Giving the definition of TED, I don't see >>> it can >>> serve that function properly. >>> TED contains topology and resource information from network. It >>> may be >>> embedded in NE. It is good to have a place to hold real network >>> information >>> and another place hold all reservations. You can flexibly apply >>> policy to >>> manage which bandwidth need to reserve ahead and which is only a >>> book. It >>> is >>> hard to see the implementation done in TED. >>> >>> Lucy >>> >>> -----Original Message----- >>> From: Payam Torab [mailto:ptorab@lopsys.com] >>> Sent: Wednesday, May 24, 2006 2:31 PM >>> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Lucy- >>> >>> What do you mean by "architecture scenario" below? I don't see any >>> conflict >>> between the current PCE architecture, and adding an element of >>> time to >>> path >>> computation. You can certainly add time constraints to TED, as >>> well as >>> computation algorithms and support scheduling if you wish. >>> >>> You mention "It seems that current TED definition does not serve >>> this >>> function (scheduling)" - How is TED definition blocking you from >>> scheduling? >>> >>> Thanks, >>> Payam Torab >>> >>>> -----Original Message----- >>>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>>> Sent: Wednesday, May 24, 2006 3:11 PM >>>> To: Dimitri.Papadimitriou@alcatel.be >>>> Cc: pce@ietf.org >>>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thank you for the comments. It is understood that the group >>>> goal is to study IP communication protocols not network >>>> architecture. However, they can not be completely separated. >>>> Before we are clear about the architecture and its >>>> components, we can't really specify the protocol, do we? The >>>> suggestion here is to add another architecture scenario which >>>> enables to support time-based reservation. I don't see this >>>> impact the protocol study. It simply adds a value for PCE >>>> based architecture. If we only study the protocols between >>>> LSR-PCE and PCE-PCE, adding this scenario does not add >>>> addition work at all. I don't see how this scenario impacts >> >>>> the scalability, performance, robustness and resiliency at >>>> all. If it is, it is scared what we are doing here. >>>> >>>> Regards, >>>> Lucy >>>> >>>> >>>> -----Original Message----- >>>> From: Dimitri.Papadimitriou@alcatel.be >>>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>>> Sent: Wednesday, May 24, 2006 12:49 PM >>>> To: Lucy Yong >>>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> lucy - >>>> >>>> take a look at >>>> >>> col-gen-reqs-0 >>>> 6.txt> >>>> section 6.16, >>>> >>>> if there is a need to consider - as you wrote - that "PCE >>>> should support >>>> time-base reservation in the general >>>> and leave as an option for carrier to implement or not." i >>>> would like to >>>> hear from operators specific rationales >>>> to incorporate as part of the communication protocol / PCE >>>> processing any >>>> time constraint >>>> >>>> now more fundamentally and as stated the role of the group is >>>> to define IP >>>> communication protocols not network >>>> architectures of some sort - reason for the suggestion made >>>> on section 5 >>>> >>>> adrian mentions what is that inter-AS PCE is in scope, he >>>> forgot probably >>>> to mention to you that the primary >>>> concerns of the work ongoing here is driven by four major concerns: >>>> scalability, performance, robustness and >>>> resiliency from this perspective any time constraint is going >>>> to seriously >>>> impact all these base objectives >>>> >>>> >>>> >>>> >>>> >>>> Lucy Yong >>>> 24/05/2006 19:33 >>>> >>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>> cc: "'Adrian Farrel'" , "'Meral >>>> Shirazipour'" , pce@ietf.org >>>> Subject: RE: [Pce] Comments about >>>> draft-ietf-pce-architecture-05 >>>> >>>> >>>> Dimitri, >>>> >>>> Because for some important reservations, carrier want to >>>> reserve the specific path for many purposes such as better >>>> optimization, request >>>> length >>>> period, service guarantee, etc. >>>> >>>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>>> elements? We >>>> are >>>> defining the architecture now. >>>> >>>> Adrian has mentioned that it is in PCE scope. >>>> >>>> Regards, >>>> Lucy >>>> >>>> -----Original Message----- >>>> From: Dimitri.Papadimitriou@alcatel.be >>>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>>> Sent: Wednesday, May 24, 2006 12:25 PM >>>> To: Lucy Yong >>>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> the question is why "time constraint" should be taken into >>>> account during path computation that would justify >>>> incorporation into the communication between LSR-PCE/PCE-PCE >>>> elements >>>> >>>> scheduling of LSPs - themselves - is outside the scope of the >>>> comm process between LSR-PCE/PCE-PCE elements, it is even >>>> outside the scope of the PCE (since not a resource manager of >>>> some sort) >>>> >>>> >>>> >>>> >>>> >>>> Lucy Yong >>>> 24/05/2006 19:08 >>>> >>>> To: "'Adrian Farrel'" , "'Meral >>>> Shirazipour'" >>>> cc: pce@ietf.org >>>> Subject: RE: [Pce] Comments about >>>> draft-ietf-pce-architecture-05 >>>> >>>> >>>> All, >>>> >>>> Thank you for all the comments. >>>> PCE should support time-base reservation in the general and >>>> leave as an option for carrier to implement or not. If we >>>> exclude this functionality, >>>> it >>>> is hard to see the full automatic network because there are >>>> quite these kinds of service demands and carrier also >>>> encourages the pre-order so they can proactively engineer the >>>> network. I'll be glad to write an informational draft to >>>> explain the possible mechanism and protocols. Weather the >>>> function should be maintained in the same database or >>>> separated databases, it would be better to see after >>>> clarifying the functionality of each element first, and then >>>> decide the solution. The service reservation database >>>> mentioned here has a lot of information that PCE does not >>>> need and has no responsibility to maintain them. Maybe some >>>> cache mechanism could be used. Welcome anyone to provide the >>>> input on the informational draft. >>>> >>>> Best Regards, >>>> Lucy >>>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Wednesday, May 24, 2006 11:11 AM >>>> To: Meral Shirazipour; Lucy Yong >>>> Cc: pce@ietf.org >>>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> Begging your pardon, Meral, but I'm a bit confused. >>>> >>>>> I agree with what you say here. This is a fact to consider >>>>> especially >>>> if >>>> >>>>> the >>>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>>> 'Internet'. >>>>> What you say here is important if we consider the Internet peering >>>> models. >>>> >>>> The architecture is already intended to be "adapted" for that >>>> purpose. >>>> Have >>>> a quick read through the first few sections and you'll see ample >>>> discussion >>>> of inter-AS. >>>> >>>> Lucy's email seems to me to be about the time-based reservation of >>>> resources. This doesn't seem to me to be outside the scope of >>>> the current >>>> architecture, but one might want to write down how PCE is >>>> used for that >>>> purpose as an informational draft. >>>> >>>> Personally, I would find Lucy's suggestion of a distinct >>>> component and >>>> database that was consulted for each computation request a >>>> costly idea, >>>> and >>>> would prefer to see this type of function rolled into a >>>> single database. >>>> >>>> Adrian >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 11:22:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHfZ-00077S-4A; Thu, 25 May 2006 11:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHfY-00077N-I6 for pce@ietf.org; Thu, 25 May 2006 11:22:36 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHfT-0002DZ-86 for pce@ietf.org; Thu, 25 May 2006 11:22:36 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZT00C47UJZ0Z@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 08:19:12 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZT00HLPUJTX3@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 08:19:11 -0700 (PDT) Date: Thu, 25 May 2006 10:22:14 -0500 From: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 In-reply-to: To: Dimitri.Papadimitriou@alcatel.be Message-id: <000101c6800f$00fe7a20$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Thank you for the concern. I did not expect the group come out a solution for this application now. All I want to say is that PCE based architecture could allow this kind of application compared to current NE based computation, which is value added for this architecture. Adding this application does require to add some features and protocols. Weather we want to solve in this group or not is debatable and depends on the peoples interests. There are five models in the basic architecture, but the group only focuses on LSR-PCE and PCE-PCE protocols not all functions architected. Therefore, why do you so much concern that showing the architecture capability to support this application will impact whole project scope? I could provide some information to show the importance of the application. People working in different areas have different views. As I mentioned, it is hard to see a large bandwidth demand or a permanent bandwidth demand will always be requested at time it needs. When the network and its management move to intelligent automatic management, it needs to have the capability to support the future reservation and we hope to have one place to do the path computation. Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, May 25, 2006 9:50 AM To: Lucy Yong Cc: 'JP Vasseur'; pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 lucy - this side discussion on TED is diverting from the (real) issue behind the initial proposal that has started this thread there is first a need to determine whether there is an interest behind this feature i.e. whether this would be addressing a real concern, and i have not seen anything similar in all the requirements document and discussion we had since so far now, assuming such requirement would pop up (i would be keen to see which applications we're speaking about here) there is a second phase that consists in assessing whether the PCE communication/entity is appropriate for processing such kind of information (side note: PCE does not perform any resource admission control nor performs any sort of resource reservation) and the impact this would have on the PCE mechanisms assumed since so far this because time based reservation / time constraint implies - network time synchronization for each resource reservation and for each LSP - the PCE that will have to take this constraint into account will also have to maintain (or obtain as information) for each reservation and for each LSP the time elapsed in order to be able to provide with the suitable answer to subsequent request (in brief, a computation will not have only to rely on the PRESENT state of the network resource reservation but also on PAST and FUTURE reservation) note: there is a side-effect on the signaling protocol mechanism as this breaks the idempotent behaviour of RSVP (for inst.) - PCEs will need to synchronize around that information during Path computation requests involving more than one PCE - PCE becomes trigger for setting up and tearing down LSP (or at least is involved in this decision process) when reservation time elapses and the signaling controller fails performing this action - Preemption will become a required mechanism (based on the LSP priority) you would have to perform actions that are also impacting network stability - etc. at the end and more specifically the "pce architecture" document is not dealing with any kind of specific usage of the functional (and informational) element that are proposed but on the other side someone proposing a specific application has imho to demonstrate that the documented mechanisms will support this specific application, and i fail to see real rationales for the time being thanks, - dimitri. Lucy Yong 25/05/2006 15:58 To: "'JP Vasseur'" cc: pce@ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: RE: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi JP, Thank you for a good catch. See me response below. Regards, Lucy -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, May 25, 2006 6:16 AM To: Lucy Yong Cc: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be; pce@ietf.org Subject: Re: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi Lucy, On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > Hi Adrian, > > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation > needs to > go through it even the result could be saved in TED. Yes, although I would suggest you to be cautious here since there would be dangerous side-effect especially in situations where the PCE is not used by all nodes to compute TE LSP paths. [Lucy] Agree. I do not assume that either. PCE could be centralized or partial distributed. > I understand the TED > may be fed by IGP extensions or potentially by other means. This > other could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, > TED can > not compute the path either. Therefore, it needs to go through the > PCE. No > need to another path computation engine. It looks like you use a different terminology than in the IETF documents related to MPLS TE: -> By "reservation system" do you mean "Control plane used to establish the TE LSP (RSVP-TE)" ? -> TED never compute paths ... this is the topology database used to compute path [Lucy]: Sorry, use the wrong term. It should be inventory system. Inventory system is manually maintained resource system. With PCE based architecture, we only want one place to compute the path, that is the PCE. Therefore, no matter where the time-based reserved resource is stored, PCE should be the place to compute the path. Maybe someone could illustrate how the basic architecture model could accomplish this task. :) Thanks. JP. > > Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > I think that some of the confusion may be coming from the > definition of TED. > > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE > LSP > service request. > > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that > this TED is > exactly the database of TE information advertised by an IGP, and > that would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. > > Regards, > Adrian > > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> Payam, >> >> The draft specifies five architecture scenarios. Suggest adding >> one for >> time-based reservation. Giving the definition of TED, I don't see >> it can >> serve that function properly. >> TED contains topology and resource information from network. It >> may be >> embedded in NE. It is good to have a place to hold real network >> information >> and another place hold all reservations. You can flexibly apply >> policy to >> manage which bandwidth need to reserve ahead and which is only a >> book. It >> is >> hard to see the implementation done in TED. >> >> Lucy >> >> -----Original Message----- >> From: Payam Torab [mailto:ptorab@lopsys.com] >> Sent: Wednesday, May 24, 2006 2:31 PM >> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Lucy- >> >> What do you mean by "architecture scenario" below? I don't see any >> conflict >> between the current PCE architecture, and adding an element of >> time to >> path >> computation. You can certainly add time constraints to TED, as >> well as >> computation algorithms and support scheduling if you wish. >> >> You mention "It seems that current TED definition does not serve this >> function (scheduling)" - How is TED definition blocking you from >> scheduling? >> >> Thanks, >> Payam Torab >> >>> -----Original Message----- >>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>> Sent: Wednesday, May 24, 2006 3:11 PM >>> To: Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> >>> Hi Dimitri, >>> >>> Thank you for the comments. It is understood that the group >>> goal is to study IP communication protocols not network >>> architecture. However, they can not be completely separated. >>> Before we are clear about the architecture and its >>> components, we can't really specify the protocol, do we? The >>> suggestion here is to add another architecture scenario which >>> enables to support time-based reservation. I don't see this >>> impact the protocol study. It simply adds a value for PCE >>> based architecture. If we only study the protocols between >>> LSR-PCE and PCE-PCE, adding this scenario does not add >>> addition work at all. I don't see how this scenario impacts > >>> the scalability, performance, robustness and resiliency at >>> all. If it is, it is scared what we are doing here. >>> >>> Regards, >>> Lucy >>> >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:49 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> lucy - >>> >>> take a look at >>> >> col-gen-reqs-0 >>> 6.txt> >>> section 6.16, >>> >>> if there is a need to consider - as you wrote - that "PCE >>> should support >>> time-base reservation in the general >>> and leave as an option for carrier to implement or not." i >>> would like to >>> hear from operators specific rationales >>> to incorporate as part of the communication protocol / PCE >>> processing any >>> time constraint >>> >>> now more fundamentally and as stated the role of the group is >>> to define IP >>> communication protocols not network >>> architectures of some sort - reason for the suggestion made >>> on section 5 >>> >>> adrian mentions what is that inter-AS PCE is in scope, he >>> forgot probably >>> to mention to you that the primary >>> concerns of the work ongoing here is driven by four major concerns: >>> scalability, performance, robustness and >>> resiliency from this perspective any time constraint is going >>> to seriously >>> impact all these base objectives >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:33 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" , pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> Dimitri, >>> >>> Because for some important reservations, carrier want to >>> reserve the specific path for many purposes such as better >>> optimization, request >>> length >>> period, service guarantee, etc. >>> >>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>> elements? We >>> are >>> defining the architecture now. >>> >>> Adrian has mentioned that it is in PCE scope. >>> >>> Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:25 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> the question is why "time constraint" should be taken into >>> account during path computation that would justify >>> incorporation into the communication between LSR-PCE/PCE-PCE >>> elements >>> >>> scheduling of LSPs - themselves - is outside the scope of the >>> comm process between LSR-PCE/PCE-PCE elements, it is even >>> outside the scope of the PCE (since not a resource manager of >>> some sort) >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:08 >>> >>> To: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" >>> cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> All, >>> >>> Thank you for all the comments. >>> PCE should support time-base reservation in the general and >>> leave as an option for carrier to implement or not. If we >>> exclude this functionality, >>> it >>> is hard to see the full automatic network because there are >>> quite these kinds of service demands and carrier also >>> encourages the pre-order so they can proactively engineer the >>> network. I'll be glad to write an informational draft to >>> explain the possible mechanism and protocols. Weather the >>> function should be maintained in the same database or >>> separated databases, it would be better to see after >>> clarifying the functionality of each element first, and then >>> decide the solution. The service reservation database >>> mentioned here has a lot of information that PCE does not >>> need and has no responsibility to maintain them. Maybe some >>> cache mechanism could be used. Welcome anyone to provide the >>> input on the informational draft. >>> >>> Best Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Wednesday, May 24, 2006 11:11 AM >>> To: Meral Shirazipour; Lucy Yong >>> Cc: pce@ietf.org >>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Begging your pardon, Meral, but I'm a bit confused. >>> >>>> I agree with what you say here. This is a fact to consider >>>> especially >>> if >>> >>>> the >>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>> 'Internet'. >>>> What you say here is important if we consider the Internet peering >>> models. >>> >>> The architecture is already intended to be "adapted" for that >>> purpose. >>> Have >>> a quick read through the first few sections and you'll see ample >>> discussion >>> of inter-AS. >>> >>> Lucy's email seems to me to be about the time-based reservation of >>> resources. This doesn't seem to me to be outside the scope of >>> the current >>> architecture, but one might want to write down how PCE is >>> used for that >>> purpose as an informational draft. >>> >>> Personally, I would find Lucy's suggestion of a distinct >>> component and >>> database that was consulted for each computation request a >>> costly idea, >>> and >>> would prefer to see this type of function rolled into a >>> single database. >>> >>> Adrian >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 11:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHtW-0000Cw-5q; Thu, 25 May 2006 11:37:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHtU-0000Cr-P6 for pce@ietf.org; Thu, 25 May 2006 11:37:00 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHtT-0003yd-Hl for pce@ietf.org; Thu, 25 May 2006 11:37:00 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZT00A6SV8ETJ@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 08:33:50 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZT00629V8425@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 08:33:50 -0700 (PDT) Date: Thu, 25 May 2006 10:36:48 -0500 From: Lucy Yong In-reply-to: <041c01c67f7d$368da590$0a23fea9@your029b8cecfe> To: 'Adrian Farrel' Message-id: <000401c68011$0d12e7e0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: pce@ietf.org Subject: [Pce] RE: Comments about draft-ietf-pce-architecture-05 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Adrian, Let's put down the time-based reservation for now. I have another comment about the draft. In the Figure 5, it shows that NMS will send request to PCE directly to get the path information and send service request to the head-end node. The request flow seems different from other the four models. Is it better to keep the consistency? We could have NMS based service request to go head-end node first and let head-end node send request to PCE, thus all models will have the same message flows. Does this make sense? Regards, Lucy _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 11:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHyv-00032m-8T; Thu, 25 May 2006 11:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHyu-00032h-2f for pce@ietf.org; Thu, 25 May 2006 11:42:36 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHyt-0004Hh-31 for pce@ietf.org; Thu, 25 May 2006 11:42:36 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4PFdFv0032263; Thu, 25 May 2006 17:39:15 +0200 In-Reply-To: <000101c6800f$00fe7a20$d4087c0a@china.huawei.com> To: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 25 May 2006 17:39:04 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/25/2006 17:39:14, Serialize complete at 05/25/2006 17:39:14 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: ba231eeb0ba293f319cac22693e776bc Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org lucy > There are five models in the basic architecture, but the group > only focuses on LSR-PCE and PCE-PCE protocols not all functions architected. indeed (because the other entities are outside the scope) > Therefore, why do you so much concern that showing the architecture > capability to support this application will impact whole project scope? for the reasons explained in my previous post - without clear answers to these issues (that are going to impact the whole approach) i don't see how you could progress > When the network and its management move to intelligent automatic management, > it needs to have the capability to support the future reservation and we hope > to have one place to do the path computation. probably ... but if you are intricating "reservation time" in the path computation request you are de-facto going to introduce resource resv. which is beyond scope of path computation i can understand that some NRENs, research nets, etc. are looking at LSP / resource scheduling functionality (... the mythical resource broker) for single domain application specific networks but PCE is not meant to incorporate such functionality thanks, - d. Lucy Yong 25/05/2006 17:22 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "'JP Vasseur'" , pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 Hi Dimitri, Thank you for the concern. I did not expect the group come out a solution for this application now. All I want to say is that PCE based architecture could allow this kind of application compared to current NE based computation, which is value added for this architecture. Adding this application does require to add some features and protocols. Weather we want to solve in this group or not is debatable and depends on the peoples interests. There are five models in the basic architecture, but the group only focuses on LSR-PCE and PCE-PCE protocols not all functions architected. Therefore, why do you so much concern that showing the architecture capability to support this application will impact whole project scope? I could provide some information to show the importance of the application. People working in different areas have different views. As I mentioned, it is hard to see a large bandwidth demand or a permanent bandwidth demand will always be requested at time it needs. When the network and its management move to intelligent automatic management, it needs to have the capability to support the future reservation and we hope to have one place to do the path computation. Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, May 25, 2006 9:50 AM To: Lucy Yong Cc: 'JP Vasseur'; pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 lucy - this side discussion on TED is diverting from the (real) issue behind the initial proposal that has started this thread there is first a need to determine whether there is an interest behind this feature i.e. whether this would be addressing a real concern, and i have not seen anything similar in all the requirements document and discussion we had since so far now, assuming such requirement would pop up (i would be keen to see which applications we're speaking about here) there is a second phase that consists in assessing whether the PCE communication/entity is appropriate for processing such kind of information (side note: PCE does not perform any resource admission control nor performs any sort of resource reservation) and the impact this would have on the PCE mechanisms assumed since so far this because time based reservation / time constraint implies - network time synchronization for each resource reservation and for each LSP - the PCE that will have to take this constraint into account will also have to maintain (or obtain as information) for each reservation and for each LSP the time elapsed in order to be able to provide with the suitable answer to subsequent request (in brief, a computation will not have only to rely on the PRESENT state of the network resource reservation but also on PAST and FUTURE reservation) note: there is a side-effect on the signaling protocol mechanism as this breaks the idempotent behaviour of RSVP (for inst.) - PCEs will need to synchronize around that information during Path computation requests involving more than one PCE - PCE becomes trigger for setting up and tearing down LSP (or at least is involved in this decision process) when reservation time elapses and the signaling controller fails performing this action - Preemption will become a required mechanism (based on the LSP priority) you would have to perform actions that are also impacting network stability - etc. at the end and more specifically the "pce architecture" document is not dealing with any kind of specific usage of the functional (and informational) element that are proposed but on the other side someone proposing a specific application has imho to demonstrate that the documented mechanisms will support this specific application, and i fail to see real rationales for the time being thanks, - dimitri. Lucy Yong 25/05/2006 15:58 To: "'JP Vasseur'" cc: pce@ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: RE: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi JP, Thank you for a good catch. See me response below. Regards, Lucy -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, May 25, 2006 6:16 AM To: Lucy Yong Cc: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be; pce@ietf.org Subject: Re: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi Lucy, On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > Hi Adrian, > > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation > needs to > go through it even the result could be saved in TED. Yes, although I would suggest you to be cautious here since there would be dangerous side-effect especially in situations where the PCE is not used by all nodes to compute TE LSP paths. [Lucy] Agree. I do not assume that either. PCE could be centralized or partial distributed. > I understand the TED > may be fed by IGP extensions or potentially by other means. This > other could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, > TED can > not compute the path either. Therefore, it needs to go through the > PCE. No > need to another path computation engine. It looks like you use a different terminology than in the IETF documents related to MPLS TE: -> By "reservation system" do you mean "Control plane used to establish the TE LSP (RSVP-TE)" ? -> TED never compute paths ... this is the topology database used to compute path [Lucy]: Sorry, use the wrong term. It should be inventory system. Inventory system is manually maintained resource system. With PCE based architecture, we only want one place to compute the path, that is the PCE. Therefore, no matter where the time-based reserved resource is stored, PCE should be the place to compute the path. Maybe someone could illustrate how the basic architecture model could accomplish this task. :) Thanks. JP. > > Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > I think that some of the confusion may be coming from the > definition of TED. > > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE > LSP > service request. > > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that > this TED is > exactly the database of TE information advertised by an IGP, and > that would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. > > Regards, > Adrian > > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> Payam, >> >> The draft specifies five architecture scenarios. Suggest adding >> one for >> time-based reservation. Giving the definition of TED, I don't see >> it can >> serve that function properly. >> TED contains topology and resource information from network. It >> may be >> embedded in NE. It is good to have a place to hold real network >> information >> and another place hold all reservations. You can flexibly apply >> policy to >> manage which bandwidth need to reserve ahead and which is only a >> book. It >> is >> hard to see the implementation done in TED. >> >> Lucy >> >> -----Original Message----- >> From: Payam Torab [mailto:ptorab@lopsys.com] >> Sent: Wednesday, May 24, 2006 2:31 PM >> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Lucy- >> >> What do you mean by "architecture scenario" below? I don't see any >> conflict >> between the current PCE architecture, and adding an element of >> time to >> path >> computation. You can certainly add time constraints to TED, as >> well as >> computation algorithms and support scheduling if you wish. >> >> You mention "It seems that current TED definition does not serve this >> function (scheduling)" - How is TED definition blocking you from >> scheduling? >> >> Thanks, >> Payam Torab >> >>> -----Original Message----- >>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>> Sent: Wednesday, May 24, 2006 3:11 PM >>> To: Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> >>> Hi Dimitri, >>> >>> Thank you for the comments. It is understood that the group >>> goal is to study IP communication protocols not network >>> architecture. However, they can not be completely separated. >>> Before we are clear about the architecture and its >>> components, we can't really specify the protocol, do we? The >>> suggestion here is to add another architecture scenario which >>> enables to support time-based reservation. I don't see this >>> impact the protocol study. It simply adds a value for PCE >>> based architecture. If we only study the protocols between >>> LSR-PCE and PCE-PCE, adding this scenario does not add >>> addition work at all. I don't see how this scenario impacts > >>> the scalability, performance, robustness and resiliency at >>> all. If it is, it is scared what we are doing here. >>> >>> Regards, >>> Lucy >>> >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:49 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> lucy - >>> >>> take a look at >>> >> col-gen-reqs-0 >>> 6.txt> >>> section 6.16, >>> >>> if there is a need to consider - as you wrote - that "PCE >>> should support >>> time-base reservation in the general >>> and leave as an option for carrier to implement or not." i >>> would like to >>> hear from operators specific rationales >>> to incorporate as part of the communication protocol / PCE >>> processing any >>> time constraint >>> >>> now more fundamentally and as stated the role of the group is >>> to define IP >>> communication protocols not network >>> architectures of some sort - reason for the suggestion made >>> on section 5 >>> >>> adrian mentions what is that inter-AS PCE is in scope, he >>> forgot probably >>> to mention to you that the primary >>> concerns of the work ongoing here is driven by four major concerns: >>> scalability, performance, robustness and >>> resiliency from this perspective any time constraint is going >>> to seriously >>> impact all these base objectives >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:33 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" , pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> Dimitri, >>> >>> Because for some important reservations, carrier want to >>> reserve the specific path for many purposes such as better >>> optimization, request >>> length >>> period, service guarantee, etc. >>> >>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>> elements? We >>> are >>> defining the architecture now. >>> >>> Adrian has mentioned that it is in PCE scope. >>> >>> Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:25 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> the question is why "time constraint" should be taken into >>> account during path computation that would justify >>> incorporation into the communication between LSR-PCE/PCE-PCE >>> elements >>> >>> scheduling of LSPs - themselves - is outside the scope of the >>> comm process between LSR-PCE/PCE-PCE elements, it is even >>> outside the scope of the PCE (since not a resource manager of >>> some sort) >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:08 >>> >>> To: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" >>> cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> All, >>> >>> Thank you for all the comments. >>> PCE should support time-base reservation in the general and >>> leave as an option for carrier to implement or not. If we >>> exclude this functionality, >>> it >>> is hard to see the full automatic network because there are >>> quite these kinds of service demands and carrier also >>> encourages the pre-order so they can proactively engineer the >>> network. I'll be glad to write an informational draft to >>> explain the possible mechanism and protocols. Weather the >>> function should be maintained in the same database or >>> separated databases, it would be better to see after >>> clarifying the functionality of each element first, and then >>> decide the solution. The service reservation database >>> mentioned here has a lot of information that PCE does not >>> need and has no responsibility to maintain them. Maybe some >>> cache mechanism could be used. Welcome anyone to provide the >>> input on the informational draft. >>> >>> Best Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Wednesday, May 24, 2006 11:11 AM >>> To: Meral Shirazipour; Lucy Yong >>> Cc: pce@ietf.org >>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Begging your pardon, Meral, but I'm a bit confused. >>> >>>> I agree with what you say here. This is a fact to consider >>>> especially >>> if >>> >>>> the >>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>> 'Internet'. >>>> What you say here is important if we consider the Internet peering >>> models. >>> >>> The architecture is already intended to be "adapted" for that >>> purpose. >>> Have >>> a quick read through the first few sections and you'll see ample >>> discussion >>> of inter-AS. >>> >>> Lucy's email seems to me to be about the time-based reservation of >>> resources. This doesn't seem to me to be outside the scope of >>> the current >>> architecture, but one might want to write down how PCE is >>> used for that >>> purpose as an informational draft. >>> >>> Personally, I would find Lucy's suggestion of a distinct >>> component and >>> database that was consulted for each computation request a >>> costly idea, >>> and >>> would prefer to see this type of function rolled into a >>> single database. >>> >>> Adrian >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 12:22:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIap-00073S-CV; Thu, 25 May 2006 12:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIan-00073N-LM for pce@ietf.org; Thu, 25 May 2006 12:21:45 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjIam-0006la-MN for pce@ietf.org; Thu, 25 May 2006 12:21:45 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZT00A0QXAKTJ@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 09:18:20 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZT009CRXA8W2@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 09:18:20 -0700 (PDT) Date: Thu, 25 May 2006 11:21:16 -0500 From: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 In-reply-to: To: Dimitri.Papadimitriou@alcatel.be Message-id: <000a01c68017$43ade1f0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7ddf3da2e36bf1816c08a54f16fcec30 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dimitri, I see your points. Since PCE based architecture opens a lot of potential compared to NE based path computation. Although the group only focus on the basic communication capability between LSR and PCE, it may be not necessary to conclude that the group will not study this in the future if this is convinced as an important functionality. Does IETF require closing the group when it finishes the charter goal? Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, May 25, 2006 10:39 AM To: Lucy Yong Cc: 'JP Vasseur'; pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 lucy > There are five models in the basic architecture, but the group > only focuses on LSR-PCE and PCE-PCE protocols not all functions architected. indeed (because the other entities are outside the scope) > Therefore, why do you so much concern that showing the architecture > capability to support this application will impact whole project scope? for the reasons explained in my previous post - without clear answers to these issues (that are going to impact the whole approach) i don't see how you could progress > When the network and its management move to intelligent automatic management, > it needs to have the capability to support the future reservation and we hope > to have one place to do the path computation. probably ... but if you are intricating "reservation time" in the path computation request you are de-facto going to introduce resource resv. which is beyond scope of path computation i can understand that some NRENs, research nets, etc. are looking at LSP / resource scheduling functionality (... the mythical resource broker) for single domain application specific networks but PCE is not meant to incorporate such functionality thanks, - d. Lucy Yong 25/05/2006 17:22 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "'JP Vasseur'" , pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 Hi Dimitri, Thank you for the concern. I did not expect the group come out a solution for this application now. All I want to say is that PCE based architecture could allow this kind of application compared to current NE based computation, which is value added for this architecture. Adding this application does require to add some features and protocols. Weather we want to solve in this group or not is debatable and depends on the peoples interests. There are five models in the basic architecture, but the group only focuses on LSR-PCE and PCE-PCE protocols not all functions architected. Therefore, why do you so much concern that showing the architecture capability to support this application will impact whole project scope? I could provide some information to show the importance of the application. People working in different areas have different views. As I mentioned, it is hard to see a large bandwidth demand or a permanent bandwidth demand will always be requested at time it needs. When the network and its management move to intelligent automatic management, it needs to have the capability to support the future reservation and we hope to have one place to do the path computation. Regards, Lucy -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, May 25, 2006 9:50 AM To: Lucy Yong Cc: 'JP Vasseur'; pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 lucy - this side discussion on TED is diverting from the (real) issue behind the initial proposal that has started this thread there is first a need to determine whether there is an interest behind this feature i.e. whether this would be addressing a real concern, and i have not seen anything similar in all the requirements document and discussion we had since so far now, assuming such requirement would pop up (i would be keen to see which applications we're speaking about here) there is a second phase that consists in assessing whether the PCE communication/entity is appropriate for processing such kind of information (side note: PCE does not perform any resource admission control nor performs any sort of resource reservation) and the impact this would have on the PCE mechanisms assumed since so far this because time based reservation / time constraint implies - network time synchronization for each resource reservation and for each LSP - the PCE that will have to take this constraint into account will also have to maintain (or obtain as information) for each reservation and for each LSP the time elapsed in order to be able to provide with the suitable answer to subsequent request (in brief, a computation will not have only to rely on the PRESENT state of the network resource reservation but also on PAST and FUTURE reservation) note: there is a side-effect on the signaling protocol mechanism as this breaks the idempotent behaviour of RSVP (for inst.) - PCEs will need to synchronize around that information during Path computation requests involving more than one PCE - PCE becomes trigger for setting up and tearing down LSP (or at least is involved in this decision process) when reservation time elapses and the signaling controller fails performing this action - Preemption will become a required mechanism (based on the LSP priority) you would have to perform actions that are also impacting network stability - etc. at the end and more specifically the "pce architecture" document is not dealing with any kind of specific usage of the functional (and informational) element that are proposed but on the other side someone proposing a specific application has imho to demonstrate that the documented mechanisms will support this specific application, and i fail to see real rationales for the time being thanks, - dimitri. Lucy Yong 25/05/2006 15:58 To: "'JP Vasseur'" cc: pce@ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: RE: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi JP, Thank you for a good catch. See me response below. Regards, Lucy -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, May 25, 2006 6:16 AM To: Lucy Yong Cc: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be; pce@ietf.org Subject: Re: What is the TED? Was: [Pce] Comments about draft-ietf-pce-architecture-05 Hi Lucy, On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > Hi Adrian, > > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation > needs to > go through it even the result could be saved in TED. Yes, although I would suggest you to be cautious here since there would be dangerous side-effect especially in situations where the PCE is not used by all nodes to compute TE LSP paths. [Lucy] Agree. I do not assume that either. PCE could be centralized or partial distributed. > I understand the TED > may be fed by IGP extensions or potentially by other means. This > other could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, > TED can > not compute the path either. Therefore, it needs to go through the > PCE. No > need to another path computation engine. It looks like you use a different terminology than in the IETF documents related to MPLS TE: -> By "reservation system" do you mean "Control plane used to establish the TE LSP (RSVP-TE)" ? -> TED never compute paths ... this is the topology database used to compute path [Lucy]: Sorry, use the wrong term. It should be inventory system. Inventory system is manually maintained resource system. With PCE based architecture, we only want one place to compute the path, that is the PCE. Therefore, no matter where the time-based reserved resource is stored, PCE should be the place to compute the path. Maybe someone could illustrate how the basic architecture model could accomplish this task. :) Thanks. JP. > > Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > I think that some of the confusion may be coming from the > definition of TED. > > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE > LSP > service request. > > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that > this TED is > exactly the database of TE information advertised by an IGP, and > that would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. > > Regards, > Adrian > > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> Payam, >> >> The draft specifies five architecture scenarios. Suggest adding >> one for >> time-based reservation. Giving the definition of TED, I don't see >> it can >> serve that function properly. >> TED contains topology and resource information from network. It >> may be >> embedded in NE. It is good to have a place to hold real network >> information >> and another place hold all reservations. You can flexibly apply >> policy to >> manage which bandwidth need to reserve ahead and which is only a >> book. It >> is >> hard to see the implementation done in TED. >> >> Lucy >> >> -----Original Message----- >> From: Payam Torab [mailto:ptorab@lopsys.com] >> Sent: Wednesday, May 24, 2006 2:31 PM >> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> Lucy- >> >> What do you mean by "architecture scenario" below? I don't see any >> conflict >> between the current PCE architecture, and adding an element of >> time to >> path >> computation. You can certainly add time constraints to TED, as >> well as >> computation algorithms and support scheduling if you wish. >> >> You mention "It seems that current TED definition does not serve this >> function (scheduling)" - How is TED definition blocking you from >> scheduling? >> >> Thanks, >> Payam Torab >> >>> -----Original Message----- >>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>> Sent: Wednesday, May 24, 2006 3:11 PM >>> To: Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> >>> Hi Dimitri, >>> >>> Thank you for the comments. It is understood that the group >>> goal is to study IP communication protocols not network >>> architecture. However, they can not be completely separated. >>> Before we are clear about the architecture and its >>> components, we can't really specify the protocol, do we? The >>> suggestion here is to add another architecture scenario which >>> enables to support time-based reservation. I don't see this >>> impact the protocol study. It simply adds a value for PCE >>> based architecture. If we only study the protocols between >>> LSR-PCE and PCE-PCE, adding this scenario does not add >>> addition work at all. I don't see how this scenario impacts > >>> the scalability, performance, robustness and resiliency at >>> all. If it is, it is scared what we are doing here. >>> >>> Regards, >>> Lucy >>> >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:49 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> lucy - >>> >>> take a look at >>> >> col-gen-reqs-0 >>> 6.txt> >>> section 6.16, >>> >>> if there is a need to consider - as you wrote - that "PCE >>> should support >>> time-base reservation in the general >>> and leave as an option for carrier to implement or not." i >>> would like to >>> hear from operators specific rationales >>> to incorporate as part of the communication protocol / PCE >>> processing any >>> time constraint >>> >>> now more fundamentally and as stated the role of the group is >>> to define IP >>> communication protocols not network >>> architectures of some sort - reason for the suggestion made >>> on section 5 >>> >>> adrian mentions what is that inter-AS PCE is in scope, he >>> forgot probably >>> to mention to you that the primary >>> concerns of the work ongoing here is driven by four major concerns: >>> scalability, performance, robustness and >>> resiliency from this perspective any time constraint is going >>> to seriously >>> impact all these base objectives >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:33 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" , pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> Dimitri, >>> >>> Because for some important reservations, carrier want to >>> reserve the specific path for many purposes such as better >>> optimization, request >>> length >>> period, service guarantee, etc. >>> >>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>> elements? We >>> are >>> defining the architecture now. >>> >>> Adrian has mentioned that it is in PCE scope. >>> >>> Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Sent: Wednesday, May 24, 2006 12:25 PM >>> To: Lucy Yong >>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> the question is why "time constraint" should be taken into >>> account during path computation that would justify >>> incorporation into the communication between LSR-PCE/PCE-PCE >>> elements >>> >>> scheduling of LSPs - themselves - is outside the scope of the >>> comm process between LSR-PCE/PCE-PCE elements, it is even >>> outside the scope of the PCE (since not a resource manager of >>> some sort) >>> >>> >>> >>> >>> >>> Lucy Yong >>> 24/05/2006 19:08 >>> >>> To: "'Adrian Farrel'" , "'Meral >>> Shirazipour'" >>> cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about >>> draft-ietf-pce-architecture-05 >>> >>> >>> All, >>> >>> Thank you for all the comments. >>> PCE should support time-base reservation in the general and >>> leave as an option for carrier to implement or not. If we >>> exclude this functionality, >>> it >>> is hard to see the full automatic network because there are >>> quite these kinds of service demands and carrier also >>> encourages the pre-order so they can proactively engineer the >>> network. I'll be glad to write an informational draft to >>> explain the possible mechanism and protocols. Weather the >>> function should be maintained in the same database or >>> separated databases, it would be better to see after >>> clarifying the functionality of each element first, and then >>> decide the solution. The service reservation database >>> mentioned here has a lot of information that PCE does not >>> need and has no responsibility to maintain them. Maybe some >>> cache mechanism could be used. Welcome anyone to provide the >>> input on the informational draft. >>> >>> Best Regards, >>> Lucy >>> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Wednesday, May 24, 2006 11:11 AM >>> To: Meral Shirazipour; Lucy Yong >>> Cc: pce@ietf.org >>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Begging your pardon, Meral, but I'm a bit confused. >>> >>>> I agree with what you say here. This is a fact to consider >>>> especially >>> if >>> >>>> the >>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>> 'Internet'. >>>> What you say here is important if we consider the Internet peering >>> models. >>> >>> The architecture is already intended to be "adapted" for that >>> purpose. >>> Have >>> a quick read through the first few sections and you'll see ample >>> discussion >>> of inter-AS. >>> >>> Lucy's email seems to me to be about the time-based reservation of >>> resources. This doesn't seem to me to be outside the scope of >>> the current >>> architecture, but one might want to write down how PCE is >>> used for that >>> purpose as an informational draft. >>> >>> Personally, I would find Lucy's suggestion of a distinct >>> component and >>> database that was consulted for each computation request a >>> costly idea, >>> and >>> would prefer to see this type of function rolled into a >>> single database. >>> >>> Adrian >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 14:34:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKej-0006zU-ME; Thu, 25 May 2006 14:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKei-0006zP-5S for pce@ietf.org; Thu, 25 May 2006 14:33:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKei-00021p-3w for pce@ietf.org; Thu, 25 May 2006 14:33:56 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjKeg-0003Yp-Bg for pce@ietf.org; Thu, 25 May 2006 14:33:56 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k4PIXnLB009555; Thu, 25 May 2006 14:33:49 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28166; Thu, 25 May 2006 14:33:48 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 25 May 2006 14:33:48 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0E248932@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: Lucy Yong , "'Adrian Farrel'" Subject: RE: [Pce] RE: Comments about draft-ietf-pce-architecture-05 Date: Thu, 25 May 2006 14:33:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Lucy, Figure 5 is specifically trying to show a different flow. In earlier figures, the source of a service request is not shown. In general, however, one likely source for a service request is an NMS. I think the difference we may be trying to show in figure 5 is that an NMS may act as a PCC on behalf of a head-end that may not be a PCC itself. -- Eric --> -----Original Message----- --> From: Lucy Yong [mailto:lucyyong@huawei.com] --> Sent: Thursday, May 25, 2006 11:37 AM --> To: 'Adrian Farrel' --> Cc: pce@ietf.org --> Subject: [Pce] RE: Comments about draft-ietf-pce-architecture-05 --> --> Adrian, --> --> Let's put down the time-based reservation for now. I have --> another comment --> about the draft. In the Figure 5, it shows that NMS will --> send request to PCE --> directly to get the path information and send service request to the --> head-end node. The request flow seems different from other --> the four models. --> Is it better to keep the consistency? --> We could have NMS based service request to go head-end node --> first and let --> head-end node send request to PCE, thus all models will --> have the same --> message flows. --> Does this make sense? --> --> Regards, --> Lucy --> --> --> --> _______________________________________________ --> Pce mailing list --> Pce@lists.ietf.org --> https://www1.ietf.org/mailman/listinfo/pce --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 14:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKid-0000UG-F4; Thu, 25 May 2006 14:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKib-0000Ng-Vf for pce@ietf.org; Thu, 25 May 2006 14:37:57 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKiX-0002eD-9K for pce@ietf.org; Thu, 25 May 2006 14:37:57 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA14523; Thu, 25 May 2006 11:37:36 -0700 (PDT) Received: from XCH-SW-40P.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4PIbZ300960; Thu, 25 May 2006 13:37:35 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SW-40P.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 11:37:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 Date: Thu, 25 May 2006 11:37:34 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2D9A8@XCH-SW-42.sw.nos.boeing.com> In-Reply-To: <006801c67f7e$71e90020$d4087c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 Thread-Index: AcZ/gaQQmewQG5t/R4mhQIWXcguxbAAp3TOg From: "Drake, John E" To: "Lucy Yong" , "Adrian Farrel" , "Payam Torab" , X-OriginalArrivalTime: 25 May 2006 18:37:34.0959 (UTC) FILETIME=[4A43FFF0:01C6802A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, I had a clarification question. Isn't it the case that it is a matter of policy whether a given node uses a PCE or computes/expands the ERO itself? If so, then I think time-based may be problematic as the PCE operating in the future domain will have no idea of the EROs that will be computed in the future by the nodes not using the PCE. Thanks, John=20 > -----Original Message----- > From: Lucy Yong [mailto:lucyyong@huawei.com] > Sent: Wednesday, May 24, 2006 3:07 PM > To: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce- > architecture-05 >=20 > Hi Adrian, >=20 > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation needs > to > go through it even the result could be saved in TED. I understand the TED > may be fed by IGP extensions or potentially by other means. This other > could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, TED can > not compute the path either. Therefore, it needs to go through the PCE. No > need to another path computation engine. >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 >=20 > Hi Lucy, >=20 > I think that some of the confusion may be coming from the definition of > TED. >=20 > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE LSP > service request. >=20 > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that this TED > is > exactly the database of TE information advertised by an IGP, and that > would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. >=20 > Regards, > Adrian >=20 > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >=20 >=20 > > Payam, > > > > The draft specifies five architecture scenarios. Suggest adding one for > > time-based reservation. Giving the definition of TED, I don't see it can > > serve that function properly. > > TED contains topology and resource information from network. It may be > > embedded in NE. It is good to have a place to hold real network > > information > > and another place hold all reservations. You can flexibly apply policy > to > > manage which bandwidth need to reserve ahead and which is only a book. > It > > is > > hard to see the implementation done in TED. > > > > Lucy > > > > -----Original Message----- > > From: Payam Torab [mailto:ptorab@lopsys.com] > > Sent: Wednesday, May 24, 2006 2:31 PM > > To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be > > Cc: pce@ietf.org > > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > > Lucy- > > > > What do you mean by "architecture scenario" below? I don't see any > > conflict > > between the current PCE architecture, and adding an element of time to > > path > > computation. You can certainly add time constraints to TED, as well as > > computation algorithms and support scheduling if you wish. > > > > You mention "It seems that current TED definition does not serve this > > function (scheduling)" - How is TED definition blocking you from > > scheduling? > > > > Thanks, > > Payam Torab > > > >> -----Original Message----- > >> From: Lucy Yong [mailto:lucyyong@huawei.com] > >> Sent: Wednesday, May 24, 2006 3:11 PM > >> To: Dimitri.Papadimitriou@alcatel.be > >> Cc: pce@ietf.org > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> > >> Hi Dimitri, > >> > >> Thank you for the comments. It is understood that the group > >> goal is to study IP communication protocols not network > >> architecture. However, they can not be completely separated. > >> Before we are clear about the architecture and its > >> components, we can't really specify the protocol, do we? The > >> suggestion here is to add another architecture scenario which > >> enables to support time-based reservation. I don't see this > >> impact the protocol study. It simply adds a value for PCE > >> based architecture. If we only study the protocols between > >> LSR-PCE and PCE-PCE, adding this scenario does not add > >> addition work at all. I don't see how this scenario impacts >=20 > >> the scalability, performance, robustness and resiliency at > >> all. If it is, it is scared what we are doing here. > >> > >> Regards, > >> Lucy > >> > >> > >> -----Original Message----- > >> From: Dimitri.Papadimitriou@alcatel.be > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > >> Sent: Wednesday, May 24, 2006 12:49 PM > >> To: Lucy Yong > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> lucy - > >> > >> take a look at > >> >> col-gen-reqs-0 > >> 6.txt> > >> section 6.16, > >> > >> if there is a need to consider - as you wrote - that "PCE > >> should support > >> time-base reservation in the general > >> and leave as an option for carrier to implement or not." i > >> would like to > >> hear from operators specific rationales > >> to incorporate as part of the communication protocol / PCE > >> processing any > >> time constraint > >> > >> now more fundamentally and as stated the role of the group is > >> to define IP > >> communication protocols not network > >> architectures of some sort - reason for the suggestion made > >> on section 5 > >> > >> adrian mentions what is that inter-AS PCE is in scope, he > >> forgot probably > >> to mention to you that the primary > >> concerns of the work ongoing here is driven by four major concerns: > >> scalability, performance, robustness and > >> resiliency from this perspective any time constraint is going > >> to seriously > >> impact all these base objectives > >> > >> > >> > >> > >> > >> Lucy Yong > >> 24/05/2006 19:33 > >> > >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > >> cc: "'Adrian Farrel'" , "'Meral > >> Shirazipour'" , pce@ietf.org > >> Subject: RE: [Pce] Comments about > >> draft-ietf-pce-architecture-05 > >> > >> > >> Dimitri, > >> > >> Because for some important reservations, carrier want to > >> reserve the specific path for many purposes such as better > >> optimization, request > >> length > >> period, service guarantee, etc. > >> > >> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE > >> elements? We > >> are > >> defining the architecture now. > >> > >> Adrian has mentioned that it is in PCE scope. > >> > >> Regards, > >> Lucy > >> > >> -----Original Message----- > >> From: Dimitri.Papadimitriou@alcatel.be > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > >> Sent: Wednesday, May 24, 2006 12:25 PM > >> To: Lucy Yong > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> the question is why "time constraint" should be taken into > >> account during path computation that would justify > >> incorporation into the communication between LSR-PCE/PCE-PCE elements > >> > >> scheduling of LSPs - themselves - is outside the scope of the > >> comm process between LSR-PCE/PCE-PCE elements, it is even > >> outside the scope of the PCE (since not a resource manager of > >> some sort) > >> > >> > >> > >> > >> > >> Lucy Yong > >> 24/05/2006 19:08 > >> > >> To: "'Adrian Farrel'" , "'Meral > >> Shirazipour'" > >> cc: pce@ietf.org > >> Subject: RE: [Pce] Comments about > >> draft-ietf-pce-architecture-05 > >> > >> > >> All, > >> > >> Thank you for all the comments. > >> PCE should support time-base reservation in the general and > >> leave as an option for carrier to implement or not. If we > >> exclude this functionality, > >> it > >> is hard to see the full automatic network because there are > >> quite these kinds of service demands and carrier also > >> encourages the pre-order so they can proactively engineer the > >> network. I'll be glad to write an informational draft to > >> explain the possible mechanism and protocols. Weather the > >> function should be maintained in the same database or > >> separated databases, it would be better to see after > >> clarifying the functionality of each element first, and then > >> decide the solution. The service reservation database > >> mentioned here has a lot of information that PCE does not > >> need and has no responsibility to maintain them. Maybe some > >> cache mechanism could be used. Welcome anyone to provide the > >> input on the informational draft. > >> > >> Best Regards, > >> Lucy > >> > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Wednesday, May 24, 2006 11:11 AM > >> To: Meral Shirazipour; Lucy Yong > >> Cc: pce@ietf.org > >> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> Begging your pardon, Meral, but I'm a bit confused. > >> > >> > I agree with what you say here. This is a fact to consider > >> > especially > >> if > >> > >> > the > >> > PCE architecture is to be adapted later on for inter-AS TE in the > >> > 'Internet'. > >> > What you say here is important if we consider the Internet peering > >> models. > >> > >> The architecture is already intended to be "adapted" for that > >> purpose. > >> Have > >> a quick read through the first few sections and you'll see ample > >> discussion > >> of inter-AS. > >> > >> Lucy's email seems to me to be about the time-based reservation of > >> resources. This doesn't seem to me to be outside the scope of > >> the current > >> architecture, but one might want to write down how PCE is > >> used for that > >> purpose as an informational draft. > >> > >> Personally, I would find Lucy's suggestion of a distinct > >> component and > >> database that was consulted for each computation request a > >> costly idea, > >> and > >> would prefer to see this type of function rolled into a > >> single database. > >> > >> Adrian > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Pce mailing list > >> Pce@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/pce > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Pce mailing list > >> Pce@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/pce > >> > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 14:56:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKzy-0001xk-Lj; Thu, 25 May 2006 14:55:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKzw-0001xf-Pw for pce@ietf.org; Thu, 25 May 2006 14:55:52 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKzv-0004DN-GW for pce@ietf.org; Thu, 25 May 2006 14:55:52 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZU00A8R46UTJ@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 11:47:18 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZU00BAZ46P6A@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 11:47:18 -0700 (PDT) Date: Thu, 25 May 2006 13:50:21 -0500 From: Lucy Yong Subject: RE: [Pce] RE: Comments about draft-ietf-pce-architecture-05 In-reply-to: <313680C9A886D511A06000204840E1CF0E248932@whq-msgusr-02.pit.comms.marconi.com> To: "'Gray, Eric'" , 'Adrian Farrel' Message-id: <000601c6802c$13d60fb0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Eric, Yeah, maybe state explicitly head-end that is not a PCC in this scenario. Thanks, Lucy -----Original Message----- From: Gray, Eric [mailto:Eric.Gray@marconi.com] Sent: Thursday, May 25, 2006 1:34 PM To: Lucy Yong; 'Adrian Farrel' Cc: pce@ietf.org Subject: RE: [Pce] RE: Comments about draft-ietf-pce-architecture-05 Lucy, Figure 5 is specifically trying to show a different flow. In earlier figures, the source of a service request is not shown. In general, however, one likely source for a service request is an NMS. I think the difference we may be trying to show in figure 5 is that an NMS may act as a PCC on behalf of a head-end that may not be a PCC itself. -- Eric --> -----Original Message----- --> From: Lucy Yong [mailto:lucyyong@huawei.com] --> Sent: Thursday, May 25, 2006 11:37 AM --> To: 'Adrian Farrel' --> Cc: pce@ietf.org --> Subject: [Pce] RE: Comments about draft-ietf-pce-architecture-05 --> --> Adrian, --> --> Let's put down the time-based reservation for now. I have --> another comment --> about the draft. In the Figure 5, it shows that NMS will --> send request to PCE --> directly to get the path information and send service request to the --> head-end node. The request flow seems different from other --> the four models. --> Is it better to keep the consistency? --> We could have NMS based service request to go head-end node --> first and let --> head-end node send request to PCE, thus all models will --> have the same --> message flows. --> Does this make sense? --> --> Regards, --> Lucy --> --> --> --> _______________________________________________ --> Pce mailing list --> Pce@lists.ietf.org --> https://www1.ietf.org/mailman/listinfo/pce --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 15:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLG8-0007XJ-GK; Thu, 25 May 2006 15:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLG7-0007TM-0D for pce@ietf.org; Thu, 25 May 2006 15:12:35 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLG5-0005hi-LW for pce@ietf.org; Thu, 25 May 2006 15:12:34 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k4PJCULB010933; Thu, 25 May 2006 15:12:30 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03912; Thu, 25 May 2006 15:12:29 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 25 May 2006 15:12:28 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0E248939@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: Lucy Yong , "Gray, Eric" , "'Adrian Farrel'" Subject: RE: [Pce] RE: Comments about draft-ietf-pce-architecture-05 Date: Thu, 25 May 2006 15:12:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Lucy, That's a possibility, but not really necesssary. It might simply be the case that a network operator wants it to work this way... -- Eric --> -----Original Message----- --> From: Lucy Yong [mailto:lucyyong@huawei.com] --> Sent: Thursday, May 25, 2006 2:50 PM --> To: 'Gray, Eric'; 'Adrian Farrel' --> Cc: pce@ietf.org --> Subject: RE: [Pce] RE: Comments about draft-ietf-pce-architecture-05 --> --> Eric, --> --> Yeah, maybe state explicitly head-end that is not a PCC in --> this scenario. --> --> Thanks, --> Lucy --> --> -----Original Message----- --> From: Gray, Eric [mailto:Eric.Gray@marconi.com] --> Sent: Thursday, May 25, 2006 1:34 PM --> To: Lucy Yong; 'Adrian Farrel' --> Cc: pce@ietf.org --> Subject: RE: [Pce] RE: Comments about draft-ietf-pce-architecture-05 --> --> Lucy, --> --> Figure 5 is specifically trying to show a different --> flow. --> --> In earlier figures, the source of a service request --> is not shown. In general, however, one likely source for --> a service request is an NMS. --> --> I think the difference we may be trying to show in --> figure 5 is that an NMS may act as a PCC on behalf of a --> head-end that may not be a PCC itself. --> --> -- --> Eric --> --> --> -----Original Message----- --> --> From: Lucy Yong [mailto:lucyyong@huawei.com] --> --> Sent: Thursday, May 25, 2006 11:37 AM --> --> To: 'Adrian Farrel' --> --> Cc: pce@ietf.org --> --> Subject: [Pce] RE: Comments about draft-ietf-pce-architecture-05 --> --> --> --> Adrian, --> --> --> --> Let's put down the time-based reservation for now. I have --> --> another comment --> --> about the draft. In the Figure 5, it shows that NMS will --> --> send request to PCE --> --> directly to get the path information and send service --> request to the --> --> head-end node. The request flow seems different from other --> --> the four models. --> --> Is it better to keep the consistency? --> --> We could have NMS based service request to go head-end node --> --> first and let --> --> head-end node send request to PCE, thus all models will --> --> have the same --> --> message flows. --> --> Does this make sense? --> --> --> --> Regards, --> --> Lucy --> --> --> --> --> --> --> --> _______________________________________________ --> --> Pce mailing list --> --> Pce@lists.ietf.org --> --> https://www1.ietf.org/mailman/listinfo/pce --> --> --> --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 15:27:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLUk-000171-NI; Thu, 25 May 2006 15:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLUi-00016B-Uw for pce@ietf.org; Thu, 25 May 2006 15:27:40 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLUi-0006UX-Au for pce@ietf.org; Thu, 25 May 2006 15:27:40 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZU00A9K5WETJ@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 12:24:15 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZU00FCK5W3DH@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 12:24:14 -0700 (PDT) Date: Thu, 25 May 2006 14:27:11 -0500 From: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 In-reply-to: <626FC7C6A97381468FB872072AB5DDC8C2D9A8@XCH-SW-42.sw.nos.boeing.com> To: "'Drake, John E'" , 'Adrian Farrel' , 'Payam Torab' , Dimitri.Papadimitriou@alcatel.be Message-id: <002801c68031$3c73e960$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi John, John, It is hard to see this time-based feature will be implemented on NE. If a network does not use PCE based architecture, carrier has to implement in other way like today's. However, today's solution, carrier needs to have two path computation engines: one in the network and one in the management system. That is why PCE provides this special value as I see. Thanks, Lucy -----Original Message----- From: Drake, John E [mailto:John.E.Drake2@boeing.com] Sent: Thursday, May 25, 2006 1:38 PM To: Lucy Yong; Adrian Farrel; Payam Torab; Dimitri.Papadimitriou@alcatel.be Cc: pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 Hi, I had a clarification question. Isn't it the case that it is a matter of policy whether a given node uses a PCE or computes/expands the ERO itself? If so, then I think time-based may be problematic as the PCE operating in the future domain will have no idea of the EROs that will be computed in the future by the nodes not using the PCE. Thanks, John > -----Original Message----- > From: Lucy Yong [mailto:lucyyong@huawei.com] > Sent: Wednesday, May 24, 2006 3:07 PM > To: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce- > architecture-05 > > Hi Adrian, > > Great explanation. Thanks. > Since PCE is the only path computation engine, any path reservation needs > to > go through it even the result could be saved in TED. I understand the TED > may be fed by IGP extensions or potentially by other means. This other > could > be the reservation system. However, the reservation system only has > ingress > and egress information, it does not have travel path information, TED can > not compute the path either. Therefore, it needs to go through the PCE. No > need to another path computation engine. > > Regards, > Lucy > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, May 24, 2006 4:34 PM > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > I think that some of the confusion may be coming from the definition of > TED. > > In the architecture I-D we have > 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. > and also > ...a PCE would > be able to compute the path of a TE LSP by operating on the TED and > considering bandwidth and other constraints applicable to the TE LSP > service request. > > This gives us the somewhat circular definition that the TED is the > database > on which PCE operates to compute TE paths. You might think that this TED > is > exactly the database of TE information advertised by an IGP, and that > would > be an entirely reasonable implementation, but the architecture and > definitions deliberately allow the TED to be supplemented from other > sources, or even created entirely from other sources. > > Regards, > Adrian > > ----- Original Message ----- > From: "Lucy Yong" > To: "'Payam Torab'" ; > > Cc: > Sent: Wednesday, May 24, 2006 9:48 PM > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > > Payam, > > > > The draft specifies five architecture scenarios. Suggest adding one for > > time-based reservation. Giving the definition of TED, I don't see it can > > serve that function properly. > > TED contains topology and resource information from network. It may be > > embedded in NE. It is good to have a place to hold real network > > information > > and another place hold all reservations. You can flexibly apply policy > to > > manage which bandwidth need to reserve ahead and which is only a book. > It > > is > > hard to see the implementation done in TED. > > > > Lucy > > > > -----Original Message----- > > From: Payam Torab [mailto:ptorab@lopsys.com] > > Sent: Wednesday, May 24, 2006 2:31 PM > > To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be > > Cc: pce@ietf.org > > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > > Lucy- > > > > What do you mean by "architecture scenario" below? I don't see any > > conflict > > between the current PCE architecture, and adding an element of time to > > path > > computation. You can certainly add time constraints to TED, as well as > > computation algorithms and support scheduling if you wish. > > > > You mention "It seems that current TED definition does not serve this > > function (scheduling)" - How is TED definition blocking you from > > scheduling? > > > > Thanks, > > Payam Torab > > > >> -----Original Message----- > >> From: Lucy Yong [mailto:lucyyong@huawei.com] > >> Sent: Wednesday, May 24, 2006 3:11 PM > >> To: Dimitri.Papadimitriou@alcatel.be > >> Cc: pce@ietf.org > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> > >> Hi Dimitri, > >> > >> Thank you for the comments. It is understood that the group > >> goal is to study IP communication protocols not network > >> architecture. However, they can not be completely separated. > >> Before we are clear about the architecture and its > >> components, we can't really specify the protocol, do we? The > >> suggestion here is to add another architecture scenario which > >> enables to support time-based reservation. I don't see this > >> impact the protocol study. It simply adds a value for PCE > >> based architecture. If we only study the protocols between > >> LSR-PCE and PCE-PCE, adding this scenario does not add > >> addition work at all. I don't see how this scenario impacts > > >> the scalability, performance, robustness and resiliency at > >> all. If it is, it is scared what we are doing here. > >> > >> Regards, > >> Lucy > >> > >> > >> -----Original Message----- > >> From: Dimitri.Papadimitriou@alcatel.be > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > >> Sent: Wednesday, May 24, 2006 12:49 PM > >> To: Lucy Yong > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> lucy - > >> > >> take a look at > >> >> col-gen-reqs-0 > >> 6.txt> > >> section 6.16, > >> > >> if there is a need to consider - as you wrote - that "PCE > >> should support > >> time-base reservation in the general > >> and leave as an option for carrier to implement or not." i > >> would like to > >> hear from operators specific rationales > >> to incorporate as part of the communication protocol / PCE > >> processing any > >> time constraint > >> > >> now more fundamentally and as stated the role of the group is > >> to define IP > >> communication protocols not network > >> architectures of some sort - reason for the suggestion made > >> on section 5 > >> > >> adrian mentions what is that inter-AS PCE is in scope, he > >> forgot probably > >> to mention to you that the primary > >> concerns of the work ongoing here is driven by four major concerns: > >> scalability, performance, robustness and > >> resiliency from this perspective any time constraint is going > >> to seriously > >> impact all these base objectives > >> > >> > >> > >> > >> > >> Lucy Yong > >> 24/05/2006 19:33 > >> > >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > >> cc: "'Adrian Farrel'" , "'Meral > >> Shirazipour'" , pce@ietf.org > >> Subject: RE: [Pce] Comments about > >> draft-ietf-pce-architecture-05 > >> > >> > >> Dimitri, > >> > >> Because for some important reservations, carrier want to > >> reserve the specific path for many purposes such as better > >> optimization, request > >> length > >> period, service guarantee, etc. > >> > >> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE > >> elements? We > >> are > >> defining the architecture now. > >> > >> Adrian has mentioned that it is in PCE scope. > >> > >> Regards, > >> Lucy > >> > >> -----Original Message----- > >> From: Dimitri.Papadimitriou@alcatel.be > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > >> Sent: Wednesday, May 24, 2006 12:25 PM > >> To: Lucy Yong > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> the question is why "time constraint" should be taken into > >> account during path computation that would justify > >> incorporation into the communication between LSR-PCE/PCE-PCE elements > >> > >> scheduling of LSPs - themselves - is outside the scope of the > >> comm process between LSR-PCE/PCE-PCE elements, it is even > >> outside the scope of the PCE (since not a resource manager of > >> some sort) > >> > >> > >> > >> > >> > >> Lucy Yong > >> 24/05/2006 19:08 > >> > >> To: "'Adrian Farrel'" , "'Meral > >> Shirazipour'" > >> cc: pce@ietf.org > >> Subject: RE: [Pce] Comments about > >> draft-ietf-pce-architecture-05 > >> > >> > >> All, > >> > >> Thank you for all the comments. > >> PCE should support time-base reservation in the general and > >> leave as an option for carrier to implement or not. If we > >> exclude this functionality, > >> it > >> is hard to see the full automatic network because there are > >> quite these kinds of service demands and carrier also > >> encourages the pre-order so they can proactively engineer the > >> network. I'll be glad to write an informational draft to > >> explain the possible mechanism and protocols. Weather the > >> function should be maintained in the same database or > >> separated databases, it would be better to see after > >> clarifying the functionality of each element first, and then > >> decide the solution. The service reservation database > >> mentioned here has a lot of information that PCE does not > >> need and has no responsibility to maintain them. Maybe some > >> cache mechanism could be used. Welcome anyone to provide the > >> input on the informational draft. > >> > >> Best Regards, > >> Lucy > >> > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Wednesday, May 24, 2006 11:11 AM > >> To: Meral Shirazipour; Lucy Yong > >> Cc: pce@ietf.org > >> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > >> > >> Begging your pardon, Meral, but I'm a bit confused. > >> > >> > I agree with what you say here. This is a fact to consider > >> > especially > >> if > >> > >> > the > >> > PCE architecture is to be adapted later on for inter-AS TE in the > >> > 'Internet'. > >> > What you say here is important if we consider the Internet peering > >> models. > >> > >> The architecture is already intended to be "adapted" for that > >> purpose. > >> Have > >> a quick read through the first few sections and you'll see ample > >> discussion > >> of inter-AS. > >> > >> Lucy's email seems to me to be about the time-based reservation of > >> resources. This doesn't seem to me to be outside the scope of > >> the current > >> architecture, but one might want to write down how PCE is > >> used for that > >> purpose as an informational draft. > >> > >> Personally, I would find Lucy's suggestion of a distinct > >> component and > >> database that was consulted for each computation request a > >> costly idea, > >> and > >> would prefer to see this type of function rolled into a > >> single database. > >> > >> Adrian > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Pce mailing list > >> Pce@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/pce > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Pce mailing list > >> Pce@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/pce > >> > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 15:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLno-0003CI-8p; Thu, 25 May 2006 15:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLbx-00038e-Lj for pce@ietf.org; Thu, 25 May 2006 15:35:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKa0-000107-1s for pce@ietf.org; Thu, 25 May 2006 14:29:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjK6g-0003G4-6n for pce@ietf.org; Thu, 25 May 2006 13:58:52 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2006 13:58:46 -0400 X-IronPort-AV: i="4.05,173,1146456000"; d="scan'208,217"; a="89474130:sNHT114104744" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4PHwjvL012990; Thu, 25 May 2006 13:58:45 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 13:58:45 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 13:58:40 -0400 In-Reply-To: <000a01c68017$43ade1f0$d4087c0a@china.huawei.com> References: <000a01c68017$43ade1f0$d4087c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Message-Id: <1DE885EF-6F19-4A6B-9CC5-E4C9B318B95A@cisco.com> From: JP Vasseur Subject: Re: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-architecture-05 Date: Thu, 25 May 2006 13:58:38 -0400 To: Lucy Yong X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 25 May 2006 17:58:40.0062 (UTC) FILETIME=[DA8EFDE0:01C68024] X-Spam-Score: -1.9 (-) X-Scan-Signature: ba180a468148886f52533468fee39de1 X-Mailman-Approved-At: Thu, 25 May 2006 15:47:22 -0400 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1949723043==" Errors-To: pce-bounces@lists.ietf.org --===============1949723043== Content-Type: multipart/alternative; boundary=Apple-Mail-64-621510631 --Apple-Mail-64-621510631 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Lucy, On May 25, 2006, at 12:21 PM, Lucy Yong wrote: > Dimitri, > > I see your points. Since PCE based architecture opens a lot of > potential > compared to NE based path computation. Although the group only > focus on the > basic communication capability between LSR and PCE, it may be not > necessary > to conclude that the group will not study this in the future if > this is > convinced as an important functionality. > Does IETF require closing the group when it finishes the charter goal? If you want to know what is under the scope of the PCE WG, here is the current charter: http://www.ietf.org/html.charters/pce-charter.html And if you plan to submit draft(s) in the future, to be adopted as WG document, yes the draft MUST be related to a WG item (under the scope of the charter). Now to answer your question, WG can be re-chartered to add new items, with the approval of the IESG, as specified in RFC2418. Thanks. JP. > > Regards, > Lucy > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, May 25, 2006 10:39 AM > To: Lucy Yong > Cc: 'JP Vasseur'; pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Comments > aboutdraft-ietf-pce-architecture-05 > > lucy > >> There are five models in the basic architecture, but the group >> only focuses on LSR-PCE and PCE-PCE protocols not all functions > architected. > > indeed (because the other entities are outside the scope) > >> Therefore, why do you so much concern that showing the architecture >> capability to support this application will impact whole project >> scope? > > for the reasons explained in my previous post - without clear answers > to these issues (that are going to impact the whole approach) i don't > see how you could progress > >> When the network and its management move to intelligent automatic > management, >> it needs to have the capability to support the future reservation >> and we > hope >> to have one place to do the path computation. > > probably ... but if you are intricating "reservation time" in the path > computation request you are de-facto going to introduce resource resv. > which is beyond scope of path computation > > i can understand that some NRENs, research nets, etc. are looking at > LSP / resource scheduling functionality (... the mythical resource > broker) for single domain application specific networks but PCE is not > meant to incorporate such functionality > > thanks, > - d. > > > > > > Lucy Yong > 25/05/2006 17:22 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "'JP Vasseur'" , pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Comments > aboutdraft-ietf-pce-architecture-05 > > > Hi Dimitri, > > Thank you for the concern. I did not expect the group come out a > solution > for this application now. All I want to say is that PCE based > architecture > could allow this kind of application compared to current NE based > computation, which is value added for this architecture. Adding this > application does require to add some features and protocols. > Weather we > want > to solve in this group or not is debatable and depends on the peoples > interests. There are five models in the basic architecture, but the > group > only focuses on LSR-PCE and PCE-PCE protocols not all functions > architected. > Therefore, why do you so much concern that showing the architecture > capability to support this application will impact whole project > scope? > > I could provide some information to show the importance of the > application. > People working in different areas have different views. As I > mentioned, it > is hard to see a large bandwidth demand or a permanent bandwidth > demand > will > always be requested at time it needs. When the network and its > management > move to intelligent automatic management, it needs to have the > capability > to > support the future reservation and we hope to have one place to do the > path > computation. > > Regards, > Lucy > > > > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, May 25, 2006 9:50 AM > To: Lucy Yong > Cc: 'JP Vasseur'; pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Comments > aboutdraft-ietf-pce-architecture-05 > > lucy - > > this side discussion on TED is diverting from the (real) issue > behind the > initial > proposal that has started this thread > > there is first a need to determine whether there is an interest behind > this feature > i.e. whether this would be addressing a real concern, and i have > not seen > anything > similar in all the requirements document and discussion we had > since so > far > > now, assuming such requirement would pop up (i would be keen to see > which > applications > we're speaking about here) there is a second phase that consists in > assessing whether > the PCE communication/entity is appropriate for processing such > kind of > information > (side note: PCE does not perform any resource admission control nor > performs any sort > of resource reservation) and the impact this would have on the PCE > mechanisms assumed > since so far > > this because time based reservation / time constraint implies > > - network time synchronization for each resource reservation and > for each > LSP > > - the PCE that will have to take this constraint into account will > also > have to maintain > (or obtain as information) for each reservation and for each LSP the > time elapsed in > order to be able to provide with the suitable answer to subsequent > request (in brief, > a computation will not have only to rely on the PRESENT state of the > network resource > reservation but also on PAST and FUTURE reservation) > > note: there is a side-effect on the signaling protocol mechanism > as this > > breaks the > idempotent behaviour of RSVP (for inst.) > > - PCEs will need to synchronize around that information during Path > computation requests > involving more than one PCE > > - PCE becomes trigger for setting up and tearing down LSP (or at > least is > involved in > this decision process) when reservation time elapses and the > signaling > controller fails > performing this action > > - Preemption will become a required mechanism (based on the LSP > priority) > you would have > to perform actions that are also impacting network stability > > - etc. > > at the end and more specifically the "pce architecture" document is > not > dealing with any > kind of specific usage of the functional (and informational) > element that > are proposed > but on the other side someone proposing a specific application has > imho to > > demonstrate > that the documented mechanisms will support this specific > application, and > > i fail to see > real rationales for the time being > > thanks, > - dimitri. > > > > > Lucy Yong > 25/05/2006 15:58 > > To: "'JP Vasseur'" > cc: pce@ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > Subject: RE: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > > Hi JP, > > Thank you for a good catch. See me response below. > > Regards, > Lucy > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, May 25, 2006 6:16 AM > To: Lucy Yong > Cc: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be; > pce@ietf.org > Subject: Re: What is the TED? Was: [Pce] Comments about > draft-ietf-pce-architecture-05 > > Hi Lucy, > > On May 24, 2006, at 6:07 PM, Lucy Yong wrote: > >> Hi Adrian, >> >> Great explanation. Thanks. >> Since PCE is the only path computation engine, any path reservation >> needs to >> go through it even the result could be saved in TED. > > Yes, although I would suggest you to be cautious here since there > would be dangerous side-effect especially in situations where the PCE > is not used by all nodes to compute TE LSP paths. > > [Lucy] Agree. I do not assume that either. PCE could be centralized or > partial distributed. > >> I understand the TED >> may be fed by IGP extensions or potentially by other means. This >> other could >> be the reservation system. However, the reservation system only has >> ingress >> and egress information, it does not have travel path information, >> TED can >> not compute the path either. Therefore, it needs to go through the >> PCE. No >> need to another path computation engine. > > It looks like you use a different terminology than in the IETF > documents related to MPLS TE: > -> By "reservation system" do you mean "Control plane used to > establish the TE LSP (RSVP-TE)" ? > -> TED never compute paths ... this is the topology database used to > compute path > > [Lucy]: Sorry, use the wrong term. It should be inventory system. > Inventory > system is manually maintained resource system. With PCE based > architecture, > we only want one place to compute the path, that is the PCE. > Therefore, no > matter where the time-based reserved resource is stored, PCE should > be the > place to compute the path. Maybe someone could illustrate how the > basic > architecture model could accomplish this task. :) > > Thanks. > > JP. > >> >> Regards, >> Lucy >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Wednesday, May 24, 2006 4:34 PM >> To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be >> Cc: pce@ietf.org >> Subject: What is the TED? Was: [Pce] Comments about >> draft-ietf-pce-architecture-05 >> >> Hi Lucy, >> >> I think that some of the confusion may be coming from the >> definition of TED. >> >> In the architecture I-D we have >> 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. >> and also >> ...a PCE would >> be able to compute the path of a TE LSP by operating on the TED >> and >> considering bandwidth and other constraints applicable to the TE >> LSP >> service request. >> >> This gives us the somewhat circular definition that the TED is the >> database >> on which PCE operates to compute TE paths. You might think that >> this TED is >> exactly the database of TE information advertised by an IGP, and >> that would >> be an entirely reasonable implementation, but the architecture and >> definitions deliberately allow the TED to be supplemented from other >> sources, or even created entirely from other sources. >> >> Regards, >> Adrian >> >> ----- Original Message ----- >> From: "Lucy Yong" >> To: "'Payam Torab'" ; >> >> Cc: >> Sent: Wednesday, May 24, 2006 9:48 PM >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >> >> >>> Payam, >>> >>> The draft specifies five architecture scenarios. Suggest adding >>> one for >>> time-based reservation. Giving the definition of TED, I don't see >>> it can >>> serve that function properly. >>> TED contains topology and resource information from network. It >>> may be >>> embedded in NE. It is good to have a place to hold real network >>> information >>> and another place hold all reservations. You can flexibly apply >>> policy to >>> manage which bandwidth need to reserve ahead and which is only a >>> book. It >>> is >>> hard to see the implementation done in TED. >>> >>> Lucy >>> >>> -----Original Message----- >>> From: Payam Torab [mailto:ptorab@lopsys.com] >>> Sent: Wednesday, May 24, 2006 2:31 PM >>> To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be >>> Cc: pce@ietf.org >>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>> >>> Lucy- >>> >>> What do you mean by "architecture scenario" below? I don't see any >>> conflict >>> between the current PCE architecture, and adding an element of >>> time to >>> path >>> computation. You can certainly add time constraints to TED, as >>> well as >>> computation algorithms and support scheduling if you wish. >>> >>> You mention "It seems that current TED definition does not serve >>> this >>> function (scheduling)" - How is TED definition blocking you from >>> scheduling? >>> >>> Thanks, >>> Payam Torab >>> >>>> -----Original Message----- >>>> From: Lucy Yong [mailto:lucyyong@huawei.com] >>>> Sent: Wednesday, May 24, 2006 3:11 PM >>>> To: Dimitri.Papadimitriou@alcatel.be >>>> Cc: pce@ietf.org >>>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thank you for the comments. It is understood that the group >>>> goal is to study IP communication protocols not network >>>> architecture. However, they can not be completely separated. >>>> Before we are clear about the architecture and its >>>> components, we can't really specify the protocol, do we? The >>>> suggestion here is to add another architecture scenario which >>>> enables to support time-based reservation. I don't see this >>>> impact the protocol study. It simply adds a value for PCE >>>> based architecture. If we only study the protocols between >>>> LSR-PCE and PCE-PCE, adding this scenario does not add >>>> addition work at all. I don't see how this scenario impacts >> >>>> the scalability, performance, robustness and resiliency at >>>> all. If it is, it is scared what we are doing here. >>>> >>>> Regards, >>>> Lucy >>>> >>>> >>>> -----Original Message----- >>>> From: Dimitri.Papadimitriou@alcatel.be >>>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>>> Sent: Wednesday, May 24, 2006 12:49 PM >>>> To: Lucy Yong >>>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> lucy - >>>> >>>> take a look at >>>> >>> col-gen-reqs-0 >>>> 6.txt> >>>> section 6.16, >>>> >>>> if there is a need to consider - as you wrote - that "PCE >>>> should support >>>> time-base reservation in the general >>>> and leave as an option for carrier to implement or not." i >>>> would like to >>>> hear from operators specific rationales >>>> to incorporate as part of the communication protocol / PCE >>>> processing any >>>> time constraint >>>> >>>> now more fundamentally and as stated the role of the group is >>>> to define IP > >>>> communication protocols not network >>>> architectures of some sort - reason for the suggestion made >>>> on section 5 >>>> >>>> adrian mentions what is that inter-AS PCE is in scope, he >>>> forgot probably >>>> to mention to you that the primary >>>> concerns of the work ongoing here is driven by four major concerns: >>>> scalability, performance, robustness and >>>> resiliency from this perspective any time constraint is going >>>> to seriously >>>> impact all these base objectives >>>> >>>> >>>> >>>> >>>> >>>> Lucy Yong >>>> 24/05/2006 19:33 >>>> >>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>> cc: "'Adrian Farrel'" , "'Meral >>>> Shirazipour'" , pce@ietf.org >>>> Subject: RE: [Pce] Comments about >>>> draft-ietf-pce-architecture-05 >>>> >>>> >>>> Dimitri, >>>> >>>> Because for some important reservations, carrier want to >>>> reserve the specific path for many purposes such as better >>>> optimization, request >>>> length >>>> period, service guarantee, etc. >>>> >>>> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE >>>> elements? We >>>> are >>>> defining the architecture now. >>>> >>>> Adrian has mentioned that it is in PCE scope. >>>> >>>> Regards, >>>> Lucy >>>> >>>> -----Original Message----- >>>> From: Dimitri.Papadimitriou@alcatel.be >>>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>>> Sent: Wednesday, May 24, 2006 12:25 PM >>>> To: Lucy Yong >>>> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org >>>> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> the question is why "time constraint" should be taken into >>>> account during path computation that would justify >>>> incorporation into the communication between LSR-PCE/PCE-PCE >>>> elements >>>> >>>> scheduling of LSPs - themselves - is outside the scope of the >>>> comm process between LSR-PCE/PCE-PCE elements, it is even >>>> outside the scope of the PCE (since not a resource manager of >>>> some sort) >>>> >>>> >>>> >>>> >>>> >>>> Lucy Yong >>>> 24/05/2006 19:08 >>>> >>>> To: "'Adrian Farrel'" , "'Meral >>>> Shirazipour'" >>>> cc: pce@ietf.org >>>> Subject: RE: [Pce] Comments about >>>> draft-ietf-pce-architecture-05 >>>> >>>> >>>> All, >>>> >>>> Thank you for all the comments. >>>> PCE should support time-base reservation in the general and >>>> leave as an option for carrier to implement or not. If we >>>> exclude this functionality, >>>> it >>>> is hard to see the full automatic network because there are >>>> quite these kinds of service demands and carrier also >>>> encourages the pre-order so they can proactively engineer the >>>> network. I'll be glad to write an informational draft to >>>> explain the possible mechanism and protocols. Weather the >>>> function should be maintained in the same database or >>>> separated databases, it would be better to see after >>>> clarifying the functionality of each element first, and then >>>> decide the solution. The service reservation database >>>> mentioned here has a lot of information that PCE does not >>>> need and has no responsibility to maintain them. Maybe some >>>> cache mechanism could be used. Welcome anyone to provide the >>>> input on the informational draft. >>>> >>>> Best Regards, >>>> Lucy >>>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Wednesday, May 24, 2006 11:11 AM >>>> To: Meral Shirazipour; Lucy Yong >>>> Cc: pce@ietf.org >>>> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 >>>> >>>> Begging your pardon, Meral, but I'm a bit confused. >>>> >>>>> I agree with what you say here. This is a fact to consider >>>>> especially >>>> if >>>> >>>>> the >>>>> PCE architecture is to be adapted later on for inter-AS TE in the >>>>> 'Internet'. >>>>> What you say here is important if we consider the Internet peering >>>> models. >>>> >>>> The architecture is already intended to be "adapted" for that >>>> purpose. >>>> Have >>>> a quick read through the first few sections and you'll see ample >>>> discussion >>>> of inter-AS. >>>> >>>> Lucy's email seems to me to be about the time-based reservation of >>>> resources. This doesn't seem to me to be outside the scope of >>>> the current >>>> architecture, but one might want to write down how PCE is >>>> used for that >>>> purpose as an informational draft. >>>> >>>> Personally, I would find Lucy's suggestion of a distinct >>>> component and >>>> database that was consulted for each computation request a >>>> costly idea, >>>> and >>>> would prefer to see this type of function rolled into a >>>> single database. >>>> >>>> Adrian >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > > > --Apple-Mail-64-621510631 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Lucy,

On = May 25, 2006, at 12:21 PM, Lucy Yong wrote:

Dimitri,

I see your points. Since PCE = based architecture opens a lot of potential
basic communication capability = between LSR and PCE, it may be not necessary
to conclude that the group will not study this in = the future if this is
convinced as an important = functionality.
Does IETF require closing the = group when it finishes the charter goal?

If you want to know what is = under the scope of the PCE WG, here is the current charter:=A0http://www.iet= f.org/html.charters/pce-charter.html=A0=A0
And if you plan to submit = draft(s) in the future, to be adopted as WG document, yes the draft MUST = be related to a WG item (under the scope of the charter).

Now to answer your = question, WG can be re-chartered to add new items, with the approval of = the IESG, as specified in RFC2418.

Thanks.

JP.


Regards,

-----Original Message-----
Sent: = Thursday, May 25, 2006 10:39 AM
To: Lucy = Yong
Cc: 'JP Vasseur'; pce@ietf.org
Subject: RE: What is the TED? Was: [Pce] = Comments

lucy=A0

There are five models in the basic architecture, but = the group
only focuses on LSR-PCE and = PCE-PCE protocols not all functions=A0
architected.

indeed (because the other = entities are outside the scope)=A0

Therefore, why do you so much concern that showing = the architecture
capability to support this = application will impact whole project scope?

for the = reasons explained in my previous post - without clear answers=A0
to these = issues (that are going to impact the whole approach) i don't
see how you could progress

When the network and its = management move to intelligent automatic=A0
management,=A0
it needs to have the capability = to support the future reservation and we=A0
hope=A0
to have one place to do the path = computation.

probably ... but if you are = intricating "reservation time" in the path=A0
which is beyond scope of path = computation=A0

i can = understand that some NRENs, research nets, etc. are looking at
LSP / resource scheduling functionality (... the = mythical resource
broker) for single domain = application specific networks but PCE is not
meant to incorporate such functionality

- d.





Lucy = Yong <lucyyong@huawei.com>
25/05/2006 17:22

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 "'JP Vasseur'" <jvasseur@cisco.com>, pce@ietf.org
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = RE: What is the TED? Was: [Pce] Comments=A0


Hi Dimitri,

Thank = you for the concern. I did not expect the group come out a = solution
for this application now. All I = want to say is that PCE based architecture
could = allow this kind of application compared to current NE based
computation, which is value added for this = architecture. Adding this
application = does require to add some features and protocols. Weather we=A0
to solve in this group or not is = debatable and depends on the peoples
interests. = There are five models in the basic architecture, but the group
only focuses on LSR-PCE and PCE-PCE protocols not = all functions=A0
architected.
Therefore, = why do you so much concern that showing the architecture
capability to support this application will impact = whole project scope?
I could provide some information = to show the importance of the=A0
People working in different = areas have different views. As I mentioned, it
is hard to see a large bandwidth demand or a = permanent bandwidth demand=A0
always be requested at time it = needs. When the network and its management
move to = intelligent automatic management, it needs to have the capability=A0
support the future reservation = and we hope to have one place to do the=A0
computation.

Lucy





Sent: = Thursday, May 25, 2006 9:50 AM
To: Lucy = Yong
Cc: 'JP Vasseur'; pce@ietf.org
Subject: RE: What is the TED? Was: [Pce] = Comments

lucy -=A0

this side = discussion on TED is diverting from the (real) issue behind the=A0
proposal that has started this = thread=A0

there is = first a need to determine whether there is an interest behind=A0
this = feature
i.e. whether this would be = addressing a real concern, and i have not seen=A0
=A0
similar in all the requirements document and = discussion we had since so=A0

now, assuming such requirement would pop up (i would = be keen to see which=A0
we're speaking about here) there = is a second phase that consists in=A0
=A0
the PCE = communication/entity is appropriate for processing such kind of=A0
=A0
(side note: PCE does not perform any resource = admission control nor=A0
performs = any sort
of resource reservation) and the = impact this would have on the PCE=A0
=A0
since so = far

this because time based reservation / time = constraint implies=A0

- = network time synchronization for each resource reservation and for = each=A0
LSP

- the PCE that will have to take = this constraint into account will also=A0
have to = maintain
=A0 (or obtain as information) = for each reservation and for each LSP the=A0
time = elapsed in=A0
=A0 = order to be able to provide with the suitable answer to = subsequent=A0
request (in brief,=A0
=A0 a computation will not have = only to rely on the PRESENT state of the=A0
network = resource=A0
=A0 = reservation but also on PAST and FUTURE reservation)=A0

=A0 note: there is a side-effect = on the signaling protocol mechanism as this=A0

breaks = the=A0
=A0 = idempotent behaviour of RSVP (for inst.)

- PCEs = will need to synchronize around that information during Path=A0
=A0 involving more than one = PCE

- PCE becomes trigger for setting up and tearing = down LSP (or at least is=A0
involved = in=A0
=A0 = this decision process) when reservation time elapses and the = signaling=A0
controller fails
=A0 performing this = action

- Preemption will become a required mechanism (based = on the LSP priority)=A0
you = would have
=A0 to perform actions that are = also impacting network stability

- etc.

at the = end and more specifically the "pce architecture" document is not=A0
dealing = with any
kind of specific usage of the = functional (and informational) element that=A0
are = proposed
but on the other side someone = proposing a specific application has imho to=A0

=A0
that the documented mechanisms will support this = specific application, and=A0

i fail to = see=A0
real rationales for the time being

- dimitri.




25/05/2006 15:58

=A0 =A0 =A0 =A0 To: =A0 =A0 "'JP Vasseur'" <jvasseur@cisco.com>
=A0 =A0 =A0 =A0 = cc: =A0 =A0 pce@ietf.org, Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 Subject:=A0 =A0 =A0 =A0 RE: What is the = TED? Was: [Pce] Comments about=A0


Hi JP,

Thank you for a good catch. See = me response below.
Regards,
Lucy


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]=A0
Sent: = Thursday, May 25, 2006 6:16 AM
To: Lucy = Yong
Cc: 'Adrian Farrel'; 'Payam = Torab'; Dimitri.Papadimitriou@alc= atel.be;
Subject: Re: What is the TED? Was: [Pce] Comments = about

Hi Lucy,

On May = 24, 2006, at 6:07 PM, Lucy Yong wrote:

Hi Adrian,

Great explanation. = Thanks.
Since PCE is the only path = computation engine, any path reservation=A0
needs = to
go through it even the result could be saved in = TED.
Yes, although I would suggest = you to be cautious here since there=A0
would be = dangerous side-effect especially in situations where the PCE=A0
is not = used by all nodes to compute TE LSP paths.

[Lucy] Agree. = I do not assume that either. PCE could be centralized or
partial distributed.

I understand the TED
may be = fed by IGP extensions or potentially by other means. This=A0
other = could
be the reservation system. = However, the reservation system only has=A0
and egress information, it does = not have travel path information,=A0
TED = can
not compute the path either. = Therefore, it needs to go through the=A0
PCE. = No
need to another path computation engine.
=

It looks like you use a different terminology than = in the IETF=A0
documents related to MPLS TE:
-> By "reservation system" do you mean "Control = plane used to=A0
establish the TE LSP (RSVP-TE)" ?
-> TED never compute paths ... this is the = topology database used to=A0
compute = path

[Lucy]: Sorry, use the wrong term. It should be = inventory system.=A0
Inventory
system is = manually maintained resource system. With PCE based=A0
we only want one place to = compute the path, that is the PCE. Therefore, no
matter where the time-based reserved resource is = stored, PCE should be the
place to = compute the path. Maybe someone could illustrate how the basic
architecture model could accomplish this task. = :)

Thanks.

JP.


Lucy

From: Adrian = Farrel [mailto:adrian@olddog.co.uk]
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Sent: Wednesday, May 24, 2006 4:34 PM
To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alc= atel.be
Subject: What is the TED? Was: [Pce] Comments = about

Hi Lucy,

I think = that some of the confusion may be coming from the=A0
In the architecture I-D we = have
=A0=A0 TED: Traffic Engineering = Database which contains the topology and
=A0=A0 resource information of = the domain. The TED may be fed by IGP
=A0=A0 extensions or potentially = by other means.
and also
=A0=A0 = ...a PCE would
=A0=A0 be able to compute the = path of a TE LSP by operating on the TED and
=A0=A0 = considering bandwidth and other constraints applicable to the = TE=A0
LSP
=A0=A0 service request.

This = gives us the somewhat circular definition that the TED is the=A0
on which PCE operates to compute = TE paths. You might think that=A0
this TED = is
exactly the database of TE information = advertised by an IGP, and=A0
that = would
be an entirely reasonable = implementation, but the architecture and
sources, or even created = entirely from other sources.

Regards,
Adrian

----- Original Message = -----
From: "Lucy Yong" <lucyyong@huawei.com>
To: "'Payam Torab'" <ptorab@lopsys.com>;=A0
Sent: Wednesday, May 24, 2006 9:48 PM
Subject: RE: [Pce] Comments about = draft-ietf-pce-architecture-05


=
Payam,

The = draft specifies five architecture scenarios. Suggest adding=A0
one = for
time-based reservation. Giving = the definition of TED, I don't see=A0
it = can
serve that function = properly.
TED contains topology and = resource information from network. It=A0
may = be
embedded in NE. It is good to have a place to = hold real network
information
and another place hold all reservations. You can = flexibly apply=A0
policy to
manage which = bandwidth need to reserve ahead and which is only a=A0
book. = It
is
hard to see = the implementation done in TED.

Lucy

From: Payam = Torab [mailto:ptorab@lopsys.com]
Sent: Wednesday, May 24, 2006 2:31 PM
Subject: RE: [Pce] Comments about = draft-ietf-pce-architecture-05

Lucy-

What do = you mean by "architecture scenario" below? I don't see any
conflict
between the = current PCE architecture, and adding an element of=A0
time = to
path
computation. = You can certainly add time constraints to TED, as=A0
well = as
computation algorithms and support scheduling = if you wish.

You mention "It seems that current TED definition = does not serve this
function (scheduling)" - = How is TED definition blocking you from

Thanks,
Payam = Torab

=
-----Original = Message-----
From: Lucy Yong [mailto:lucyyong@huawei.com]
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Sent: Wednesday, May 24, 2006 3:11 PM
Subject: RE: [Pce] Comments about = draft-ietf-pce-architecture-05


Hi Dimitri,

Thank you for the comments. It = is understood that the group
goal is to = study IP communication protocols not network
architecture. However, they can not be completely = separated.
Before we are clear about the = architecture and its
components, we can't really = specify the protocol, do we? The
suggestion = here is to add another architecture scenario which
enables to support time-based reservation. I don't = see this
impact the protocol study. It = simply adds a value for PCE
based = architecture. If we only study the protocols between
LSR-PCE and PCE-PCE, adding this scenario does not = add
addition work at all.=A0 I don't see how this scenario = impacts

the scalability, performance, = robustness and resiliency at
all. If it = is, it is scared what we are doing here.

Lucy


-----Original = Message-----
Sent: Wednesday, May 24, = 2006 12:49 PM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org
Subject: RE: [Pce] Comments about = draft-ietf-pce-architecture-05

lucy -

take a = look at
col-gen-reqs-0
section 6.16,

if there = is a need to consider - as you wrote - that "PCE
should support
time-base = reservation in the general
and leave as = an option for carrier to implement or not." i
would like to
hear from = operators specific rationales
to = incorporate as part of the communication protocol / PCE
processing any
time = constraint

now more fundamentally and as stated the role of the = group is
to define IP
=

communication = protocols not network
architectures of some sort = - reason for the suggestion made
on section = 5

adrian mentions what is that inter-AS PCE is in = scope, he
forgot probably
to mention to you that the primary
concerns of the work ongoing here is driven by four = major concerns:
scalability, performance, = robustness and
resiliency from this perspective = any time constraint is going
to = seriously
impact all these base = objectives





24/05/2006 19:33

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 "'Adrian Farrel'" <adrian@olddog.co.uk>, = "'Meral
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = RE: [Pce] Comments about


Dimitri,

Because for some important = reservations, carrier want to
reserve the = specific path for many purposes such as better
optimization, request
period, service guarantee, = etc.

Why should PCE WG limits the scope between = LSR-PCE/PCE-PCE
elements? We
are
defining the = architecture now.

Adrian has mentioned that it is in PCE = scope.

Regards,

-----Original Message-----
Sent: Wednesday, May 24, = 2006 12:25 PM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org
Subject: RE: [Pce] Comments about = draft-ietf-pce-architecture-05

the question is why "time = constraint" should be taken into
account = during path computation that would justify
=A0

scheduling of LSPs - themselves - is outside the = scope of the
comm process between = LSR-PCE/PCE-PCE elements, it is even
outside the = scope of the PCE (since not a resource manager of
some sort)





24/05/2006 19:08

=A0 =A0 =A0 =A0 To: =A0 =A0 "'Adrian Farrel'" <adrian@olddog.co.uk>, = "'Meral
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = RE: [Pce] Comments about


All,

Thank you for all the = comments.
PCE should support time-base = reservation in the general and
leave as an = option for carrier to implement or not. If we
exclude this functionality,
it
is hard to see the full = automatic network because there are
quite these = kinds of service demands and carrier also
network. I'll be glad to write = an informational draft to
explain the = possible mechanism and protocols. Weather the
function should be maintained in the same database = or
separated databases, it would be better to see = after
clarifying the functionality of = each element first, and then
decide the = solution. The service reservation database
need and has no responsibility to maintain them. = Maybe some
cache mechanism could be used. = Welcome anyone to provide the
input on the = informational draft.
Best Regards,
Lucy

-----Original = Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Sent: Wednesday, May 24, 2006 11:11 AM
To: Meral Shirazipour; Lucy Yong
Subject: Re: [Pce] Comments about = draft-ietf-pce-architecture-05

Begging your pardon, Meral, but = I'm a bit confused.
=A0 I agree with what you say = here. This is a fact to consider
if

the
PCE = architecture is to be adapted later on for inter-AS TE in the
'Internet'.
What you say = here is important if we consider the Internet peering
=
models.

The = architecture is already intended to be "adapted" for that
purpose.
a quick read through the first = few sections and you'll see ample
of inter-AS.

Lucy's = email seems to me to be about the time-based reservation of
resources. This doesn't seem to me to be outside the = scope of
the current
architecture, but one might want to write down how = PCE is
used for that
purpose as an informational draft.

component and
database that = was consulted for each computation request a
costly idea,
and
would prefer to see this type of function rolled = into a
single database.







Pce mailing list









Pce mailing list





Pce mailing list








Pce mailing list



Pce mailing list






=

= --Apple-Mail-64-621510631-- --===============1949723043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1949723043==-- From pce-bounces@lists.ietf.org Thu May 25 15:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLqd-0005Ln-9Y; Thu, 25 May 2006 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLqO-0005HZ-D8; Thu, 25 May 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLqM-00089G-5y; Thu, 25 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4PJo1et020498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FjLqL-0002OQ-U7; Thu, 25 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 25 May 2006 15:50:01 -0400 X-Spam-Score: 0.6 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-06.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-06.txt Pages : 21 Date : 2006-5-22 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Thu May 25 15:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLqy-0005XO-1O; Thu, 25 May 2006 15:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLqx-0005XJ-5a for pce@ietf.org; Thu, 25 May 2006 15:50:39 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLqs-0008Ai-GD for pce@ietf.org; Thu, 25 May 2006 15:50:39 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA21721; Thu, 25 May 2006 14:50:06 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4PJo5B15203; Thu, 25 May 2006 12:50:05 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 12:50:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce-architecture-05 Date: Thu, 25 May 2006 12:50:04 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2D9AD@XCH-SW-42.sw.nos.boeing.com> In-Reply-To: <002801c68031$3c73e960$d4087c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce-architecture-05 Thread-Index: AcaAMVAPjA1TqRTiR3ytu3bdAHZ7TwAAiM4Q From: "Drake, John E" To: "Lucy Yong" , "Adrian Farrel" , "Payam Torab" , X-OriginalArrivalTime: 25 May 2006 19:50:05.0571 (UTC) FILETIME=[6B6EB530:01C68034] X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Lucy, It's probably just a matter of design philosophy. If you want to use time- based, I think you need to lock-step the network through time and you need to address the set of issues that Dimitri raised. I don't remember if Dimitri raised the issue that unplanned link/node outages may wreak havoc with your nicely planned future. If you don't want to use time-based, then pre-emption mechanisms in signaling allow the network to adapt to the conditions at a given point in time. Thanks, John > -----Original Message----- > From: Lucy Yong [mailto:lucyyong@huawei.com] > Sent: Thursday, May 25, 2006 12:27 PM > To: Drake, John E; 'Adrian Farrel'; 'Payam Torab'; > Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce- > architecture-05 >=20 > Hi John, >=20 > John, >=20 > It is hard to see this time-based feature will be implemented on NE. > If a network does not use PCE based architecture, carrier has to implement > in other way like today's. However, today's solution, carrier needs to > have > two path computation engines: one in the network and one in the management > system. That is why PCE provides this special value as I see. >=20 > Thanks, > Lucy >=20 > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Thursday, May 25, 2006 1:38 PM > To: Lucy Yong; Adrian Farrel; Payam Torab; > Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Comments > aboutdraft-ietf-pce-architecture-05 >=20 > Hi, >=20 > I had a clarification question. Isn't it the case that it is a matter > of policy whether a given node uses a PCE or computes/expands the ERO > itself? >=20 > If so, then I think time-based may be problematic as the PCE operating > in the future domain will have no idea of the EROs that will be computed > in the future by the nodes not using the PCE. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Lucy Yong [mailto:lucyyong@huawei.com] > > Sent: Wednesday, May 24, 2006 3:07 PM > > To: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > > Cc: pce@ietf.org > > Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce- > > architecture-05 > > > > Hi Adrian, > > > > Great explanation. Thanks. > > Since PCE is the only path computation engine, any path reservation > needs > > to > > go through it even the result could be saved in TED. I understand the > TED > > may be fed by IGP extensions or potentially by other means. This other > > could > > be the reservation system. However, the reservation system only has > > ingress > > and egress information, it does not have travel path information, TED > can > > not compute the path either. Therefore, it needs to go through the > PCE. No > > need to another path computation engine. > > > > Regards, > > Lucy > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Wednesday, May 24, 2006 4:34 PM > > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > > Cc: pce@ietf.org > > Subject: What is the TED? Was: [Pce] Comments about > > draft-ietf-pce-architecture-05 > > > > Hi Lucy, > > > > I think that some of the confusion may be coming from the definition > of > > TED. > > > > In the architecture I-D we have > > 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. > > and also > > ...a PCE would > > be able to compute the path of a TE LSP by operating on the TED and > > considering bandwidth and other constraints applicable to the TE > LSP > > service request. > > > > This gives us the somewhat circular definition that the TED is the > > database > > on which PCE operates to compute TE paths. You might think that this > TED > > is > > exactly the database of TE information advertised by an IGP, and that > > would > > be an entirely reasonable implementation, but the architecture and > > definitions deliberately allow the TED to be supplemented from other > > sources, or even created entirely from other sources. > > > > Regards, > > Adrian > > > > ----- Original Message ----- > > From: "Lucy Yong" > > To: "'Payam Torab'" ; > > > > Cc: > > Sent: Wednesday, May 24, 2006 9:48 PM > > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > > > > > Payam, > > > > > > The draft specifies five architecture scenarios. Suggest adding one > for > > > time-based reservation. Giving the definition of TED, I don't see it > can > > > serve that function properly. > > > TED contains topology and resource information from network. It may > be > > > embedded in NE. It is good to have a place to hold real network > > > information > > > and another place hold all reservations. You can flexibly apply > policy > > to > > > manage which bandwidth need to reserve ahead and which is only a > book. > > It > > > is > > > hard to see the implementation done in TED. > > > > > > Lucy > > > > > > -----Original Message----- > > > From: Payam Torab [mailto:ptorab@lopsys.com] > > > Sent: Wednesday, May 24, 2006 2:31 PM > > > To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be > > > Cc: pce@ietf.org > > > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > > > > Lucy- > > > > > > What do you mean by "architecture scenario" below? I don't see any > > > conflict > > > between the current PCE architecture, and adding an element of time > to > > > path > > > computation. You can certainly add time constraints to TED, as well > as > > > computation algorithms and support scheduling if you wish. > > > > > > You mention "It seems that current TED definition does not serve > this > > > function (scheduling)" - How is TED definition blocking you from > > > scheduling? > > > > > > Thanks, > > > Payam Torab > > > > > >> -----Original Message----- > > >> From: Lucy Yong [mailto:lucyyong@huawei.com] > > >> Sent: Wednesday, May 24, 2006 3:11 PM > > >> To: Dimitri.Papadimitriou@alcatel.be > > >> Cc: pce@ietf.org > > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> > > >> Hi Dimitri, > > >> > > >> Thank you for the comments. It is understood that the group > > >> goal is to study IP communication protocols not network > > >> architecture. However, they can not be completely separated. > > >> Before we are clear about the architecture and its > > >> components, we can't really specify the protocol, do we? The > > >> suggestion here is to add another architecture scenario which > > >> enables to support time-based reservation. I don't see this > > >> impact the protocol study. It simply adds a value for PCE > > >> based architecture. If we only study the protocols between > > >> LSR-PCE and PCE-PCE, adding this scenario does not add > > >> addition work at all. I don't see how this scenario impacts > > > > >> the scalability, performance, robustness and resiliency at > > >> all. If it is, it is scared what we are doing here. > > >> > > >> Regards, > > >> Lucy > > >> > > >> > > >> -----Original Message----- > > >> From: Dimitri.Papadimitriou@alcatel.be > > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > > >> Sent: Wednesday, May 24, 2006 12:49 PM > > >> To: Lucy Yong > > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> lucy - > > >> > > >> take a look at > > >> > >> col-gen-reqs-0 > > >> 6.txt> > > >> section 6.16, > > >> > > >> if there is a need to consider - as you wrote - that "PCE > > >> should support > > >> time-base reservation in the general > > >> and leave as an option for carrier to implement or not." i > > >> would like to > > >> hear from operators specific rationales > > >> to incorporate as part of the communication protocol / PCE > > >> processing any > > >> time constraint > > >> > > >> now more fundamentally and as stated the role of the group is > > >> to define IP > > >> communication protocols not network > > >> architectures of some sort - reason for the suggestion made > > >> on section 5 > > >> > > >> adrian mentions what is that inter-AS PCE is in scope, he > > >> forgot probably > > >> to mention to you that the primary > > >> concerns of the work ongoing here is driven by four major concerns: > > >> scalability, performance, robustness and > > >> resiliency from this perspective any time constraint is going > > >> to seriously > > >> impact all these base objectives > > >> > > >> > > >> > > >> > > >> > > >> Lucy Yong > > >> 24/05/2006 19:33 > > >> > > >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > >> cc: "'Adrian Farrel'" , "'Meral > > >> Shirazipour'" , pce@ietf.org > > >> Subject: RE: [Pce] Comments about > > >> draft-ietf-pce-architecture-05 > > >> > > >> > > >> Dimitri, > > >> > > >> Because for some important reservations, carrier want to > > >> reserve the specific path for many purposes such as better > > >> optimization, request > > >> length > > >> period, service guarantee, etc. > > >> > > >> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE > > >> elements? We > > >> are > > >> defining the architecture now. > > >> > > >> Adrian has mentioned that it is in PCE scope. > > >> > > >> Regards, > > >> Lucy > > >> > > >> -----Original Message----- > > >> From: Dimitri.Papadimitriou@alcatel.be > > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > > >> Sent: Wednesday, May 24, 2006 12:25 PM > > >> To: Lucy Yong > > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> the question is why "time constraint" should be taken into > > >> account during path computation that would justify > > >> incorporation into the communication between LSR-PCE/PCE-PCE > elements > > >> > > >> scheduling of LSPs - themselves - is outside the scope of the > > >> comm process between LSR-PCE/PCE-PCE elements, it is even > > >> outside the scope of the PCE (since not a resource manager of > > >> some sort) > > >> > > >> > > >> > > >> > > >> > > >> Lucy Yong > > >> 24/05/2006 19:08 > > >> > > >> To: "'Adrian Farrel'" , "'Meral > > >> Shirazipour'" > > >> cc: pce@ietf.org > > >> Subject: RE: [Pce] Comments about > > >> draft-ietf-pce-architecture-05 > > >> > > >> > > >> All, > > >> > > >> Thank you for all the comments. > > >> PCE should support time-base reservation in the general and > > >> leave as an option for carrier to implement or not. If we > > >> exclude this functionality, > > >> it > > >> is hard to see the full automatic network because there are > > >> quite these kinds of service demands and carrier also > > >> encourages the pre-order so they can proactively engineer the > > >> network. I'll be glad to write an informational draft to > > >> explain the possible mechanism and protocols. Weather the > > >> function should be maintained in the same database or > > >> separated databases, it would be better to see after > > >> clarifying the functionality of each element first, and then > > >> decide the solution. The service reservation database > > >> mentioned here has a lot of information that PCE does not > > >> need and has no responsibility to maintain them. Maybe some > > >> cache mechanism could be used. Welcome anyone to provide the > > >> input on the informational draft. > > >> > > >> Best Regards, > > >> Lucy > > >> > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Wednesday, May 24, 2006 11:11 AM > > >> To: Meral Shirazipour; Lucy Yong > > >> Cc: pce@ietf.org > > >> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> Begging your pardon, Meral, but I'm a bit confused. > > >> > > >> > I agree with what you say here. This is a fact to consider > > >> > especially > > >> if > > >> > > >> > the > > >> > PCE architecture is to be adapted later on for inter-AS TE in the > > >> > 'Internet'. > > >> > What you say here is important if we consider the Internet > peering > > >> models. > > >> > > >> The architecture is already intended to be "adapted" for that > > >> purpose. > > >> Have > > >> a quick read through the first few sections and you'll see ample > > >> discussion > > >> of inter-AS. > > >> > > >> Lucy's email seems to me to be about the time-based reservation of > > >> resources. This doesn't seem to me to be outside the scope of > > >> the current > > >> architecture, but one might want to write down how PCE is > > >> used for that > > >> purpose as an informational draft. > > >> > > >> Personally, I would find Lucy's suggestion of a distinct > > >> component and > > >> database that was consulted for each computation request a > > >> costly idea, > > >> and > > >> would prefer to see this type of function rolled into a > > >> single database. > > >> > > >> Adrian > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Pce mailing list > > >> Pce@lists.ietf.org > > >> https://www1.ietf.org/mailman/listinfo/pce > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Pce mailing list > > >> Pce@lists.ietf.org > > >> https://www1.ietf.org/mailman/listinfo/pce > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 25 16:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjM2X-0002cP-LF; Thu, 25 May 2006 16:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjM2V-0002bv-Sa for pce@ietf.org; Thu, 25 May 2006 16:02:35 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjM2O-0001D4-3j for pce@ietf.org; Thu, 25 May 2006 16:02:35 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZU00HW77IRYN@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 12:59:16 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZU00B7G7IG6A@usaga01-in.huawei.com> for pce@ietf.org; Thu, 25 May 2006 12:59:15 -0700 (PDT) Date: Thu, 25 May 2006 15:02:12 -0500 From: Lucy Yong Subject: RE: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce-architecture-05 In-reply-to: <626FC7C6A97381468FB872072AB5DDC8C2D9AD@XCH-SW-42.sw.nos.boeing.com> To: "'Drake, John E'" , 'Adrian Farrel' , 'Payam Torab' , Dimitri.Papadimitriou@alcatel.be Message-id: <002f01c68036$208e8c00$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org John, Please keep in mind, not all the future books need to reserve the bandwidth, especially for the future order that requires carrier to build new network spans. We will gradually address Dimitri's concern. The design philosophy is to keep path computation functionality in the same place. Thanks, Lucy -----Original Message----- From: Drake, John E [mailto:John.E.Drake2@boeing.com] Sent: Thursday, May 25, 2006 2:50 PM To: Lucy Yong; Adrian Farrel; Payam Torab; Dimitri.Papadimitriou@alcatel.be Cc: pce@ietf.org Subject: RE: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce-architecture-05 Lucy, It's probably just a matter of design philosophy. If you want to use time- based, I think you need to lock-step the network through time and you need to address the set of issues that Dimitri raised. I don't remember if Dimitri raised the issue that unplanned link/node outages may wreak havoc with your nicely planned future. If you don't want to use time-based, then pre-emption mechanisms in signaling allow the network to adapt to the conditions at a given point in time. Thanks, John > -----Original Message----- > From: Lucy Yong [mailto:lucyyong@huawei.com] > Sent: Thursday, May 25, 2006 12:27 PM > To: Drake, John E; 'Adrian Farrel'; 'Payam Torab'; > Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce- > architecture-05 > > Hi John, > > John, > > It is hard to see this time-based feature will be implemented on NE. > If a network does not use PCE based architecture, carrier has to implement > in other way like today's. However, today's solution, carrier needs to > have > two path computation engines: one in the network and one in the management > system. That is why PCE provides this special value as I see. > > Thanks, > Lucy > > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Thursday, May 25, 2006 1:38 PM > To: Lucy Yong; Adrian Farrel; Payam Torab; > Dimitri.Papadimitriou@alcatel.be > Cc: pce@ietf.org > Subject: RE: What is the TED? Was: [Pce] Comments > aboutdraft-ietf-pce-architecture-05 > > Hi, > > I had a clarification question. Isn't it the case that it is a matter > of policy whether a given node uses a PCE or computes/expands the ERO > itself? > > If so, then I think time-based may be problematic as the PCE operating > in the future domain will have no idea of the EROs that will be computed > in the future by the nodes not using the PCE. > > Thanks, > > John > > > -----Original Message----- > > From: Lucy Yong [mailto:lucyyong@huawei.com] > > Sent: Wednesday, May 24, 2006 3:07 PM > > To: 'Adrian Farrel'; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > > Cc: pce@ietf.org > > Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce- > > architecture-05 > > > > Hi Adrian, > > > > Great explanation. Thanks. > > Since PCE is the only path computation engine, any path reservation > needs > > to > > go through it even the result could be saved in TED. I understand the > TED > > may be fed by IGP extensions or potentially by other means. This other > > could > > be the reservation system. However, the reservation system only has > > ingress > > and egress information, it does not have travel path information, TED > can > > not compute the path either. Therefore, it needs to go through the > PCE. No > > need to another path computation engine. > > > > Regards, > > Lucy > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Wednesday, May 24, 2006 4:34 PM > > To: Lucy Yong; 'Payam Torab'; Dimitri.Papadimitriou@alcatel.be > > Cc: pce@ietf.org > > Subject: What is the TED? Was: [Pce] Comments about > > draft-ietf-pce-architecture-05 > > > > Hi Lucy, > > > > I think that some of the confusion may be coming from the definition > of > > TED. > > > > In the architecture I-D we have > > 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. > > and also > > ...a PCE would > > be able to compute the path of a TE LSP by operating on the TED and > > considering bandwidth and other constraints applicable to the TE > LSP > > service request. > > > > This gives us the somewhat circular definition that the TED is the > > database > > on which PCE operates to compute TE paths. You might think that this > TED > > is > > exactly the database of TE information advertised by an IGP, and that > > would > > be an entirely reasonable implementation, but the architecture and > > definitions deliberately allow the TED to be supplemented from other > > sources, or even created entirely from other sources. > > > > Regards, > > Adrian > > > > ----- Original Message ----- > > From: "Lucy Yong" > > To: "'Payam Torab'" ; > > > > Cc: > > Sent: Wednesday, May 24, 2006 9:48 PM > > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > > > > > Payam, > > > > > > The draft specifies five architecture scenarios. Suggest adding one > for > > > time-based reservation. Giving the definition of TED, I don't see it > can > > > serve that function properly. > > > TED contains topology and resource information from network. It may > be > > > embedded in NE. It is good to have a place to hold real network > > > information > > > and another place hold all reservations. You can flexibly apply > policy > > to > > > manage which bandwidth need to reserve ahead and which is only a > book. > > It > > > is > > > hard to see the implementation done in TED. > > > > > > Lucy > > > > > > -----Original Message----- > > > From: Payam Torab [mailto:ptorab@lopsys.com] > > > Sent: Wednesday, May 24, 2006 2:31 PM > > > To: 'Lucy Yong'; Dimitri.Papadimitriou@alcatel.be > > > Cc: pce@ietf.org > > > Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > > > > > Lucy- > > > > > > What do you mean by "architecture scenario" below? I don't see any > > > conflict > > > between the current PCE architecture, and adding an element of time > to > > > path > > > computation. You can certainly add time constraints to TED, as well > as > > > computation algorithms and support scheduling if you wish. > > > > > > You mention "It seems that current TED definition does not serve > this > > > function (scheduling)" - How is TED definition blocking you from > > > scheduling? > > > > > > Thanks, > > > Payam Torab > > > > > >> -----Original Message----- > > >> From: Lucy Yong [mailto:lucyyong@huawei.com] > > >> Sent: Wednesday, May 24, 2006 3:11 PM > > >> To: Dimitri.Papadimitriou@alcatel.be > > >> Cc: pce@ietf.org > > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> > > >> Hi Dimitri, > > >> > > >> Thank you for the comments. It is understood that the group > > >> goal is to study IP communication protocols not network > > >> architecture. However, they can not be completely separated. > > >> Before we are clear about the architecture and its > > >> components, we can't really specify the protocol, do we? The > > >> suggestion here is to add another architecture scenario which > > >> enables to support time-based reservation. I don't see this > > >> impact the protocol study. It simply adds a value for PCE > > >> based architecture. If we only study the protocols between > > >> LSR-PCE and PCE-PCE, adding this scenario does not add > > >> addition work at all. I don't see how this scenario impacts > > > > >> the scalability, performance, robustness and resiliency at > > >> all. If it is, it is scared what we are doing here. > > >> > > >> Regards, > > >> Lucy > > >> > > >> > > >> -----Original Message----- > > >> From: Dimitri.Papadimitriou@alcatel.be > > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > > >> Sent: Wednesday, May 24, 2006 12:49 PM > > >> To: Lucy Yong > > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> lucy - > > >> > > >> take a look at > > >> > >> col-gen-reqs-0 > > >> 6.txt> > > >> section 6.16, > > >> > > >> if there is a need to consider - as you wrote - that "PCE > > >> should support > > >> time-base reservation in the general > > >> and leave as an option for carrier to implement or not." i > > >> would like to > > >> hear from operators specific rationales > > >> to incorporate as part of the communication protocol / PCE > > >> processing any > > >> time constraint > > >> > > >> now more fundamentally and as stated the role of the group is > > >> to define IP > > >> communication protocols not network > > >> architectures of some sort - reason for the suggestion made > > >> on section 5 > > >> > > >> adrian mentions what is that inter-AS PCE is in scope, he > > >> forgot probably > > >> to mention to you that the primary > > >> concerns of the work ongoing here is driven by four major concerns: > > >> scalability, performance, robustness and > > >> resiliency from this perspective any time constraint is going > > >> to seriously > > >> impact all these base objectives > > >> > > >> > > >> > > >> > > >> > > >> Lucy Yong > > >> 24/05/2006 19:33 > > >> > > >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > >> cc: "'Adrian Farrel'" , "'Meral > > >> Shirazipour'" , pce@ietf.org > > >> Subject: RE: [Pce] Comments about > > >> draft-ietf-pce-architecture-05 > > >> > > >> > > >> Dimitri, > > >> > > >> Because for some important reservations, carrier want to > > >> reserve the specific path for many purposes such as better > > >> optimization, request > > >> length > > >> period, service guarantee, etc. > > >> > > >> Why should PCE WG limits the scope between LSR-PCE/PCE-PCE > > >> elements? We > > >> are > > >> defining the architecture now. > > >> > > >> Adrian has mentioned that it is in PCE scope. > > >> > > >> Regards, > > >> Lucy > > >> > > >> -----Original Message----- > > >> From: Dimitri.Papadimitriou@alcatel.be > > >> [mailto:Dimitri.Papadimitriou@alcatel.be] > > >> Sent: Wednesday, May 24, 2006 12:25 PM > > >> To: Lucy Yong > > >> Cc: 'Adrian Farrel'; 'Meral Shirazipour'; pce@ietf.org > > >> Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> the question is why "time constraint" should be taken into > > >> account during path computation that would justify > > >> incorporation into the communication between LSR-PCE/PCE-PCE > elements > > >> > > >> scheduling of LSPs - themselves - is outside the scope of the > > >> comm process between LSR-PCE/PCE-PCE elements, it is even > > >> outside the scope of the PCE (since not a resource manager of > > >> some sort) > > >> > > >> > > >> > > >> > > >> > > >> Lucy Yong > > >> 24/05/2006 19:08 > > >> > > >> To: "'Adrian Farrel'" , "'Meral > > >> Shirazipour'" > > >> cc: pce@ietf.org > > >> Subject: RE: [Pce] Comments about > > >> draft-ietf-pce-architecture-05 > > >> > > >> > > >> All, > > >> > > >> Thank you for all the comments. > > >> PCE should support time-base reservation in the general and > > >> leave as an option for carrier to implement or not. If we > > >> exclude this functionality, > > >> it > > >> is hard to see the full automatic network because there are > > >> quite these kinds of service demands and carrier also > > >> encourages the pre-order so they can proactively engineer the > > >> network. I'll be glad to write an informational draft to > > >> explain the possible mechanism and protocols. Weather the > > >> function should be maintained in the same database or > > >> separated databases, it would be better to see after > > >> clarifying the functionality of each element first, and then > > >> decide the solution. The service reservation database > > >> mentioned here has a lot of information that PCE does not > > >> need and has no responsibility to maintain them. Maybe some > > >> cache mechanism could be used. Welcome anyone to provide the > > >> input on the informational draft. > > >> > > >> Best Regards, > > >> Lucy > > >> > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Wednesday, May 24, 2006 11:11 AM > > >> To: Meral Shirazipour; Lucy Yong > > >> Cc: pce@ietf.org > > >> Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 > > >> > > >> Begging your pardon, Meral, but I'm a bit confused. > > >> > > >> > I agree with what you say here. This is a fact to consider > > >> > especially > > >> if > > >> > > >> > the > > >> > PCE architecture is to be adapted later on for inter-AS TE in the > > >> > 'Internet'. > > >> > What you say here is important if we consider the Internet > peering > > >> models. > > >> > > >> The architecture is already intended to be "adapted" for that > > >> purpose. > > >> Have > > >> a quick read through the first few sections and you'll see ample > > >> discussion > > >> of inter-AS. > > >> > > >> Lucy's email seems to me to be about the time-based reservation of > > >> resources. This doesn't seem to me to be outside the scope of > > >> the current > > >> architecture, but one might want to write down how PCE is > > >> used for that > > >> purpose as an informational draft. > > >> > > >> Personally, I would find Lucy's suggestion of a distinct > > >> component and > > >> database that was consulted for each computation request a > > >> costly idea, > > >> and > > >> would prefer to see this type of function rolled into a > > >> single database. > > >> > > >> Adrian > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Pce mailing list > > >> Pce@lists.ietf.org > > >> https://www1.ietf.org/mailman/listinfo/pce > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Pce mailing list > > >> Pce@lists.ietf.org > > >> https://www1.ietf.org/mailman/listinfo/pce > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 26 23:32:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjpWd-0008UJ-Bs; Fri, 26 May 2006 23:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjpWb-0008Qa-AA for pce@ietf.org; Fri, 26 May 2006 23:31:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjowg-0003vM-Hw for pce@ietf.org; Fri, 26 May 2006 22:54:30 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjopA-0000KD-Fb for pce@ietf.org; Fri, 26 May 2006 22:46:45 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZW00CWRL31XF@szxga03-in.huawei.com> for pce@ietf.org; Sat, 27 May 2006 10:47:25 +0800 (CST) Received: from M55527 ([10.110.114.96]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZW0075LL30FL@szxga03-in.huawei.com> for pce@ietf.org; Sat, 27 May 2006 10:47:25 +0800 (CST) Date: Sat, 27 May 2006 10:38:37 +0800 From: Mach Chen Subject: [PCE]Comments about draft-ietf-pce-architecture-05 To: JP Vasseur , Adrian Farrel , gash@att.com Message-id: <008301c68136$a8856790$60726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: -1.2 (-) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0074821189==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0074821189== Content-type: multipart/alternative; boundary="Boundary_(ID_UoLH72znFzBkROTQwT0jFA)" This is a multi-part message in MIME format. --Boundary_(ID_UoLH72znFzBkROTQwT0jFA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi,Adrian,Vasseur,Ash I just have finished read the draft,it's good. Here I have a question about section "5.5 Management-Based PCE Usage".NMS as the PCC sends service request to PCE and gets the response,then supplies the head-end LSR with computed path.why not PCE sends the response with service request direct to the head-end? AS it just looks like the figure as below: ----------- | ----- | Service | | TED |<-+-----------> Request | ----- | TED synchronization | | | | mechanism (for example, v | | | routing protocol) ------------- | v | | | Request | ----- | | NMS |---------+> | PCE | | | | | ----- | ------------- ----------- Service |Response Request | v ---------- Signaling ----------- | Head-End | Protocol | Adjacent | | Node |<--------->| Node | ---------- ----------- If so ,we can reduce the complication and burden of NMS,and increase the efficiency (NMS don't need to transfer respone between PCE and head-end). Regards, Mach Chen Huawei Technologies, Beijing,China --Boundary_(ID_UoLH72znFzBkROTQwT0jFA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,Adrian,Vasseur,Ash
    I just have finished read the draft,it's good.
 
    Here I have a question about section "5.5 Management-Based PCE Usage".NMS as the PCC sends service request to PCE and gets the response,then supplies the head-end LSR with computed path.why not PCE sends the response with service request direct to the head-end? AS it just looks like the figure as below:
   
                                 -----------
                                |   -----   |
            Service             |  | TED |<-+----------->
            Request             |   -----   |  TED synchronization
               |                |     |     |  mechanism (for example,
               v                |     |     |  routing protocol)
         -------------          |     v     |
        |             | Request |   -----   |
        |     NMS     |---------+> | PCE |  |
        |             |         |   -----   |
         -------------           -----------
                              Service |Response
                              Request |
                                      v
                               ----------  Signaling  -----------
                              | Head-End | Protocol  | Adjacent  |
                              |   Node   |<--------->|   Node    |
                               ----------             -----------
 
If so ,we can reduce the complication and burden of NMS,and increase the efficiency (NMS don't need  to transfer respone between PCE and head-end).
 

Regards,

Mach Chen

Huawei Technologies, Beijing,China

--Boundary_(ID_UoLH72znFzBkROTQwT0jFA)-- --===============0074821189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0074821189==-- From pce-bounces@lists.ietf.org Sat May 27 09:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjyrY-0007WO-Mr; Sat, 27 May 2006 09:29:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjyrW-0007WJ-6l for pce@ietf.org; Sat, 27 May 2006 09:29:50 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjyrT-0005ai-Jq for pce@ietf.org; Sat, 27 May 2006 09:29:50 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 27 May 2006 06:29:47 -0700 X-IronPort-AV: i="4.05,179,1146466800"; d="scan'208,217"; a="1814086490:sNHT51680896" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4RDTloJ030221; Sat, 27 May 2006 06:29:47 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4RDTkIs027632; Sat, 27 May 2006 06:29:46 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 May 2006 09:29:45 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 May 2006 09:29:45 -0400 In-Reply-To: <008301c68136$a8856790$60726e0a@china.huawei.com> References: <008301c68136$a8856790$60726e0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Message-Id: <5141EDE6-0C1A-4A1A-BD54-9EEB085420D3@cisco.com> From: JP Vasseur Subject: Re: [PCE]Comments about draft-ietf-pce-architecture-05 Date: Sat, 27 May 2006 09:29:43 -0400 To: Mach Chen X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 27 May 2006 13:29:45.0186 (UTC) FILETIME=[9E3FCC20:01C68191] DKIM-Signature: a=rsa-sha1; q=dns; l=10293; t=1148736587; x=1149600587; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[PCE]Comments=20about=20draft-ietf-pce-architecture-05; X=v=3Dcisco.com=3B=20h=3DSI0+PiHYebWHfDGBRzgz0mbaXSA=3D; b=nuLnzzFifUdaZYFxw1ZN4Fci1BN0yKX3yP41p+dOkxJq8Q26y7L6ugY+yn1HyhtbGRbWfQRz rFDgCJ6xY3DNbDic4GdWfNo8S7V+3SRWRMWRF6A1Jz/spK+TO6ei+hnW; Authentication-Results: sj-dkim-5.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0653314717==" Errors-To: pce-bounces@lists.ietf.org --===============0653314717== Content-Type: multipart/alternative; boundary=Apple-Mail-83-778175352 --Apple-Mail-83-778175352 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On May 26, 2006, at 10:38 PM, Mach Chen wrote: > Hi,Adrian,Vasseur,Ash > I just have finished read the draft,it's good. > > Here I have a question about section "5.5 Management-Based PCE > Usage".NMS as the PCC sends service request to PCE and gets the > response,then supplies the head-end LSR with computed path.why not > PCE sends the response with service request direct to the head-end? Because the architecture defines the interaction between a PCC and a PCE and in this case the NMS acts as a PCC. If A asks a question to B, B may answer to C but the dialogue may quickly be confusing. Thanks. JP. > AS it just looks like the figure as below: > > ----------- > | ----- | > Service | | TED |<-+-----------> > Request | ----- | TED synchronization > | | | | mechanism (for example, > v | | | routing protocol) > ------------- | v | > | | Request | ----- | > | NMS |---------+> | PCE | | > | | | ----- | > ------------- ----------- > Service |Response > Request | > v > ---------- Signaling ----------- > | Head-End | Protocol | Adjacent | > | Node |<--------->| Node | > ---------- ----------- > > If so ,we can reduce the complication and burden of NMS,and > increase the efficiency (NMS don't need to transfer respone > between PCE and head-end). > > Regards, > > Mach Chen > > Huawei Technologies, Beijing,China > > --Apple-Mail-83-778175352 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On May 26, = 2006, at 10:38 PM, Mach Chen wrote:

=A0=A0=A0 I = just have finished read the draft,it's = good.
=A0

Because the architecture = defines the interaction between a PCC and a PCE and in this case the NMS = acts as a PCC. If A asks a question to B, B may answer to C but the = dialogue may quickly be confusing.

Thanks.

JP.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 |=A0=A0=A0=A0= |=A0 mechanism (for example,
=A0=A0=A0=A0=A0=A0= =A0=A0 -------------=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 v=A0=A0=A0=A0= |
=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Request |=A0=A0 -----=A0=A0 = |
=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0 NMS=A0=A0=A0=A0 |---------+> | PCE |=A0 |
=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 -----=A0=A0 = |
=A0=A0=A0=A0=A0=A0= =A0=A0 -------------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -----------
=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 Service |Response
=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 Request |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0 =A0=A0=A0 v
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0 = =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 ----------=A0 Signaling=A0 = -----------
=A0=A0=A0=A0=A0=A0= =A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0 | Head-End | = Protocol =A0| Adjacent=A0 |
=A0=A0=A0=A0=A0=A0= =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0 = ----------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-----------=
=A0
If so ,we can = reduce the complication and=A0burden=A0of NMS,and increase the = efficiency (NMS don't need=A0 to transfer respone between PCE and = head-end).
=A0
<= P class=3D"MsoNormal">Regards,

Mach Chen

Huawei Technologies, = Beijing,China



= --Apple-Mail-83-778175352-- --===============0653314717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0653314717==-- From pce-bounces@lists.ietf.org Sun May 28 16:46:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkS93-0005mq-RB; Sun, 28 May 2006 16:45:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkS93-0005mk-0M for pce@ietf.org; Sun, 28 May 2006 16:45:53 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkS92-0005NO-7b for pce@ietf.org; Sun, 28 May 2006 16:45:52 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 May 2006 22:45:50 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 28 May 2006 22:45:50 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260379B4C1@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MPLS2006 INTERNATIONAL CONFERENCE] Update of the CFP Thread-Index: AcaCl7PBOfOwzsw4TyO6GxOSnXolBQ== From: "MOIGNARD Renaud RD-CORE-LAN" To: X-OriginalArrivalTime: 28 May 2006 20:45:50.0729 (UTC) FILETIME=[B48A8F90:01C68297] X-Spam-Score: 0.1 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e Cc: Subject: [Pce] [MPLS2006 INTERNATIONAL CONFERENCE] Update of the CFP X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1252283215==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1252283215== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_002A_01C682A8.775084C0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C682A8.775084C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002B_01C682A8.775084C0" ------=_NextPart_001_002B_01C682A8.775084C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Call for Presentations at MPLS 2006 MPLS 2006, the 9th Annual International Conference on MPLS and Related Technologies, will be held on October 15 through 18, 2006, in Washington, DC. The Program Committee of MPLS2006 is soliciting presentation proposals for the conference. The program committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. The deadline for submission of presentation proposals is June 7, 2006. Submit your presentation : http://www.isocore.com/mpls2006/cfpupload.php Technical Program Committee Co-Chairs Daniel Awduche [Verizon Business] Renaud Moignard [France Telecom] Technical Program Committee Zubair Ahmad [Equant] David McDysan [Verizon] Loa Andersson [Acreo] Monique Morrow [Cisco Systems] Peter Arberg [Redback] Eiji Oki [NTT] Alia Atlas [Google] Lyndon Ong [Ciena] Jerry Ash [ATT] Tomohiro Otani [KDDI Labs] Deborah Brungard [ATT] Dimitri Papadimitriou [Alcatel] Marco Carugi [Nortel Networks] Rajiv Papneja [Isocore] Bruce Davie [Cisco Systems] Richard Rabbat [Fujitsu] Luyuan Fang [ATT] Yakov Rekhter [Juniper Networks] Adrian Farrel [Old Dog Consulting] George Swallow [Cisco Systems] Don Fedyk [Nortel Networks] Kohei Shiomoto [NTT] Bur Goode [ATT] JP Vasseur [Cisco Systems] Joao Gomes [Orange] Anwar Walid [Lucent] Bijan Jabbari [Isocore] Lei Wang [Telenor] Kireeti Kompella [Juniper Networks] Bert Wijnen [Lucent] Vach Kompella [Alcatel] Rajesh Yadav [Verizon] Francois Le Faucheur [Cisco Systems] Naoaki Yamanaka [Keio] Jean Louis Le Roux [France Telecom] Ferit Yegenoglu [Lockheed Martin] Bill Li [Huawei] Ali Zadeh [Isocore] Tove Madsen [Acreo] Yong Zhou [Redback] Andy Mallis [Tellabs] James Zhu [Huawei] Alex Zinin [Alcatel] This year's conference will include, but will not be limited to, the following topics: - MPLS in multi-area and multi-AS networks - Point-to-multipoint MPLS and applications - Multicast in MPLS L3 VPNs and for VPLS - Single and Multi-hop Pseudowire placement, setup, and management - Providing QoS in MPLS networks - MPLS network management - OAM for MPLS networks - MPLS in Next Generation Networks - Voice over IP/MPLS - IMS and IPTv over MPLS - Triple-play applications on MPLS - MPLS-enabled Advanced services and converged networks - Interworking and migration for MPLS and GMPLS - Multi-layer networks and integration with non-packet technologies - Deploying, interworking, and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance, and security - Testing: MPLS test tools and certification experience - Protection, restoration, and reliability - Network processors for MPLS and GMPLS - MPLS/GMPLS control plane resilience, scaling and robustness - MPLS TE applications of the Path Computation Element (PCE) - MPLS to the access network - MPLS and IPv6 - MPLS in the Enterprise Arena - Carrier Ethernet Services - GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI) - Fast Routing Convergence - High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc) - MPLS in the Mobile Trunking Space - MPLS Applications for Mobile Access Optimization For additional information please see www.mpls2006.com . ------=_NextPart_001_002B_01C682A8.775084C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [MPLS2006 INTERNATIONAL CONFERENCE] Update of the CFP

Call for Presentations at MPLS = 2006
MPLS 2006, the 9th Annual = International Conference on MPLS and Related Technologies, will be held = on October 15 through 18, 2006, in Washington, DC. The Program Committee = of MPLS2006 is soliciting presentation proposals for the conference. The = program committee seeks original and unpublished work to continue the = tradition initiated by this conference in 1998 of covering cutting-edge = topics. Presentations addressing new technologies and operational = experience are solicited from network equipment vendors, service = providers, the research community, government agencies, and enterprise = users.

The deadline for submission of = presentation proposals is June 7, 2006.
Submit your = presentation : http://www.isocore.com/mpls2006/cfpupload.php<= /A>=20
Technical Program Committee = Co-Chairs
Daniel Awduche [Verizon Business] = Renaud Moignard [France Telecom]
Technical Program = Committee
Zubair Ahmad [Equant] David McDysan = [Verizon]
Loa Andersson [Acreo] Monique Morrow = [Cisco Systems]
Peter Arberg [Redback] Eiji Oki = [NTT]
Alia Atlas [Google] Lyndon Ong = [Ciena]
Jerry Ash [ATT] Tomohiro Otani [KDDI = Labs]
Deborah Brungard [ATT] Dimitri = Papadimitriou [Alcatel]
Marco Carugi [Nortel Networks] Rajiv = Papneja [Isocore]
Bruce Davie [Cisco Systems] Richard = Rabbat [Fujitsu]
Luyuan Fang [ATT] Yakov Rekhter = [Juniper Networks]
Adrian Farrel [Old Dog Consulting] = George Swallow [Cisco Systems]
Don Fedyk [Nortel Networks] Kohei = Shiomoto [NTT]
Bur Goode [ATT] JP Vasseur [Cisco = Systems]
Joao Gomes [Orange] Anwar Walid = [Lucent]
Bijan Jabbari [Isocore] Lei Wang = [Telenor]
Kireeti Kompella [Juniper Networks] = Bert Wijnen [Lucent]
Vach Kompella [Alcatel] Rajesh Yadav = [Verizon]
Francois Le Faucheur [Cisco Systems] = Naoaki Yamanaka [Keio]
Jean Louis Le Roux [France Telecom] = Ferit Yegenoglu [Lockheed Martin]
Bill Li [Huawei] Ali Zadeh = [Isocore]
Tove Madsen [Acreo] Yong Zhou = [Redback]
Andy Mallis [Tellabs] James Zhu = [Huawei]
Alex Zinin [Alcatel]
This year's conference will include, = but will not be limited to, the following topics:
- MPLS in multi-area and multi-AS = networks
- Point-to-multipoint MPLS and applications
- Multicast in MPLS L3 VPNs and for VPLS
- Single and Multi-hop Pseudowire placement, setup, and management
- Providing QoS in MPLS networks
- MPLS network management
- OAM for MPLS networks
- MPLS in Next Generation Networks
- Voice over IP/MPLS
- IMS and IPTv over MPLS
- Triple-play applications on MPLS
- MPLS-enabled Advanced services and converged networks
- Interworking and migration for MPLS and GMPLS
- Multi-layer networks and integration with non-packet technologies
- Deploying, interworking, and operating L2 and L3 MPLS VPNs
- MPLS deployment experience: scaling, performance, and security
- Testing: MPLS test tools and certification experience
- Protection, restoration, and reliability
- Network processors for MPLS and GMPLS
- MPLS/GMPLS control plane resilience, scaling and robustness
- MPLS TE applications of the Path Computation Element (PCE)
- MPLS to the access network
- MPLS and IPv6
- MPLS in the Enterprise Arena =
- Carrier Ethernet Services
- GMPLS Applications (L1 VPNs, ASON, = Optical Internetworking, NNI/UNI)
- Fast Routing Convergence
- High Availability (Graceful = Restart, Non-Stop Routing, In-Service Software Upgrades, etc)
- MPLS in the Mobile Trunking Space =
- MPLS Applications for Mobile Access = Optimization
For additional information please see = www.mpls2006.com.


------=_NextPart_001_002B_01C682A8.775084C0-- ------=_NextPart_000_002A_01C682A8.775084C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISRjCCBHYw ggNeoAMCAQICAh1yMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFu Y2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRp b25uZWxsZTAeFw0wNDA3MjYxMzM4MDhaFw0wNzA3MjYxMzM4MDhaMIGhMQswCQYDVQQGEwJGUjEX MBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQVNQSUMxGDAWBgNVBAMTD1Jl bmF1ZCBNT0lHTkFSRDEYMBYGCgmSJomT8ixkAQETCFJJRU02NTExMTAwLgYJKoZIhvcNAQkBFiFy ZW5hdWQubW9pZ25hcmRAZnJhbmNldGVsZWNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBANwKgWWbcF4ydr3artBnnPCZZvyQeQMOCr4prBQxdmfE6L0eXZFerJZ1OfljPDu6zzUxWwZ1 mxm0UJeduoV4APyYSy1P7ur1VKIProV10CLRFrfD5P8JKYN/voknWGkk5k02wvFVYX503wlUruq1 RoiBKPOXRWh5aXhtPbSYMaLHAgMBAAGjggF+MIIBejAdBgNVHQ4EFgQUyZmjipbYDUl8ssXnh1Po jgugJRcwHwYDVR0jBBgwFoAUp4e40Iv0b+PBwNrtjrTgpxAp/NgwgZIGA1UdHwSBijCBhzBHoEWg Q4ZBaHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxvcGVyYXRp b25uZWxsZS5jcmwwPKA6oDiGNmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0ZWxlY29tLmZyL2NybG9w ZXJhdGlvbm5lbGxlLmNybDAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwEQYJ YIZIAYb4QgEBBAQDAgUgMCwGA1UdEQQlMCOBIXJlbmF1ZC5tb2lnbmFyZEBmcmFuY2V0ZWxlY29t LmNvbTA9BglghkgBhvhCAQ0EMBYuQ2VydGlmaWNhdCBkZSBDaGlmZnJlbWVudCBwb3VyIFJlbmF1 ZCBNT0lHTkFSRDANBgkqhkiG9w0BAQUFAAOCAQEAh34Ot/bDb9UPOivDtJ+8X7MChib5OX76CPfD dtO9iMl2/Zqu9pOh2dniPnlU8k3tFAcnrt+cF1SDm9fA/57rf5yPiR3RFx/KWfWD/vf92GlkRaWg 04zSCqLrhkfgJXGRuRyl4NNwghEdwzhwPYJYjcz3WowsfRX2dKZgImYuWcXzZLPEyqYu/0sXUhUy PvHuSwMNyeXTs9Dsg2gUbUWFUeLCdQ+vFXv9a+k6G/OlmLKka0nAYULytyH5/5+wboprmPF6go9K JuU4oKdLtDcevXhXBRZh3rhAG6Ogc+YxalM7TP2sUq1UsXTlj8766byySyxx9ZZlkOFKerqFgGRD BTCCBIAwggNooAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoT DkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJh Y2luZTAeFw0wMjEwMDMwNzA3NThaFw0xMjEwMDIwNzA3NThaMFQxCzAJBgNVBAYTAkZSMRcwFQYD VQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEXMBUGA1UEAxMORlRSRCBB QyBSYWNpbmUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDfNb9DTp38mMZszg1TJwHe ONcylQu+PXC7oOjphIYne0HQQHUSXjKDKJ7vblnTkArsr3Ruu1QrAOvOmkmwz8k06M03hcGZ0Y92 8oWa3KG6idksdKwNj40JqWbpIEkt5fAsNDp2TuZaUGUgXzieBdDkY3uyFq0G/EG6T7f3Gwj4nu2Y 4VIpa947Nk0ljwFK4WSSqdDTUh8ZOVfpaAfsUi6laynWFpaIquEa4xKVy/O/djTMEelEZva8ADib tC8GFNO6uoiyjiNdOqk7ynoy1cQC+frE+WFiv7m4vIXS4VvLvQsTk5knyfaWPANRYqj8lnCd4B0s 9iLUbx9piatXPyLjAgMBAAGjggFbMIIBVzASBgNVHRMBAf8ECDAGAQH/AgEBMB0GA1UdDgQWBBS3 Se6TQSJ/2aiXlSc+ZGaerhg/AzB8BgNVHSMEdTBzgBS3Se6TQSJ/2aiXlSc+ZGaerhg/A6FYpFYw VDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFz cGljMRcwFQYDVQQDEw5GVFJEIEFDIFJhY2luZYIBADAOBgNVHQ8BAf8EBAMCAQYwgYAGA1UdHwR5 MHcwP6A9oDuGOWh0dHA6Ly9sdWNpZmVyLnJkLmZyYW5jZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3Js cmFjaW5lLmNybDA0oDKgMIYuaHR0cDovL3BraS1sLnJkLmZyYW5jZXRlbGVjb20uZnIvY3JscmFj aW5lLmNybDARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAGi8vbslCQ47x0nr 1vZXWmbBvs5e0NSfj5zDzgn32B3ShyOv67c6dEvq1BjFhHRfNhcRpxmiE9P4HOqftoD7/v92MRlo G9GgSucRI8SHn5oQO6xisabqxquD5hI+G+mHv2fYUwRZRSNiMbudc5OIRLx6JMvKBXUHc29vaueN aRQbD+6m4ncYuts5asRO0uGcftys5HoAySCepOF1yt9O41GCQW5wu2gaHUk+j9iPKk13JRu6k5Cn /8M8tcvA0skajQAaF+ly3kMjPaJhqygEYXQoLDFC6DzUQDCNTdZ9w5Qwin1oyZe1lWmssMihlZok iiJ22LTOVwdoaGhKydWRJN0wggSIMIIDcKADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV BAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEXMBUG A1UEAxMORlRSRCBBQyBSYWNpbmUwHhcNMDIxMDAzMDcxNTIwWhcNMTIxMDAyMDcxNTIwWjBcMQsw CQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMx HzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDyhK63MkH/rYERgbIgUChhp74XjBfhO+FwEZJA6zZy/6AOcOnvejY+Xhe03aIhOwCE EbzlKyZCPcT++LMw1D/wjwT1ccS9POeacqB/6gXIHVQlVgQyhhq6HPQOTnl7CgonrW9cuPj1eSXk FcN3uNb6idOlLfNUGD5GfOLiUiIkTaGmRvnQWATnz/KS9xo9o51+d3rJX3Yl47JTJO4nG73LwLgZ cx1Py5CzR2Vf4hCRhn491/JDjBdHt79TpQF/k1xGJbwOOsJ336lTCIIohWwBzzgTCKjjDlUF8dkn aJEXKQLB7W/C3Gi60rHg3/25s74ZLn6eqmKFKDQvbOIOPCfRAgMBAAGjggFbMIIBVzASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBSnh7jQi/Rv48HA2u2OtOCnECn82DB8BgNVHSMEdTBzgBS3 Se6TQSJ/2aiXlSc+ZGaerhg/A6FYpFYwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBU ZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJhY2luZYIBADAO BgNVHQ8BAf8EBAMCAQYwgYAGA1UdHwR5MHcwP6A9oDuGOWh0dHA6Ly9sdWNpZmVyLnJkLmZyYW5j ZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3JscmFjaW5lLmNybDA0oDKgMIYuaHR0cDovL3BraS1sLnJk LmZyYW5jZXRlbGVjb20uZnIvY3JscmFjaW5lLmNybDARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZI hvcNAQEFBQADggEBALaNFmEzT8zTf163U9ueSMDym2C2Q/2EX0MMHGweBX+hfSpvievSi6WWWcdG f/K07I1RXNwNkB0zMuDgdrydajzFDviZWoaoR27p+Bh8TNMZfasxgGr3qOcbyDKh2FJ50WerPC2n UFW5HB8YMOKD5MERmyqBsk+lhHRYVpp+ATgbsFETfyS+C8p05MBxJJQ24XhMgFUzqySG2fPK1gCj qEsw4Q/lrv2Vb23GLmDXr6mnyXHg9YOq0IWs+zuB5xnZomrt/2sle2TQ6sZ5tEn5YuK+JbU4uhpM ZhKE+19SXSrh9J2tGXWEaKsUaKTPLi7BTDh3OOhk+x8LDXKl3LUaTkQwggS4MIIDoKADAgECAgId cTANBgkqhkiG9w0BAQUFADBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20x EzARBgNVBAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwHhcN MDQwNzI2MTMzODA3WhcNMDcwNzI2MTMzODA3WjCBoTELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZy YW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFTUElDMRgwFgYDVQQDEw9SZW5hdWQgTU9JR05B UkQxGDAWBgoJkiaJk/IsZAEBEwhSSUVNNjUxMTEwMC4GCSqGSIb3DQEJARYhcmVuYXVkLm1vaWdu YXJkQGZyYW5jZXRlbGVjb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQClchLywuea Vw1yziql8mDBZun+5SNe/X+fpNV267k9viFGhGLRTl2MALs2O2jw4+qN3q2UCFlWSbuUjs/g31RR lsZHC2yhJphwejKCJ4GpwEvcLh9F/Hg0w8XxPCanW2cH15ktuGv7CbI2rMXTPH0P6IO1zbaMhYgT pxAkK7ysxwIDAQABo4IBwDCCAbwwHQYDVR0OBBYEFMlbTWyq4IAj1uDG142eefcX9awqMB8GA1Ud IwQYMBaAFKeHuNCL9G/jwcDa7Y604KcQKfzYMIGSBgNVHR8EgYowgYcwR6BFoEOGQWh0dHA6Ly9s dWNpZmVyLnJkLmZyYW5jZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3Jsb3BlcmF0aW9ubmVsbGUuY3Js MDygOqA4hjZodHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5mci9jcmxvcGVyYXRpb25uZWxs ZS5jcmwwDgYDVR0PAQH/BAQDAgbAMCkGA1UdJQQiMCAGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYB BAGCNxQCAjARBglghkgBhvhCAQEEBAMCBaAwWgYDVR0RBFMwUaAsBgorBgEEAYI3FAIDoB4MHG1v aWduYXJlQHJkLmZyYW5jZXRlbGVjb20uZnKBIXJlbmF1ZC5tb2lnbmFyZEBmcmFuY2V0ZWxlY29t LmNvbTA7BglghkgBhvhCAQ0ELhYsQ2VydGlmaWNhdCBkZSBTaWduYXR1cmUgcG91ciBSZW5hdWQg TU9JR05BUkQwDQYJKoZIhvcNAQEFBQADggEBAKbsVcoteE6rKkIFuZUmlIu/E9Nh7s7Hy9ncjDLb VSi/W+XbpPdI4PxGCcgiUFI8wCNfVf8RnqX8pfeT/1fJubWC4uYLfWWHJLF5i98TYntFLM+oFEfY uIV20+Q26vbjbLkqXJf5ZRAjexfbjk6X3JiPjZn2x4e60Kn2c8QQGpnQsmfxnPUL3lTUcWlJ5rQu Uu0W8bv6IY7SnZJU6aTxoiTFFoJZze/8JtP7m+DDpyN5ozBTQPS8uyWUh0aNwl9v/GW7PT3bDX+u nSM/rN2vT7NqrKcw+o1EaEEpPGFg3BpqCBDgNnomgJXgUsEIgUxEKuWleTEu8LCQXeAUecSLGYUx ggK6MIICtgIBATBiMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEG A1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZQICHXEwCQYF Kw4DAhoFAKCCAa4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYw NTI4MjA0NTQ5WjAjBgkqhkiG9w0BCQQxFgQUklVkKsbtwDwPE3W8WQ71sEly9+4wZwYJKoZIhvcN AQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcQYJKwYBBAGCNxAEMWQwYjBc MQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNw aWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUCAh1yMHMGCyqGSIb3DQEJEAILMWSg YjBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQt QXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUCAh1yMA0GCSqGSIb3DQEBAQUA BIGAPTuU9ro6AKm1xHgtvnlgTPvap3gWoVdDht96ulrICMuwHzj0la2ws9vdXzY5HJzsCwZRCtdN JwIeVCKuop7DiRejbtRZ/NcvcKS2B9LheKuPkVCnRcX4PeFfjQzgylDWMjF8HAW3bWF+0+KkiLR7 sIXxCKnOM3cfXnJgAgE8sRQAAAAAAAA= ------=_NextPart_000_002A_01C682A8.775084C0-- --===============1252283215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1252283215==-- From pce-bounces@lists.ietf.org Wed May 31 15:49:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWgA-00070x-Kx; Wed, 31 May 2006 15:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWg9-00070r-Vp for pce@ietf.org; Wed, 31 May 2006 15:48:29 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWg8-0008Rm-Jp for pce@ietf.org; Wed, 31 May 2006 15:48:29 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J05006Z4AVJ9T@usaga01-in.huawei.com> for pce@ietf.org; Wed, 31 May 2006 12:45:19 -0700 (PDT) Received: from Lee736821 ([10.124.8.245]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0500MKKAVFZG@usaga01-in.huawei.com> for pce@ietf.org; Wed, 31 May 2006 12:45:19 -0700 (PDT) Date: Wed, 31 May 2006 14:48:24 -0500 From: Young Lee To: ccamp@ops.ietf.org, pce@ietf.org Message-id: <000a01c684eb$2dba4180$f5087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcaE6y1AxIyUUwPdRviXO83vBvWlOA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Subject: [Pce] a new internet draft X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0438055068==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0438055068== Content-type: multipart/alternative; boundary="Boundary_(ID_r4NnkGSzbZOh4PBDBOuvag)" This is a multi-part message in MIME format. --Boundary_(ID_r4NnkGSzbZOh4PBDBOuvag) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi all, A new internet draft is available on the ID repository. http://www.ietf.org/internet-drafts/draft-lee-ccamp-pce-policy-recovery-00.t xt Abstract: This document describes a framework for policy-based protection/ restoration mechanism in GMPLS network. This document provides the definition for recovery policy, architecture framework and the protocol requirements to be able to support policy-based recovery mechanism. Comments and suggestions will be appreciated. Best regards, Young Lee Huawei Technologies (USA) --Boundary_(ID_r4NnkGSzbZOh4PBDBOuvag) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

Hi all,

 

A new internet draft is available on the ID repository.

 

http://www.ietf.org/internet-drafts/draft-lee-ccamp-pce-policy-recovery-00.txt

 

Abstract:

 

This document describes a framework for policy-based protection/ restoration mechanism 
in GMPLS network.  This document provides the definition for recovery policy, architecture 
framework and the protocol requirements to be able to support policy-based recovery 
mechanism.

 

Comments and suggestions will be appreciated.

 

Best regards,

 

Young Lee

Huawei Technologies (USA)

--Boundary_(ID_r4NnkGSzbZOh4PBDBOuvag)-- --===============0438055068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0438055068==--