From pce-bounces@lists.ietf.org Wed Nov 01 16:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNTN-0003ij-Q4; Wed, 01 Nov 2006 16:18:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNTL-0003U4-PX for pce@ietf.org; Wed, 01 Nov 2006 16:18:07 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNTK-0003qF-QR for pce@ietf.org; Wed, 01 Nov 2006 16:18:07 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2006 13:18:03 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208,217"; a="47591852:sNHT8105540090" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1LI2sl019136; Wed, 1 Nov 2006 16:18:02 -0500 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 kA1LI1DM007122; Wed, 1 Nov 2006 16:18:02 -0500 (EST) 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.1830); Wed, 1 Nov 2006 16:18:01 -0500 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:17:59 -0500 In-Reply-To: <20061024233725.AC8F.OKI.EIJI@lab.ntt.co.jp> References: <25168B2D-E43E-4D8F-B57B-3459B0F02DF9@cisco.com> <20061024233725.AC8F.OKI.EIJI@lab.ntt.co.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <22B6BBA4-B863-4226-8F3B-CD8697F46F07@cisco.com> From: JP Vasseur Subject: Re: [Pce] Feed-back on Monitoring ? Date: Wed, 1 Nov 2006 16:18:05 -0500 To: Eiji Oki X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Nov 2006 21:18:00.0004 (UTC) FILETIME=[35555040:01C6FDFB] DKIM-Signature: a=rsa-sha1; q=dns; l=35337; t=1162415882; x=1163279882; c=relaxed/simple; s=rtpdkim2001; 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]=20Feed-back=20on=20Monitoring=20? |To:Eiji=20Oki=20; X=v=3Dcisco.com=3B=20h=3DOaJs1szumJCUxDJ6EGgPSuNtd4w=3D; b=dR1JoSYX3yJR/zpeS/V4CoybZQQhVFIkb1dHKu+vWQLO0v53nFh69AtfHMiM/gYH+onXbg9B F7y8+5ycp7nEauxcZ3wce6JRYzcZa3vyhl2mgJMHkVgtGFdzwBmzJy7t; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 31 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f5e3f76ec5b90a46b9b8bc53da20ed8e 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="===============0074416809==" Errors-To: pce-bounces@lists.ietf.org --===============0074416809== Content-Type: multipart/alternative; boundary=Apple-Mail-295--574907785 --Apple-Mail-295--574907785 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Eiji, On Oct 24, 2006, at 10:38 AM, Eiji Oki wrote: > Hi JP, > > The ID looks very great. Thanks for your feed-back. > > I have several comments. > > 1. Section 3.2: The last sentense > The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and > LOAD- > BALANCING objects are defined in [I-D.ietf-pce-pcep]. > is not neccessary, as these objects do not appear in PCMonRep. > Indeed, it has been removed, thanks. > 2. Section 4.1 describes > P (Processing Time) - 1 bit: the P bit of the MONITORING object > carried in a PCMonReq message is set to indicate that the > processing... > > "or a PCReq message" would be added after "a PCMonReq message". > Good catch, added, thanks. > 3. Section 4.3 describes > When the processing time is requested in addition to a path > computation, the PROC-TIME object always report the actual > processing > time for that request and thus the E bits MUST be cleared. > > Is it possible to define "actulal" Min- Max- Average- procssing time > with E=0? No because for the Min, Max, Average and Variance the values are computed based on some history, they're not estimated. The case of an estimated metric is when the request relates to a particular TE LSP path computation (as opposed to a general request). I clarified: "When a request is specific (related to a particular TE LSP path computation), the G bit MUST be cleared and the Min-processing-time, Max-processing-time, Average-processing-time and Variance-processing- time MUST be set to 0x00000000." > Otherwise, when E is cleared, Min- Max- Average- procssing > time MUST be set to 0x00000000. In other words, > If the G flag of the MONITORING object is set then E bit MUST be > cleared. > Please clarify it. > Yes, actually there's no such E bit for the Min, Max, Average and Variance (removed). The E bit is only relevant for specific request for which the G bit is cleared. Does that clarify ? > 4. Section 4.1 > > C (Check) - 1 bit: when set, this indicates that the performance > metric of interest is the PCE's availability. > > What does the PCE's availablity mean? This is a way to ensure that the PCE is alive. This way, you can for example, check a path computation chain by specifying a set of PCE- ID. I will replace "availability" by "liveness". > If a specific TE LSP computation is requested, does it mean that > PCE has > the ability to compute the path with the specified constraints? Yes indeed, in this case a PCC can request the computation of a path + gather the processing time on each hop. > In case of the general computation, does it mean that PCE is alive or > not? > Please clarify it. I'm not sure to see your question ? Thanks for your comments. JP. > > Thank you. > Eiji > > On Fri, 20 Oct 2006 08:30:06 -0400 > JP Vasseur wrote: > >> Hi, >> >> See below a new ID related to the monitoring of PCE-based path >> computation architecture so as to required various performance >> metrics such as liveness verification of the various elements of a >> path computation chain, processing time spent on path computation at >> each hop (for performance monitoring or troubleshooting, ...). >> >> Comments and opinions are most welcome. >> >> Thanks. >> >> JP. >> >> >> Begin forwarded message: >> >>> From: Internet-Drafts@ietf.org >>> Date: October 20, 2006 2:50:01 AM EDT >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-vasseur-pce-monitoring-01.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : A set of monitoring tools for Path Computation Element >>> based Architecture >>> Author(s) : J. Vasseur >>> Filename : draft-vasseur-pce-monitoring-01.txt >>> Pages : 16 >>> Date : 2006-10-19 >>> >>> A Path Computation Element (PCE) based architecture has been >>> specified for the computation of Traffic Engineering (TE) Label >>> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and >>> Generalized MPLS (GMPLS) networks in the context of single or >>> multiple domains (where 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). In such PCE-based environment it is thus critical to >>> monitor the state of the path computation chain and potentially >>> gather various performance metrics with regards to the set of >>> involved PCE(s) that can be used for performance monitoring and >>> troubleshooting purposes. This document specifies procedures and >>> extensions to the Path Computation Element Protocol (PCEP) in >>> order >>> to gather such information. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >>> monitoring-01.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-monitoring-01.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-monitoring-01.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-10-19191734.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-295--574907785 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Eiji,

On = Oct 24, 2006, at 10:38 AM, Eiji Oki wrote:

Hi JP,=A0

The ID looks = very great.=A0

Thanks for your = feed-back.


I have = several comments.

1. Section 3.2: The last sentense=A0
=A0=A0 The SVEC, RP, END-POINTS, = LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD-
=A0=A0 BALANCING objects are = defined in [I-D.ietf-pce-pcep].
is not = neccessary, as these objects do not appear in PCMonRep.


Indeed, it has been = removed, thanks.

2. = Section 4.1 describes=A0
=A0=A0 P (Processing Time) - 1 = bit: the P bit of the MONITORING object
=A0=A0 carried in a PCMonReq = message is set to indicate that the processing...

"or a = PCReq message" would be added after "a PCMonReq message".


Good catch, added, = thanks.

3. Section 4.3 = describes
=A0=A0 When the processing time = is requested in addition to a path
=A0=A0 computation, the PROC-TIME = object always report the actual processing
=A0=A0 time for that request and = thus the E bits MUST be cleared.

Is it possible to define = "actulal" Min- Max- Average- procssing time
with = E=3D0?

No because for the Min, = Max, Average and Variance the values are computed based on some history, = they're not estimated. The case of an estimated metric is when the = request relates to a particular TE LSP path computation (as opposed to a = general request). I clarified:
"When a request is specific (related to a = particular TE LSP path computation), the G bit MUST be cleared and the = Min-processing-time, Max-processing-time, Average-processing-time and = Variance-processing-time MUST be set to = 0x00000000."

Otherwise, when E is cleared, Min- Max- Average- = procssing
time MUST be set to 0x00000000. = In other words,=A0
If the G flag of the MONITORING object is set then E = bit MUST be cleared.
Please clarify = it.
Yes, actually there's no = such E bit for the=A0Min, Max, Average and Variance (removed). The E bit = is only relevant for specific request for which the G bit is = cleared.

Does = that clarify ?

4. = Section 4.1

=A0 C = (Check) - 1 bit: when set, this indicates that the performance
=A0=A0 = metric of interest is the PCE's availability.

What = does the PCE's availablity mean?

This is a way to ensure = that the PCE is alive. This way, you can for example, check a path = computation chain by specifying a set of PCE-ID. I will replace = "availability" by "liveness".

If a specific TE LSP computation is requested, does = it mean that PCE has
the ability to compute the = path with the specified constraints?

Yes indeed, in this case a = PCC can request the computation of a path + gather the processing time = on each hop.

In case = of the general computation, does it mean that PCE is alive or
not?
Please = clarify it.

I'm not sure to see your = question ?

Thanks for your = comments.

JP.


Thank you.

On Fri, 20 Oct 2006 08:30:06 -0400
JP Vasseur <jvasseur@cisco.com> = wrote:

=
Hi,

See = below a new ID related to the monitoring of PCE-based path =A0
=A0
metrics = such as liveness verification of the various elements of a =A0
path = computation chain, processing time spent on path computation at =A0
each hop = (for performance monitoring or troubleshooting, ...).

Comments = and opinions are most welcome.

Thanks.



Begin = forwarded message:
From: Internet-Drafts@ietf.org
Date: October 20, 2006 2:50:01 AM EDT
Subject: I-D = ACTION:draft-vasseur-pce-monitoring-01.txt
internet-drafts@ietf.org

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


Title : A set of monitoring tools for = Path Computation Element =A0
based = Architecture
Author(s) : J. = Vasseur
Filename : = draft-vasseur-pce-monitoring-01.txt
= Pages = = : 16
Date : 2006-10-19

A Path = Computation Element (PCE) based architecture has been
=A0=A0 = specified for the computation of Traffic Engineering (TE) = Label
=A0=A0 Switched Paths (LSPs) in = Multiprotocol Label Switching (MPLS) and
=A0=A0 Generalized MPLS (GMPLS) = networks in the context of single or
=A0=A0 multiple domains (where a = domain is referred to as a collection of
=A0=A0 network elements within a = common sphere of address management or =A0
=A0=A0 computational = responsibility such as IGP areas and Autonomous
=A0=A0 = Systems).=A0 In such = PCE-based environment it is thus critical to
=A0=A0 = monitor the state of the path computation chain and = potentially
=A0=A0 gather various performance = metrics with regards to the set of
=A0=A0 involved PCE(s) that can = be used for performance monitoring and
=A0=A0 troubleshooting = purposes.=A0 This document = specifies procedures and
=A0=A0 extensions to the Path = Computation Element Protocol (PCEP) in order
=A0=A0 = to gather such information.

A URL for this Internet-Draft = is:
To remove yourself from the I-D = Announcement list, send a message to
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of
the message.
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-monitoring-01.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-monitoring-01.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

I-D-Announce mailing list

=

= --Apple-Mail-295--574907785-- --===============0074416809== 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 --===============0074416809==-- From pce-bounces@lists.ietf.org Thu Nov 02 01:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVzK-0001HR-Pe; Thu, 02 Nov 2006 01:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVzK-0001GZ-AN for pce@ietf.org; Thu, 02 Nov 2006 01:23:42 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfVzI-0008TM-8h for pce@ietf.org; Thu, 02 Nov 2006 01:23:42 -0500 Received: from mfs4.rdh.ecl.ntt.co.jp (mfs4.rdh.ecl.ntt.co.jp [129.60.39.113]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA26NaYk016460; Thu, 2 Nov 2006 15:23:36 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA26NaCs014326; Thu, 2 Nov 2006 15:23:36 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA26NZZT017412; Thu, 2 Nov 2006 15:23:35 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA26NZRO013360; Thu, 2 Nov 2006 15:23:35 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA26NZJC013357; Thu, 2 Nov 2006 15:23:35 +0900 (JST) Received: from [129.60.80.237] ([129.60.80.237]) by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA26NYJT007152; Thu, 2 Nov 2006 15:23:34 +0900 (JST) Date: Thu, 02 Nov 2006 15:23:34 +0900 From: Eiji Oki To: JP Vasseur Subject: Re: [Pce] Feed-back on Monitoring ? In-Reply-To: <22B6BBA4-B863-4226-8F3B-CD8697F46F07@cisco.com> References: <20061024233725.AC8F.OKI.EIJI@lab.ntt.co.jp> <22B6BBA4-B863-4226-8F3B-CD8697F46F07@cisco.com> Message-Id: <20061102152004.7C1B.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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 JP, Thanks for your clarifications. Please ignore my last question. Thank you. Eiji On Wed, 1 Nov 2006 16:18:05 -0500 JP Vasseur wrote: > Hi Eiji, > > On Oct 24, 2006, at 10:38 AM, Eiji Oki wrote: > > > Hi JP, > > > > The ID looks very great. > > Thanks for your feed-back. > > > > > I have several comments. > > > > 1. Section 3.2: The last sentense > > The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and > > LOAD- > > BALANCING objects are defined in [I-D.ietf-pce-pcep]. > > is not neccessary, as these objects do not appear in PCMonRep. > > > > Indeed, it has been removed, thanks. > > > 2. Section 4.1 describes > > P (Processing Time) - 1 bit: the P bit of the MONITORING object > > carried in a PCMonReq message is set to indicate that the > > processing... > > > > "or a PCReq message" would be added after "a PCMonReq message". > > > > Good catch, added, thanks. > > > 3. Section 4.3 describes > > When the processing time is requested in addition to a path > > computation, the PROC-TIME object always report the actual > > processing > > time for that request and thus the E bits MUST be cleared. > > > > Is it possible to define "actulal" Min- Max- Average- procssing time > > with E=0? > > No because for the Min, Max, Average and Variance the values are > computed based on some history, they're not estimated. The case of an > estimated metric is when the request relates to a particular TE LSP > path computation (as opposed to a general request). I clarified: > "When a request is specific (related to a particular TE LSP path > computation), the G bit MUST be cleared and the Min-processing-time, > Max-processing-time, Average-processing-time and Variance-processing- > time MUST be set to 0x00000000." > > > Otherwise, when E is cleared, Min- Max- Average- procssing > > time MUST be set to 0x00000000. In other words, > > If the G flag of the MONITORING object is set then E bit MUST be > > cleared. > > Please clarify it. > > > > Yes, actually there's no such E bit for the Min, Max, Average and > Variance (removed). The E bit is only relevant for specific request > for which the G bit is cleared. > > Does that clarify ? > > > 4. Section 4.1 > > > > C (Check) - 1 bit: when set, this indicates that the performance > > metric of interest is the PCE's availability. > > > > What does the PCE's availablity mean? > > This is a way to ensure that the PCE is alive. This way, you can for > example, check a path computation chain by specifying a set of PCE- > ID. I will replace "availability" by "liveness". > > > If a specific TE LSP computation is requested, does it mean that > > PCE has > > the ability to compute the path with the specified constraints? > > Yes indeed, in this case a PCC can request the computation of a path > + gather the processing time on each hop. > > > In case of the general computation, does it mean that PCE is alive or > > not? > > Please clarify it. > > I'm not sure to see your question ? > > Thanks for your comments. > > JP. > > > > > Thank you. > > Eiji > > > > On Fri, 20 Oct 2006 08:30:06 -0400 > > JP Vasseur wrote: > > > >> Hi, > >> > >> See below a new ID related to the monitoring of PCE-based path > >> computation architecture so as to required various performance > >> metrics such as liveness verification of the various elements of a > >> path computation chain, processing time spent on path computation at > >> each hop (for performance monitoring or troubleshooting, ...). > >> > >> Comments and opinions are most welcome. > >> > >> Thanks. > >> > >> JP. > >> > >> > >> Begin forwarded message: > >> > >>> From: Internet-Drafts@ietf.org > >>> Date: October 20, 2006 2:50:01 AM EDT > >>> To: i-d-announce@ietf.org > >>> Subject: I-D ACTION:draft-vasseur-pce-monitoring-01.txt > >>> Reply-To: internet-drafts@ietf.org > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> > >>> Title : A set of monitoring tools for Path Computation Element > >>> based Architecture > >>> Author(s) : J. Vasseur > >>> Filename : draft-vasseur-pce-monitoring-01.txt > >>> Pages : 16 > >>> Date : 2006-10-19 > >>> > >>> A Path Computation Element (PCE) based architecture has been > >>> specified for the computation of Traffic Engineering (TE) Label > >>> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and > >>> Generalized MPLS (GMPLS) networks in the context of single or > >>> multiple domains (where 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). In such PCE-based environment it is thus critical to > >>> monitor the state of the path computation chain and potentially > >>> gather various performance metrics with regards to the set of > >>> involved PCE(s) that can be used for performance monitoring and > >>> troubleshooting purposes. This document specifies procedures and > >>> extensions to the Path Computation Element Protocol (PCEP) in > >>> order > >>> to gather such information. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- > >>> monitoring-01.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-monitoring-01.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-monitoring-01.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-10-19191734.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 From pce-bounces@lists.ietf.org Thu Nov 02 05:15:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZb6-0005v7-G3; Thu, 02 Nov 2006 05:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYxy-0002Z5-5T; Thu, 02 Nov 2006 04:34:30 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYxw-0000hd-84; Thu, 02 Nov 2006 04:34:30 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kA29Y4bs007317; Thu, 2 Nov 2006 04:34:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Nov 2006 11:34:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-farrel-pce-manageability-requirements-00.txt Thread-Index: Acb+Ygi+IsvFkvVzRWKcCEWIAc0r5Q== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 02 Nov 2006 05:14:55 -0500 Cc: ops-nm@ietf.org, MIB Doctors Subject: [Pce] Comments on draft-farrel-pce-manageability-requirements-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: , Errors-To: pce-bounces@lists.ietf.org First let me salute this I-D. I believe that it's useful for PCE, and an evolution of this work can be useful for other WGs in the Routing Area and in other Areas.=20 A few comments: 1. The organization of the document does not follow its own recommendation in Section 2.4, by not placing the Manageability Considerations section immediately before the Security Considerations section 2. I believe that a more appropriate title for the mandatory section that is being proposed would be 'Operational and Manageability Considerations' 3. In Section 2.1 it would be useful to give an example of a case when a null (Operational and) Manageability Consideration section is justified. For example, when the document extends and updates another document, and the original section covers all necessary information.=20 4. Section 3 should include a subsection detailing what management operations are expected to be performed as result of the deployment of the protocol - specifically if write operations will be allowed (on routers? on hosts?), if notifications for alarms or other events will be allowed 5. Section 3.1 could be extended to include information about installation and initial deployment. Beyond the timers example Section 3.1 could also include information about default modes of operation and default state of logical control variables.=20 6. It would be useful to mention in Section 3.2 if read-write or only read-only access is allowed for the information and/or data models 7. Section 3.5 deserves some editing for clarity. Is this about what protocols are recommended or expected to be used for operational or management purposes?=20 Thanks and Regards, Dan _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Nov 02 05:15:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZb6-0005v7-G3; Thu, 02 Nov 2006 05:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYxy-0002Z5-5T; Thu, 02 Nov 2006 04:34:30 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYxw-0000hd-84; Thu, 02 Nov 2006 04:34:30 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kA29Y4bs007317; Thu, 2 Nov 2006 04:34:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Nov 2006 11:34:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-farrel-pce-manageability-requirements-00.txt Thread-Index: Acb+Ygi+IsvFkvVzRWKcCEWIAc0r5Q== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 02 Nov 2006 05:14:55 -0500 Cc: ops-nm@ietf.org, MIB Doctors Subject: [Pce] Comments on draft-farrel-pce-manageability-requirements-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: , Errors-To: pce-bounces@lists.ietf.org First let me salute this I-D. I believe that it's useful for PCE, and an evolution of this work can be useful for other WGs in the Routing Area and in other Areas.=20 A few comments: 1. The organization of the document does not follow its own recommendation in Section 2.4, by not placing the Manageability Considerations section immediately before the Security Considerations section 2. I believe that a more appropriate title for the mandatory section that is being proposed would be 'Operational and Manageability Considerations' 3. In Section 2.1 it would be useful to give an example of a case when a null (Operational and) Manageability Consideration section is justified. For example, when the document extends and updates another document, and the original section covers all necessary information.=20 4. Section 3 should include a subsection detailing what management operations are expected to be performed as result of the deployment of the protocol - specifically if write operations will be allowed (on routers? on hosts?), if notifications for alarms or other events will be allowed 5. Section 3.1 could be extended to include information about installation and initial deployment. Beyond the timers example Section 3.1 could also include information about default modes of operation and default state of logical control variables.=20 6. It would be useful to mention in Section 3.2 if read-write or only read-only access is allowed for the information and/or data models 7. Section 3.5 deserves some editing for clarity. Is this about what protocols are recommended or expected to be used for operational or management purposes?=20 Thanks and Regards, Dan _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Nov 02 05:15:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZb6-0005v2-99; Thu, 02 Nov 2006 05:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNzr-0001p4-03 for pce@ietf.org; Wed, 01 Nov 2006 16:51:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNzo-00035U-Mb for pce@ietf.org; Wed, 01 Nov 2006 16:51:42 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2006 13:51:40 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208,217"; a="338377406:sNHT176228678" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1Lpeol006723; Wed, 1 Nov 2006 13:51:40 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LpMbd018892; Wed, 1 Nov 2006 13:51:39 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:51:39 -0500 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:51:37 -0500 In-Reply-To: <007501c6fcd0$0147aef0$860c6f0a@china.huawei.com> References: <25168B2D-E43E-4D8F-B57B-3459B0F02DF9@cisco.com> <007501c6fcd0$0147aef0$860c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: From: JP Vasseur Subject: Re: [Pce] Feed-back on Monitoring ? Date: Wed, 1 Nov 2006 16:51:45 -0500 To: Mach Chen X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Nov 2006 21:51:37.0585 (UTC) FILETIME=[E7E7BE10:01C6FDFF] DKIM-Signature: a=rsa-sha1; q=dns; l=46492; t=1162417900; x=1163281900; c=relaxed/simple; s=sjdkim7002; 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]=20Feed-back=20on=20Monitoring=20?; X=v=3Dcisco.com=3B=20h=3Dq/3V0EUONgvsclGvhOcsDweGHPs=3D; b=WrJtHbDqE3EjnAmk12AguX82CQM5W9wJuHkyGvYOTh7R/nrpsEYlm23N3ArYImujFGWYyFee 7oCl9MhXT6qlkrzOznpN3kTxjatY80Kz5/sGxmFXZGCcAAhUf3MXXoAN; Authentication-Results: sj-dkim-7.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 31 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 813368b10167e7c87c318e91999bcea9 X-Mailman-Approved-At: Thu, 02 Nov 2006 05:14:55 -0500 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="===============1071211595==" Errors-To: pce-bounces@lists.ietf.org --===============1071211595== Content-Type: multipart/alternative; boundary=Apple-Mail-297--572888616 --Apple-Mail-297--572888616 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Mach, On Oct 31, 2006, at 4:36 AM, Mach Chen wrote: > Hi JP, > > Your I-D is great. Thanks. > > I have some comments and questions. > > 1.Section 4.1 > > "C (Check) - 1 bit: when set, this indicates that the performance > metric of interest is the PCE's availability." > > When this "C bit" present in a PCMonRep messages, whether it > indicates the PCE is available? Is it enough to indicate a PCE's > availability? Some more detail info may be desirable. > Yes, the aim of th From pce-bounces@lists.ietf.org Thu Nov 02 05:15:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZb6-0005v2-99; Thu, 02 Nov 2006 05:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNzr-0001p4-03 for pce@ietf.org; Wed, 01 Nov 2006 16:51:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNzo-00035U-Mb for pce@ietf.org; Wed, 01 Nov 2006 16:51:42 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2006 13:51:40 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208,217"; a="338377406:sNHT176228678" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1Lpeol006723; Wed, 1 Nov 2006 13:51:40 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LpMbd018892; Wed, 1 Nov 2006 13:51:39 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:51:39 -0500 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:51:37 -0500 In-Reply-To: <007501c6fcd0$0147aef0$860c6f0a@china.huawei.com> References: <25168B2D-E43E-4D8F-B57B-3459B0F02DF9@cisco.com> <007501c6fcd0$0147aef0$860c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: From: JP Vasseur Subject: Re: [Pce] Feed-back on Monitoring ? Date: Wed, 1 Nov 2006 16:51:45 -0500 To: Mach Chen X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Nov 2006 21:51:37.0585 (UTC) FILETIME=[E7E7BE10:01C6FDFF] DKIM-Signature: a=rsa-sha1; q=dns; l=46492; t=1162417900; x=1163281900; c=relaxed/simple; s=sjdkim7002; 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]=20Feed-back=20on=20Monitoring=20?; X=v=3Dcisco.com=3B=20h=3Dq/3V0EUONgvsclGvhOcsDweGHPs=3D; b=WrJtHbDqE3EjnAmk12AguX82CQM5W9wJuHkyGvYOTh7R/nrpsEYlm23N3ArYImujFGWYyFee 7oCl9MhXT6qlkrzOznpN3kTxjatY80Kz5/sGxmFXZGCcAAhUf3MXXoAN; Authentication-Results: sj-dkim-7.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 31 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 813368b10167e7c87c318e91999bcea9 X-Mailman-Approved-At: Thu, 02 Nov 2006 05:14:55 -0500 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="===============1071211595==" Errors-To: pce-bounces@lists.ietf.org --===============1071211595== Content-Type: multipart/alternative; boundary=Apple-Mail-297--572888616 --Apple-Mail-297--572888616 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Mach, On Oct 31, 2006, at 4:36 AM, Mach Chen wrote: > Hi JP, > > Your I-D is great. Thanks. > > I have some comments and questions. > > 1.Section 4.1 > > "C (Check) - 1 bit: when set, this indicates that the performance > metric of interest is the PCE's availability." > > When this "C bit" present in a PCMonRep messages, whether it > indicates the PCE is available? Is it enough to indicate a PCE's > availability? Some more detail info may be desirable. > Yes, the aim of this bit is just to check the PCE's liveness. As pointed in the ID, other metrics may be collected that will be carried in new objects / flags (to be defined). > > 2.Section 4.1 > "The monitoring-id-number MUST be incremented each time a new > monitoring is sent to a PCE." > > Although 32-bit monitoring-id-number is a huge number, it will > overflow one day.So, when this happen, how to deal with it? Restart > another round or by other means? Yes the counter will simply roll-over and considering the set of values, the probability of overlap is extremely low ... to say the least. I'll clarify this. > > When a PCMonReq message is sent along with a PCE chain, the > monitoring-id-number is always the same or each PCE will regenerate > a new one? > Yes, > 3.Section 4.3 > > What's the meaning of "Variance-processing-time"? > This is the mean squared deviation. > 4.Section 7 > "Reception of a PCMonRep message: upon receiving a PCMonRep message, > the PCE processes the request, adds the relevant objects to the > PCMonRep message and forwards the PCMonRep message to the upstream > requesting PCE or PCC." > For a specific PCMonReq message, whether all the PCE along with the > PCE chain will do the some collection or some of them will do some > special collection? It is requested to gather performance metrics from all PCE along the path computation chain. That said, if some of them do not provide the requested data, then the I bit of the MONITORING object is set. Thanks for your comments. JP. > > > Thanks, > > Mach > ----- Original Message ----- > From: JP Vasseur > To: pce@ietf.org > Sent: Friday, October 20, 2006 8:30 PM > Subject: [Pce] Feed-back on Monitoring ? > > Hi, > > See below a new ID related to the monitoring of PCE-based path > computation architecture so as to required various performance > metrics such as liveness verification of the various elements of a > path computation chain, processing time spent on path computation > at each hop (for performance monitoring or troubleshooting, ...). > > Comments and opinions are most welcome. > > Thanks. > > JP. > > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: October 20, 2006 2:50:01 AM EDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-vasseur-pce-monitoring-01.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : A set of monitoring tools for Path Computation Element >> based Architecture >> Author(s) : J. Vasseur >> Filename : draft-vasseur-pce-monitoring-01.txt >> Pages : 16 >> Date : 2006-10-19 >> >> A Path Computation Element (PCE) based architecture has been >> specified for the computation of Traffic Engineering (TE) Label >> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and >> Generalized MPLS (GMPLS) networks in the context of single or >> multiple domains (where 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). In such PCE-based environment it is thus critical to >> monitor the state of the path computation chain and potentially >> gather various performance metrics with regards to the set of >> involved PCE(s) that can be used for performance monitoring and >> troubleshooting purposes. This document specifies procedures and >> extensions to the Path Computation Element Protocol (PCEP) in >> order >> to gather such information. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >> monitoring-01.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 anonymois bit is just to check the PCE's liveness. As pointed in the ID, other metrics may be collected that will be carried in new objects / flags (to be defined). > > 2.Section 4.1 > "The monitoring-id-number MUST be incremented each time a new > monitoring is sent to a PCE." > > Although 32-bit monitoring-id-number is a huge number, it will > overflow one day.So, when this happen, how to deal with it? Restart > another round or by other means? Yes the counter will simply roll-over and considering the set of values, the probability of overlap is extremely low ... to say the least. I'll clarify this. > > When a PCMonReq message is sent along with a PCE chain, the > monitoring-id-number is always the same or each PCE will regenerate > a new one? > Yes, > 3.Section 4.3 > > What's the meaning of "Variance-processing-time"? > This is the mean squared deviation. > 4.Section 7 > "Reception of a PCMonRep message: upon receiving a PCMonRep message, > the PCE processes the request, adds the relevant objects to the > PCMonRep message and forwards the PCMonRep message to the upstream > requesting PCE or PCC." > For a specific PCMonReq message, whether all the PCE along with the > PCE chain will do the some collection or some of them will do some > special collection? It is requested to gather performance metrics from all PCE along the path computation chain. That said, if some of them do not provide the requested data, then the I bit of the MONITORING object is set. Thanks for your comments. JP. > > > Thanks, > > Mach > ----- Original Message ----- > From: JP Vasseur > To: pce@ietf.org > Sent: Friday, October 20, 2006 8:30 PM > Subject: [Pce] Feed-back on Monitoring ? > > Hi, > > See below a new ID related to the monitoring of PCE-based path > computation architecture so as to required various performance > metrics such as liveness verification of the various elements of a > path computation chain, processing time spent on path computation > at each hop (for performance monitoring or troubleshooting, ...). > > Comments and opinions are most welcome. > > Thanks. > > JP. > > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: October 20, 2006 2:50:01 AM EDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-vasseur-pce-monitoring-01.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : A set of monitoring tools for Path Computation Element >> based Architecture >> Author(s) : J. Vasseur >> Filename : draft-vasseur-pce-monitoring-01.txt >> Pages : 16 >> Date : 2006-10-19 >> >> A Path Computation Element (PCE) based architecture has been >> specified for the computation of Traffic Engineering (TE) Label >> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and >> Generalized MPLS (GMPLS) networks in the context of single or >> multiple domains (where 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). In such PCE-based environment it is thus critical to >> monitor the state of the path computation chain and potentially >> gather various performance metrics with regards to the set of >> involved PCE(s) that can be used for performance monitoring and >> troubleshooting purposes. This document specifies procedures and >> extensions to the Path Computation Element Protocol (PCEP) in >> order >> to gather such information. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >> monitoring-01.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-monitoring-01.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-monitoring-01.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-10-19191734.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-297--572888616 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Mach,

On = Oct 31, 2006, at 4:36 AM, Mach Chen wrote:

Hi = JP,
=C2=A0
Your I-D is = great.

Thanks.

=C2=A0
I have some = comments and questions.
=C2=A0
1.Section = 4.1
=C2=A0> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-vasseur-pce-monitoring-01.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-monitoring-01.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-10-19191734.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-297--572888616 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Mach,

On = Oct 31, 2006, at 4:36 AM, Mach Chen wrote:

Hi = JP,
=C2=A0
Your I-D is = great.

Thanks.

=C2=A0
I have some = comments and questions.
=C2=A0
1.Section = 4.1
=C2=A0
"C (Check) - 1 bit: when set, this = indicates that the performance
=C2=A0=C2=A0 metric of interest is the = PCE's availability."
=C2=A0
When this "C bit" present in a = PCMonRep messages, whether it indicates the PCE is available? Is it = enough to indicate a PCE's availability? Some more detail info=C2=A0may = be desirable.
=C2=A0

Yes, the aim of this bit is = just to check the PCE's liveness. As pointed in the ID, other metrics = may be collected that will be carried in new objects / flags (to be = defined).=C2=A0

=C2=A0
2.Section = 4.1
"The monitoring-id-number MUST be = incremented each time a new monitoring is sent to a = PCE."
=C2=A0
Although 32-bit = monitoring-id-number is a huge number, it will overflow one day.So, when = this happen, how to deal with it? Restart another round or by other = means?

Yes the counter will simply = roll-over and considering the set of values, the probability of overlap = is extremely low ... to say the least. I'll clarify = this.

=C2=A0
When a = PCMonReq message is sent along with a PCE chain,=C2=A0the = monitoring-id-number is always the same or each PCE will regenerate a = new one?
=C2=A0

Yes,

"C (Check) - 1 bit: when set, this = indicates that the performance
=C2=A0=C2=A0 metric of interest is the = PCE's availability."
=C2=A0
When this "C bit" present in a = PCMonRep messages, whether it indicates the PCE is available? Is it = enough to indicate a PCE's availability? Some more detail info=C2=A0may = be desirable.
=C2=A0

Yes, the aim of this bit is = just to check the PCE's liveness. As pointed in the ID, other metrics = may be collected that will be carried in new objects / flags (to be = defined).=C2=A0

=C2=A0
2.Section = 4.1
"The monitoring-id-number MUST be = incremented each time a new monitoring is sent to a = PCE."
=C2=A0
Although 32-bit = monitoring-id-number is a huge number, it will overflow one day.So, when = this happen, how to deal with it? Restart another round or by other = means?

Yes the counter will simply = roll-over and considering the set of values, the probability of overlap = is extremely low ... to say the least. I'll clarify = this.

=C2=A0
When a = PCMonReq message is sent along with a PCE chain,=C2=A0the = monitoring-id-number is always the same or each PCE will regenerate a = new one?
=C2=A0

Yes,

3.Section = 4.3
=C2=A0
What's the meaning of = "Variance-processing-time"?
=C2=A0

This is the mean squared = deviation.

4.Section = 7
"Reception of a PCMonRep message: = upon receiving a PCMonRep message,
=C2=A0=C2=A0 = the PCE processes the request, adds the relevant objects to = the
=C2=A0=C2=A0 PCMonRep message and forwards the = PCMonRep message to the upstream
=C2=A0=C2=A0 = requesting PCE or PCC."
For a specific PCMonReq message, = whether all the PCE along with the PCE chain will do the some collection = or some of them will do some special = collection?

It is requested to gather = performance metrics from all PCE along the path computation chain. That = said, if some of them do not provide the requested data, then the I bit = of the MONITORING object is set.

Thanks for your = comments.

JP.

=C2=A0
=C2=A0
=C2=A0
3.Section = 4.3
=C2=A0
What's the meaning of = "Variance-processing-time"?
=C2=A0

This is the mean squared = deviation.

4.Section = 7
"Reception of a PCMonRep message: = upon receiving a PCMonRep message,
=C2=A0=C2=A0 = the PCE processes the request, adds the relevant objects to = the
=C2=A0=C2=A0 PCMonRep message and forwards the = PCMonRep message to the upstream
=C2=A0=C2=A0 = requesting PCE or PCC."
For a specific PCMonReq message, = whether all the PCE along with the PCE chain will do the some collection = or some of them will do some special = collection?

It is requested to gather = performance metrics from all PCE along the path computation chain. That = said, if some of them do not provide the requested data, then the I bit = of the MONITORING object is set.

Thanks for your = comments.

JP.

=C2=A0
=C2=A0
=C2=A0
----- Original Message -----
To: pce@ietf.orgSent: Friday, October 20, 2006 8:30 PM
Subject: [Pce] = Feed-back on Monitoring ?

Hi,

See below a new ID = related to the monitoring of PCE-based path computation architecture so = as to required various performance metrics such as liveness verification = of the various elements of a path computation chain, processing time = spent on path computation at each hop (for performance monitoring or = troubleshooting, ...).=C2=A0

Comments and opinions are most welcome.

Thanks.

JP.=C2=A0


Begin forwarded message:

Mach
----- Original Message -----
To: pce@ietf.orgSent: Friday, October 20, 2006 8:30 PM
Subject: [Pce] = Feed-back on Monitoring ?

Hi,

See below a new ID = related to the monitoring of PCE-based path computation architecture so = as to required various performance metrics such as liveness verification = of the various elements of a path computation chain, processing time = spent on path computation at each hop (for performance monitoring or = troubleshooting, ...).=C2=A0

Comments and opinions are most welcome.

Thanks.

JP.=C2=A0


Begin forwarded message:

Date: = October 20, 2006 2:50:01 AM = EDT
Subject: = I-D = ACTION:draft-vasseur-pce-monitoring-01.txtinternet-drafts@ietf.org

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

Date: = October 20, 2006 2:50:01 AM = EDT
Subject: = I-D = ACTION:draft-vasseur-pce-monitoring-01.txtinternet-drafts@ietf.org

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

: A set of monitoring tools for Path Computation Element = based Architecture
Author(s) : J. Vasseur
Filename : draft-vasseur-pce-monitoring-01.txt
Pages : 16
: 2006-10-19

A Path Computation Element (PCE) based architecture = has been
=C2=A0=C2=A0 specified = for the computation of Traffic Engineering (TE) Label
=C2=A0=C2=A0 Switched = Paths (LSPs) in Multiprotocol Label Switching (MPLS) = and
=C2=A0=C2=A0 Generalized = MPLS (GMPLS) networks in the context of single or
: A set of monitoring tools for Path Computation Element = based Architecture
Author(s) : J. Vasseur
Filename : draft-vasseur-pce-monitoring-01.txt
Pages : 16
: 2006-10-19

A Path Computation Element (PCE) based architecture = has been
=C2=A0=C2=A0 specified = for the computation of Traffic Engineering (TE) Label
=C2=A0=C2=A0 Switched = Paths (LSPs) in Multiprotocol Label Switching (MPLS) = and
=C2=A0=C2=A0 Generalized = MPLS (GMPLS) networks in the context of single or
=C2=A0=C2=A0 multiple = domains (where a domain is referred to as a collection = of
=C2=A0=C2=A0 network = elements within a common sphere of address management or = path
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 = In such PCE-based environment it is thus critical = to
=C2=A0=C2=A0 monitor the = state of the path computation chain and potentially
=C2=A0=C2=A0 gather = various performance metrics with regards to the set of
=C2=A0=C2=A0 involved = PCE(s) that can be used for performance monitoring and
=C2=A0=C2=A0 =C2=A0 This = document specifies procedures and
=C2=A0=C2=A0 = extensions to the Path Computation Element Protocol (PCEP) in = order
=C2=A0=C2=A0 to gather = such information.

A URL for = this Internet-Draft is:



To remove = yourself from the I-D Announcement list, send a message to=C2=A0


or =







__________________________________= _____________
Pce mailing list
Pce@lists.ietf.org
https://www1.= ietf.org/mailman/listinfo/pce


=C2=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: <>


__________________________________= _____________
Pce mailing list
Pce@lists.ietf.org
https://www1.= ietf.org/mailman/listinfo/pce


= --Apple-Mail-297--572888616-- --===============1071211595== 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 --===============1071211595==-- IV>= --Apple-Mail-297--572888616-- --===============1071211595== 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 --===============1071211595==-- From pce-bounces@lists.ietf.org Thu Nov 02 11:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GffNW-0008CM-3x; Thu, 02 Nov 2006 11:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GffNU-00089X-W4 for pce@ietf.org; Thu, 02 Nov 2006 11:25:17 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GffNJ-00030c-PK for pce@ietf.org; Thu, 02 Nov 2006 11:25:16 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 17:24:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Nov 2006 17:24:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pce-pcecp-interarea-reqs-03.txt Thread-Index: Acb6sANdtfYogCbLS7mwnoXAu2uE5wD2TqrQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 02 Nov 2006 16:24:53.0591 (UTC) FILETIME=[6D6D6670:01C6FE9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: pce@ietf.org Subject: [Pce] RE: draft-ietf-pce-pcecp-interarea-reqs-03.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 Hi Adrian Thanks for the review. A new revision accounting for your comments will be posted next week. See inline for some comments, > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : samedi 28 octobre 2006 13:28 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : pce@ietf.org > Objet : Re: draft-ietf-pce-pcecp-interarea-reqs-03.txt=20 >=20 > Hi, >=20 > Hot on the heals of JP's comment, here are my thoughts on this draft. >=20 > None of the issues is sufficiently large to warrant a respin=20 > before WG last call, but if you have time over the next two=20 > weeks it would be nice for people to have a clean copy to=20 > review immediately after San Diego. >=20 > Thanks, > Adrian >=20 >=20 > Minor > =3D=3D=3D > Section 3 > It is expected that a solution for a PCECP satisfies these > requirements. > What do we mean here exactly? > I think that we mean... > Any PCECP solution MUST satisfy the requirements of > [RFC4657] and MUST either satisfy the requirements > specified in this document of MUST be readily extensible > to satisfy these requirements. Humm this sounds a bit too vague. Actually here we request for specific = PCEP procedures. What about: "It is expected that PCECP procedures be defined to satisfy these = requirements."=20 > --- > Section 5.1 > I think you need to require a failure reason that says "can't=20 > compute intra-area path to destination" This is a good point: What about:=20 "In situations where an intra-area path is requested while there is no = feasible intra-area path, the response message MUST allow indicating = that an intra-area path cannot be found." > --- > Section 5.2 > Hence the > response message MUST support the inclusion of the=20 > identifiers of the > crossed areas and MUST allow identifying the corresponding path > segments. > Can you add a few words to clarify? What you are asking for=20 > is that the returned path be segmented and marked so that it=20 > is possible to tell which pieces of the path lie within which area? Yes it is. Would the following clarify? "Hence the response message MUST allow identifying the crossed areas. = Also the response message MUST allow segmenting the returned path and = marking each segment so that it is possible to tell which pieces of the = path lie within which area." > --- > Section 5.4 > Need to clarify the intent of the list of preferred PCEs. Is=20 > there a requirement that only these PCEs will be used? Is=20 > there a requirement that all of these PCEs will be tried=20 > before any other is tried? Is there a linkage between the=20 > preferred PCEs and the IGP areas? > although these questions do not impact on the bits and bytes=20 > of the protocol extensions that would be defined, they do=20 > change how the protocol procedure extensions will be defined,=20 > so you must say something here. Here is the requirement we have actually in mind: "In case of multiple-PCE inter-area path computation, a PCC may want to = indicate a preferred list of PCEs to be used, one per area.=20 In each area the preferred PCE should be tried before another PCE is = selected." > --- > Section 5.6 > I think that for completeness and to ensure that the protocol=20 > meets your requirements, you should provide a table of all of=20 > the options that you wish to be able to signal. Do you mean a table of all requirements in the draft? > --- > Section 5.6 > The response message MUST allow indicating the level of=20 > diversity of > a set of computed loose paths. > There is something implicit in this sentence. You are saying=20 > that the level of diversity provided may be different from=20 > the level of diversity requested (if it was not different,=20 > you would not need to provide an indication of the actual=20 > diversity).=20 Yes, the level of diversity provided may be higher than the requested = one (e.g. you requested link diversity and the returned paths are node = diverse), and this may be useful for the PCC to know the actual level.=20 By the way the same applies to various path parameters (metric = bound...). >I think this means that the diversity request can=20 > be exactly a request, not a demand. > So you need to clarify. Does the path computation request=20 > message have "desired diversity" and "required diversity"=20 > constraints as separate fields? No, there is only "required" diversity. > --- > Section 5.7 > There is a mention of AS-crossing. Is that in scope? Strictly speaking no it isn't...but this is pretty linked. Anyway we can remove it. > --- > Section 5.7 > How is the second bullet different from the first paragraph=20 > of section 5.1? No difference, can be removed. > --- > Do you need to add the ability to list areas that are to be=20 > explicitly excluded form the path? This is a good point, what about the following additional section: "4.6. Area Exclusion In some situations it may be useful to exclude one or more area(s) from = the path (e.g. request for a path between LSRs in two stub areas = connected to the same ABR(s), which must not cross the backbone area). = Hence the request message MUST allow indicating a set of one or more = area(s) that must be explicitely excluded from the path." > --- > Section 6 > I think you are adding requirements for a few extra things to=20 > be visible/manageable through the MIB modules. Which things?=20 > Which MIB modules? What about: "The inter-area application implies some new manageability requirements = in addition to those already listed in [RFC4657]. The PCECP PCC MIB = module MUST allow recording the proportion of inter-area requests and = the success rate of inter-area requests. It MUST also allow recording = the performances of a PCE chain (minimum maximum and average response = time), in case of multiple-PCE inter-area path computation. A built in diagnostic tool MUST be defined to monitor the performances = of a PCE chain, in case of multiple-PCE inter-area path computation. It = MUST allow determining the minimum maximum and average response time = globally for the chain, and on a per PCE basis." > --- >=20 >=20 > Nits > =3D=3D=3D=3D All these nits will be addressed. Thanks again for this detailed review, JL >=20 > Title > The RFC Editor is still not ready to accept that MPLS and=20 > GMPLS are well-known terms, so the title needs to change to... >=20 > Path Computation Element Communication Protocol (PCECP)=20 > Specific Requirements for Inter-Area Multiprotocol Label=20 > Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering > --- > Abstract > You need to expand the following acronyms in the abstract... > IGP > TE > LSP > LSR > --- > Abstract > OLD > In a multi-area network, topology visibility remains local to > a given area, and a head-end LSR cannot compute alone an inter-area > shortest constrained path. > NEW > In a multi-area network, topology visibility remains local to > a given area, and a head-end LSR cannot compute an inter-area > shortest constrained path. > --- > Abstract > I think you should add a sentence to explain where PCECP fits=20 > in. For example... > One key application of the Path > Computation Element (PCE) based architecture is the computation of > inter-area TE-LSP paths. > ** The PCE Communication Protocol (PCECP) is used to communicate > computation requests from PCE clients to PCE servers and to return > computed paths in responses.*** > This document lists a detailed set of PCECP specific=20 > requirements for > support of inter-area TE-LSP path computation. > --- > Abstract > It complements generic > requirements for a PCE Communication Protocol. > s/generic/the generic/ > --- > Section 1 > I suggest you remove this as the Gen Art reviewers keep objecting. > You have section 12 anyway. > --- > Section 2 > Add ERO > --- > Section 3 > OLD > The main challenge with inter-area MPLS-TE > relies actually on path computation. > NEW > The main challenge with inter-area MPLS-TE > lies in path computation. > --- > Section 3 > OLD > Indeed the head-end LSR cannot > compute a constrained path across areas, as its topology visibility > is limited to its own area. > NEW > Indeed the head-end LSR cannot > compute an explicit path across areas, as its topology visibility > is limited to its own area. > --- > Section 3 > The generic requirements for a PCE Communication Protocol (PCECP), > which allows a PCC to send path computation requests to a=20 > PCE and the > PCE to sent path computation responses to a PCC, are set forth in > [RFC4657]. > s/sent/send/ > --- > Section 3 > Note that PCE-based inter-area path computation may require a > mechanism for an automatic PCE discovery across areas, which is out > of the scope of this document. > s/for an automatic/for automatic/ > --- > Section 4 > OLD > IGP hierarchy allows improving IGP scalability, by dividing the IGP > domain into areas and limiting the flooding scope of topology > information to area boundaries. A router in an area has=20 > full topology > information for its own area but only reachability to=20 > destinations in > other areas._ Thus, a head-end LSR cannot compute an end-to-end > constrained path that traverses more than one IGP area. > NEW > IGP hierarchy enables improved IGP scalability by dividing the IGP > domain into areas and limiting the flooding scope of topology > information to within area boundaries. A router in an area has full > topology information for its own area, but only information about > reachability to destinations in other areas. Thus, a head-end LSR > cannot compute an end-to-end path that crosses the boundary of its > IGP area. > --- > Section 4 > OLD > A solution for computing inter-area TE-LSP path currently=20 > relies on a > per domain path computation ([PD-COMP]). It is based on loose hop > routing with an ERO expansion on each ABR. This can allow=20 > setting up > a constrained path, but faces two major limitations: > - This does not allow computing an optimal constrained path; > - This may lead to several crankback signaling messages and > hence delay the LSP setup, and also invoke possible alternate > routing activities. > NEW > A current solution for computing inter-area TE-LSP path relies on a > per domain path computation mechanism ([PD-COMP]). It is based > on loose hop routing with an ERO expansion on each ABR. This > allows an LSP to be set up following a contrained path,=20 > but faces two > major limitations: > - This does not guarantee the use of an optimal constrained path; > - This may lead to several crankback signaling messages and > hence delay the LSP setup, and may also invoke possible alternate > routing activities. > --- > Section 4 > OLD > The PCE based architecture [RFC4655] is well suited to inter-area > path computation, as it allows overcoming the path computation > limitations resulting from the limited topology visibility, by > introducing path computation entities with more topology=20 > visibility, > or by allowing cooperation between path computation=20 > entities in each > area. > NEW > The PCE based architecture [RFC4655] is well suited to inter-area > path computation, as it allows the path computation limitations > resulting from the limited topology visibility to be overcome by > introducing path computation entities with more topology=20 > visibility, > or by allowing cooperation between path computation=20 > entities in each > area. > --- > Section 4 > OLD > - Single PCE computation: The path is computed by a single PCE that > has topology visibility in all areas and can alone=20 > compute an end- > to-end optimal constrained path. > NEW > - Single PCE computation: The path is computed by a single PCE that > has topology visibility in all areas and can compute an=20 > end-to-end > optimal constrained path on its own. > --- > Section 4 > - Multiple PCE computation with inter-PCE communication: the path > computation is distributed on multiple PCEs, which have partial > topology visibility. They compute path segments in their areas of > visibility and collaborate with each other so as to arrive at an > end-to-end optimal constrained path. Such collaboration=20 > is ensured > thanks to inter-PCE communication. > s/communication: the/communication: The/ s/their areas/their domains/ > --- > Section 5.1 > Missing paragraph break after first paragraph. > --- > Section 5.3 > s/one ore more/one or more/ > --- > Section 5.4 > Missing paragraph break between paras 2 and 3 > --- >=20 > Section 5.5 > Missing paragraph break > --- > Sections 10.1 and 10.2 > Some non-ASCII characters crept in thanks to MS smart-quotes. > --- > Section 10.2 > [ID-RSVP] is not cited in the main text. > --- > Section 10.2 > Missing reference for [METRIC] > ---=20 >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Nov 06 09:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh5wC-0002H7-8r; Mon, 06 Nov 2006 09:59:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh5wA-0002Gm-Nh for pce@ietf.org; Mon, 06 Nov 2006 09:58:58 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh5w3-0003r6-8M for pce@ietf.org; Mon, 06 Nov 2006 09:58:56 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 15:58:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 15:58:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vasseur-pce-monitoring-01.txt Thread-Index: Acb3elDw1HOpri2dRSi3dH6EgH36XAKJD7aw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" X-OriginalArrivalTime: 06 Nov 2006 14:58:37.0652 (UTC) FILETIME=[09FAC940:01C701B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pce@ietf.org Subject: [Pce] Comments on draft-vasseur-pce-monitoring-01.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 Hi Jean-Philippe, This is a relevant draft. Find below some comments: -Section 3.1: PCMonReq One may want to gather performance metrics with syncrhonized path computations (e.g. Diverse Path computation). Hence the PCMonReq message should IMO be extended. The SVEC object and a list of lsp-requests should be added. Actually the PCE id object is required for many other applications (e.g. to fit inter-area requirements of PCE list enforcement in a request and recording in a reply), hence I would suggest defining this object is a separate draft.=20 >"A PCMonReq message is sent to gather various performance metrics along a path computation=20 >chain. Such metrics may relate to a specific path computation chain encoded in the form of a=20 >series of PCE-ID objects defined in section 4.2. Alternatively it may be desired to collect=20 >such performance metrics along the path computation chain involved to compute a TE-LSP". Actually it appears here that the two options (series of PCE ids and TE-LSP) are exclusive.=20 One may actually want to collect the metrics along a specific PCE chain for a given TE-LSP.=20 So you may have both a PCE-id list and an lsp-request within a PCMonReq. That would be good to add a fourth example to illustrate this case: "PCC3 requests to gather performance metrics along the specific path computation chain PCE1-PCE2-PCE3, for the computation of T1..." =20 -Section 4.2 First sentence: "the PCE-ID object is used in a PCMonReq to record the IP address of the PCE for which performance metrics are collected"... This is not clear. To me it is used in the PCMonReq to enforce the chain of PCEs to be used... Section 4.3 Current-Processing time: Does this represents only the path computation time, or does it also account for the waiting time in the request queue? May be you could distinguish the computation time and the response time? Min/Max/Average/Variance processing time "If the G flag is cleared then this field must be set to 0..." Why such restriction? It may be useful to know the expected min/max/average processing time for a specific LSP. E bit control: It would be good to add a flag in the MONITORING object that would allow a PCC to indicate whether the time should be estimated or based on actual computation. General comment: It may be useful to record the congestion status of a PCE chain.=20 Hence I would suggest adding a flag in the MONITORING object, the S flag: Saturation, when set this indicates that the congestion is a metric of interest. And a CONGESTION Object could be defined, that would indicate the congestion satus, and optionally, if policy permits the reasons for the congestion (request buffer full...). Also some minor edits: Section 3.2 The format of a PCReq message is as follows =3D> The format of a = PCMonRep message is as follows ^^^^^ ^^^^^^^^ Section 3.2 Remove "the SVEC, RP...are defined in [I-D.ietf-pce-pcep]" Section 4.2, first line The PCE-ID object is used in a PCMonReq or a message =3D> The PCE-ID object is used in a PCMonReq or a PCReq message ^^^^^ Section 4.3 "If the G flag of the MONITORING Object if cleared then this field MUST be set to 0x00000000." ^^is Regards, JL=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Nov 06 10:49:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6j5-0006GC-An; Mon, 06 Nov 2006 10:49:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6j3-0006DE-U8 for pce@ietf.org; Mon, 06 Nov 2006 10:49:29 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6j0-0002mr-6V for pce@ietf.org; Mon, 06 Nov 2006 10:49:29 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Nov 2006 07:49:25 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABznTkVAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="47987019:sNHT3636442580" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6FnN2C009798; Mon, 6 Nov 2006 10:49:23 -0500 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 kA6FnNYJ008064; Mon, 6 Nov 2006 10:49:23 -0500 (EST) 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.1830); Mon, 6 Nov 2006 10:49:22 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:49:22 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2393A3C6-9391-4F81-8277-FEB860B6A4B7@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 6 Nov 2006 10:49:30 -0500 To: "LE ROUX Jean-Louis RD-CORE-LAN" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Nov 2006 15:49:22.0580 (UTC) FILETIME=[20E5ED40:01C701BB] DKIM-Signature: a=rsa-sha1; q=dns; l=4885; t=1162828163; x=1163692163; c=relaxed/simple; s=rtpdkim2001; 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=20Comments=20on=20draft-vasseur-pce-monitoring-01.txt |To:=22LE=20ROUX=20Jean-Louis=20RD-CORE-LAN=22=20; X=v=3Dcisco.com=3B=20h=3DX8zSmwAcv3eJdeTjvwW8MWirWz0=3D; b=xZL4ew3dixwOhK3c8rde5q8r/s6SrnqL75W9hzyh02fcgvX5G1GRfG6k7nlz4nBFGAIWnBhL hcgkkLDIBiOFEpxvFKKvSvrUFdyZgpsVR0rXUrogk5efaH9+rS3yXx28; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: pce@ietf.org Subject: [Pce] Re: Comments on draft-vasseur-pce-monitoring-01.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 Hi Jean-Louis, On Nov 6, 2006, at 9:58 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Jean-Philippe, > > This is a relevant draft. > Thanks. In line, > Find below some comments: > > -Section 3.1: PCMonReq > > One may want to gather performance metrics with syncrhonized path > computations (e.g. Diverse Path computation). > Hence the PCMonReq message should IMO be extended. The SVEC object > and a > list of lsp-requests should be added. > OK let's discuss this for the next revision. > Actually the PCE id object is required for many other applications > (e.g. > to fit inter-area requirements of PCE list enforcement in a request > and > recording in a reply), hence I would suggest defining this object is a > separate draft. > No objection to this, I put it there for now but indeed we could have it in a separate ID in which we could address the other inter-area requirements. >> "A PCMonReq message is sent to gather various performance metrics >> along > a path computation >> chain. Such metrics may relate to a specific path computation chain > encoded in the form of a >> series of PCE-ID objects defined in section 4.2. Alternatively it may > be desired to collect >> such performance metrics along the path computation chain involved to > compute a TE-LSP". > > Actually it appears here that the two options (series of PCE ids and > TE-LSP) are exclusive. > One may actually want to collect the metrics along a specific PCE > chain > for a given TE-LSP. > So you may have both a PCE-id list and an lsp-request within a > PCMonReq. > That would be good to add a fourth example to illustrate this case: > > "PCC3 requests to gather performance metrics along the specific path > computation chain PCE1-PCE2-PCE3, for the computation of T1..." > Absolutely, ambiguous wording since this was the intention. Will fix that in the next revision. > > -Section 4.2 > > First sentence: "the PCE-ID object is used in a PCMonReq to record the > IP address of the PCE for which performance metrics are collected"... > > This is not clear. To me it is used in the PCMonReq to enforce the > chain > of PCEs to be used... OK will clarify. > > Section 4.3 > > Current-Processing time: Does this represents only the path > computation > time, or does it also account for the waiting time in the request > queue? > May be you could distinguish the computation time and the response > time? > The intent was to report the processing time=waiting time+processing time. Do you think that both might be useful (for example in case of CPU intensive cases to differentiate the waiting time from the actual computation time) ? > Min/Max/Average/Variance processing time > "If the G flag is cleared then this field must be set to 0..." > Why such restriction? It may be useful to know the expected > min/max/average processing time for a specific LSP. > Well the average is computed over a set of requests ... so it cannot really apply to a specific request. Similarly, with regards to the min. max and variance they are computed over a set of requests. So when these fields apply to general requests. That said, we could extend to request to get the (estimated) time for a specific request and in addition collect performance metrics for a set of requests that have been processed in the past. Thoughts ? > E bit control: It would be good to add a flag in the MONITORING object > that would allow a PCC to indicate whether the time should be > estimated > or based on actual computation. Good point. Next revision. > > General comment: > It may be useful to record the congestion status of a PCE chain. > Hence I would suggest adding a flag in the MONITORING object, the S > flag: Saturation, when set this indicates that the congestion is a > metric of interest. > And a CONGESTION Object could be defined, that would indicate the > congestion satus, and optionally, if policy permits the reasons for > the > congestion (request buffer full...). > Also a good point. > > > Also some minor edits: > > Section 3.2 > > The format of a PCReq message is as follows => The format of a > PCMonRep > message is as follows > ^^^^^ > ^^^^^^^^ > > Section 3.2 > > Remove "the SVEC, RP...are defined in [I-D.ietf-pce-pcep]" > > Section 4.2, first line > > The PCE-ID object is used in a PCMonReq or a message > => The PCE-ID object is used in a PCMonReq or a PCReq message > ^^^^^ > > Section 4.3 > > "If the G flag of the MONITORING Object if cleared then this field > MUST > be set to 0x00000000." > ^^is > Thanks for these useful comments. Cheers, JP. > > Regards, > > JL _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Nov 06 13:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9MO-00063o-Ou; Mon, 06 Nov 2006 13:38:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9MM-00063W-Qp for pce@ietf.org; Mon, 06 Nov 2006 13:38:14 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9MH-0007jd-9V for pce@ietf.org; Mon, 06 Nov 2006 13:38:14 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:38:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 19:38:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vasseur-pce-monitoring-01.txt Thread-Index: AccBuyP4iGj3cYdqSqiRMoJfMjG6cQAChFjg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" X-OriginalArrivalTime: 06 Nov 2006 18:38:04.0339 (UTC) FILETIME=[B1EFC830:01C701D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: pce@ietf.org Subject: [Pce] RE: Comments on draft-vasseur-pce-monitoring-01.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 Hi Jean-Philippe,=20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com]=20 > Envoy=E9 : lundi 6 novembre 2006 16:50 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : pce@ietf.org > Objet : Re: Comments on draft-vasseur-pce-monitoring-01.txt >=20 > Hi Jean-Louis, >=20 > On Nov 6, 2006, at 9:58 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Jean-Philippe, > > > > This is a relevant draft. > > >=20 > Thanks. In line, >=20 > > Find below some comments: > > > > -Section 3.1: PCMonReq > > > > One may want to gather performance metrics with syncrhonized path=20 > > computations (e.g. Diverse Path computation). > > Hence the PCMonReq message should IMO be extended. The SVEC=20 > object and=20 > > a list of lsp-requests should be added. > > >=20 > OK let's discuss this for the next revision. >=20 > > Actually the PCE id object is required for many other applications=20 > > (e.g. > > to fit inter-area requirements of PCE list enforcement in a request=20 > > and recording in a reply), hence I would suggest defining=20 > this object=20 > > is a separate draft. > > >=20 > No objection to this, I put it there for now but indeed we=20 > could have it in a separate ID in which we could address the=20 > other inter-area requirements. OK >=20 > >> "A PCMonReq message is sent to gather various performance metrics=20 > >> along > > a path computation > >> chain. Such metrics may relate to a specific path computation chain > > encoded in the form of a > >> series of PCE-ID objects defined in section 4.2.=20 > Alternatively it may > > be desired to collect > >> such performance metrics along the path computation chain=20 > involved to > > compute a TE-LSP". > > > > Actually it appears here that the two options (series of PCE ids and > > TE-LSP) are exclusive. > > One may actually want to collect the metrics along a specific PCE=20 > > chain for a given TE-LSP. > > So you may have both a PCE-id list and an lsp-request within a=20 > > PCMonReq. > > That would be good to add a fourth example to illustrate this case: > > > > "PCC3 requests to gather performance metrics along the=20 > specific path=20 > > computation chain PCE1-PCE2-PCE3, for the computation of T1..." > > >=20 > Absolutely, ambiguous wording since this was the intention.=20 > Will fix that in the next revision. >=20 > > > > -Section 4.2 > > > > First sentence: "the PCE-ID object is used in a PCMonReq to=20 > record the > > IP address of the PCE for which performance metrics are=20 > collected"... > > > > This is not clear. To me it is used in the PCMonReq to enforce the =20 > > chain > > of PCEs to be used... >=20 > OK will clarify. >=20 > > > > Section 4.3 > > > > Current-Processing time: Does this represents only the path =20 > > computation > > time, or does it also account for the waiting time in the request =20 > > queue? > > May be you could distinguish the computation time and the response =20 > > time? > > >=20 > The intent was to report the processing time=3Dwaiting time+processing = =20 > time. > Do you think that both might be useful (for example in case of CPU =20 > intensive cases to differentiate the waiting time from the actual =20 > computation time) ? Yes this could be useful.=20 >=20 > > Min/Max/Average/Variance processing time > > "If the G flag is cleared then this field must be set to 0..." > > Why such restriction? It may be useful to know the expected > > min/max/average processing time for a specific LSP. > > >=20 > Well the average is computed over a set of requests ... so it cannot =20 > really apply to a specific request.=20 It could be based on all requests of the same nature (same objective = function, constraint and correlation). Similarly, with regards to the =20 > min. max and variance they are computed over a set of requests. So =20 > when these fields apply to general requests. > That said, we could extend to request to get the (estimated)=20 > time for =20 > a specific request and in addition collect performance metrics for a =20 > set of requests that have been processed in the past. Thoughts ? Yes this would be useful if these are requests of the same nature. Regards, JL >=20 > > E bit control: It would be good to add a flag in the=20 > MONITORING object > > that would allow a PCC to indicate whether the time should be =20 > > estimated > > or based on actual computation. >=20 > Good point. Next revision. >=20 > > > > General comment: > > It may be useful to record the congestion status of a PCE chain. > > Hence I would suggest adding a flag in the MONITORING object, the S > > flag: Saturation, when set this indicates that the congestion is a > > metric of interest. > > And a CONGESTION Object could be defined, that would indicate the > > congestion satus, and optionally, if policy permits the=20 > reasons for =20 > > the > > congestion (request buffer full...). > > >=20 > Also a good point. >=20 > > > > > > Also some minor edits: > > > > Section 3.2 > > > > The format of a PCReq message is as follows =3D> The format of a =20 > > PCMonRep > > message is as follows > > ^^^^^ > > ^^^^^^^^ > > > > Section 3.2 > > > > Remove "the SVEC, RP...are defined in [I-D.ietf-pce-pcep]" > > > > Section 4.2, first line > > > > The PCE-ID object is used in a PCMonReq or a message > > =3D> The PCE-ID object is used in a PCMonReq or a PCReq message > > ^^^^^ > > > > Section 4.3 > > > > "If the G flag of the MONITORING Object if cleared then this field =20 > > MUST > > be set to 0x00000000." > > ^^is > > >=20 > Thanks for these useful comments. >=20 > Cheers, >=20 > JP. >=20 > > > > Regards, > > > > JL >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Nov 08 19:37:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxuD-0003VP-Mr; Wed, 08 Nov 2006 19:36:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxuC-0003VK-Sv for pce@ietf.org; Wed, 08 Nov 2006 19:36:32 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhxuB-0008BK-II for pce@ietf.org; Wed, 08 Nov 2006 19:36:32 -0500 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 <0J8F003XNTJODV@usaga01-in.huawei.com> for pce@ietf.org; Wed, 08 Nov 2006 16:33:24 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8F001ILTJM8U@usaga01-in.huawei.com> for pce@ietf.org; Wed, 08 Nov 2006 16:33:24 -0800 (PST) Received: from [172.24.1.6] (Forwarded-For: [130.129.67.85]) by szxmc02-in.huawei.com (mshttpd); Wed, 08 Nov 2006 16:36:26 -0800 Date: Wed, 08 Nov 2006 16:36:26 -0800 From: MachChen 55527 Subject: RE: [PCE] About ASBR locate To: gmirsky@turinnetworks.com Message-id: <3974b803975544.39755443974b80@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Gergory, Fisrt, thanks for questions. Your question: How a RR avoid sending ASBR info(carried by EBGP summary session nlri) to non-PCE router? In our I-D, we defined a new AFI/SAFI pair for such EBGP summary session nlri. So when a router begins to set up a connecton with RR, they will do capability negotiation. If the router dosen't carry such new AFI/SAFI info in the open message(indicates it's a non-PCE router or a router which doesn't consern about such info), then the RR will not send any such ASBR info to that router. Any feedback and comments are welcome. Best regards, Mach Chen FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Locate ASBR in PCE Author(s) : R. Zhang, M. Chen Filename : draft-zhang-pce-locate-asbr-00.txt Pages : 8 Date : 2006-10-12 The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. This document specifies a procedure for an inter-AS PCE to locate boundary node within its domain dynamically, which is used for path computation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhang-pce-locate-asbr-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-zhang-pce-locate-asbr-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-zhang-pce-locate-asbr-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. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Pce mailing list Pce at lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce -------------------------------------------------------------------------------- Prev by Date: [PCE] Inter-AS PCE Path Sequence Autoexplore Next by Date: RE: [PCE] About ASBR locate Previous by thread: [PCE] Inter-AS PCE Path Sequence Autoexplore Next by thread: RE: [PCE] About ASBR locate Index(es): Date Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Nov 14 13:22:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2un-0007B5-AP; Tue, 14 Nov 2006 13:21:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2ul-0007B0-Jz for pce@ietf.org; Tue, 14 Nov 2006 13:21:43 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2ug-0004AY-MO for pce@ietf.org; Tue, 14 Nov 2006 13:21:43 -0500 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 1Gk2uQ-0007P4-00 for pce@ietf.org; Tue, 14 Nov 2006 18:21:23 +0000 Received: from your029b8cecfe ([217.158.132.104] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 18:21:21 +0000 Message-ID: <0e3a01c70819$a4134780$5a418182@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" References: <0afd01c707f5$a1b20950$5a418182@your029b8cecfe> <3C58B997-6693-4E26-AA06-192047FFB464@cisco.com> Date: Tue, 14 Nov 2006 18:18:32 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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 Nov 2006 18:21:22.0985 (UTC) FILETIME=[B0634990:01C70819] X-Spam-Score: 0.1 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: Eiji Oki , Arthi Ayyangar , pce@ietf.org, Kenji Kumaki , akatlas@alum.mit.edu Subject: [Pce] High level PCEP Review 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, As discussed, it is time to review PCEP from outside the design team. JP asked (well, OK, he begged :-) that at this review I limit myself to major protocol issues, and leave other documentation issues to a later review. I have mainly done that, but I have also included a few process-related comments that I think you should resolve in the next revision. Cheers, Adrian === Frontpage authors list. You need to cut this down to at most 5, but preferably no more than 4 people. I guess it is time to work out who the main editors are, and make the split. === Title I don't think that naming the protocol "Version 1" is appropriate. It is almost a statement of intended failure! It is still OK to have the protocol version field. === Spelling If you could run the text through a spell-checker, it would really improve the readability and hence the quality of review. === "PCEP protocol" Could you fix that rather annoying phrase! === Section 2 needs to include a statement of intent (or otherwise) to satisfy the requirements in RFC4657. === I think section 4 belongs after section 5 === Any reason why the Open, Close, and Keepalive messages do not conform to the naming convention "PCXxxx" of all other messages? === Remove RFC2119 language from section 5 === PCErr is missing from section 5. Indeed, the use of PCNtfy as shown in figure 5 to express cancellation of a request by a PCE would seem to be the correct usage of PCErr. I suggest a bit of a rationalisation (and perhaps the creation of a new message - PCCncl). Thus PCNtfy becomes a benign notification message, PCErr is used by the PCE to report an error (but not a failure), PCCncl is used by the PCC to cancel a PCReq. It is best if we can resist overloading the semantics of the different messages. === Section 5.2.5 would benefit from a statement that it is your intention that the TCP connection can be re-established and recover the context of a session without further exchange of Open messages. I think this is what you intend. I am not sure it is good, and would prefer that the session was also re-established with the exchange of a list of PCReq I-Ds still outstanding OR that a failed TCP connection automatically cleared the session. Otherwise you complicate the protocol and the implementation with handling duplicate request I-Ds and lost requests/responses. === In section 6 you imply that a malformed PCErr will cause the generation of a PCErr. I suggest you need to avoid this behavior to prevent duelling error messages! === Can you include a reference to the definition of BNF in section 6 === In 6.1 you need to describe the default settings of the Flags and Reserved fields === Do you really support 2^32 byte messages? If this is a conscious decision, then maybe OK. === 6.3 doesn't mention the use of keepalive to detect TCP connection failure. I think it should. === In 6.4 the End-Points object is described as mandatory, but the BNF has it optional === In 6.7 The PCErr message may be sent by a PCC or a PCE in response to a request or in an unsolicited manner. "may"? === In the objects you define reserved fields as MUST be set to zero. I think you need: - SHOULD be set to zero - MUST be ignored on receipt === In 7.1 it is unclear, but I think the P flag would only have meaning on a request, and the I flag on a response. So actually, you only need one flag (or you have some clarification text to write) === You will also need to explain what it means when a PCRep has the I flag set for an object that had the P flag set on the PCReq. As currently phrased this is an encoding error that would require a PCErr, but that would clearly be a waste of time. === In fact, why would you ever send a PCErr in response to a PCRep? === At the end of 7.1 you need to explain padding rules === Why does the Open need a protocol version number? This is in the message header so we all know what protocol is being used/supported. in fact, I think you need to re-write the protocol version support processing and negotiation. === Dead timer. Should it be "SHOULD be set to zero, and MUST be ignored if the keepalive timer is zero" === The fields in the Open object are a mess! Can you bring the flags up with the version to improve the byte- alignment? === Note that in the message header the version is four bits but in the Open object it is three bits. === In the Open object SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP session number that identifies the current session. Are you using bit compression? === Open object TLVs may be out of the scope of this doc (7.2) but the format needs to be defined here. === When present in an Open message, the OPEN object specifies the proposed PCEP session characteristics. Upon receiving unacceptable PCEP session characteristics during the PCEP session initialization phase, the receiving PCEP peer (PCE) MAY include a PCEP object within the PCErr message so as to propose alternative session characteristic values. Isn't there an issue with duelling Open messages? You seem to have an independent Open in each direction, each of which is responded with a PCErr, leading to a new Open in each direction. Is it necessary to have this symmetry? After all, the TCP connection is always initiated by the PCC, so can't we also have the Open initiated by the PCC and responded with a PCErr or an Open by the PCE. Keepalives then follow. === 7.3 Why is the P flag set in an RP object carried in a PCNtf or PCErr? No computation action is required. === Why is there a reserved piece of the RP object? Is there a difference between the unused flags bits and the reserved field? === 7.3.1 Note that it is not required for a PCE to support the priority field: in this case, it is RECOMMENDED to set the priority field to 0 by the PCC in the RP object. Why would it matter what value is set if it is not supported by the PCE? Wouldn't it possibly be helpful if the PCE forwards the request to another PCE? === 7.3.1 As described here there is no difference between the R and the F bit. Both are used to recompute a path allowing re-use of resources already used by the path. Presumably in the case of the F bit, some information about the failure is also supplied through an exclusion, but this is not mentioned. The behavior at the PCE for these two bits would seem to be identical so unless you can give better separation of the meanings, I suggest you merge the bits. === 7.3.1 The description of the O-bit is very confusing. I think the problem lies with the definition of "explicit path" Loose means that it is acceptable to include loose hops You have no term to distinguish the use of abstract nodes that contain more than one network node Explicit just means an ERO Strict means that only strict hops are allowed === 7.3.1 You need to think about how the Request ID is handled when the PCC restarts. Are you requiring the PCC to have persistent memory to avoid re-use of a Request ID? (That is how the text reads!) === 7.3.2 The description of R-bit handling looks broken. The previous setting of the O-bit is not important because the PCC is able to use RRO to collect information from the network. Thus, the question is actually about how detailed the RRO is. The point you are making remains (that it is hard to compute a proper make- before-break resource-sharing path if you don't know the previous path. [Those of you looking at the inter-area/AS PCE problem space will recognise this as impossible to solve unless stateful PCEs are used or the PCE is provided with a way to issue an enquiry to the ABR/ASBR.] === 7.3.2 If the PCC receives a PCRep message that contains a RP object referring to an unknown Request-ID-Number, the PCC MUST send a PCErr message with Error-Type="Unknown request reference". This feels like at most a "MAY". Why is there a requirement to respond? === 7.4 I don't think the description on the inclusion of "failed" constraints in the PCRep message is in agreement with the BNF in section 6.5. The BNF appears to imply that an ERO must be present in order to include, for example, a Metric object. [By the way: I continue to believe that this business of reporting the failed constraints is extremely dubious. Where there are two absolute constraints to be satisfied, it is often impossible to state which of them led to the failure to compute a path.] === 7.4 How does a PCC tell the difference between a PCRep that contains the "failed" constraints echoed from the PCReq, and modified constraints that could have been satisfied? From the text it appears that you intend the C-bit to make this distinction, but the description of the C-bt does not say this. === 7.4 Wouldn't it be a good idea to put a reason code in the No-Path object? === 7.5 Can you add a note to say where the end points of the LSP *are* encoded. That is, although this PCReq is computing a segment only, it is important (at least for policy) to know the LSP end points as well. === 7.6 First paragraph is hard to parse, but I think it says that the Bandwidth object must always be present in a PCReq! But the second paragraph explains what it means if it is absent. === 7.6 Can you give a references to the IEEE FP definition. === 7.7 Please add a third metric: hop count I think you need to allow the Metric object to be present multiple times, and you have this in the text, but it is missing in the BNF. On the other hand, you need to describe how to interpret multiple Metric objects for the same Type setting === 7.7 Why do you need the B-bit? The metric value is set to zero with the same semantic. === 7.7 The text appears to say that only one Metric object may be present with the B-flag cleared. Why? === 7.8 and 7.9 (and everywhere) A real nit, but when you write "ERO object" or "RRO object" do you mean EROO and RROO? :-) === 7.8 You say that the ERO is bounded by 3209, 3473 and 3477 which is fine, but how will an MPLS-TE LSR handle an ERO with an explicit label in it? You also allow future extensions to subobjects. I think this means that the PCReq must include a way for the requester to limit the subobjects that will be returned. === 7.9 RRO is also used for reporting the path of a failed LSP? === 7.10 What are optional TLVs for? Perhaps to carry the additional attributes as defined in RFC4420? === 7.10 Why do you need an LSPA object without resource affinities? This is pointless. It only exists in 3209 for backwards compatibility. === 7.10 What is the meaning of holding priority with respect to path computation? === 7.10 Why are the Flags and Reserved fields different sizes in the two objects? === 7.10 When computing a path to satisfy a request with the L-bit set, how will the PCE know which links are protected with FRR? === 7.11 Good to see the IRO Why is there no XRO? Exclusion is a standard part of the MPLS-TE MIB (RFC3812 see mplsTunnelHopInclude). If the exclusion can be configured on the headend LSR, I think we need to be able to compute the path. Besides, this is a requirement in RC4657. === 7.11 Why is it necessary to list the subobjects for the IRO but not for the ERO or the RRO? === 7.12.1 I urge caution in the use of "simultaneously" in this section. === 7.12.1 At the end of this section, you suddenly introduce the term "bundle". I think this is supposed to refer to the presence of multiple requests in a single PCReq message. Note that the SVEC can apply across messages. It would, perhaps be better to explain that requests in the same message are not necessarily associated by an SVEC, and that requests in separate messages may be associated by an SVEC. === 7.12 You are missing text to describe the use of the SVEC on a PCRep (allowed according to 6.5). It feels like you would only use SVEC in the case of an RP, but the BNF has them as independent. Please clarify === 7.12.2 You have MUST NOT for each of your diversity characteristics. I think you also need "desired" so that you can get "as much diversity as possible". How will you handle the overlap between (for example) node and link diversity? Just needs some text to explain. === 7.12 Is it possible to end up with a nasty mesh of synchronized requests? Are there any rules to resolve this? === 10 The state machine is quite hard to parse for reviewing purposes. It would be good to at least name the arrows on the figure. My personal preference is to draw the FSM as a grid because this shows up missing state/event combinations far more easily. Is the OpenRetry counter just a substate of OpenWait? The description of OpenRetry is at odds with the error used (1:5). The error says a second unacceptable Open has been received, but the text says that OpenRetry is incremented if the Open is anything except malformed. Can I suggest that the use of a separate state and not a substate would help you resolve this type of issue. LocalOK also looks like a substate. Ditto RemoteOK. Please don't use substates, they are evil! The flip flop between OpenWait and KeepWait caused by these two variables and the negotiation of parameters is ghastly. I think that what the state machine shows us is that we do not need independent Open messages in each direction. Anyway, if we *do* need them, we need correct states to manage them. === 10 If a malformed PCEP message is received or the TCP connection fails, the systems sends a PCEP CLOSE message, the system releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State. This seems to be in contradiction with text in the main body of the draft and with the existence of error code 6. === App A Is this appendix just present to help you track the requirements you still need to satisfy, or do you intend to leave some requirements unanswered? BTW, I don't think this is a full list. Route exclusions is not listed. What are you doing to ensure that the list is complete? === I think Kenji's email address may have changed Same for Jean-Louis _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Nov 20 09:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmA6e-0005bi-7j; Mon, 20 Nov 2006 09:26:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmA6d-0005bZ-OX for pce@ietf.org; Mon, 20 Nov 2006 09:26:43 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmA6b-0001kd-AT for pce@ietf.org; Mon, 20 Nov 2006 09:26:43 -0500 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 1GmA6S-0004Yb-00 for pce@ietf.org; Mon, 20 Nov 2006 14:26:32 +0000 Received: from your029b8cecfe ([217.158.132.15] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 14:26:17 +0000 Message-ID: <001e01c70caf$d581c450$0f849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Mon, 20 Nov 2006 14:24:13 -0000 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: 20 Nov 2006 14:26:17.0955 (UTC) FILETIME=[D79D0330:01C70CAF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Pce] Liaison received from ITU-T SG15 on PCE in ASON 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 have received a new liaison from ITU-T Study Group 15 on recently consented ASON Recommendations. G.7715.2 refers to the applicability of PCE in an ASON environment. The text is below. You can see the liaison at https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=292 No action is required. Adrian === ITU-T SG15 Question 14 (Q14/15) is pleased to inform you of the consent of two ASON documents at the SG15 meeting 30 October - 10 November 2006. Attached for your information are the consented documents: - New Draft Recommendation G.7715.2/Y.1706.2 "ASON routing architecture and requirements for remote route query" - New Draft Amendment 1 to Recommendation G.7715/Y.1706 "Architecture and requirements for routing in the automatically switched optical networks" _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Nov 20 11:15:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBnu-0001v2-Aw; Mon, 20 Nov 2006 11:15:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlxEA-0000BY-Gk; Sun, 19 Nov 2006 19:41:38 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlxEA-00027G-AE; Sun, 19 Nov 2006 19:41:38 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 2965726E0F; Mon, 20 Nov 2006 00:41:38 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GlxEA-0001XP-2N; Sun, 19 Nov 2006 19:41:38 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Adrian Farrel , Deborah Brungard , JP Vasseur From: Greg Jones (ITU-T SG 15) Message-Id: Date: Sun, 19 Nov 2006 19:41:38 -0500 X-Spam-Score: -2.3 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Mon, 20 Nov 2006 11:15:29 -0500 Cc: sjtrowbridge@lucent.com, greg.jones@itu.int, Bill Fenner , hklam@lucent.com, sob@harvard.edu, yoichi.maeda@ntt-at.co.jp, ccamp@ops.ietf.org, pce@ietf.org, Ross Callon , tsbsg15@itu.int Subject: [Pce] New Liaison Statement, "Consented ASON Documents" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsbsg15@itu.int, greg.jones@itu.int List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Title: Consented ASON Documents Submission Date: 2006-11-19 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=292 From: Greg Jones(ITU-T SG 15) To: IETF ccamp and pce WG(Adrian Farrel , Deborah Brungard , JP Vasseur ) Cc: sob@harvard.edu Ross Callon Bill Fenner Alex Zinin yoichi.maeda@ntt-at.co.jp sjtrowbridge@lucent.com ccamp@ops.ietf.org pce@ietf.org Reponse Contact: tsbsg15@itu.int greg.jones@itu.int Technical Contact: hklam@lucent.com Purpose: For information Body: Attachment(s): Consented ASON Documents (https://datatracker.ietf.org/documents/LIAISON/file395.doc) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Nov 21 15:51:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcZs-0002jO-KK; Tue, 21 Nov 2006 15:50:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcZd-0002HX-2G; Tue, 21 Nov 2006 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GmcZb-0002vJ-Nl; Tue, 21 Nov 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 9A7ED2AC1A; Tue, 21 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GmcZ7-0006Tr-CB; Tue, 21 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 21 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-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 : PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : J. Le Roux Filename : draft-ietf-pce-pcecp-interarea-reqs-04.txt Pages : 11 Date : 2006-11-21 For scalability purposes a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered-Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE) based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCC) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-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-pcecp-interarea-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-pcecp-interarea-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-11-21101548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcecp-interarea-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-21101548.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 Wed Nov 22 02:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmmR1-00074v-37; Wed, 22 Nov 2006 02:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmmQz-00074o-KK for pce@ietf.org; Wed, 22 Nov 2006 02:22:17 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmmQx-0002m9-57 for pce@ietf.org; Wed, 22 Nov 2006 02:22:17 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 08:21:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-04.txt Date: Wed, 22 Nov 2006 08:22:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-04.txt Thread-Index: AccNrwAMNpHHjIv7TJWI2rHH8glAhwAVzMVw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Nov 2006 07:21:52.0880 (UTC) FILETIME=[E2126F00:01C70E06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 all, This new version accounts for several comments. Here are the main changes: -The manageability section has been detailed -Added requirement for area inclusion/exclusion -The Area ID recording requirement has been clarified -The PCE list enforcement/recording requirement has been clarified Regards, JL > -----Message d'origine----- > De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Envoy=E9 : mardi 21 novembre 2006 21:50 > =C0 : i-d-announce@ietf.org > Cc : pce@ietf.org > Objet : [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-04.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 Protocol (PCECP)=20 > Specific Requirements for Inter-Area Multi Protocol Label=20 > Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering > Author(s) : J. Le Roux > Filename : draft-ietf-pce-pcecp-interarea-reqs-04.txt > Pages : 11 > Date : 2006-11-21 > =09 > For scalability purposes a network may comprise multiple Interior=20 > Gateway Protocol (IGP) areas. An inter-area Traffic=20 > Engineered-Label=20 > Switched Path (TE-LSP) is an LSP that transits through at=20 > least two=20 > IGP areas. In a multi-area network, topology visibility=20 > remains local=20 > to a given area, and a head-end Label Switching Router=20 > (LSR) cannot=20 > compute an inter-area shortest constrained path. One key=20 > application=20 > of the Path Computation Element (PCE) based architecture is the=20 > computation of inter-area TE-LSP paths. The PCE Communication=20 > Protocol (PCECP) is used to communicate computation requests from=20 > Path Computation Clients (PCC) to PCEs, and to return=20 > computed paths=20 > in responses. This document lists a detailed set of PCECP specific=20 > requirements for support of inter-area TE-LSP path computation. It=20 > complements the generic requirements for a PCE Communication=20 > Protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-inter > area-reqs-04.txt >=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 > 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=20 > "get draft-ietf-pce-pcecp-interarea-reqs-04.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 > 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-pcecp-interarea-reqs-04.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Nov 22 09:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtS9-0000mB-Hf; Wed, 22 Nov 2006 09:51:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtS8-0000lr-Da for pce@ietf.org; Wed, 22 Nov 2006 09:51:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmtS6-0002V6-4C for pce@ietf.org; Wed, 22 Nov 2006 09:51:56 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 06:51:53 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAMEpqNT016405; Wed, 22 Nov 2006 09:51:52 -0500 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 kAMEplYV016661; Wed, 22 Nov 2006 09:51:52 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 09:51:51 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 09:51:50 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26774B45-13E1-4902-A970-021BF0E86CF4@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 22 Nov 2006 09:51:47 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Nov 2006 14:51:50.0967 (UTC) FILETIME=[BE2F9470:01C70E45] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=365; t=1164207112; x=1165071112; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Working=20Group=20Last=20Call=20on=20draft-ietf-pce-pcecp-int erarea-reqs-04.txt=20 |Sender:=20 |To:=20pce@ietf.org; bh=M+/tJfbr2Dx/WMuaIqzc8/01AwR3QsoPhvrx72xTxIU=; b=cOZbdAW/ZSEAqomhbtHadVw+dYjvHs/cyyCzg6qosVibClhYSemXwDVAypwffwTg9UbHu0Rf T8PeK5uo6stnPIt5vmXsZsT58wKTOm9n+FgEUxwTq1szo2tzIXM4e5E7; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Pce] Working Group Last Call on draft-ietf-pce-pcecp-interarea-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 Dear WG, A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev -04) has been posted that addresses the remaining issues/comments. This email initiates a Working Group Last Call on draft-ietf-pce- pcecp-interarea-reqs-04.txt. The last call will end on December 8th at noon EST. Please send your comments to the mailing list. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Nov 22 10:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtbR-0005wz-Vs; Wed, 22 Nov 2006 10:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtbR-0005wT-1p for pce@ietf.org; Wed, 22 Nov 2006 10:01:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmtbO-0003R2-NL for pce@ietf.org; Wed, 22 Nov 2006 10:01:33 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 22 Nov 2006 07:01:30 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kAMF1T94007827; Wed, 22 Nov 2006 07:01:29 -0800 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 kAMF1EOp013360; Wed, 22 Nov 2006 07:01:29 -0800 (PST) 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.1830); Wed, 22 Nov 2006 10:01:23 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 10:01:23 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <1DBE0992-37F6-4306-9CC5-41D200078B8A@cisco.com> From: JP Vasseur Date: Wed, 22 Nov 2006 10:01:18 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Nov 2006 15:01:23.0284 (UTC) FILETIME=[13503940:01C70E47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1625; t=1164207689; x=1165071689; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Feed-back=20on=20new=20WGs=20documents |Sender:=20; bh=aBTpY5NBvhKbMgMHC2x9tZGHWHsMNrk9no2C3RHNYHg=; b=rOS0+u4zm+XOnK+rJpJ1N61hIwz9r9+oQBQu/0Sx+PoRdXnV7XqZ6ajkKEfXYgXOfnQ4IEKi MJELxIKpSVQ32M4zvtkPcx+8Yn0Cgs89wzwLA/PdYRWuQuHjmL323vWw; Authentication-Results: sj-dkim-5; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Pce] Feed-back on new WGs documents 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="===============1662299870==" Errors-To: pce-bounces@lists.ietf.org --===============1662299870== Content-Type: multipart/alternative; boundary=Apple-Mail-84--930599058 --Apple-Mail-84--930599058 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Could you provide us your feed-back on adopting the two following IDs as a WG documents ? draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for Path Computation Element draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for Path Computation Element Discovery Protoocl Note that other MIB-related IDs are expected (e.g. PCEP, ...). JP and Adrian. --Apple-Mail-84--930599058 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Dear = WG,

Could you = provide us your feed-back on adopting the two following IDs as a WG = documents ?

draft-stephan-pce-tc-mib-00 = -=A0Definitions of Textual Conventions for Path Computation = Element

draft-stephan-pce-disc-mib-00 -=A0Definitions of Managed Objects = for Path Computation Element Discovery Protoocl

Note that other MIB-related IDs are expected = (e.g. PCEP, ...).

JP = and Adrian.

= --Apple-Mail-84--930599058-- --===============1662299870== 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 --===============1662299870==-- From pce-bounces@lists.ietf.org Wed Nov 22 10:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmtdr-00071A-1N; Wed, 22 Nov 2006 10:04:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmtdq-000715-6D for pce@ietf.org; Wed, 22 Nov 2006 10:04:02 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmtdl-0003dn-OO for pce@ietf.org; Wed, 22 Nov 2006 10:04:02 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 16:03:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Feed-back on new WGs documents Date: Wed, 22 Nov 2006 16:03:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Feed-back on new WGs documents Thread-Index: AccORyRvYdOfratMQeq2WUYXtCR48gAAC8+w From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 22 Nov 2006 15:03:45.0426 (UTC) FILETIME=[68095F20:01C70E47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: , Content-Type: multipart/mixed; boundary="===============0353239293==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0353239293== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70E47.6CB29830" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70E47.6CB29830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Philippe, al =20 Yes for both drafts =20 Regards, =20 JL ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : mercredi 22 novembre 2006 16:01 =C0 : pce@ietf.org Objet : [Pce] Feed-back on new WGs documents =09 =09 Dear WG, Could you provide us your feed-back on adopting the two following IDs = as a WG documents ? draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for = Path Computation Element draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for Path = Computation Element Discovery Protoocl Note that other MIB-related IDs are expected (e.g. PCEP, ...). JP and Adrian. ------_=_NextPart_001_01C70E47.6CB29830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jean-Philippe, al
 
Yes for both drafts
 
Regards,
 
JL

De : JP Vasseur=20 [mailto:jvasseur@cisco.com]
Envoy=E9 : mercredi 22 = novembre 2006=20 16:01
=C0 : pce@ietf.org
Objet : [Pce] = Feed-back=20 on new WGs documents

Dear=20 WG,

Could you provide us your feed-back = on=20 adopting the two following IDs as a WG documents ?

draft-stephan-pce-tc-mib-00 = - Definitions=20 of Textual Conventions for Path Computation Element

draft-stephan-pce-disc-mib-00=20 - Definitions of Managed Objects for Path Computation Element = Discovery=20 Protoocl

Note that other MIB-related IDs are = expected=20 (e.g. PCEP, ...).

JP and = Adrian.

------_=_NextPart_001_01C70E47.6CB29830-- --===============0353239293== 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 --===============0353239293==-- From pce-bounces@lists.ietf.org Wed Nov 22 10:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmts6-0003uZ-1P; Wed, 22 Nov 2006 10:18:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmts5-0003r3-1v for pce@ietf.org; Wed, 22 Nov 2006 10:18:45 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmtpl-0004jJ-95 for pce@ietf.org; Wed, 22 Nov 2006 10:16:22 -0500 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 kAMFGJSL026499; Wed, 22 Nov 2006 10:16:19 -0500 (EST) 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 KAA08843; Wed, 22 Nov 2006 10:16:19 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Nov 2006 10:16:18 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125E406EB@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" To: JP Vasseur , pce@ietf.org Subject: RE: [Pce] Feed-back on new WGs documents Date: Wed, 22 Nov 2006 10:16:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Content-Type: multipart/mixed; boundary="===============1773969734==" Errors-To: pce-bounces@lists.ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1773969734== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70E49.277BE4A4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C70E49.277BE4A4 Content-Type: text/plain Yes to both... _____ From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Wednesday, November 22, 2006 10:01 AM To: pce@ietf.org Subject: [Pce] Feed-back on new WGs documents Dear WG, Could you provide us your feed-back on adopting the two following IDs as a WG documents ? draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for Path Computation Element draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for Path Computation Element Discovery Protoocl Note that other MIB-related IDs are expected (e.g. PCEP, ...). JP and Adrian. ------_=_NextPart_001_01C70E49.277BE4A4 Content-Type: text/html
Yes to both...

From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Wednesday, November 22, 2006 10:01 AM
To: pce@ietf.org
Subject: [Pce] Feed-back on new WGs documents

Dear WG,

Could you provide us your feed-back on adopting the two following IDs as a WG documents ?

draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for Path Computation Element

draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for Path Computation Element Discovery Protoocl

Note that other MIB-related IDs are expected (e.g. PCEP, ...).

JP and Adrian.

------_=_NextPart_001_01C70E49.277BE4A4-- --===============1773969734== 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 --===============1773969734==-- From pce-bounces@lists.ietf.org Wed Nov 22 11:11:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmuhE-00085S-NL; Wed, 22 Nov 2006 11:11:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmuhD-00085F-TK for pce@ietf.org; Wed, 22 Nov 2006 11:11:35 -0500 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmuhB-00058M-FL for pce@ietf.org; Wed, 22 Nov 2006 11:11:35 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id kAMGBDWx005303; Wed, 22 Nov 2006 17:11:13 +0100 Received: from [172.25.78.192] ([172.25.78.192]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006112217111216:7765 ; Wed, 22 Nov 2006 17:11:12 +0100 Message-ID: <456476A0.4030007@alcatel.fr> Date: Wed, 22 Nov 2006 17:11:12 +0100 From: Emmanuel.Dotaro@alcatel.fr Organization: Alcatel CTO/R&I User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Feed-back on new WGs documents References: <1DBE0992-37F6-4306-9CC5-41D200078B8A@cisco.com> In-Reply-To: <1DBE0992-37F6-4306-9CC5-41D200078B8A@cisco.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/22/2006 17:11:12, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/22/2006 17:11:13, Serialize complete at 11/22/2006 17:11:13 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Emmanuel.Dotaro@alcatel.fr List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359247734==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0359247734== Content-Type: multipart/alternative; boundary="------------040002040702060402010105" This is a multi-part message in MIME format. --------------040002040702060402010105 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed ok for both Emmanuel JP Vasseur wrote: > > Dear WG, > > Could you provide us your feed-back on adopting the two following IDs > as a WG documents ? > > draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for > Path Computation Element > > draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for > Path Computation Element Discovery Protoocl > > Note that other MIB-related IDs are expected (e.g. PCEP, ...). > > JP and Adrian. > > ------------------------------------------------------------------------ > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --------------040002040702060402010105 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1 ok for both

Emmanuel

JP Vasseur wrote:

Dear WG,

Could you provide us your feed-back on adopting the two following IDs as a WG documents ?

draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for Path Computation Element

draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for Path Computation Element Discovery Protoocl

Note that other MIB-related IDs are expected (e.g. PCEP, ...).

JP and Adrian.


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--------------040002040702060402010105-- --===============0359247734== 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 --===============0359247734==-- From pce-bounces@lists.ietf.org Wed Nov 22 12:25:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvqN-000673-8J; Wed, 22 Nov 2006 12:25:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvqL-00066d-Gq for pce@ietf.org; Wed, 22 Nov 2006 12:25:05 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmvqK-0008P9-8k for pce@ietf.org; Wed, 22 Nov 2006 12:25:05 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1164216302!9793606!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23814 invoked from network); 22 Nov 2006 17:25:02 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-146.messagelabs.com with SMTP; 22 Nov 2006 17:25:02 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAMHP1L3017556; Wed, 22 Nov 2006 12:25:02 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAMHOtKL017469; Wed, 22 Nov 2006 12:24:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Feed-back on new WGs documents Date: Wed, 22 Nov 2006 11:24:54 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7FA1@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <1DBE0992-37F6-4306-9CC5-41D200078B8A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Feed-back on new WGs documents Thread-Index: AccOR0TY36mQS5etTZuPliFYUk6RZgAE8XGQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Content-Type: multipart/mixed; boundary="===============1542832654==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1542832654== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70E5B.203E7E62" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70E5B.203E7E62 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yes to both. ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Wednesday, November 22, 2006 10:01 AM To: pce@ietf.org Subject: [Pce] Feed-back on new WGs documents Dear WG, Could you provide us your feed-back on adopting the two following IDs as a WG documents ? draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for Path Computation Element draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for Path Computation Element Discovery Protoocl Note that other MIB-related IDs are expected (e.g. PCEP, ...). JP and Adrian. ------_=_NextPart_001_01C70E5B.203E7E62 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Yes to both.

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: Wednesday, November 22, 2006 10:01 AM
To:=20 pce@ietf.org
Subject: [Pce] Feed-back on new WGs=20 documents

Dear=20 WG,

Could you provide us your feed-back on = adopting=20 the two following IDs as a WG documents ?

draft-stephan-pce-tc-mib-00 = - Definitions=20 of Textual Conventions for Path Computation Element

draft-stephan-pce-disc-mib-00 = - Definitions=20 of Managed Objects for Path Computation Element Discovery Protoocl

Note that other MIB-related IDs are = expected=20 (e.g. PCEP, ...).

JP and Adrian.

------_=_NextPart_001_01C70E5B.203E7E62-- --===============1542832654== 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 --===============1542832654==-- From pce-bounces@lists.ietf.org Wed Nov 22 16:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmznG-0001VR-7P; Wed, 22 Nov 2006 16:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmznE-0001VK-K0 for pce@ietf.org; Wed, 22 Nov 2006 16:38:08 -0500 Received: from [143.209.238.159] (helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmznD-0008E9-AI for pce@ietf.org; Wed, 22 Nov 2006 16:38:08 -0500 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id kAMLc6Ar030635; Wed, 22 Nov 2006 15:38:06 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 22 Nov 2006 15:38:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Feed-back on new WGs documents Date: Wed, 22 Nov 2006 15:38:05 -0600 Message-ID: In-Reply-To: <1DBE0992-37F6-4306-9CC5-41D200078B8A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Feed-back on new WGs documents Thread-Index: AccOSGZT6pjryF+9Q+6DDtuT4eme7gANhKvg From: "DOLGANOW Andrew" To: "JP Vasseur" , X-OriginalArrivalTime: 22 Nov 2006 21:38:06.0060 (UTC) FILETIME=[7EDF9AC0:01C70E7E] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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: , Content-Type: multipart/mixed; boundary="===============2005298184==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2005298184== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70E7E.7E9D38F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70E7E.7E9D38F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes to both =20 Andrew ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Wednesday, November 22, 2006 10:01 AM To: pce@ietf.org Subject: [Pce] Feed-back on new WGs documents =09 =09 Dear WG, Could you provide us your feed-back on adopting the two following IDs as a WG documents ? draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions for Path Computation Element draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for Path Computation Element Discovery Protoocl Note that other MIB-related IDs are expected (e.g. PCEP, ...). JP and Adrian. ------_=_NextPart_001_01C70E7E.7E9D38F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes to both
 
Andrew

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: Wednesday, November 22, 2006 10:01 AM
To:=20 pce@ietf.org
Subject: [Pce] Feed-back on new WGs=20 documents

Dear=20 WG,

Could you provide us your feed-back = on=20 adopting the two following IDs as a WG documents ?

draft-stephan-pce-tc-mib-00 = - Definitions=20 of Textual Conventions for Path Computation Element

draft-stephan-pce-disc-mib-00=20 - Definitions of Managed Objects for Path Computation Element = Discovery=20 Protoocl

Note that other MIB-related IDs are = expected=20 (e.g. PCEP, ...).

JP and = Adrian.

------_=_NextPart_001_01C70E7E.7E9D38F1-- --===============2005298184== 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 --===============2005298184==-- From pce-bounces@lists.ietf.org Mon Nov 27 12:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokRg-0002Ia-Ql; Mon, 27 Nov 2006 12:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokRf-0002HG-Fu for pce@ietf.org; Mon, 27 Nov 2006 12:39:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GokRe-0006g4-32 for pce@ietf.org; Mon, 27 Nov 2006 12:39:07 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2006 09:39:05 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kARHd5eH003077 for ; Mon, 27 Nov 2006 09:39:05 -0800 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 kARHcbdg005872 for ; Mon, 27 Nov 2006 09:39:05 -0800 (PST) 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.1830); Mon, 27 Nov 2006 12:38:53 -0500 Received: from [161.44.71.112] ([161.44.71.112]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 12:38:52 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Mon, 27 Nov 2006 12:38:53 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 Nov 2006 17:38:52.0886 (UTC) FILETIME=[E7C7CF60:01C7124A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1213; t=1164649145; x=1165513145; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20PCE=20Working=20Group=20Minutes=20IETF-67=20available |Sender:=20; bh=RRQ4zfYtpIZRwLHp1mTn+eHmcx8NkUKNts3r2B5VBhY=; b=OvuBQRohlTtFbcfvLoqw+tWEDsuB6SGJyikemFJviMK8nBbwH6GawDf38X5bs9kIJa9VXV+S 4rAU6j5yIVP3m3EyQkTaL1FzthR0JiD4//f4HO0pZRljw49uX6wR6uw/; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Pce] Draft PCE Working Group Minutes IETF-67 available 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="===============0127085237==" Errors-To: pce-bounces@lists.ietf.org --===============0127085237== Content-Type: multipart/alternative; boundary=Apple-Mail-14--489144127 --Apple-Mail-14--489144127 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Draft minutes are available at: http://www3.ietf.org/proceedings/ 06nov/minutes/pce.txt Please provide your comments if any by the end of this week. Thanks. JP and Adrian. --Apple-Mail-14--489144127 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

<= BR class=3D"khtml-block-placeholder">
Please provide your = comments if any by the end of this week.

Thanks.

JP and = Adrian.
= --Apple-Mail-14--489144127-- --===============0127085237== 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 --===============0127085237==-- From pce-bounces@lists.ietf.org Wed Nov 29 03:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKu0-0008S0-8g; Wed, 29 Nov 2006 03:34:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKtz-0008Rv-4I for pce@ietf.org; Wed, 29 Nov 2006 03:34:47 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpKtw-000097-Km for pce@ietf.org; Wed, 29 Nov 2006 03:34:47 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAT8Yi5B025782; Wed, 29 Nov 2006 09:34:44 +0100 In-Reply-To: <26774B45-13E1-4902-A970-021BF0E86CF4@cisco.com> To: JP Vasseur Subject: Re: [Pce] Working Group Last Call on draft-ietf-pce-pcecp-interarea-reqs-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 29 Nov 2006 09:34:38 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/29/2006 09:34:39, Serialize complete at 11/29/2006 09:34: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: f66b12316365a3fe519e75911daf28a8 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 comment on this doc. 4.5. Inclusion of Area IDs in Request The knowledge of the areas in which the source and destination lie would allow selection of appropriate cooperating PCEs. => so is there an assumption that the PCE-Area ID knowledge is available - how come ? A PCE may not be able to determine the location of the source and destination and in such a case it would be useful that a PCC indicates the source and destination area IDs. => not sure to see the reasoning - i guess the initial PCE referred to here is an intermediate PCE that does not have any visibility of the source/destination areas and potentially more - the whole problem in this sentence is the interpretation of the term - location - For that purpose the request message MUST support the inclusion of the source and destination area IDs. Note that this information could be learned by the PCC through configuration. => how to be sure that the local area PCE is going only to be contacted by local area PCC's - we're entering into a chicken egg problem, from one side mandate knowledge of source/destination area but on the other there is no guarantee about interpretation of this information before knowing the PCC - area ID relationship 4.6. Area Inclusion/Exclusion In some situations it may be useful to include one or more area(s) in the path. => for inter-area it is certainly true that the actual path will cross multiple areas but i wonder whether what you mean is not the request includes one or more areas to be followed by the path to be computed It may also be useful to exclude one or more area(s) from the path (e.g. request for a path between LSRs in two stub areas connected to the same ABR(s), which must not cross the backbone area). Hence the request message MUST allow indicating a set of one or more area(s) that must be explicitly included in the path, and a set of one or more area(s) that must be explicitly excluded from the path. => be prepared to incorporate a loop avoidance mechanism, in case the request will have to cross multiple PCEs other comments to follow - d. JP Vasseur 22/11/2006 15:51 To: pce@ietf.org cc: Subject: [Pce] Working Group Last Call on draft-ietf-pce-pcecp-interarea-reqs-04.txt Dear WG, A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev -04) has been posted that addresses the remaining issues/comments. This email initiates a Working Group Last Call on draft-ietf-pce- pcecp-interarea-reqs-04.txt. The last call will end on December 8th at noon EST. Please send your comments to the mailing list. Thanks. JP. _______________________________________________ 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 Nov 29 03:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpL49-0006Fy-6i; Wed, 29 Nov 2006 03:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpL48-0006Fk-6F for pce@ietf.org; Wed, 29 Nov 2006 03:45:16 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpL46-0002Kt-NZ for pce@ietf.org; Wed, 29 Nov 2006 03:45:16 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAT8jGaJ031726; Wed, 29 Nov 2006 09:45:16 +0100 In-Reply-To: <26774B45-13E1-4902-A970-021BF0E86CF4@cisco.com> To: JP Vasseur MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 29 Nov 2006 09:45:09 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/29/2006 09:45:11, Serialize complete at 11/29/2006 09:45:11 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: pce@ietf.org Subject: [Pce] specific comment on draft-ietf-pce-pcecp-interarea-reqs-04.txt - Section 4.7 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 section 4.7 Inter-area Diverse Path computation o) wrt 6. Security Considerations "IGP areas are administrated by the same = entity. .." does the latter ensure uniqueness of the SRLG IDs ? o) The response message MUST allow indicating the level of diversity of=20 a set of computed loose paths.=20 do you mean partial disjointness ? or something equivalent ?=20 o) last sentence =A73 unclear to me wrt to the next sentence - is it=20 referring to a=20 diversity of a given wrt to a set of resources but the next sentence=20 refers to the diversity of a given LSP wrt to a set of other LSPs but also their SRLG=20 set for inst. ? thanks, - d. =20 JP Vasseur 22/11/2006 15:51 =20 To: pce@ietf.org cc:=20 Subject: [Pce] Working Group Last Call on=20 draft-ietf-pce-pcecp-interarea-reqs-04.txt Dear WG, A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev -04) has=20 been posted that addresses the remaining issues/comments. This email initiates a Working Group Last Call on draft-ietf-pce-=20 pcecp-interarea-reqs-04.txt. The last call will end on December 8th=20 at noon EST. Please send your comments to the mailing list. Thanks. JP. =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